DHC WG Internet Draft T. Ogawa Ed. M. Yanagiya M. Ohta Document: draft-ogawa-fhopt-00.txt NTT Expires: Aug. 2005 February 2005 DHCPv6 Options for Fast Handovers Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed,in accordance with RFC 3668. 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 Mobile IP node (MN) changes its wireless network attachment point (performs a handover), it gets new IP layer configuration information (a new network prefix and address of a new default gateway) from a new access router and tries to know whether it has moved to other subnet. If it has, it changes its IP layer configuration. During such a handover process,it cannot send and receive IP packets from its corresponding node(CN), so a service disruption is caused. In this document, we introduce new DHCP options. With them, DHCP servers can send new information before a handover to be used after the handover, and MNscan reduce handover process time. 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 RFC-2119. Most terms used in this draft are defined in RFC3315[2] and RFC3775[3]. Ogawa Expires - August 2005 [Page 1] DHCPv6 Options for Fast Handovers February 2005 AP: network attachment point. If the network interface is a wireless LAN, it is the same as an access point. MN: Mobile node. MN is the same as DHCP client in this document. Previous domain: a DHCP-domain that the MN is attaching before handover. New domain: a DHCP-domain that the MN is attaching after handover. Domain-APs: APs in a DHCP-domain. Neighbor-AP: APs physically neighboring to an AP. Table of Contents 1. Introduction...................................................2 2. New functions..................................................3 3. Protocol details...............................................4 3.1 DHCP Fast Handover Options exchange...........................4 3.2 DHCP Fast Handover Options format.............................7 4. Security Considerations.......................................13 5. IANA Consideration............................................13 6. References....................................................13 1. Introduction When a standard Mobile IP node (MN) changes its wireless network attachment point (performs a handover), it cannot send and receive IP packets from its corresponding node (CN) during a handover process. A handover process consists of the following six processes. (1) The MN detects an L2 disconnection between it and a current network attachment point (AP), and searches for other APs, then sets-up a new L2 connection between it and a new AP. (2) The MN gets a new network prefix and address of a new default gateway by RA from a new access router (AR). (3) If the M flag of the RA is set, it requests its new IP address from DHCP servers. (4) The MN tries NUD of an old AR to detect L3 movement. (5) The MN tries DAD of new IP addresses (NCoAs). (6) The MN sends a NCoA BU to its HA. In IETF, Fast handovers for Mobile IP (FMIP)[4] are to be standardized soon as experimental RFC. It reduces the handover processes (2), (3), and (4) by sending interface-IDs of candidate attachment points and associated new IP layer information to an MN from a previous AR before a handover. The MN can detect network movement without NUD and configure new IP layer parameters by exchanging neither RS/RA nor DHCP messages with a network. With great effort of many researchers, the protocol design of FMIP is to be completed. However, authors think there are the following issues to apply current FMIP to real networks. (a) With FMIP, all AR must be equipped with the FMIP function, and every AR must be able to exchange FMIP messages with neighboring AR. Ogawa Expires - August 2005 [Page 2] DHCPv6 Options for Fast Handovers February 2005 Therefore, in case an operator plans to offer seamless handover service in a wide area, the number of facilities to be upgraded may be numerous, and connectivity between a pair of different venders and kinds of ARs shall be assured. The authors insist that the fewer facilities to be upgraded the better, and less correlation between facilities is better. (b) With FMIP, FBU messages (introduced in FMIP), as well as MIP BU messages, MUST be authenticated by MN and AR to prevent service from being stolen. However, with FMIP, MNs exchange messages with ARs, which change every handover, so it is necessary to set up a security association between an MN and a new AR every handover without an increase in handover time. However, there is no standard method yet for doing this. (c) If the address policy of a link is stateful, an AR sets the M flag of the RA, and plain IP nodes get IP addresses from a DHCP server if the M flag of the received RA was set. With FMIP, a new stateful IP address to be used after handover is distributed by PrRtAdv (introduced in FMIP). We insist that a unified method is better. (d) In case wireless LAN is used, the L2 handover time may be a few hundred milliseconds or more. However there is no function to reduce the L2 processing time in FMIP. In this document, new DHCP options (Fast Handover Options) and their protocol is defined; the main functions of this protocol are ported from FMIP and some new functions are added. Based on existing DHCP, issues (a), (b), and (c) mentioned above are solved as below. (a) In this protocol, only DHCP servers must be upgraded, but not ARs, and no message exchange between network facilities is needed for Fast Handover. (b) In this protocol, no handover message between the MN and new DHCP server is exchanged during the handover process. MNs can set up a security association (SA) between a new DHCP server after handover, so the set-up time does not cause serious problems. (The SA set-up method between the MN and DHCP server is out of the scope of this document.) (c) In this protocol, stateful IP address is managed only in DHCP servers but not in ARs. Furthermore, in issue (d), this protocol transmits "L2 information" (e.g., in the case of 802.11, valid channel numbers) and helps MNs reduce L2 handover time. This document defines "L2 information" for 802.11, but "L2 information" for other media is out of the scope of this document. Interruption time during DAD needs to be reduced, but that is also out of the scope of this document, Opt-DAD[5] may be applied. For packet-loss-sensitive applications, packet loss free handover may be required, but that is also out of the scope of this document. Tunnel buffering [6] may be applied. There are many user authentication methods, for example, 802.1X, pana and how to reduce the user authentication time during a handover is to be standardized but is also out of the scope of this document. Ogawa Expires - August 2005 [Page 3] DHCPv6 Options for Fast Handovers February 2005 2. New functions This document defines new DHCP options (Fast Handover Options), and with these options, the following 5 functions are achieved. Functions (A), (B) and (C) are almost the same as FMIP, but (D) and (E) are new functions that FMIP does not offer. (A) RA proxying function Fast Handover Options carry information to MNs on old links, which are to be carried by standard RAs (prefix, router's IP address, link-layer address) on new links, and MNs do not need to exchange RS/RA messages on new links. (B) DHCP proxying function Fast Handover Options also carry information to MNs on old links, which are to be carried by the standard DHCP IA option (stateful IP address) on new links, and MNs can reduce the number of DHCP confirm/reply exchanges on new links. (C) Movement detection function Fast Handover Options also carry new AP's ID (e.g., BSSID) to MNs on old links, and MNs can detect movement without using NUD on a new link. (D) Layer 2 information distribution function Fast Handover Options also carry new link information, for example, channel number used by new APs, and MNs can search for the notified channel only instead of all channels and can reduce layer 2 handover time. (E) Confirm Message solicit function A unique ID for DHCP-domains is introduced. Fast Handover Information Options carry IDs for the DHCP-domains, and a MN can know whether it has entered a new DHCP-domain after handover. If the MN is still in the same DHCP-domain, it does not need to send a confirm Message to a DHCP server on a new link. 3. Protocol details 3.1 DHCP Fast Handover Options exchange Fast Handover Options are composed of six new DHCP options: Fast Handover Information Request Option, Previous AP ID Option, New AP ID Option, Fast Handover Information Replay Option, Layer 2 Information Option, and Layer 3 Information Option. The Fast Handover Information Request Option is sent by MNs, and the Fast Handover Information Reply Option is sent by DHCP servers. The previous AP ID and New AP ID options are used in the Fast Handover Information Request Option. The Layer 2 information and Layer 3 Information Options are used in Fast Handover Information Reply Option. Ogawa Expires - August 2005 [Page 4] DHCPv6 Options for Fast Handovers February 2005 To get the Fast Handover Information Reply Option, the MN sends a Fast handover Information Request Option in DHCP messages. If a DHCP server receives a DHCP message including a Fast Handover Information Request Option, it replies with the Fast Handover Reply Option in the Reply Message. When a MN is rebooted, or it attaches to a network for the first time, it sends a Request Message or Request Information Message including the Fast Handover Request Option. It MUST NOT send Solicit Messages including the Fast Handover Information Request Option. To confirm information that is to be used on neighbor links, the MN sends a Confirmation Message including a Fast Handover Information Request Option. To extend the valid and preferred lifetimes for addresses that are to be used on neighbor links associated with IAs, MNs send Renew or Rebind massages including the Fast Handover request option including IA options. To release one or more addresses that are to be used on neighbor links, the MN sends Release massages including the Fast Handover Information Request Option that has IA options. It is noted that if the addresses are distributed with Fast Handover Information Reply Option from a DHCP server, and not for the current link but for a neighboring link, the MN MUST NOT send Renew, Rebind nor Release Messages including IA options for addresses on neighboring links that are not included in the Fast Handover Information Request Option. The MN does not send Decline Messages including a Fast Handover Request Option. If the addresses distributed with the Fast Handover Information Reply Option are invalid on a new link as a result of DAD[7] or Opt-DAD[5], the MN MUST send Decline Messages including IA options but not including the Fast Handover Information Request Option on that link. The MN MUST NOT send Reconfigure Messages including Fast Handover information request option. The Fast Handover Information Request Option MUST include a Previous AP ID option, and one or more IA options. The fast handover Information Request Option may include other options. The previous AP ID option includes the unique AP-ID of the current AP to which the MN is attaching. In case the network interface is a wireless LAN, the BSSID of the access point is used as the AP-ID. The new AP ID option is used if the MN knows the next AP's ID to be handed over. If New AP ID information is in the fast handover Information Option, the DHCP server replies the AP's information that is distinguished by the AP-ID in the New AP ID option. Ogawa Expires - August 2005 [Page 5] DHCPv6 Options for Fast Handovers February 2005 It is noted that if the current link's address policy, which the MN is attaching to, is stateful or not, the Fast Handover Information Request Option MUST include one or more IA options because the neighboring links' policy may be stateful. A DHCP server manages all APs' information in DHCP-domains that it controls (Domain-APs) and the information of APs physically next to those APs(neighbor-APs). To distinguish each AP and each DHCP-domain, a unique ID in the DHCP server is assigned to the AP and DHCP-domain. It is noted that some APs near the border of a DHCP-domain, may be managed by some DHCP servers, and the AP-ID of such an AP depends on DHCP servers. The DHCP server replies to the MN sending all AP information that belongs to the same DHCP-domain as the AP distinguished by the AP-ID in the Previous AP ID option. The DHCP servers send Fast Handover Information Option to the MN in response to the Fast Handover Information Request Option. If the Fast Handover Information Request Option does not include Next AP ID option, the Fast Handover Information Option includes Layer 2 Information Options and Layer 3 Information Options of all APs in the previous domain and neighbor-APs. It is noted that Layer 3 information options are as many as links that the APs are attaching and if multiple APs are attaching to a link, they are less than Layer 2 Information Options. If the Fast Handover Information Request Option includes a Next AP ID option, the Fast Handover Information Option includes Layer 2 Information Options and Layer 3 Information Options of the AP in the Next AP ID option. The layer 2 Information Option includes an AP-ID, the AP's DHCP-domain- ID, its neighboring AP's AP-IDs, and a Layer 3-information-ID, and its other layer 2 information (in the case of 802.11, channel number and ESSID) In the case of 802.11, when the MN tries to connect to neighboring APs, it does not need to search all channels just available channels shown in the layer 2 information. After the MN attaches to a new AP, with information in the Layer 3 Information Option described below, it evaluates whether it has moved to new link or not, and configures its IP layer settings (e.g., network prefix and IP address) Furthermore, it compares the new AP's DHCP-domain-ID with that of the previous AP, and determines whether it should send a Confirm Message. If the DHCP-domain-IDs differ and are not "xFFFFFFFF" the MN MUST send a Confirm Message containing the IA option or other options. Ogawa Expires - August 2005 [Page 6] DHCPv6 Options for Fast Handovers February 2005 If the new DHCP-domain-ID is "xFFFFFFFF" the MN MUST sends a Solicit Message. The Layer 3 Information Option includes prefix relative information (prefix, gateway router's IP address, and MAC address) and IA information available on a link. The layer 3 Information Option may contain multiple prefix information. If the address policy of the link is stateless, the Layer 3 Information Option MUST NOT include IA options. If the address policy of the link is stateful, the Layer 3 Information Option MUST include IA options. 3.2 DHCP Fast Handover Options format This section defines the DHCP Fast Handover Options format. The format is based on DHCPv6[2] and differences are clearly noted below 3.2.1 Fast Handover Information Request Option The Fast Handover Information Request Option is used to request Fast Handover Information Option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FHO_REQ | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FHO_REQ-options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_FHO_REQ(tbd). option-len Length of FHO_REQ-options field. FHO_REQ-options Options associated with this FHO_REQ The FHO_REQ-options field encapsulates those options that are specific to this FHO_REQ. It MUST contain one Previous AP ID option and one or more IA options defined in RFC3315, and may contain a New AP ID option and other DHCP options. Ogawa Expires - August 2005 [Page 7] DHCPv6 Options for Fast Handovers February 2005 3.2.2 Fast Handover Information Reply Option The Fast Handover Information Reply Option is used to reply to the Fast Handover Information Request Option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FHO_REL | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FHO_REL-options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_FHO_REL(tbd). option-len length of Status Code Option field + length of FHO_REL-options field. Status Status Code Option Status field encapsulates Status Code Option defined in RFC3315. If the Status Code is not Success, the MN MUST ignore the following field. FHO_REL-options options associated with this FHO_REL FHO_REL-options field encapsulates those options that are specific to this FHO_REL. It MUST contain one or more Layer 2 Information Options, and one or more Layer 3 Information Options. 3.2.3 Previous AP ID option The Previous AP ID option is used in the Fast Handover Information Request Option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FHO_Previous_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP- protocol | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_FHO_Previous_ID (tbd). option-len 2 + length of ID. Ogawa Expires - August 2005 [Page 8] DHCPv6 Options for Fast Handovers February 2005 AP-protocol 1.Wireless LAN 802.11b 2.Wireless LAN 802.11g 3.Wireless LAN 802.11a ID MAC address of the AP. If the AP-protocol is 1, 2, or 3, BSSID is used. 3.2.4 New AP ID option The New AP ID option is used in the Fast Handover Information Request Option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FHO_New_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP- protocol | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_FHO_New_ID (tbd). option-len 2 + length of ID. AP-protocol 1.Wireless LAN 802.11b 2.Wireless LAN 802.11g 3.Wireless LAN 802.11a ID MAC address of the AP. If AP-protocol is 1, 2, or 3, BSSID is used. Ogawa Expires - August 2005 [Page 9] DHCPv6 Options for Fast Handovers February 2005 3.2.5 Layer 2 Information Option The Layer 2 Information Option carries Layer 2 information associated with an AP and is used in the Fast Handover Information Reply Option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FHO_L2_INFO | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP-ID | L3-information-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHCP-domain-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | neighbor-AP-number | neighbor-AP-ID-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | neighbor-AP-ID-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP-type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | info (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_FHO_L2_INFO(tbd). option-len 12 + length of 2 * neighbor-AP-number + length of info. AP-ID Unique ID of the AP. "0" is reserved. L3-information-ID This number indicates associated Layer 3 Information Option. The same number is also set in associated Layer 3 Information Option. If the DHCP does not know Layer 3 information about the AP, "(0x0000)" is set. DHCP-domain-ID Unique ID of the DHCP-domain that the AP belongs to. "0"is reserved. If the DHCP-domain is not managed by the DHCP server, "(0xffffffff)" is set. neighbor-AP-number Number of neighbor-APs of the AP. neighbor-AP-ID AP-ID of the neighbor-APs. (As many as the neighbor-AP-number). AP-protocol 1.Wireless LAN 802.11b 2.Wireless LAN 802.11g 3.Wireless LAN 802.11a info information associated with AP-protocol Ogawa Expires - August 2005 [Page 10] DHCPv6 Options for Fast Handovers February 2005 If AP-type is 1, 2, or 3, the info field is defined as below. Authentication algorithms other than open system are to be discushed. 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 (6 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ch | ESSID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESSID(variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authtication-algorithm-number | auth-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | auth-data(variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BSSID BSSID of the AP. ch channel number. ESSID-Length Length of ESSID (octets) ESSID See section 7.3.2.1 "Service Set Identity (SSID) element" of 802.11. authentication-algorithm-number See section 7.3.1.1 Authentication Algorithm Number field of 802.11. 0: open system authentication. auth-len Length of auth-data associated with authentication-algorithm-number (octets). If authentication-algorithm-number is 0, auth-len is 0. auth-data Authentication data associated with authentication-algorithm-number. If authentication-algorithm-number is 0, auth-data does not exist. Ogawa Expires - August 2005 [Page 11] DHCPv6 Options for Fast Handovers February 2005 3.2.6 Layer3 Information Option The layer 3 Information Option carries Layer 3 information associated with a link and is used in the Fast Handover Information Reply Option. If the link has multiple prefixes, multiple sets of GW-MAC-address to IA-data fields appear in this option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FHO_L3_INFO | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L3-information-ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | GW-MAC-address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | GW-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-length | | +-+-+-+-+-+-+-+-+ IPv6 prefix | | (16 octets) | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |I| Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IA-data(variable length) | ================================================================= | GW-MAC-address | | o | | o | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA-data(variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_FHO_L3_INFO(tbd). option-len 42 + length of IA-data. L3-information-ID This number associates the Layer 2 Information Option with the Layer 3 Information Option. The same number is also set in the associated Layer 2 Information Option. "(0x0000)" is reserved in this field. Ogawa Expires - August 2005 [Page 12] DHCPv6 Options for Fast Handovers February 2005 GW-MAC-address Gateway router's MAC address (6 byte) GW-address Gateway router's IP address (16 byte) prefix-length bits IPv6 prefix 16 byte I 1:IA-data exists after the flag 0:No IA-data exists. Reserved 0 IA-data IA_NA options and/or IA_TA options The IA-data field encapsulates IA_NA options and/or IA_TA options that are associated with the IA options in the FHO_REQ-options field in the Fast Handover Information Request Option. 4. Security Considerations Secure delivery of Fast Handover information from a DHCP server to a mobile node (DHCP client) relies on overall DHCP security. The particular option defined in this draft does not have an additional impact on the DHCP security. The DHCP authentication mechanism MUST 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 is to be standardized but is also out of the scope of this document. 5. IANA Consideration This document introduces six new DHCPv6 options. The type numbers for these new DHCP 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., Bound, J., Volz, B., Lemon, T., Perkins, C., and Carney M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [3] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in IPv6", RFC3775, Jun. 2004. Ogawa Expires - August 2005 [Page 13] DHCPv6 Options for Fast Handovers February 2005 Informative References [4] Koodli, R., Editor, "Fast Handovers for Mobile IPv6", draft-ietf- mipshop-fast-mipv6-03.txt, October 2004. [5] Moore, N., "Optimistic Duplicate Address Detection for IPv6", draft-moore-mobopts-tunnel-buffering-00.txt, December 2004. [6] Moore, N., "Tunnel Buffering for Mobile IPv6", draft-ietf-ipv6- optimistic-dad-03.txt, July 2004. [7] Narten, T. et al, "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998. Acknowledgments We thank Shingo Horisawa, Masayuki Arai and Nick Moore for their discussions and significant contribution to this draft. Authors' Addresses Takeshi Ogawa, Mayumi Yanagiya, Masazumi Ohta 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 Mayumi.yanagiya@lab.ntt.co.jp Masazumi.ohta@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 icense 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 - August 2005 [Page 14] DHCPv6 Options for Fast Handovers February 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 - August 2005 [Page 15]