Personal G. Tsirtsis Editor A. Yegin C. Perkins G. Dommety K. El-Malki M. Khalil Internet Draft Title: draft-ietf-mobileip-fast-mipv6-01.txt Category: Informational April 2001 Expires : September 2001 Fast Handovers for Mobile IPv6 Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document specifies protocol enhancements to MIPv6 that enable mobile nodes to more quickly become connected at new points of attachment to the Internet. These protocol enhancements are intended to minimize the time during which the mobile node is unable to send or receive IPv6 packets (i.e., the handover latency). Design Team 1 Internet Draft Fast Handovers for MIPv6 April 2001 1. Introduction In this draft we not to consider scenarios in which the handover cannot be initiated until the mobile node has layer-2 connectivity to the new access router, since these are covered by the base Mobile IPv6 Specification [MIPv6]. In scenarios which the handover can be initiated while the mobile node still has layer-2 connectivity at the previous access router, another design decision has been taken. Since this specification deals with layer-3 issues, the handover is considered to require some layer three information relevant to the new access router. Specifically, the handover at layer 3 requires a new care-of-address on the new link, as well as prefix lifetime information and possibly other link parameters typically advertised by the new access router. In parallel the acquisition of this new care-of-address should be performed in away that a duplicate or invalid address can not be picked and in the rare case that it does the system to be able to recover gracefully. Situations where the mobile node would be expected to acquire this information from advertisements from the new access router while still maintaining link layer connectivity with the previous access router are excluded from consideration in this specification. Otherwise, the protocol would actually become a special case of again the base MIPv6 specification. Other Assumptions: - An access router MUST be able to derive the IP address of a neighboring access router from the link layer address of an access point attached to it. The mechanism used for this resolution is outside the scope of this specification. - In Network Determined handover the network is expected to get indication that the mobile node is about to move and in some cases may be able to move the mobile node to the new access router. - Expectation of movement should precede actual movement so that the mobile has enough time to exchange Router Solicitation for Proxy, Proxy Router Advertisement and possibly Fast Binding Update and Fast Binding Acknowledgement messages with the old access router. The extend of the expectation will vary and while this protocol can benefit from extended expectation, such expectation is not required. In fact the protocol will work to its limit even if the mobile node moves immediately after it sends the Fast Binding Update (without receiving the Fast Binding Acknowledgement). Good results, however, will also be seen even if the mobile node moves as soon as it sends a Router Solicitation for Proxy (for the mobile determined handover) or if it moves just after it receives the Proxy Router Advertisement (for the network determined handover) since this bypasses DAD at the new access router. - The mobile node is expected to receive a L2 trigger when it attaches to the new access router. When MN detects this new attachment, it can send either a standard Neighbor Advertisement if Design Team 2 Internet Draft Fast Handovers for MIPv6 April 2001 it has already received the Fast Binding Acknowledgement or a Fast Neighbor Advertisement if it has not. Additionally, a similar (but optional) trigger on the access router side may allow newAR to detect the arrival of a mobile node, therefore change neighbor cache state to REACHABLE without waiting for a Neighbor Advertisement or Fast Neighbor Advertisement. 2. Protocol Overview The aim of this protocol is to enable the mobile node to configure a new care-of-address before it moves to a new access router in a way that can use this new care-of-address immediately at connection with new access router. The areas of preparation are new care-of-address configuration, Duplicate Addressing avoidance and Neighbor Discovery. This proposal described here applies both to networks in which the network determines that a handover will take place and to networks in which the mobile determines that a handover will take place. The model also preserves the Mobile IP characteristic of having the mobile making the ultimate determination of whether traffic destined to it is diverted to its new point of attachment. Fast handover is implemented by adding a number of new messages implemented between access routers and between an access router and a mobile node. An access router is the last router between the network and the mobile node. From the point of view of an upcoming handover, the old Access Router (oldAR) is the router to which the mobile node is currently attached (mobile's default router) and the new Access Router (newAR) is the router to which the mobile node is about to move. The following messages are used in this specification and are defined in detail in later sections together with a number of new options: - Router Solicitation for Proxy (RtSolPr) - MN to oldAR - Proxy Router Advertisement (PrRtAdv) - oldAR to MN - Handover Initiate (HI) - oldAR to newAR - Handover Acknowledgement (HAck) - newAR to oldAR - Fast Binding Update (F-BU) - from the MN to the oldAR - Fast Binding Acknowledgement (F-BACK) - from the oldAR to the MN - Fast Neighbor Advertisement (F-NA) - from MN to newAR The behavior of the entities involved in the exchange are described as follows. Design Team 3 Internet Draft Fast Handovers for MIPv6 April 2001 To initiate a fast handover the mobile node sends a Router Solicitation for Proxy to the old access router indicating that it desires to implement a fast handover to a new attachment point. The Router Solicitation Proxy contains some form of identifier to indicate the new attachment point. It will receive in response a Proxy Router Advertisement message from the old access router with a set of possible responses indicating that the point of attachment is unknown, the point of attachment is known and is connected through the same access router, or is known and here is the prefix (or care- of-address) you should use to form your new care-of-address (COA). The mobile node sends a Fast Binding Update using its newly formed COA as the last message before it executes the handover. The mobile node then receives a Fast Binding Acknowledgement either through the old access router or the new access router indicating that the binding was complete. Whenever a mobile node moves to the new access router it sends the Fast Neighbor Advertisement to initiate the flow of packets that may be waiting there for the mobile. The old access router can also initiate a handover for the mobile node using the same messages. In this case the mobile node receives a Proxy Router Advertisement with a new prefix (or care-of-address) indicating that the mobile is about to be moved. The mobile responds by sending a Fast Binding Update to the old access router with its new care-of-address. The mobile receives a Fast Binding Acknowledgement indicating that the handover is complete. The mobile node needs to be prepared for a number of error conditions. It may not receive a response to an initial Router Solicitation for Proxy in which case it needs to resend it. It also may not receive a response to its Fast Binding Update in which case it needs to sends a Fast Neighbor Advertisement to the new access router. If it does not receive its Fast Binding Acknowledgement at this point, the Fast Binding Update never got to the old access router and it thus it is resent. The old access router communicates with the mobile node using the exchange of packets described above. If the mobile node is initiating the handover it will send a Router Solicitation for Proxy with some access network information. The old access router will respond to this in one of three ways. If it does not understand the access network information it will respond saying that the access network information is unknown. If the old access router understands the access network information but realizes that the access network information provided uses the same access router it will respond that the mobile node will continue to use the same access router. If the old access router recognizes the access network information but realizes it uses a different access router, it will respond with a care-of-address or prefix for the new Access Router. The method by which an access router finds the IP address of another access router connected to the access point defined in the Router Solicitation for Proxy is outside the scope of this document. Design Team 4 Internet Draft Fast Handovers for MIPv6 April 2001 The old access router waits for a Fast Binding Update from the mobile node before actually forwarding packets. The old access router sends a Fast Binding Acknowledgement message to the mobile node through the temporary tunnel that is constructed and MAY also send it to the mobile node over its old link. If the old access router is initiating the handover, it will begin the exchange by using the Proxy Router Advertisement informing the mobile node of the new care-of-address that will be used to deliver packets to it. The old access router MUST wait for a Binding Update from the mobile node before actually forwarding packets. The old access router sends a Binding Acknowledgement message to the mobile node through the temporary tunnel that is constructed and to the mobile node over its old link. In addition to the exchange with the mobile node the old access router exchanges information with the new access router to facilitate the forwarding of packets between the two and reduce the latency perceived by the mobile node during the handover. The old access router sends a Handover Initiate (HI) message to the new access router with the requested care-of-address on the new access router and the care-of-address being used currently at the old access router. The old access router receives in response a Handover Acknowledgement (HACK) message either accepting or rejecting the new care-of-address. If the new care-of-address is accepted, the old access router sets up a temporary tunnel to forward packets destined for the mobile to the new care-of-address on the new access router. If the new care-of-address is rejected by the new access router, the old access router sets up a temporary tunnel to forward packets destined for the mobile to the old care-of-address which will be temporarily hosted on the new access router. In either case the old access router does not forward packets until it has received a Fast Binding Update from the mobile node. In the case of stateful address allocation, oldAR obtains a care-of- address from newAR through HI/HACK message exchange. Therefore, HI/HACK messaging needs to be completed before transmitting Proxy Router Advertisement, which carries this care-of-address to the mobile node. The new access router also exchanges messages with the old access router and forwards messages between the old access router and the mobile node. When the new access router receives a Handover Initiate message without a new care-of-address, it allocates a new care-of- address and sends it to the old access router in the Handover Acknowledgement message. When the new access router receives a Handover Initiate message with a new care-of-address it determines whether the new care-of-address is valid and sends an indication in the Handover Acknowledgement message. If a valid new care-of-address is returned to the old access router, the new access router will be receiving packets for the mobile node with a valid new care-of- address and will just forward them as normal to the mobile node. If no valid new care-of-address is determined, the new access router Design Team 5 Internet Draft Fast Handovers for MIPv6 April 2001 will record the old care-of-address, de-tunnel the packets received in the tunnel from the old access router and deliver them to the mobile node. The new access router will deliver packets to the mobile node when it receives an indication from the access network that it can begin sending packets to the mobile node or when it receives a neighbor advertisement from the mobile node, also an indication that it can send packets to the mobile node. The following summarizes the semantics of the messages. The Router Solicitation for Proxy is always an indication to the old access router that the mobile node would like to perform a handover and is requesting information to enable the handover to be performed with minimal interruption. The Proxy Router Advertisement is an indication that the mobile node should go ahead and move and it provides the prefix or address to be used on the new access router. If the handover is mobile determined it provides information about whether the handover will involve moving to a new access router. If the handover is network determined it provides the indication that the mobile is about to be moved and the information that it will be using in the new access router. In network determined handover, failure to conform with the Proxy Router Advertisement may result in loss of service. The Fast Binding Update indicates the Binding that the mobile node wants the old access router to make. It also indicates to the network that the mobile is moving and that it wants its packets forwarded. The Fast Binding Acknowledgement indicates whether the Fast Binding Update was successful or not. A negative acknowledgement may indicate that the new care-of-address is invalid or that the Fast Binding Update failed for any of the standard reasons. The Handover Initiate message indicates the old access router is trying to facilitate a fast handover to the new access router and the old care-of-address that will be used in the case that the requested address negotiation between the routers fail. The Handover Acknowledgement message indicates what the new care-of- address should be in the new Router. Mobile node sends a Fast Neighbor Advertisement to the newAR to announce its arrival. This message also triggers a response in the form of a Router Advertisement that can indicate whether the Fast Binding Update was successful for the now Care-of-Address or old Care-of-Address. Design Team 6 Internet Draft Fast Handovers for MIPv6 April 2001 3. Supported scenarios The framework described above applies to two main network scenarios. A Network Determined Handover scenario were the network is responsible for moving the mobile node from one attachment point to another and a Mobile Determined Handover scenario were the mobile itself has to define and initiate the handovers. 3.1. Network Determined Handover In this scenario both stateless and stateful care-of-address configuration is supported. 3.1.1. Stateless new Care-of-Address Configuration When the old access router realizes (or gets notified) that a mobile node must move to a new access router it compiles a new care-of- address based on the mobile node's Interface ID and the new access router's Prefix. It then sends this new care-of-address to the mobile node together with the new access router IP address and Link Layer Address using the Proxy Router Advertisement message. At the same time the old access router sends the Handover Initiate message to the new access router indicating the mobile node's old care-of-address as well as the newly created new care-of-address. The new access router first establishes whether the new care-of- address is a valid address performing checks to ensure that it is not a duplicate. If the new care-of-address is legal and acceptable to the new access router it adds it to the Neighboring Cache for a short time period so it can defend it and it responds with a Handover Acknowledgement. If the new care-of-address is not valid (e.g.: used by another node) the new access router adds a host route for the old care-of-address pointing to its mobility interface, for a short time period and responds to the old access router with a Handover Acknowledgement ("Handover accepted but new care-of-address not valid"). MN oldAR newAR | | | |<------PrRtAdv-------|--------HI--------->| |-------F-BU--------->|<-------HAck--------| Disconnect <-F-BACK-|-F-BACK-> | | | | | forward | | packets===============>| | | | |------------------F-NA-----------> | | | deliver |<=====================================Packets Figure 1: Network Determined and Stateless Design Team 7 Internet Draft Fast Handovers for MIPv6 April 2001 If the Handover Acknowledgement message indicates the new care-of- address is valid the old access router will get ready to forward packets for this mobile node to its new care-of-address. If the Handover Acknowledgement indicates the new care-of-address is not valid the old access router will get ready to forward packets for this mobile node to the new access router. The old access router will only change its routing regarding an mobile node after it receives a Fast Binding Update from the mobile node confirming the handover. This Fast Binding Update SHOULD be sent (if permitted by the link layer conditions at handover time) to the old access router while the mobile node is still connected to the old access router. If this is not possible the Fast Binding Update MUST be sent after the mobile node connects to the new access router. The old access router MUST then send a Fast Binding Acknowledgement message to the mobile node both locally and by way of new access router (using the new care-of-address or the new access router as encapsulating address) On reception of the Fast Binding Update and providing the Handover Acknowledgement has also been received, the old access router can start forwarding packets destined to the mobile node's old care-of- address to either the new care-of-address or the new access router, depending of the Handover Acknowledgement value. Additionally, and if the link layer supports such indications, the old access router MAY delay the routing change until it determines that the mobile node has disconnected. Now the old access router acts as a Home Agent with home address being the mobile node's old care-of-address and care-of- address being either the mobile node's new care-of-address or the new access router address. The mobile node MUST NOT use the new care-of-address address as source address until it receives a Fast Binding Acknowledgement from the old access router. The Fast Binding Acknowledgement may be received while the mobile node is still connected to the old access router in which case the mobile node will only have to announce itself to the new access router to get full connectivity. In the case were the Fast Binding Acknowledgement was sent but not received at the old access router, there will be a copy of it waiting for the mobile node at the new access router. If the Fast Binding Acknowledgement is not received at all the mobile node should assume the Fast Binding Update was not received by the old access router and it MUST resent the Fast Binding Update to the old access router. Design Team 8 Internet Draft Fast Handovers for MIPv6 April 2001 3.1.2. Stateful new Care-of-Address Configuration An alternative message sequence has HI/HAck message exchange proceeds the Proxy Router Advertisement message send from the old access router to the mobile node. This provides a way to retrieve the topologically correct and statefully allocated care-of-address for the Proxy Router Advertisement from the new access router when this information is not available to the old access router by other means. MN oldAR newAR | | | | |--------HI--------->| | |<-------HAck--------| |<------PrRtAdv-------| | | | | Figure 2: Network Determined and Stateful The rest of the process is identical to the stateless approach 3.2. Mobile Determined Handover The main difference between this and the Network Determined approach is that here the mobile node MUST send a Router Solicitation for Proxy message to the old access router and trigger the Proxy router Advertisement. In the Router Solicitation for Proxy message the mobile node indicates the Link Layer address or the Identifier of the Attachment Point that it wants to attach to. The old access router will then reply with a Proxy Router Advertisement which contains the same information with the stateless approach of Network Determined approach. MN oldAR newAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------|--------HI--------->| |------F-BU---------->|<------HACK---------| Disconnect <--F-BACK--|--F-BACK--> | | | | | forward | | packets===============>| Connect | | |----------------F-NA-------------> | | | Deliver |<=====================================Packets Figure 3: Mobile Determined Design Team 9 Internet Draft Fast Handovers for MIPv6 April 2001 The rest of the behavior is the same in that the new care-of-address is sent to the new access router for validation using the HI/HACK sequence and the old access router does not changes its routing regarding the mobile in question unless it receives a Binding Update from it, and depending on the link layer until the mobile node disconnects, while the mobile node does not use the new care-of- address until it receives a Fast Binding Acknowledgement. After all this is done, as before, the old access router acts as a Home Agent with home address being the mobile node's old care-of-address and care-of-address being either the mobile node's new care-of-address or the new access router address. 3.3. Sending BUs, F-BUs and F-NAs at the New Access Router When the mobile node moves to a new access router, it needs to send a Binding Update to its home agent. It also may need to send a Fast Binding Update to its old access router, unless it has a positive indication that the old access router already has made the appropriate binding cache modifications. The typical form of such a positive indication is a Fast Binding Acknowledgement send from the old access router to the mobile node; if the mobile node expects but does not receive the acknowledgement, then it MUST resend the Fast Binding Acknowledgement one more time. In this section, it is considered that all necessary link establishment details have been completed. This may possibly include Duplicate Address Detection, and/or reception of a Router Advertisement from the new access router. Those events may not always have to occur, and when they are needed they must have occurred before the transmission of Binding Updates messages. When the new access router receives any packet from the mobile node to be forwarded elsewhere, it means that the mobile node considers the new access router to be its default router, and thus that link establishment is complete from the point of view of the mobile node. If the Fast Binding Acknowledgement was received, then the mobile node only has to send the Binding Update to its home agent. In that case, that Binding Update would be sent through the mobile node's default router--that is, the new access router. If on the other hand the mobile node has not yet received a Fast Binding Acknowledgement from the old access router, then the mobile node SHOULD arrange for old access router to receive an appropriate Fast Binding Update associating the mobile node's old care-of-address to its new care-of-address. Furthermore, alternative encapsulation strategies, which would allow both Binding Update options to be sent with a single transmission over the air from the mobile node, are the subject of current discussion in the design team. Design Team 10 Internet Draft Fast Handovers for MIPv6 April 2001 In any case a Fast Neighbor Advertisement is sent to the new access router as soon as the Mobile Node gains connectivity to it, in the absence of Fast Binding Acknowledgement since that would mean the mobile node is still unsure about the address it should be using in the new access router. The message contains both new and old care-of- addresses as well as the mobile node's link layer address. The new access router checks the link layer address to see if it has a mapping in its Neighbor Cache. First the new access router should check for mappings to the old care-of-address of the mobile node, if non-exists the new care of address should also be checked. If there is no such mapping the new access router will send a Routing Advertisement to the mobile node using the old care-of-address as destination address. This Routing Advertisement will include the NAACK option as described in 4.4.3. If a mapping is found with the new care-of-address then, the new access router will change the cache entry to REACHABLE and send a Routing Advertisement with the NAACK option. If the mapping is found with the old care-of-address, then the same process will follow. Note that it is possible for the mobile node to send data packets immediately following the F-NA message, without waiting for the reaction of the new access router. Such packets MUST use the old care-of-address as source address and the implementer should be aware that if the new access router is not aware of the mobile, these packets are likely to be dropped. 3.3.1. Features enabling Partial Handover Optimization The following features are related, and yet able to be separated, and enable various facets of connectivity between the mobile node and the new access router. 1. The mobile node may be able to discover the IP address of the new access router 2. The mobile node may be able to discover the MAC address of the new access router. 3. The mobile node may be able to direct the new access router to ascertain the uniqueness of its new care-of-address before establishing connectivity with the new access router 4. The mobile node may be able to send a Binding Update to its previous access router before breaking the previous connection 4a. The mobile node may be able to receive the Fast Binding Acknowledgement for the Fast Binding Update sent to the old access router before breaking the old connection. Design Team 11 Internet Draft Fast Handovers for MIPv6 April 2001 4b. The mobile node may fail to receive the Fast Binding Acknowledgement for the Fast Binding Update sent to the previous access router before breaking the old connection. But mobile node may receive the other copy of the Fast Binding Acknowledgement at the new link after attaching to new access router. All of these operations are possibly both in the network-determined and the mobile-determined scenarios. If (1), (2), and (3) hold, then the mobile node can begin to use the new access router as its default router as soon as layer-2 connectivity is established. Thus, in this optimal circumstance, any necessary Binding Updates can be delivered without any additional delay as soon as the mobile node gets to the new network. If any of (1), (2) or (3) do not hold, then the mobile node is required to perform some combination of Neighbor Discovery and Duplicate Address Detection when it arrives at the new access router's area. For all of cases 4, 4a, 4b, a simple rule is effective. If the mobile node does not receive a Fast Binding Acknowledgement for the Fast Binding Update that it has sent, then it MUST retransmit the Fast Binding Update. 4. Message Definitions and Option Formats In this section, message and option formats are specified. The description for each message extension and option will specify which message or option it may be used with. 4.1. New Neighbor Discovery messages 4.1.1. Router Solicitation for Proxy (RtSolPr) Hosts send Router Solicitation for Proxy in order to prompt routers for Proxy Router Advertisements. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Design Team 12 Internet Draft Fast Handovers for MIPv6 April 2001 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. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 0 Checksum The ICMP checksum. See [ICMPv6]. Identifier MUST be set by the sender so replies can be matched to this Solicitation. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender, if known. It SHOULD be included on link layers that have addresses. New attachment point link-layer address The link-layer address or identification of the attachment point the mobile node requests routing advertisement information for. It MUST be included in all RtSolPr messages. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. Design Team 13 Internet Draft Fast Handovers for MIPv6 April 2001 Description The mobile node MUST sends this message if it wants to initiate a fast handover. It indicates its destination with the New Attachment Point Link-Layer Address. A Proxy Router Advertisement message should be received in response. If such message is not received in a short time period but no less than 2 times the typical round trip time (RTT) over the access link or 100msec if RTT is not known, it SHOULD resend it once or at the most twice (after the same waiting time). If the Proxy Router Advertisement is not received by the time the mobile node disconnects from old access router, Fast Handover can not be performed and the mobile node SHOULD revert back to normal MIPv6. 4.1.2 Proxy Router Advertisement (PrRtAdv) Routers send out Router Advertisement message unsolicited if the network is controlling the handover or in response to a Router Solicitation for Proxy message from a mobile node. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address The Source Address of an invoking Router Solicitation for Proxy or the address of the node the Access Router is instructing to handover. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. Design Team 14 Internet Draft Fast Handovers for MIPv6 April 2001 ICMP Fields: Type TBA Code 0 - Handover Information 1 - No change of COA required 128 - New Attachment Point not known Checksum The ICMP checksum. See [ICMPv6]. Identifier Copied from Router Solicitation for Proxy or set to Zero if unsolicited. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender, if known. It SHOULD be included on link layers that have addresses. Link-layer address of proxied originator (i.e.: newAR) The link-layer address of the Access Router for which this message is proxied for. Prefix Information These options specify the prefixes of the Access Router the message is proxied for and are used for address autoconfiguration. New COA Option In stateful configuration, this option MUST be sent to allocate an address on behalf of the Access Router this message is proxied for (i.e.: the new access router). In stateless address auto- configuration this option may or may not be sent. If sent, indicates that the requesting node SHOULD use this address as new care-of-address for the duration of the handover. If not sent the requesting node SHOULD compute the new care-of- address using the Interface ID from the Destination Address of this message. Design Team 15 Internet Draft Fast Handovers for MIPv6 April 2001 Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. Description A Proxy Router Advertisement with Code 0 but without a New COA Option means that the mobile node SHOULD construct a new care-of-address out of its Interface ID (used in the Destination Address in this Proxy Router Advertisement) and the Prefix in the Prefix Information Option. A Proxy Router Advertisement with Code 0 and a New COA Option means that the mobile node SHOULD use the COA indicated as a new care-of-address at the new Access Router. This MUST used when Stateful COA configuration is in use and MAY be used to help the old access router and mobile node calculate the same new care-of-address when Stateless COA configuration is used. A Proxy Router Advertisement with Code 1 is sent if handover to the New Attachment Point, as indicated by the New Attachment Point Link Layer address in the corresponding RtSolPr message, does not require change of COA. No options required in this case. A Proxy Router Advertisement with Code 2 means that the old access router is not aware of the Prefix Information requested. The mobile node MUST give up its attempt to perform fast handover to this new attachment point. Normal MIPv6 MAY be used instead. No options required in this case. This message is sent once for every Router Solicitation for Proxy received. 4.1.3 Fast Neighbor Advertisement (F-NA) Message Format A node sends a Fast Neighbor Advertisement to announce itself to the new access router Design Team 16 Internet Draft Fast Handovers for MIPv6 April 2001 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + NewCOA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + OldCOA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An address assigned to the interface from which the advertisement is sent. Destination Address Typically the all-nodes multicast address. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBD Code 0 Checksum The ICMP checksum. See [ICMPv6]. Reserved 32-bit unused field. It MUST be initialized to Design Team 17 Internet Draft Fast Handovers for MIPv6 April 2001 zero by the sender and MUST be ignored by the receiver. NewCOA The New Care-Of-Address given to the mobile node in the Proxy Router Advertisement OldCOA The Old Care-Of-Address of the mobile node. Possible options: Target link-layer address The link-layer address for the target, i.e., the sender of the advertisement. This option MUST be included in all F-NAs. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. Description The Fast Neighbor Advertisement is sent to the new access router as soon as the Mobile Node gains connectivity to it and in the absence of Fast Binding Acknowledgement since that would mean the mobile node is still unsure about the address it should be using in the new access router. The message contains both new and old care-of-addresses as well as the mobile node's link layer address. The new access router checks the link layer address to see if it has a mapping in its Neighbor Cache. The new access router should check for mappings to the old care-of-address of the mobile node first and if such a mapping does not exist it should check the new care-of-address. If there is no such mapping either the new access router will send a Routing Advertisement to the mobile node using the old care-of-address as destination address. This Routing Advertisement will include the NAACK option as described in NAACK. If a mapping is found with the new care-of-address then, the new access router will change the cache entry to REACHABLE and send a Routing Advertisement with the NAACK option as described in 4.3.3. If the mapping is found with the old care-of-address, then the same process will follow. Note that it is possible for the mobile node to send data packets immediately following the F-NA message, without waiting for the reaction of the new access router. Such packets MUST use the old care-of-address as source address and the implementer should be aware that if the new access router is not aware of the mobile, these packets are likely to be dropped. Design Team 18 Internet Draft Fast Handovers for MIPv6 April 2001 4.2. Inter-Access Router Messages 4.2.1 Handover Initiation (HI) The Handover Initiation message is a new ICMPv6 message sent by the old Access Router to new Access Router to initiate the process of Mobile Node's handover from one sub-network to another. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |S|U| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address The IP address of the Router sending this message Destination Address The IP address of the Router this message is sent To. Hop Limit 255 Authentication Header A Security Association MUST exists between the sender and the destination address. This messages MUST be authenticated and so the authentication header MUST be used when this message is sent. ICMP Fields: Type TBA Code 0 Checksum The ICMP checksum. See [ICMPv6]. Identifier MUST be set by the sender so replies can be matched to this Solicitation. S Stateful address configuration flag. When SET this message requests a new COA to be returned by the destination. Design Team 19 Internet Draft Fast Handovers for MIPv6 April 2001 U Buffer flag. The destination SHOULD buffer any packets towards the node indicated in the options of this message. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Link-layer address of mobile node The link-layer address of the mobile node that is being handed of to the destination. This options SHOULD be included to help the destination recognize the mobile node when it will be connected to it. Old Care-of-Address The IP address used by the mobile node while attached to the originating router. This option MUST be included so packets to this mobile node can be redirected to the destination even if the new care-of-address is not acceptable. New Care-of-Address The IP address the mobile node wants to use when connected to the destination. In Stateless configuration this option indicates the new Care of Address the mobile node will be using when connected to the destination. Description If Handover Acknowledgement message is not received as a response to this message. the Handover Initiate SHOULD be resent up to 4 times using a short retransmission timer but no less than twice the round trip time between source and destination or 100msec if RTT is not known. Failure to receive an Handover Acknowledgement means that no fast handover can be performed. The purpose of this message is to notify the new access router about the upcoming handover and establish a valid new care-of-address for the mobile node. If the S flag is SET this message requests an address from the new access router to be assigned statefully. If the new COA option is included the old access router requests the new access router to confirm that this is a valid new care-of- address. Design Team 20 Internet Draft Fast Handovers for MIPv6 April 2001 4.2.2 Handover Acknowledgement (HACK) Message The Handover Acknowledgement message is a new ICMPv6 message that MUST be sent by the new Access Router to the old Access Router in response to a Handover Initiate message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address Copied from the destination address of the Handover Initiate Message this message is in response to. Destination Address Copied from the source address of the Handover Initiate Message this message is in response to. Hop Limit 255 Authentication Header A Security Association MUST exists between the sender and the destination address. This messages MUST be authenticated and so the authentication header MUST be used when this message is sent ICMP Fields: Type TBA Code 0-Handover Accepted, newCOA valid 1-Handover Accepted, newCOA not valid 2-Handover Accepted, newCOA in use 3-Handover Accepted, newCOA assigned (Stateful) 4-Handover Accepted, newCOA not assigned (Stateful) 128-Handover Not Accepted, reason unspecified 129-Administratively prohibited 130-Insufficient resources Checksum The ICMP checksum. See [ICMPv6]. Design Team 21 Internet Draft Fast Handovers for MIPv6 April 2001 Identifier Copied from the corresponding field in the Handover Initiate message this message is in response to. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: New Care of Address If the S flag in the Handover Initiate message is SET, this option is used to provide the new Care- of-Address the mobile node should use when connected to this router. Description On reception of Handover Initiate the new access router MUST respond with an Handover Acknowledgement. If the S flag is SET in the Handover Initiate, the new access router SHOULD include the new Care of Address option and a Code of 3. If the S flag is not SET in the Handover Initiate, the new access router SHOULD check the validity of the new care- of-address sent with the Handover Initiate and reply accordingly. If the new care-of-address is valid and the handover the new access router SHOULD insert the new care-of-address in its Neighbor Cache and defended on behalf of the mobile for a short period of time of a default value of 1 second in which period the mobile node is expected to connect to the new access router. If the new care-of-address is not valid or not assigned (Stateful), the newAR SHOULD insert a host specific route for the mobile node's old care-of-address in its routing table. This route entry will not be used until new access router receives an indication that mobile node has attached to one of its links". The new access router can always refuse the handover in which case it should indicate the reason in one of the available Code values. 4.3. New Destination Options 4.3.1 Fast Binding Update (F-BU) Destination Option The Fast Binding Update destination option is used by a mobile node to notify an old access router that is about to move to a new access router. As a destination option, it MAY be included in any existing packet being sent to this same destination or MAY be sent in a packet by itself; a packet containing a Binding Update is sent in the same way as any packet sent by a mobile node according to [MIPv6]. The Fast Binding Update option is encoded in type-length-value (TLV) Design Team 22 Internet Draft Fast Handovers for MIPv6 April 2001 format as follows: 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 Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Option Type TBA Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 8 plus the total length of all sub-options present, including their Sub-Option Type and Sub-Option Len fields. Reservd or Res This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix Length The Prefix Length field is set by the sending mobile node to The (nonzero) length of its subnet prefix in its home address (given in the Home Address option in the packet) to request its home agent to use the interface identifier in the mobile node's home address (the remaining low-order bits after the indicated subnet prefix) to form all other home addresses for the mobile node on the home link. The home agent becomes the home agent not only for the individual home address given in this binding, but also for all other home addresses for this mobile node formed from this interface identifier. That is, for each on-link prefix on the home link, the home agent uses the interface identifier to form other valid addresses for the mobile node on the home link, and acts as a home agent also for those addresses. In addition, the home agent forms the link-local address and site-local address corresponding to this interface identifier, and defends each for purposes of Duplicate Address Detection. The home agent also performs Duplicate Address Detection on at least one such address as part of the home registration processing (before returning Design Team 23 Internet Draft Fast Handovers for MIPv6 April 2001 the Binding Acknowledgement), if the Duplicate Address Detection (D) bit is set in the Binding Update; it is not necessary to perform Duplicate Address Detection individually on each of these addresses, since address uniqueness here is determined solely by the interface identifier [27]. Details of this operation are described in Section 9.3. Sequence Number Used by the receiving node to sequence Fast Binding Updates and by the sending node to match a returned Fast Binding Acknowledgement with this Fast Binding Update. Each Fast Binding Update sent by a mobile node MUST use a Sequence Number greater than the Sequence Number value sent in the previous Fast Binding Update (if any) to the same destination address (modulo 2**16, as defined in Section 4.6). There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Fast Binding Update sent or received. Lifetime 32-bit unsigned integer. The number of seconds remaining before the binding MUST be considered expired. A value of all one bits (0xffffffff) indicates infinity. A value is zero indicates that the Binding Cache entry for the mobile node MUST be deleted. Sub-Options Additional information, associated with this Fast Binding Update option, that need not be present in all Fast Binding Updates sent. This use of sub-options also allows for future extensions to the format of the Fast Binding Update option to be defined. The encoding and format of defined sub-options are described in [MIPv6]. The following sub-options are valid in a Fast Binding Update option: - Unique Identifier Sub-Option - Alternate Care-of Address Sub-Option The alignment requirement [ICMPv6] for the Fast Binding Update option is 4n+2. Any packet that includes a Fast Binding Update option MUST also include a Home Address option. The home address of the mobile node in the binding given in the Fast Binding Update option is that which was received as the value of the Home Address field in the Home Address option in the packet. The care-of-address for the binding given in the Fast Binding Update Design Team 24 Internet Draft Fast Handovers for MIPv6 April 2001 option is the new care-of-address given to the mobile node by the Proxy Router Advertisement message and is included in the Alternate Care-of Address sub-option in the Fast Binding Update option which MUST be present in all Fast Binding Updates. Any packet that includes a Fast Binding Update option MUST be protected in the way Binding Updates are protected in [MIPv6]. If the Lifetime field in the Fast Binding Update option is equal to 0, the Fast Binding Update option indicates that any existing binding for the mobile node MUST be deleted. In this case a Binding Cache entry for the mobile node MUST NOT be created in response to receiving the Fast Binding Update. The last Sequence Number value sent to a destination in a Fast Binding Update is stored by the mobile node in its Fast Binding Update List entry for that destination; the last Sequence Number value received from a mobile node in a Fast Binding Update is stored by a correspondent node in its Binding Cache entry for that mobile node. Thus, the mobile node's and the correspondent node's knowledge of the last sequence number expire at the same time. If the sending mobile node has no Fast Binding Update List entry, the Sequence Number may start at any value; if the receiving correspondent node has no Binding Cache entry for the sending mobile node, it MUST accept any Sequence Number value in a received Fast Binding Update from this mobile node. The three highest-order bits of the Option Type are encoded to indicate specific processing of the option. For the Binding Update option, these three bits are set to XXX, indicating that any IPv6 node processing this option that does not recognize the Option Type must discard the packet and, only if the packet's Destination Address was not a multicast address, return an ICMP Parameter Problem, Code 2, message to the packet's Source Address; and that the data within the option cannot change en-route to the packet's final destination. 4.3.2 Fast Binding Acknowledgement (F-BACK) Destination Option The Fast Binding Acknowledgement destination option is used to acknowledge receipt of a Fast Binding Update option. When a node receives a packet containing a Fast Binding Update option, with this node being the destination of the packet (only the destination node processes the option since it is a destination option), this node MUST return a Binding Acknowledgement to the source of the packet, if the Acknowledge (A) bit is set in the Binding Update. The Fast Binding Acknowledgement MUST NOT be send to the Mobile Node before the old access router receives a Handover Acknowledgement from the new access router. If the Handover Acknowledgement is a positive acknowledgement for the validity of the new care-of-address the Fast Binding Acknowledgement MUST be send with the mobile node's new care- of-address as destination address. If the Handover Acknowledgement Design Team 25 Internet Draft Fast Handovers for MIPv6 April 2001 indicates that the new care-of-address is not valid, the Fast Binding Acknowledgement MUST be send with the mobile node's old care-of- address as destination address and encapsulated into an IPv6 packet with the new access router's IPv6 address as a destination address. The Fast Binding Acknowledgement MAY also be send to the mobile node's old care-of-address at the local subnet of the old access router (e.g.: over the air) were the mobile node was before it moved to the new access router. The Fast Binding Acknowledgement option is encoded in type-length- value (TLV) format as follows: 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 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Status | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Option Type TBA Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 11 plus the total length of all sub-options present, including their Sub-Option Type and Sub-Option Len fields. Status 8-bit unsigned integer indicating the disposition of the Fast Binding Update. Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. The following such Status values are currently defined: 0 Fast Binding Update accepted 1 Fast Binding Update accepted but newCOA is invalid Values of the Status field greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following such Status values are currently defined: Design Team 26 Internet Draft Fast Handovers for MIPv6 April 2001 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Incorrect interface identifier length Up-to-date values of the Status field are to be specified in the most recent "Assigned Numbers". Sequence Number The Sequence Number in the Fast Binding Acknowledgement is copied from the Sequence Number field in the Fast Binding Update being acknowledged, for use by the mobile node in matching this Acknowledgement with an outstanding Fast Binding Update. Lifetime The granted lifetime, in seconds, for which this node will attempt to retain the entry for this mobile node in its Binding Cache. If the node sending the Binding Acknowledgement is serving as the mobile node's home agent, the Lifetime period also indicates the period for which this node will continue this service; if the mobile node requires home agent service from this node beyond this period, the mobile node MUST send a new Binding Update to it before the expiration of this period (even if it is not changing its primary care-of-address), in order to extend the lifetime. The value of this field is undefined if the Status field indicates that the Binding Update was rejected. Sub-Options Additional information, associated with this Fast Binding Acknowledgement option, that need not be present in all Fast Binding Acknowledgements sent. This use of sub-options also allows for future extensions to the format of the Fast Binding Acknowledgement option to be defined. The encoding and format of defined sub-options are described in [MIPv6]. Currently, no valid sub-options are defined for a Fast Binding Acknowledgement option. The alignment requirement [ICMPv6] for the Fast Binding Acknowledgement option is 4n+3. Design Team 27 Internet Draft Fast Handovers for MIPv6 April 2001 4.4. New ICMP options 4.4.1 IP Address Option This section defines the IP Address Option, used by the ICMPv6 messages defined in this document. The extension format is based on [MIER]. 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 | Sub-Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 3 Sub-Type 1 Old Care-of Address 2 New Care-of Address Prefix Length The Length of the IPv6 Address Prefix IPv6 address The IP address for the unit defined by the Type field. This option is sent in the Proxy Router Advertisement, the Handover Initiate and Handover Acknowledgement messages. The Proxy Router Advertisement and Handover Acknowledgement messages only contain the new care-of-address while the Handover Initiate message may include both new care-of-address and old care-of-address. Design Team 28 Internet Draft Fast Handovers for MIPv6 April 2001 4.4.2 Link-layer Addresses (LLA) This extension is based on the [MIER] 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 | Sub-Type | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option (including the type, sub-type and length fields) in units of 8 octets. Sub-Type 1 for the Link-layer Address of the new Attachment Point. 2 for the Link-layer Address of the Mobile Node. 3 for the Link-layer Address of the Proxied Originator LLA The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. Description The New Attachment Point Link Layer address contains the link-layer address of the attachment point the mobile node attempts to handover to. This is used in the Router Solicitation for Proxy message. The Mobile Node Link-Layer address option contains the link- layer address of a mobile node. It is used in the Handover Initiation message. The Proxied Originator Link-Layer address option contains the Link Layer address of the Access Router the Proxy Router Solicitation message refers to. These options MUST be silently ignored for other Neighbor Discovery messages. NOTE: Source and Target Link Layer Addresses as defined in [ND] MAY also be used by Router Solicitation for Proxy and Proxy Routing Advertisement messages. Design Team 29 Internet Draft Fast Handovers for MIPv6 April 2001 4.4.3 Neighbor Advertisement Acknowledgement (NAACK) This extension is formatted as follows. 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 | Sub-Type | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 4. Sub-Type 0 Status 8-bit unsigned integer indicating the disposition of the Fast Binding Update. Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. The following such Status values are currently defined: 0 The new care-of-address is valid 1 The old care-of-address is valid 128 Link Layer Address unrecognized Up-to-date values of the Status field are to be specified in the most recent "Assigned Numbers". Description The NAACK is included in a Router Advertisement in response to a Fast Neighbor Advertisement to indicate to a Mobile Node whether the new care-of-address is valid or not. The same information is given to the Mobile Node in the Fast Binding Acknowledgement message the old access router sends to it as a response to an Fast Binding Update. If an implementation of an new access router is capable of recognizing that the Fast Binding Acknowledgement is in a buffer ready to be send to the mobile node on reception of the F-NA, then, the Routing Advertisement and consequently the NAACK option MAY not be send as a response to the F-NA message. In all other cases the Routing Advertisement with the NAACK message MUST be send. If the new care-of-address is valid, the Routing Advertisement Design Team 30 Internet Draft Fast Handovers for MIPv6 April 2001 MUST use the new care-of-address as destination address and the Mobile Node SHOULD use it as its Care-of-address as defined in [MIPv6]. If the old care-of-address is valid, the Routing Advertisement MUST use the old care-of-address as destination address and the Mobile Node MAY use this address as source address and SHOULD start the process of getting a new care-of- address and performing DAD as defined in Neighbor Discovery [ND]. If the NAACK indicates that the Link Layer Address is unrecognized the Mobile Node MUST NOT use the new care-of- address or the old care-of-address and SHOULD start immediately the process of acquiring a new care-of-address and performing DAD as defined in Neighbor Discovery [ND]. 5. Error Cases and other issues In this section we are going to examine some common error cases that may affect the performance and/or reliability of the mechanisms described in this specification. 5.1. DAD handling Duplicate Address Detection (DAD) was defined in [AUTO] to avoid address duplication on links when stateless address auto- configuration is used. The use of DAD to verify the uniqueness of a statelessly configured IPv6 address may add delays to a MIPv6 handover. The probability of an interface identifier duplication on the same subnet can be considered very low, however it can not be ignored. In this draft certain precautions are proposed to minimize the effects of a duplicate address occurrence. In some cases the new AR may already have the knowledge required to assess whether the mobile node's address is duplicated or not, before the mobile node moves to the new subnet. For example, the AR can have a list of all nodes on its subnet (may be used for access control) and by searching this list it can confirm whether the mobile node's address is duplicated. The result of this search can be sent back to the old AR in the HAck message. If such knowledge is not available in the new AR, the mobile node would have to perform DAD after moving to the new subnet. To avoid delays due to performing DAD, it is suggested that the mobile node performs DAD while using its old care-of-address. This is possible since the framework described in this specification allows packet redirection based on the old care-of-address encapsulated into the new access router IP address. Design Team 31 Internet Draft Fast Handovers for MIPv6 April 2001 So, if the new access router cannot confirm the validity of the new care-of-address address included in the Handover Initiate message but is never the less willing to serve the mobile node it can describe that in the Handover Acknowledgement message and install a host route towards its mobility interface regarding the mobile node's old care- of-address. The old access router on reception of this type of Handover Acknowledgement replies with a BACK with status code "1" to the Fast Binding Update sent by the mobile node attempting to registers is new care-of-address. The old access router now forwards packets for this mobile node to the new access router which will decapsulates and due to the host route installed earlier it can forward these packets to the mobile. The mobile node will at some point, either at the old or at the new access router receive the BUNACK and thus attempt to get a new care- of-address. If the mobile node does not receive the Fast Binding Acknowledgement or BUNACK at the old access router and after connecting to the new access router it still does not receive it in a short time frame (X sec) it can assume that the Fast Binding Update was not received by the old access router and it MUST retransmit it. The source address used in this Fast Binding Update SHOULD be the new care-of-address, which is not yet confirmed, to avoid ingress filtering. If the new care-of-address is not valid the old access router will send (or resend) a BUNACK to the old care-of-address, encapsulated in the address of the new access router and thus it will safely be received by the mobile node. 5.2. Fast and erroneous movement Although this is a specification for fast handovers, the protocol has its limits in terms of how fast a mobile node can move. A special case of fast movement is ping-pong were a mobile node moves between the same two access points rapidly. Another instance of the same problem is erroneous movement i.e.: the mobile node think that it is moving to a new access point and it is either moving to a different one or aborts movement altogether. All of the above behaviors are usually the result of link layer instabilities and thus are often tackled at the link layer itself. IP layer mobility, however, introduces its own limits. IP layer handovers should be in a frequency that allows enough time to the mobile node to update the binding of at least it's Home Agent and preferably that of every correspondent node it is in communication with. A mobile that moves faster than that may start loosing packets and ultimately connectivity while its signaling overhead over the air and in the network may increase significantly especially in the case of rapid movement between two access routers. To avoid the signaling overhead and the chance of routing loops (because of multiple Design Team 32 Internet Draft Fast Handovers for MIPv6 April 2001 temporary tunnels for the same mobile node) we suggest the following measures. A mobile node returning to the old access router before updating the necessary bindings in the new access router MUST send a Binding Update with Home Address equal to the mobile node's old care-of- address and a lifetime of zero, to the old access router; remember that the mobile node should have a security association with the old access router since it performed a fast handover from it to the new access router. The old access router on reception of this Binding Update will check its set of outgoing (temporary fast handover) tunnels and if it finds a match it SHOULD drop that tunnel; i.e.: stop forwarding packets for this mobile node and start delivering packets directly to the node instead. The mobile node SHOULD NOT make any attempt to use any of the fast handover mechanisms described in this specification and SHOULD revert back to standards mobile IPv6 [MIPv6]. Temporary tunnels for the purposes of fast handovers should use sort lifetimes (in the order of a small number of seconds or less). The lifetime of such tunnels should be enough to allow a mobile node to update all its active bindings, while long life times increase the chance of a circular tunnel from AR1 to AR2 and back again to AR3 which could essentially result in a routing loop, especially if the old care-of-address is used with tunnels between access routers themselves (rather than forwarding to new care-of-address). Erroneous movement is not likely to damage the network but it may cause loss of packets since routing can change and the old access router may forward packets towards another access router before the mobile node actually connects to that access router. If the mobile gets it wrong, a Fast Binding Update or even a standard Binding Update to the old access router SHOULD be sent. Since for Fast and standard Binding Updates are authenticated, they MUST supersede the existing binding and packets SHOULD be redirected to the new confirmed location of the mobile node. No attempt should be made to recover packets from the access router the mobile was supposed to connect to. 5.3. Neighbor Cache Considerations When an access router receives a Handover Initiate message it checks if the new care-of-address indicated is already in use by another node. If not, a new cache entry is created with the new care-of- address and the mobile node's link layer address also included in the Handover Initiate message. If the new care-of-address is already in use, the cache entry is created for the old care-of-address of the mobile node instead. In either case, access router must set the state of this cache entry to INCOMPLETE. The state should be changed to REACHABLE as soon as a confirmation of reachability of the neighbor is received. Such a confirmation could be in the form of a Neighbor Advertisement, a Fast Neighbor Advertisement or a link layer trigger. Design Team 33 Internet Draft Fast Handovers for MIPv6 April 2001 The functionality of Fast Neighbor Advertisement is as follows: - It records the link-layer address in the neighbor Cache entry. - The state of the entry is set to REACABLE. - It sets the IsRouter flag in the entry to 0. - It sends any packet queued for the neighbor. 6. Security Considerations The security needed for fast handover is almost the same as is needed for handling Binding Updates in IPv6. If a handover could be initiated by a node masquerading as the mobile node, a range of undesirable effects might result. The malicious node could usurp traffic destined from the mobile node, diverting it to a nearby router and possibly an unauthorized care-of-address. The exact details of the possible effects would depend on the kinds of handover data available as part of the fast handover process. The Fast MIPv6 Handover proposal assumes that a security association exists between the old access router and the mobile node, as well as between the old and new access routers. Providing the above is true then, routing is only changes by a Fast Binding Update from the mobile node, which MUST be authenticated. It is also highly recommended that Router Solicitation for Proxy and Proxy Router Advertisement messages are also authenticated since they are between old access router and mobile node which have a security association. 7. Acknowledgements The Design Team would like to recognize Hesham Soliman's valuable contribution to this work. Also, a warm thank you to Basavaraj Patil and Phil Roberts for supporting this effort and the whole Mobile IP WG for participating in the initial discussion. References [ASSNUM] J. Reynolds, J. Postel, Assigned Numbers, Request For Comments (Standards Track) 1700. October 1994. [AUTO] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. Design Team 34 Internet Draft Fast Handovers for MIPv6 April 2001 [ICMPv6] Alex Conta and Stephen Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 2463, December 1998. [IMSI] TIA/EIA/IS-95-B [MAC] D. Plummer, "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1982. [MIER] M.Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, Mobile IP Extensions Rationalization (MIER)(work in progress). draft-ietf-mobileip-mier-05.txt, December 1999. [MIPv6] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. [ND] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com The authors of this document are: Alper Yegin, Sun Microsystems, Alper.Yegin@eng.sun.com Charles E. Perkins, Nokia, charliep@iprg.nokia.com George Tsirtsis, Flarion Technologies, G.Tsirtsis@flarion.com Gopal Dommety, Cisco Systems, gdommety@cisco.com Karim El-Malki, Ericsson, Karim.El-Malki@era.ericsson.se Mohamed Khalil, Nortel Networks, mkhalil@nortelnetworks.com Design Team 35