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]