Internet DRAFT - draft-ogawa-mobopts-dhcpv4-fho

draft-ogawa-mobopts-dhcpv4-fho





   MobOpts WG                                                           
   Internet Draft                                              T. Ogawa 
   Document: draft-ogawa-mobopts-dhcpv4-fho-00.txt                  NTT 
   Expires: Jan. 2006                                         July 2005 
    
    
                      DHCPv4 Extensions and Option for Fast Handovers  
    
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/1id-abstracts.html 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 
    
    
Abstract 
    
   When a standard IPv4 node (mobile node: MN) changes its wireless 
   network attachment point (performs a handover), it gets new IP layer 
   configuration information (e.g., its new IP address and the addresses 
   of new routers) from a DHCP server and changes its IP layer 
   configuration. During such a handover process, it cannot send or 
   receive IP packets to/from its corresponding node (CN), so a service 
   disruption is caused. In this document, we introduce new DHCPv4 
   extensions and an option (Fast Handover Option) for fast handovers. 
   This protocol is ported from "DHCPv6 options for Fast Handovers" [6]. 
   It enables DHCP servers to send new configuration information to MNs 
   before a handover to be used after the handover, so MNs can have 
   shorter handover processing times. It is noted that DHCP servers and 
   MNs implementing this protocol can achieve fast handovers with 
   standard IPv4 routers without any other micro-mobility management 
   protocols. 
     
 
 
Ogawa                   Expires - January 2006                [Page 1] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
    
    
Conventions used in this document 
    
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this  
   document are to be interpreted as described in RFC2119 [1]. Most 
   terms used in this draft are defined in RFC2131 [2] and RFC2132 [3]. 
     
    
    
    This document uses the following terms. 
      
      o MN 
       Mobile Node. MN is the same as a DHCP client in this document.  
    
      o CN 
        Corresponding Node. A node with which an MN is communicating. 
    
      o DHCP-domain 
        A group of subnets that a DHCP server can manage, and for which 
        an MN can use the same configuration except for subnet mask, 
        router address, MN's IP address, and some subnet-specific 
        options. 
    
      o Previous domain 
        The DHCP-domain to which the MN was attached before a handover.  
    
      o New domain 
        The DHCP-domain to which the MN is attached after a handover.  
    
      o D-LABEL 
        Unique number of a DHCP-domain in a DHCP server. 
    
      o AP 
        Attachment point of the network. If the network interface is a  
        wireless LAN, it is the same as an access point.  
    
      o AP-ID 
        Unique ID of an AP. 
    
      o AP-LABEL 
       Unique number of an AP in a DHCP server.  
    
      o Domain-Aps 
        APs in a DHCP-domain. 
    
      o Neighbor-Aps 
 
 
Ogawa                   Expires - January 2006                [Page 2] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
        APs physically neighboring an AP. 
    
      o L-LABEL 
        A unique number of a link (subnet) in a DHCP server that is used 
        to associate an AP Information Sub-option and a Link Information 
        Sub-option.  
    
      o Original DHCP server 
        A DHCP server that sent the fast handover options that the MN 
        is using. 
    
Table of Contents 
      1. Introduction..................................................3  
      2. New Functions.................................................4  
      3. Protocol Details..............................................5  
      3.1 DHCPv4 Fast Handover Extensions..............................5  
      3.2 Format of DHCP Fast Handover Option..........................9  
      4. Security Considerations......................................14 
      5. IANA Considerations..........................................14  
      6. References...................................................14 
    
    
1. Introduction  
  
  When a standard IPv4 node (mobile node: MN) changes its wireless 
  network attachment point (AP) (performs a handover), it cannot send 
  and receive IP packets to/from its corresponding node (CN) during the 
  handover process. Typically, a handover process consists of the 
  following processes [2] and takes more than ten seconds.  
  
  (1) The MN detects a Layer-2 disconnection between itself and the 
      current (AP), searches for other APs, and sets up a new Layer-2 
      connection between itself and a new AP.  
  (2) The MN detects a link-up and waits for a random time between one 
      and ten seconds and then sends a DHCPREQUEST message that 
      includes the previously allocated IP address to all DHCP servers.  
  (3) The DHCP servers respond to the DHCPNACK message by rejecting the 
      address (in this case, the MN is assumed to have moved to another 
      subnet). 
  (4) The MN waits for more than ten seconds and sends a DHCPDISCOVER 
      message. 
  (5) The DHCP servers respond with DHCPOFFER messages. 
  (6) The MN receives one or more DHCPOFFER messages from the DHCP 
      servers including offers of new IP addresses and it selects one 
      server. 

 
 
