Mobile IPv4 Working Group Rajeev Koodli INTERNET DRAFT Charles E. Perkins 23 October 2006 Nokia Research Center Mobile IPv4 Fast Handovers draft-ietf-mip4-fmipv4-02.txt 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a submission of the IETF MIP4 WG. Comments should be directed to the MIP6 WG mailing list, mip4@ietf.org. Abstract The Mobile IPv6 fast handover document [2] specifies a protocol to improve latency and packet loss resulting from Mobile IPv6 handover operations. This document adapts the protocol for IPv4 networks to improve performance over Mobile IPv4 operations, including processing of Agent Advertisements, new Care of Address acquisition and Registration Request and Reply. Using the concepts outlined in [2], this document also addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration, the document currently proposes that the new CoA is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. Koodli, Perkins Expires 23 April 2007 [Page i]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 Contents Abstract i 1. Introduction 2 2. Factors Affecting Handover 2 3. Protocol Operation 3 3.1. Basic NCoA Support . . . . . . . . . . . . . . . . . . . 4 3.2. Assigned Addressing Support . . . . . . . . . . . . . . . 5 4. Use of Previous FA Notification Extension 5 5. Message Formats 5 5.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 5 5.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 7 5.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 8 5.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . 10 5.5. Inter-Access Router Messages . . . . . . . . . . . . . . 12 5.5.1. Handover Initiate (HI) . . . . . . . . . . . . . 12 5.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . 13 6. Option formats 15 6.1. Link-Layer Address Option Format . . . . . . . . . . . . 15 6.2. New IPv4 Address Option Format . . . . . . . . . . . . . 16 6.3. New Router Prefix Information Option . . . . . . . . . . 16 7. Security Considerations 17 8. IANA Considerations 18 Intellectual Property Statement 18 Disclaimer of Validity 19 Copyright Statement 19 Acknowledgment 19 Koodli, Perkins Expires 23 April 2007 [Page 1]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 1. Introduction This document adapts the fast handover specification [2] to IPv4 networks. The fast handover protocol specified in this document is particularly interesting for operation on commonly available wireless links such as IEEE 802.11 WLAN links. Fast handovers are not typically needed for wired media due to the relatively large delays attributable to establishing new connections in today's wired networks. Mobile IPv4 registration messages are re-used (with new type numbers) to enable quick implementation using existing foreign agent software. This draft does not rely on link-layer triggers for protocol operation, but performance will typically be enhanced by using the appropriate triggers when they are available. The active agents that enable continued packet delivery to a mobile node are the access routers on the networks that the mobile node connects to. Handover means that the mobile node changes its network connection, and we consider the scenario in which this change means change in access routers. The mobile node utilizes the access routers as default routers in the normal sense, but also as partners in mobility management. Thus, when the mobile node moves to a new network, it processes handover-related signaling in order to identify and develop a relationship with a new access router. In this document, we call the previous access router PAR and the new access router NAR. Unless otherwise mentioned, a PAR is also a Previous FA (PFA) and a NAR is also a New FA (NFA). On a particular network, the MN may obtain its IP address via DHCP (i.e., CCoA) or use the Foreign Agent CoA. During a handover, the new CoA is always made to be that of NAR. This allows a MN to receive and send packets using its previous CoA, so that delays resulting from IP configuration (such as DHCP address acquisition delay) subsequent to attaching to the new link are disengaged from affecting the existing sessions. 2. Factors Affecting Handover Both the link-layer operations and IP layer procedures affect the perceived handover performance. However, the overall performance is also (always) a function of specific implementation of the technology as well as the system configuration. This document only specifies IP layer protocol operations. The purpose of this section is to provide an illustration of events that affect handover performance, but it is purely informative. The IP layer handover delay and packet loss are influenced by latencies due to movement detection, IP address configuration and Mobile IP registration procedure. Movement detection latency comes Koodli, Perkins Expires 23 April 2007 [Page 2]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 from the need to reliably detect movement to a new subnet. This is a function of frequency of router advertisements as well as default agent reachability. IP address configuration latency depends on the particular IP CoA being used. If co-located mode with DHCP is used, the latency is quite likely going to be higher and unacceptable for real-time applications such as Voice over IP. Finally, the Mobile IP registration procedure needs a round-trip of delay between the Mobile Node and its Home Agent over the Internet. This delay is incurred after the Mobile Node performs movement detection and IP configuration. Underlying the IP operations are link-layer procedures. These are clearly technology-specific. For instance, in IEEE 802.11b which is also known as WLAN, the handover operation may involve scanning access points over all available channels, selecting a suitable access point and associating with it. It may also involve performing access control operations such as those specified in IEEE 802.1X. These delays contribute to the handover performance. Optimizations have been proposed and are being standardized in IEEE however. Together with appropriate implementation techniques, these optimizations can provide the required level of delay support for real-time applications. 3. Protocol Operation The design of the protocol is the same as for Mobile IPv6 [2]. Readers should consult [2] for details, and here we provide a summary. The protocol avoids the delay due to movement detection and IP configuration and disengage Mobile IP registration delay from the time-critical path. The protocol provides the surrounding network network neighborhood information so that a Mobile Node can determine whether it is moving to a new subnet even before the handover. The information provided and the signaling exchange between the local mobility agents allows the Mobile Node to send and receive packets immediately after handover. In order to disengage the Mobile IP registration latency, the protocol provides routing support for the continued use of a Mobile Node's previous CoA. After a MN obtains its IPv4 care-of address, it builds a neighborhood access point and subnet map using the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement messages. The MN may scan for access points (APs) based on the configuration policy in operation for its wireless network interface. If a scan results in a new AP discovery, the MN resolves the AP-ID to subnet information using the messages defined below. Koodli, Perkins Expires 23 April 2007 [Page 3]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 The coordination between the access routers is done by way of the Handover Initiate (HI) and Handover Acknowledge (HAck) messages. After these signals have been exchanged between the previous and new access routers (PAR and NAR), data arriving at PAR will be tunneled to NAR for delivery to the newly arrived mobile node. The purpose of HI is to securely deliver the routing parameters for establishing this tunnel. The tunnel is created by the access routers in response to the delivery of the FBU from the mobile node. We consider three scenarios. First, the access routers are not involved in IP address assignment for the MN not any more than, e.g., being a DHCP Relay when DHCP is being used. Second, an access router acts as a foreign agent, using the same IP address for use by a multiplicity of mobile nodes. In this scenario, an access router provides its own IP address for the MN to use upon connecting to the new link. Third, an access router may allocate an IP address to a visiting mobile node by some means not specified in this document. Just as a simple example, an access router may maintain a pool of IPv4 addresses for temporary use by visiting mobile nodes. The protocol semantics are almost identical in all scenarios. The packet formats presented in RFC 3344 are re-used to achieve maximum compatibility with Mobile IP. 3.1. Basic NCoA Support In response to a handover trigger or indication, the MN sends a Fast Binding Update message to Previous Access Router (PAR) (see Section 5.1). This message should be sent when the MN is still connected to PAR. When sent in this ``predictive'' mode, the ``Home Address'' field must be the PCoA, which can be either the Home Address (in FA CoA mode) or the co-located CoA. The Home Agent field, even though redundant, must be set to PAR's IP address, and the Care-of Address field must be the NAR's IP address discovered via PrRtAdv message. The destination IP address of the FBU message must be PAR's IP address. The source IP address of FBU message must contain the PCoA (in co-located mode) or the Home Address (in FA CoA mode) or NAR's IP address (when NAR forwards the message to PAR). When attachment to a new link is detected, FBU should be (re)sent. When sent in this ``reactive'' mode, the destination address must be NAR's IP address, and the source address must be either Home Address (FA CoA mode) or PCoA (in co-located mode) the from the FBU message. The Home Agent field must be set to PAR's IP address. When NAR receives FBU, it may already have processed the HI message and created a host route entry for the PCoA. In that case, NAR can immediately forward arriving and buffered packets including the FBAck Koodli, Perkins Expires 23 April 2007 [Page 4]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 message. In any case, NAR MUST forward the contents of this message, starting from the Type field, to PAR. The Handover Initiate (HI) and Handover Acknowledge (HAck) messages serve to establish a bidirectional tunnel between the routers to support packet forwarding for PCoA. The tunnel itself is established as a response to the FBU message. The PAR sends HI message with Code = 0 when it receives FBU with source IP address set to PCoA. The PAR sends HI with Code = 1 when it receives FBU with source IP address not set to PCoA (i.e., when received from NAR). This allows NAR to disambiguate HI message processing sent as a response to predictive and reactive modes of operation. 3.2. Assigned Addressing Support In this mode, the NAR provides NCoA, which is delivered to the MN in the FBAck message either on the previous link or on the new link. Since the MN is unaware of the address that NAR might assign, it always binds its PCoA to NAR's address. This results in a bidirectional tunnel between PAR and NAR. The source IP address in FBU is PCoA regardless of the link it is sent from. The destination address is either PAR's IP address or the NAR's IP address depending on the link from which FBU is sent. The FBAck message MUST include a NCoA extension. The NAR MUST provide NCoA in the HAck message. The NAR MUST also include the extension when responding to FBU sent from the new link. 4. Use of Previous FA Notification Extension Sending FBU from the new link (i.e., reactive mode) is similar to using the extension defined in [3]. However, with the neighborhood information gathered using the proxy router messages (see Section 5.3, Section 5.4), movement detection and router discovery delays are avoided even in the reactive case. The FBU and FBAck messages defined in this document can be naturally used even when no neighborhood information is available. 5. Message Formats 5.1. Fast Binding Update (FBU) The FBU format is bitwise identical to the Registration Request format in RFC 3344. The same destination port number, 434, is used, Koodli, Perkins Expires 23 April 2007 [Page 5]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 but the FBU and FBAck messages in this specification have new message type numbers. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Figure 1: Fast Binding Update (FBU) Message IP fields: Source address The interface address from which the message is sent. Either PCoA (co-located mode), or Home Address (FA CoA mode) or NAR's IP address (when forwarded from NAR to PAR). Destination Address The IP address of the Previous Access Router or the New Access Router. Source Port variable Destination port 434 (TBA) Type To be assigned by IANA Flags See RFC 3344 Koodli, Perkins Expires 23 April 2007 [Page 6]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 Lifetime The number of seconds remaining before binding expires. MUST NOT exceed 10 seconds. Home Address MUST be PCoA or the MN's Home Address Home Agent The Previous Access Router's global IP address Care-of Address The New Access Router's global IP address Identification See RFC 3344 Extensions MUST contain the MN - PAR Authentication Extension 5.2. Fast Binding Acknowledgment (FBAck) The FBAck format is bitwise identical to the Registration Reply format in [4]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Figure 2: Fast Binding Acknowledgment (FBAck) Message Koodli, Perkins Expires 23 April 2007 [Page 7]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 IP fields: Source address Typically copied from the destination address of the FBU message Destination Address Copied from the Source IP address in FBU message Source Port variable Destination port copied from thr source port in FBU message Type To be assigned by IANA Code Indicates the result of processing FBU message. Code = 0 means Fast Binding Update accepted. Code = 1 means Fast Binding Update accepted but NCoA is supplied as an extension. Lifetime The number of seconds remaining before binding expires. MUST NOT exceed 10 seconds. Home Address PCoA or MN's Home Address Home Agent The Previous Access Router's global IP address Identification a 64-bit number used for matching FBU. See RFC 3344. Extensions The PAR - MN Authentication extension MUST be present. In addition, a NCoA option MUST be present when NAR supplies the NCoA. If the FBAck message indicates that the new care-of address is a Foreign Agent care-of address [4], then the mobile node MUST set the 'D' bit in its Registration Request message that it uses to register the NCoA with its home agent. 5.3. Router Solicitation for Proxy Advertisement (RtSolPr) Mobile Nodes send Router Solicitation for Proxy Advertisement in order to prompt routers for Proxy Router Advertisements. All the link-layer address options have the format defined in 6.1. The Koodli, Perkins Expires 23 April 2007 [Page 8]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 message format and processing rules are identical to that defined in [2]. We only provide the format here for convenience. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 3: Router Solicitation for Proxy (RtSolPr) Message IP Fields: Source Address An IP address assigned to the sending interface Destination Address The address of the Access Router or the all routers multicast address. Time-to-Live At least 1. See RFC 1256. ICMP Fields: Type To be assigned by IANA Code 0 Checksum The ICMP checksum. See RFC 1256 Subtype To be assigned by IANA Reserved MUST be set to zero by the sender and ignored by the receiver. Identifier MUST be set by the sender so that replies can be matched to this Solicitation. Valid Options: Koodli, Perkins Expires 23 April 2007 [Page 9]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 New Access Point Link-layer Address The link-layer address or identification of the access point for which the MN requests routing advertisement information. It MUST be included in all RtSolPr messages. More than one such address or identifier can be present. This field can also be a wildcard address with all bits set to zero. 5.4. Proxy Router Advertisement (PrRtAdv) Access routers send out Proxy Router Advertisement message gratuitously if the handover is network-initiated or as a response to RtSolPr message from a MN, providing the link-layer address, IP address and subnet prefixes of neighboring routers. All the link-layer address options have the format defined in 6.1. The message format and processing rules are identical to that defined in [2]. We only provide the format here for convenience. The ICMP checksum is defined in [1]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 4: Proxy Router Advertisement (PrRtAdv) Message IP Fields: Source Address An IP address assigned to the sending interface Destination Address The Source Address of an invoking Router Solicitation for Proxy Advertisement or the address of the node the Access Router is instructing to Koodli, Perkins Expires 23 April 2007 [Page 10]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 handover. Time-to-Live At least 1. See RFC 1256. ICMP Fields: Type To be assigned by IANA Code 0, 1, 2, 3 or 4. See below. Checksum The ICMP checksum. See RFC 1256. Subtype To be assigned by IANA. Reserved MUST be set to zero by the sender and ignored by the receiver. Identifier Copied from Router Solicitation for Proxy Advertisement or set to Zero if unsolicited. Valid Options in the following order: New Access Point Link-layer Address The link-layer address or identification of the access point is copied from RtSolPr message. This option MUST be present. New Router's Link-layer Address The link-layer address of the Access Router for which this message is proxied for. This option MUST be included when Code is 0 or 1. New Router's IP Address The IP address of NAR. This option MUST be included when Code is 0 or 1. New Router Prefix Information Option The number of leading bits that define the network number of the corresponding Router's IP Address option (see above). New CoA Option MAY be present when PrRtAdv is sent unsolicited. PAR MAY compute new CoA using NAR's prefix information and the MN's L2 address, or by any other means. Koodli, Perkins Expires 23 April 2007 [Page 11]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 5.5. Inter-Access Router Messages 5.5.1. Handover Initiate (HI) The Handover Initiate (HI) is an ICMP message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a MN's handover. The message format and processing rules are identical to that defined in [2]. We only provide the format here for convenience. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype |S|U| Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 5: Handover Initiate (HI) Message IP Fields: Source Address The IP address of the PAR Destination Address The IP address of the NAR Time-to-Live At least 1. See RFC 1256. ICMP Fields: Type To be assigned by IANA Code 0 or 1. See below Checksum The ICMP checksum. See RFC 1256 Subtype To be assigned by IANA Koodli, Perkins Expires 23 April 2007 [Page 12]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 S Assigned address configuration flag. When set, this message requests a new CoA to be returned by the destination. May be set when Code = 0. MUST be 0 when Code = 1. U Buffer flag. When set, the destination SHOULD buffer any packets towards the node indicated in the options of this message. Used when Code = 0, SHOULD be set to 0 when Code = 1. Reserved MUST be set to zero by the sender and ignored by the receiver. Identifier MUST be set by the sender so replies can be matched to this message. Valid Options: Link-layer address of MN The link-layer address of the MN that is undergoing handover to the destination (i.e., NAR). This option MUST be included so that the destination can recognize the MN. Previous Care of Address The IP address used by the MN while attached to the originating router. This option SHOULD be included so that host route can be established in case necessary. New Care of Address The IP address the MN wishes to use when connected to the destination. When the `S' bit is set, NAR MAY assign this address. 5.5.2. Handover Acknowledge (HAck) The Handover Acknowledgment message is a new ICMP message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate (HI) (see section 5.5.1) message. The message format and processing rules are identical to that defined in [2]. We only provide the format here for convenience. IP Fields: Koodli, Perkins Expires 23 April 2007 [Page 13]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 6: Handover Acknowledge (HAck) Message Source Address Copied from the destination address of the Handover Initiate Message to which this message is a response. Destination Address Copied from the source address of the Handover Initiate Message to which this message is a response. Time-to-Live At least 1. See RFC 1256. ICMP Fields: Type To be assigned by IANA Code 0: Handover Accepted, NCoA valid 1: Handover Accepted, NCoA not valid 2: Handover Accepted, NCoA in use 3: Handover Accepted, NCoA assigned (used in Assigned addressing) 4: Handover Accepted, NCoA not assigned (used in Assigned addressing) 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources Checksum The ICMP checksum. See RFC 1256. Subtype To be assigned by IANA. Koodli, Perkins Expires 23 April 2007 [Page 14]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 Reserved MUST be set to zero by the sender and ignored by the receiver. Identifier Copied from the corresponding field in the Handover Initiate message this message is in response to. Valid Options: New Care of Address If the S flag in the Handover Initiate message is set, this option MUST be used to provide NCoA the MN should use when connected to this router. This option MAY be included even when `S' bit is not set, e.g., Code 2 above. 6. Option formats The options in this section are specified as optional extensions for the HI and HAck messages, as well as for the Router Proxy Solicitation and Router Proxy Advertisement messages.. 6.1. Link-Layer Address Option Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Link-Layer Address Option Format Fields: Type 1 Mobile Node Link-layer Address 2 New Access Point Link-layer Address 3 NAR Link-layer Address Length The length of the option (including the type and length fields) in units of octets. For example, the length for IEEE 802 addresses is 1 [IPv6- Koodli, Perkins Expires 23 April 2007 [Page 15]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 ETHER]. Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) depends on the specific link-layer in use. 6.2. New IPv4 Address Option Format This option is used to provide the new router's IPv4 address in PrRtAdv. When it is also used to provide NCoA, it MUST appear after the new router's IPv4 address to distinguish the two addresses. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: New IPv4 Address Option Format Fields: Type To be assigned by IANA Length The length of the option (including the type and length fields) in units of octets. Reserved Set to zero. NCoA The New CoA assigned by NAR. 6.3. New Router Prefix Information Option This option is the same as the ``Prefix-Lengths Extension'' in RFC 3344 (Section 2.1.2). Koodli, Perkins Expires 23 April 2007 [Page 16]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix-Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: New Router Prefix Information Option Format Fields: Type To be assigned by IANA Length 1 Prefix-Length The number of leading bits that define the network number of the corresponding Router's IP Address option. Reserved Set to zero. 7. Security Considerations The FBU and FBack messages MUST be protected using a security association shared between a MN and its access router. In particular, the MN - PAR Authentication Extension MUST be present in each of these messages. Failure to include this extension can lead to a bogus node claiming a genuine MN's address and binding it to an arbitrary address. When the NCoA is NAR's address, there is no risk of a genuine MN misdirecting traffic, either inadvertantly or intentionally, to an unsuspecting node on NAR's subnet. When NCoA is other than NAR's address, NAR MUST ensure that the proposed NCoA in HI is conflict-free, and MUST indicate the disposition in the HAck message. If there is a conflict, PAR MUST NOT tunnel packets to the address in question. Instead, PAR SHOULD tunnel packets to the address specified in HAck, if any is provided. Koodli, Perkins Expires 23 April 2007 [Page 17]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 8. IANA Considerations All the messages and the option formats specified in this document require Type assignment from IANA. References [1] S. Deering. ICMP Router Discovery Messages. Request for Comments (Proposed Standard) 1256, Internet Engineering Task Force, September 1991. [2] R. Koodli (Editor). Fast Handovers for Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mipshop-fast-mipv6-03.txt, October 2005. [3] C. Perkins and D. Johnson. Route Optimization in Mobile IP (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-optim-09.txt, February 2000. [4] C. Perkins (Editor). IP Mobility Support for IPv4. Request for Comments (Proposed Standard) 3344, Internet Engineering Task Force, August 2002. Questions about this memo can be directed to the authors: Rajeev Koodli Charles E. Perkins Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2986 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an Koodli, Perkins Expires 23 April 2007 [Page 18]
Internet Draft Fast Handovers for Mobile IPv4 23 October 2006 attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koodli, Perkins Expires 23 April 2007 [Page 19]