Ogawa                   Expires - January 2006                [Page 3] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
  (7) The MN sends a DHCPREQUEST message to the selected server, and 
      the server replies with a DHCPACK message including other 
      configuration information. 
  (8) The MN sends an ARP message for duplicated address detection 
      (DAD) of new IP addresses. 
  
  In IETF, Fast Handovers for Mobile IPv6 (FMIPv6)[4] are to be 
  standardized soon as an experimental RFC, and the Fast Handovers for 
  Mobile IPv4 (FMIPv4)[5] protocol ported from FMIPv6 has been proposed 
  as an individual draft. It reduces the handover time from steps (2) 
  to (6) above by sending new configuration information to an MN from a 
  previous access router (AR) before a handover. However, with FMIPv4, 
  all ARs must be equipped with the FMIP function, and every AR must be 
  able to exchange FMIPv4 messages with neighboring ARs.  
  
  In this document, new DHCPv4 extensions and an option (Fast Handover 
  Option) are defined for fast handovers. This protocol is ported from 
  "DHCPv6 options for Fast Handovers" [6]. It is noted that DHCP 
  servers and MNs implementing this protocol can reduce the process 
  time of steps (1) to (7) with standard IPv4 routers without any other 
  micro-mobility management protocols. Step (8) needs to be reduced, 
  but that is out of the scope of this document. One idea is to apply 
  Opt-DAD [7] for IPv6. There are many user authentication methods, for 
  example, we think that 802.1X, pana, and how to reduce the user 
  authentication time during a handover are worth standardizing, but 
  these are also out of the scope of this document. To enable an MN to 
  continue communication with its corresponding nodes (CNs) after a 
  handover, some kind of macro-mobility management protocol, for 
  example, mobile IP v4 [8] or SIP [9] is required. 
 
  
2. New Functions    
  
  This document introduces four new functions. 
 
  (1) AP information distribution function  
     The Fast Handover Option carries AP information about the new link. 
     For example, if the candidate new APs use a wireless LAN, MNs can 
     know the channel numbers used by the APs before the handover. 
     During a handover, MNs only need to search for the notified 
     channels instead of all channels, which can reduce the layer-2 
     handover time.  
 
 
 
Ogawa                   Expires - January 2006                [Page 4] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
 
  (2) Fast network movement detection function  
     The Fast Handover Option also carries lists of the IDs of 
     candidate new APs (e.g., BSSID) and corresponding new access 
     router's (NAR's) IP address to the MN on the old link. When the MN 
     connects to one of the APs, it searches for its ID in the list and 
     discovers to which subnet it has moved. 
 
  (3) Fast IP address assigning function 
     The Fast Handover Option also carries the candidate new DHCP 
     server's server identifier (IP address). When the MN moves to a 
     new link, it sends a DHCPREQUEST message including the 
     corresponding DHCP server identifier via the corresponding NAR as 
     soon as it detects the link-up. The DHCP server replies with a 
     DHCPACK message including the MN's new IP address and other 
     configuration information. 
 
  (4) DHCP proxying function  
     If the IP address-pool of the new DHCP server is large and the 
     original DHCP server can assign candidate new IP addresses to the 
     MNs before the handover, this DHCP proxying function is useful to 
     reduce the number of DHCP messages during a handover. 
     This function also enables the Fast Handover Option to carry an 
     MN's candidate new IP addresses and unique numbers for DHCP-
     domains (see "Conventions used in this document"), and an MN can 
     know whether it has entered a new DHCP-domain upon link-up. If the 
     DHCP proxying function is used and the MN is still in the same 
     DHCP-domain, it does not need to send DHCP messages to the new 
     DHCP server.  
  
  
3. Protocol Details   
 
3.1 DHCPv4 Fast Handover Extensions  
 
  This section defines DHCPv4 extensions for fast handovers. They are 
  based on DHCP [2] and differences are noted below. 
 
  DHCPREQUEST, DHCPLELEASE, and DHCPACK messages may include the Fast 
  Handover Option, but other messages MUST NOT include the Fast 
  Handover Option. 
 
 
 
 
Ogawa                   Expires - January 2006                [Page 5] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
 
 
  Table 4 of [2] MUST be changed to the following Tables 1 and 2. 

 
  +--------------+------------+-------------+-------------+------------+ 
  |              |INIT-REBOOT |SELECTING    |BOUND to     | RENEWING to| 
  |              |            |             |   RENEWING  |  REBINDING | 
  +--------------+------------+-------------+-------------+------------+ 
  |broad/unicast |broadcast   |broadcast    |unicast      |broadcast   | 
  |server-ip     |MUST NOT    |MUST         |MUST NOT     |MUST NOT    | 
  |requested-ip  |MUST        |MUST         |MUST NOT     |MUST NOT    | 
  |ciaddr        |zero        |zero         |IP address   |IP address  | 
  +--------------+------------+-------------+-------------+------------+ 
 
              Table 1: Client messages from different states 
 
 
              +-------------------------------------------+ 
              |              | BOUND, RENEWING and REBIND | 
              |              |      to REQUESTING         |  
              +--------------+----------------------------+ 
              |broad/unicast |unicast                     | 
              |server-ip     |MUST                        | 
              |requested-ip  |MAY                         | 
              |ciaddr        |zero                        | 
              +--------------+----------------------------+ 
 
              Table 2: Client messages from different states 
 
 
 
 3.1.1 Initial exchange of DHCPREQUEST and DHCPACK 
 
  If an MN detects a link-up for the first time (when it is booted, 
  rebooted, or attached to a network for the first time), it enters the 
  INIT state or SELECTING state [2], and it MUST send a DHCPREQUEST 
  message including a First Handover option, and it enters the 
  REBOOTING state or REQUESTING state, respectively. The Fast Handover 
  option MUST include the Previous AP-ID. If the MN knows the new AP's 
  ID before handover, it MAY add the New AP-ID in the First Handover 
  option. 
 
 
 
Ogawa                   Expires - January 2006                [Page 6] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
  If a DHCP server receives a DHCPREQUEST message that includes a 
  Previous AP-ID, it replies with DHCPACK messages including Fast 
  Handover options. Information carried in the options depend on the 
  new AP-ID in the DHCPREQUEST message.   
 
   o If the DHCPREQUEST message includes new AP-ID, the DHCPACK message 
      includes two AP Information Sub-options, and one or two Link 
      Information Sub-options corresponding to the APs specified by the 
      Previous AP-ID and new AP-ID. 
   o If the DHCPREQUEST message does not include new AP-ID, the DHCPACK 
      message includes as many AP Information Sub-options as the number 
      of APs in the DHCP-domain to which the MN is attached and as many 
      Link Information Sub-options as the number of subnets in the 
      DHCP-domain. 
 
  An AP Information Sub-option MUST include an AP's Layer-2 protocol 
  code and Layer-2-dependent information (e.g., channel number) and the 
  AP's neighbor-AP's AP-LABEL, and an unique number of a subnet (L-
  LABEL) to which the AP is attached. 
  A Link Information Sub-option MUST include the following information 
  about a subnet: an L-LABEL, an unique number of a DHCP-domain (D-
  LABEL) that includes the subnet, new DHCP server's identifier, yiaddr 
  (clients IP address), a subnet mask, and the routers' IP addresses. 
  The Sub-option MAY encapsulate subnet specific other options defined 
  [3] requested by the MN. 
  If the DHCP server cannot offer the new DHCP server's IP address to 
  the MN, the new DHCP server's identifier MUST be set to "0xffffffff". 
  If the DHCP server cannot assign an IP address to the MN, the yiaddr 
  MUST be set to "0". 
  If an MN in the REBOOTING or REQUESTING state accepts the DHCPACK, it 
  records the leases of all IP addresses offered by the DHCPACK, sets 
  their timers T1 and T2, and enters the BOUND state.   
 
 
 3.1.2 Handover 
 
  In the BOUND, RENEWING, and REBINDING states, MNs MUST watch the 
  Layer-2 state, and if the MN decides to perform a handover, it looks 
  up the AP Information Sub-option corresponding to the current AP and 
  get information about the AP's neighboring APs. If the neighboring 
  APs use a wireless LAN, the MN searches for only the notified channel 
  instead of for all channels. The interface between Layer 2 and DHCP 
  in the MN is out of the scope of this document. 
 
 
Ogawa                   Expires - January 2006                [Page 7] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
 
  If the MN detects a Layer-2 handover, it gets the AP-ID of the AP to 
  which the MN is attached from its Layer 2.  
  The MN searches the AP Information Sub-options received before the 
  handover, gets the L-LABEL corresponding to the AP-ID, looks up the 
  Link Information Sub-option corresponding to the L-LABEL, and gets 
  the new DHCP server's identifier and its new configuration. 
  If the new DHCP server's identifier is "ffffffff", the MN MUST enter 
  the INIT state immediately.  
  If the new DHCP server's identifier is not "ffffffff", it MUST do one 
  of following process. 
    o If the L-LABEL is the same as the previous L-LABEL, this means 
      that the MN is still in the same subnet, so it MUST NOT change 
      the configuration. 
 
    o If the L-LABEL is not the same as the previous L-LABEL and the 
     yiaddr in the sub-option is not "0" and the D-LABEL in the sub-
     option is the same as the previous D-LABEL, the MN checks on the 
     yiaddr (e.g., ARP for allocated IP address) offered by the 
     original DHCP server. If the yiaddr is invalid in the new subnet, 
     the MN MUST send a DHCPDECLINE Message to the original DHCP server 
     and enter the INIT state. If the address is valid, it MUST use the 
     configuration information in the Fast Handover Option (yiaddr, 
     subnet mask, routers address and some configuration information 
     specific to the subnet). 
 
   o Otherwise, the MN MUST send a DHCPREQUEST unicast message 
     including siaddr (server identifier) notified by the Link 
     Information Sub-option and a Fast Handover option including the 
     Previous AP-ID (ID of the AP to which the MN is now attached). The 
     message MAY include the requested IP address option notified by 
     the Link Information Sub-option as yiaddr. Then, the MN  enters 
     the REQUESTING state. 
 
  It is defined in [2] that: "(If the MN is in the INIT-REBOOT state), 
  the client (MN) SHOULD wait (sending a DHCPREQUEST message) for a 
  random time between one and ten seconds to desynchronize the use of 
  DHCP at startup". However, in this case, if the MN is sure that the 
  link-up was not caused by the failure of the previous AP, or by the 
  power-on operation of the new AP, and the probability of message 
  synchronization is small, then the MN SHOULD send the DHCPREQUEST 
  message immediately. 
 
 
 
Ogawa                   Expires - January 2006                [Page 8] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
 
 3.1.3 Releasing and renewing 
 
  To release or renew addresses offered by the Fast Handover Option 
  from a server, the MN MUST send DHCPRELEASE or DHCPRENEW unicast 
  messages including a Fast Handover Information Request Option to the 
  original DHCP server.  
 
 
 3.1.4 Rebinding 
 
  To Rebind addresses offered by the Fast Handover Option, the MN sends 
  a DHCPREBIND broadcast message including a Fast Handover Information 
  Option. The option MUST include the Previous AP-ID and MAY include 
  the New AP-ID. 
 

 
3.2 Format of DHCP Fast Handover Option  
    
  This section defines the format of the DHCP Fast Handover Option and 
  its sub-options. The format is based on DHCPv4 [2], [3] and 
  differences are clearly noted below.  
 
 
 3.2.1 Fast Handover Option 
 
  A Fast Handover Option sent by an MN MUST encapsulate one Previous AP 
  ID Sub-option and may encapsulate a New AP ID Sub-option.  
  A Fast Handover Option sent by a server MUST encapsulate an AP 
  Information Sub-option or a Link Information Sub-option. 
 
    Code   Len        Sub-options 
   +-----+-----+-----+-----+-----+-----+ 
   | tbd |  n  | ... 
   +-----+-----+-----+-----+-----+-----+ 
 
 
 
 
 
 
 
 
 
Ogawa                   Expires - January 2006                [Page 9] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
 3.2.2 Previous AP ID Sub-option (FHO-Previous_AP-ID)  
 
  The Previous AP ID Sub-option is used in the Fast Handover Option.  
 
  Sub-code Len Value  AP-ID 
   +-----+-----+-----+-----+-----+-----+ 
   | tbd |  n  |  a  | ... 
   +-----+-----+-----+-----+-----+-----+ 
 
   Value a              1. Wireless LAN 802.11b  
                        2. Wireless LAN 802.11g  
                        3. Wireless LAN 802.11a  
                        (1 octet) 
     
   AP-ID                If the Value a is 1, 2, or 3, BSSID is used.  
                        (variable length) 
     
     
 3.2.3 New AP ID Sub-option (FHO-New_AP-ID) 
     
   The New AP ID Sub-option is used in the Fast Handover option.  
 
 
  Sub-code Len Value AP-ID 
   +-----+-----+-----+-----+-----+-----+ 
   | tbd |  n  |  a  | ...              
   +-----+-----+-----+-----+-----+-----+ 
     
   Value a               1. Wireless LAN 802.11b  
                         2. Wireless LAN 802.11g  
                         3. Wireless LAN 802.11a  
                         (1 octet) 
   
   
   AP-ID                 If the Value a is 1, 2, or 3, BSSID is used.  
                         (variable length) 
 
 
 
 
 
 
    
 
 
Ogawa                   Expires - January 2006               [Page 10] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
 3.2.4 AP Information Sub-option  
     
  The AP Information Sub-option carries AP Information associated  
  with an AP and is used in the Fast Handover Option.  
 
 
  Sub-code Len AP-LABEL L-LABEL  Value neighbor-AP-LABEL  Value info 
   +-----+-----+--------+--------+-----+-----+-----+-----+-----+---- 
   | tbd |  n  |AP-LABEL|L-LABEL |  b  | L1  | L2  | ... |  a  |... 
   +-----+-----+--------+--------+-----+-----+-----+-----+-----+---- 
     
   AP-LABEL             Unique number in a DHCP-domain of the AP. "0" is 
                        reserved. 
                        (1 octet) 
  
     
   L-LABEL              This number indicates associated Layer-3  
                        Information Sub-option. The same number is also  
                        set in the associated Link Information Sub-
                        option.  
                        If the DHCP does not know Link Information  
                        about the AP, "(0x00)" is set.  
                        (1 octet) 
     
  
     
   Value b (neighbor-AP-number) 
                        Number of neighbor-APs of the AP.  
                        (1 octet) 
 
     
   Neighbor- AP-LABEL   AP-LABELs of the neighbor-APs.   
                        (as many as the number of neighbor-APs).      
                        (1 octet) 
  
   Value a              1. Wireless LAN 802.11b  
                        2. Wireless LAN 802.11g  
                        3. Wireless LAN 802.11a       
                        (1 octet) 
     
   info                 AP-ID and other information associated with the 
                        "Value a". 
                        (variable length)    
 
 
Ogawa                   Expires - January 2006               [Page 11] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
   If the "Value a" is 1, 2, or 3, the info field is defined as below.  
   Authentication algorithms other than open system ones are to be 
  discussed.   
     
     0                   1                   2                   3  
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |                             BSSID                             |  
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |                               |      ch       |  ESSID-Length |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |                    ESSID (variable length)                    |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    | auth-algorithm-number         |           auth-len            |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |   auth-data(variable length)  |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
     
   BSSID                BSSID of the AP. (AP-ID)  
                       (6 octets) 
     
   ch                   channel number.  
                        (1 octet) 
 
     
   ESSID-Length         Length of ESSID (octets)  
    
   ESSID                See section 7.3.2.1 "Service Set Identity  
                        (SSID) element" of 802.11.  
                        (variable length)  
     
   auth-algorithm-number   
                        See section 7.3.1.1 Authentication Algorithm  
                        Number field of 802.11.  
                        0: open system authentication.  
                        (2 octets) 
  
     
   auth-len             Length of auth-data associated with  
                        authentication-algorithm-number (octets).  
                        If authentication-algorithm-number is 0,  
                        then auth-len is 0.  
                        (2 octets) 
 
 
Ogawa                   Expires - January 2006               [Page 12] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
   auth-data            Authentication data associated with  
                        authentication-algorithm-number.  
                        If authentication-algorithm-number is 0,  
                        auth-data does not exist.  
                        (variable length) 
 
 
 
 3.2.5 Link Information Sub-option  
     
  The Link Information Sub-option carries Link Information associated  
  with a link and is used in the Fast Handover Option.  
  It MUST encapsulate the subnet mask option and the router option in 
  [3]. It MAY encapsulate other subnet-specific options defined in [3] 
  requested by MN. 
     
Sub-code Len  L-LABEL  D-LABEL     siaddr       yiaddr         options 
  +----+-----+--------+--------+---+---+---+---+---+---+---+---+-----+-- 
  |tbd |  n  | L-LABEL|D-LABEL | a1| a2| a3| a4| a1| a2| a3| a4|... 
  +----+-----+--------+--------+---+---+---+---+---+---+---+---+-----+-- 
    
 L-LABEL                This number associates the AP Information  
                        Sub-option with the Link Information Sub-option. 
                        The same number is also set in the associated 
                        Layer-2 Information Sub-option. "(0x00)" is 
                        reserved in this field.  
                        (1 octet) 
  
  D-LABEL               Unique number of the DHCP-domain to which the AP 
                        belongs.  
                        "0" is reserved. If the DHCP-domain is not 
                        managed by the DHCP server, then "(0xff)" is  
                        set.   
                        (1 octet) 
 
 
  siaddr                New server IP address on this link.  
                        If the original DHCP server cannot offer the 
                        address, then               "(0xffffffff)" is 
                        set. 
                        (4 octets) 
                         
 
 
 
Ogawa                   Expires - January 2006               [Page 13] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
  yiaddr                client IP address on this link.  
                        If the DHCP server cannot offer the address, 
                        then "0" is set.                                              
                        (1 octet) 
  
 
4. Security Considerations  
     
   Secure delivery of Fast Handover information from a DHCP  
   server to a (DHCP client) relies on overall DHCP  
   security. The option defined in this draft does not have  
   an additional impact on DHCP security. The DHCP authentication  
   mechanism shall be used when the operator seeks authentication of the  
   requestor and the information source (DHCP server).  
   There are many user authentication methods, for example, 802.1x, pana,  
   and how to reduce the user authentication time during a handover are  
   to be standardized, but these are also out of the scope of this 
   document.  
  
     
  
5. IANA Considerations  
  
   This document introduces a new DHCPv4 option and some sub-options.  
   The type numbers for these new options are currently TBD.  
   An appropriate request will be made to IANA if this Internet draft  
   gets accepted as an RFC.  
  
     
6. References  
 
  Normative References  
  
   [1] Bradner S., "Key words for use in RFCs to Indicate Requirement  
       Levels," BCP 14, RFC 2119, March 1997.  
   [2] Droms R., "Dynamic Host Configuration Protocol," RFC 2131, Mar. 
       1997.  
   [3] Alexander S., et al., "DHCP Options and BOOTP Vendor Extensions," 
       RFC 2132, 
       Mar. 1997.  
 
 
 
 
 
Ogawa                   Expires - January 2006               [Page 14] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
 Informative References  
  
   [4] Koodli R., Editor, "Fast Handovers for Mobile IPv6," draft-ietf- 
       mipshop-fast-mipv6-03.txt, Oct. 2004.  
   [5] Koodli R., et. al., "Adapting Mobile IPv6 Fast Handovers for 
       IPv4," draft-koodli-fmipv4-00.txt, Oct. 2004. 
   [6] Ogawa T., et. al., "DHCPv6 Options for Fast Handovers,"  
       draft-ogawa-fhopt-00.txt, Feb. 2005. 
   [7] N. Moore, et al., "Optimistic Duplicate Address Detection for 
       IPv6," draft-ietf-ipv6-optimistic-dad-03.txt, December 2004. 
   [8] C. Perkins, et al., "IP Mobility Support for IPv4," RFC 3344, 
       August 2002.  
   [9] M. Handley, et al., "SIP: Session Initiation Protocol," IETF RFC 
       3261, June 2002. 
 
 
Author's Addresses  
     
    Takeshi Ogawa  
    NTT Network Systems Laboratories, NTT Corporation   
    9-11 Midori-Cho 3-Chome   
    Musashino-Shi, Tokyo 180-8585, Japan   
       
    Phone: +81 422 59 4053   
    Email: ogawa.takeshi@lab.ntt.co.jp       
     
 
Intellectual Property Statement  
     
     
   The IETF takes no position regarding the validity or scope of any  
   intellectual property or other rights that might be claimed to  
   pertain to the implementation or use of the technology described in  
   this document or the extent to which any license under such rights  
   might or might not be available; neither does it represent that it  
   has made any effort to identify any such rights. Information on the  
   IETF's procedures with respect to rights in standards-track and  
   standards-related documentation can be found in BCP-11. Copies of  
   claims of rights made available for publication and any assurances of  
   licenses to be made available, or the result of an attempt made to  
   obtain a general license or permission for the use of such  
   proprietary rights by implementors or users of this specification can  
   be obtained from the IETF Secretariat.   
 
 
Ogawa                   Expires - January 2006               [Page 15] 
                  DHCPv6 Options for Fast Handovers         July 2005 
 
 
   The IETF invites any interested party to bring to its attention  
   any copyrights, patents or patent applications, or other proprietary  
   rights which may cover technology that may be required to practice  
   this standard. Please address the information to the IETF Executive  
   Director.  
     
 
Full Copyright Statement  
     
     
   Copyright (C) The Internet Society (2005). This document is subject  
   to the rights, licenses and restrictions contained in BCP 78, and  
   except as set forth therein, the authors retain all their rights.  
     
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
                      
     























 
 
Ogawa                   Expires - January 2006               [Page 16]