Personal G. Tsirtsis Editor A. Yegin C. Perkins G. Dommety K. El-Malki M. Khalil Internet Draft Title: draft-ietf-mobileip-fast-mipv6-00.txt Category: Informational February 2001 Expires : July 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 February 2001 1. Introduction This draft presents the initial output of the MIPv6 Design Team on Fast Handovers with Mobile IPv6. The design decision has been taken 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 adequately 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 rear 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 layer-2 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. 2. Protocol Overview The aim of this protocol is to enable the MN to configure a newCOA before it moves to a newAR in a way that can use this newCOA immediately at connection with newAR. The areas of preparation are newCOA configuration, Duplicate Addressing avoidance and Neighbor Discovery. The pictured model provides standard terminology, standard behavior, standard messages, and standard message semantics that enable fast handover behavior with minimal interruption to packets flowing to a mobile node as it moves. This model 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. Design Team 2 Internet Draft Fast Handovers for MIPv6 February 2001 MN oldAR newAR | | | |-----RtSolPr-------->| | | | | |<------PrRtAdv-------| | | |--------HI--------->| |----------BU-------->| | |<---------BACK-------|<-------HACK--------| | forward | | packets===============>| | | | |--------------------NA-----------> | | | deliver |<=====================================Packets Figure 1: General Framework. Fast handover is implemented by adding 4 new messages which are 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: - Router Solicitation for Proxy (RtSolPr) - MN to oldAR - Proxy Router Advert (PrRtAdv) - oldAR to MN - Handover Initiate (HI) - oldAR to newAR - Handover Ack (HAck) - newAR to oldAR - Binding Update (BU/BACK) - as defined in [MIPv6] + some flags The behavior of the entities involved in the exchange are described as follows. To initiate a fast handover the mobile node sends a Router Solicitation for Proxy to the oldAR 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 oldAR 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 Design Team 3 Internet Draft Fast Handovers for MIPv6 February 2001 use to form your new care-of-address (COA). The mobile node sends a Binding Update using its newly formed COA as the last message before it executes the handover. The mobile node then receives a Binding Acknowledgement either through the oldAR or the newAR indicating that the binding was complete. Whenever a mobile node moves to the newAR it sends the Neighbor Advertisement to initiate the flow of packets that may be waiting there for the mobile. The oldAR 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 Binding Update to the oldAR with its new care-of-address. The mobile receives a Binding Acknowledgement indicating that the handover is complete. The MN needs to be prepared for a number of error conditions. It may not receive a response to an initial RtSolPr in which case it needs to resend it. It also may not receive a response to its Binding Update in which case it needs to sends a Neighbor Advertisement to the newAR. If it does not receive its BACK at this point, the Binding Update never got to the old access router and the Binding Update needs to be resent. The oldAR communicates with the MN using the exchange of packets described above. If the mobile node is initiating the handover it will receive a Router Solicitation Proxy with some access network information. It 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 oldAR 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 oldAR 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 oldAR MUST wait for a Binding Update from the MN before actually forwarding packets. The oldAR sends a Binding Update acknowledgement message to the mobile node through the temporary tunnel that is constructed and to the mobile node over its old link. If the oldAR is initiating the handover, it will begin the exchange by using the Proxy Router Advertisement informing the MN of the new care-of-address that will be used to deliver packets to it. The oldAR MUST wait for a Binding Update from the MN before actually forwarding packets. The oldAR 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 MN the oldAR exchanges information with the newAR to facilitate the forwarding of packets between the two and reduce the latency perceived by the MN during the handover. The oldAR sends a Handover Initiate (HI) message to the Design Team 4 Internet Draft Fast Handovers for MIPv6 February 2001 newAR with the requested care-of-address on the newAR and the care- of-address being used currently at the oldAR. The oldAR 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 oldAR sets up a temporary tunnel to forward packets destined for the mobile to the new care-of-address on the newAR. If the new care-of-address is rejected by the newAR, the oldAR 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 newAR. In either case the oldAR does not forward packets until it has received a Binding Update from the MN. In the case of stateful address allocation, the HI/HACK exchange needs to be completed before the Proxy Router Advertisement is sent to the mobile node. The newAR also exchanges messages with the oldAR and forwards messages between the oldAR and the MN. When the newAR receives an HI message without a new COA it allocates a new COA and sends it to the oldAR in the HACK message. When the newAR receives an HI message with a new COA it determines whether the newCOA is valid and sends an indication in the HACK message. If a valid newCOA is returned to the oldAR the newAR will be receiving packets for the MN with a valid newCOA and will just forward them as normal to the MN. If no valid newCOA is determined, the newAR will record the oldCOA, de-tunnel the packets received in the tunnel from the oldAR and deliver them to the MN. The newAR will deliver packets to the MN when it receives an indication from the access network that it can begin sending packets to the MN or when it receives a neighbor advertisement from the MN, also an indication that it can send packets to the MN. The following summarizes the semantics of the messages. The Router Solicitation for Proxy is always an indication to the oldAR that the MN 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 MN should go ahead and move and it provides the prefix or address to be used on the New AR. If the handover is mobile determined it provides information about whether the handover will involve moving to a new AR. 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 newAR. In network determined handover, failure to conform with the Proxy Router Advertisement may result in loss of service. The Binding Update indicates the Binding that the mobile node wants the oldAR to make. It also indicates to the network that the mobile is moving and that it wants its packets forwarded. Design Team 5 Internet Draft Fast Handovers for MIPv6 February 2001 The Binding Update Ack indicates whether the Binding Update was successful. A negative acknowledgement may indicate that the newCOA is invalid or that the Binding Update failed for any of the standard reasons. The Handover Initiate Message indicates the oldAR is trying to facilitate a fast handover to the newAR and the oldCOA that will be used in the case that the requested address negotiation between the routers fail. The Handover Ack Message indicates what the newCOA should be in the new Router. 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. In either case the ultimate decision is on the mobile, in that no routing change (no redirection of packets) takes place unless the MN confirms the handover with a Binding Update to the old Access Router. 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 oldAR realizes (or gets notified) that a MN must move to a newAR it compiles a newCOA based on the MN's Interface ID and the newAR's Prefix. It then sends this newCOA to the MN together with the NewAR IP address and Link Layer Address using the PrRtAdv message. At the same time the oldAR sends the HI message to the newAR indicating the MN's oldCOA as well as the newly created newCOA. The newAR first establishes whether the newCOA is a valid address performing checks to ensure that it is not a duplicate. If the newCOA is legal and acceptable to the newAR it adds it to the Neighboring Cash for a short time period so it can defend it and it responds with an HACK. If the newCOA is not valid (e.g.: used by other node) the newAR adds a host route for the oldCOA pointing to its mobility interface, for a short time period and responds to the oldAR with a HACK (newCOA not valid). Design Team 6 Internet Draft Fast Handovers for MIPv6 February 2001 MN oldAR newAR | | | |<------PrRtAdv-------|--------HI--------->| |--------BU---------->|<-------HAck--------| Disconnect <--BACK--|--BACK--> | | | | | forward | | packets===============>| | | | |--------------------NA-----------> | | | deliver |<=====================================Packets Figure 2: Network Determined and Stateless If the HACK indicates the newCOA is valid the oldAR will get ready to forward packets for this MN to its newCOA. If the HACK indicates the newCOA is not valid the oldAR will get ready to forward packets for this MN to the newAR. The oldAR will only change its routing regarding an MN after it receives a BU from the MN confirming the handover. This BU SHOULD be sent (if permitted by the link layer conditions at handover time) to the oldAR while the MN is still connected to the oldAR. If this is not possible the BU MUST be sent after the MN connects to the newAR. The oldAR MUST then send a BACK message to the MN both locally and by way of newAR (using the newCOA or the newAR as encapsulating address) On reception of the BU and providing the HACK has also been received, the oldAR can start forwarding packets destined to the MN's oCOA to either the newCOA or the newAR, depending of the HACK value. Additionally, and if the link layer supports such indications, the oldAR MAY delay the routing change until it determines that the MN has disconnected. Now the oldAR acts as a Home Agent with home address being the MN's oldCOA and care-of-address being either the MN's newCOA or the newAR address. The MN MUST NOT use the newCOA address as source address until it receives a BACK from the oldAR. The BACK may be received while the MN is still connected to the oldAR in which case the MN will only have to announce itself to the newAR to get full connectivity. In the case were the BACK was sent but not received at the oldAR, there will be a copy of it waiting for the MN at the newAR. If the BACK is not received at all the MN should assume the BU was not received by the oldAR and it MUST resent the BU to the oldAR. Design Team 7 Internet Draft Fast Handovers for MIPv6 February 2001 3.1.2. Stateful new Care-of-Address Configuration An alternative message sequence has HI/HAck message exchange proceeds the PrRtAdv message send from the oldAR to the MN. This provides a way to retrieve the correct contents for the PrRtAdv from the newAR when this information is not available to the oldAR by other means. MN oldAR newAR | | | | |--------HI--------->| | |<-------HAck--------| |<------PrRtAdv-------| | | | | Figure 3: 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 oldAR and trigger the Proxy router Advertisement. In the RtSolPr message the MN indicates the Link Layer address or the Identifier of the Attachment Point that it wants to attach to. The oldAR will then reply with a PrRtAdv which contains the same information with the stateless approach of Network Determined approach. MN oldAR newAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------|--------HI--------->| |--------BU---------->|<------HACK---------| Disconnect <--BACK--|--BACK--> | | | | | forward | | packets===============>| Connect | | |------------------NA-------------> | | | Deliver |<=====================================Packets Figure 4: Mobile Determined Design Team 8 Internet Draft Fast Handovers for MIPv6 February 2001 The rest of the behavior is the same in that the newCOA is sent to the newAR for validation using the HI/HACK sequence and the oldAR 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 MN disconnects, while the MN does not use the newCOA until it receives a BACK. After all this is done, as before, the oldAR acts as a Home Agent with home address being the MN's oldCOA and care-of- address being either the MN's newCOA or the newAR address. 3.3. Sending Binding Updates at the New Access Router When the mobile node move to a new access router, it needs to send a Binding Update to its home agent. It also may need to send a 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 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 effectively carry out the retransmission algorithm for Binding Updates, as specified in [MIPv6]. 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 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 Binding Acknowledgement from the old access router, then the mobile node SHOULD arrange for oldAR to receive an appropriate Binding Update associating the mobile node's new care-of address to its new care-of address (as specified in [MIPv6]). Therefore, we specify that if the mobile node knows the address of the newAR, it should first send any necessary Binding Update packet to its old access router, before sending the Binding Update packet to its home agent. Furthermore, alternative encapsulation strategies, which would allow both Binding Update options to be sent with a single transmission Design Team 9 Internet Draft Fast Handovers for MIPv6 February 2001 over the air from the mobile node, are the subject of current discussion in the design team. If the mobile node does not know the address of the new access router, Neighbor Discovery will have to take place before the Binding Update is send. In some circumstances, packets sent by the mobile node to the previous access router just before handover may have been dropped. If this information contained directives to the oldAR to initiate the smooth handover, the new access router may not have taken any steps to speed up the handover before the mobile node arrives. In this case, the mobile node may assume that the new access router is ready to provide connectivity, and then send a Binding Update through the new access router before Duplicate Address Detection has been accomplished for the new care-of address. In this case, the new access router is expected to send a (perhaps newly defined) ICMP message back to the mobile node. After taking care of the necessary processes to protect its link-local address on the network at the new point of attachment, the mobile node MAY resend the same Binding Update packet(s) to the new access router, and/or home agent without any recalculation. 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 Binding Acknowledgement for the Binding Update sent to the old access router before breaking the old connection. 4b. The mobile node may fail to receive the Binding Acknowledgement for the Binding Update sent to the previous access router before breaking the old connection. Design Team 10 Internet Draft Fast Handovers for MIPv6 February 2001 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 Binding Acknowledgement for the Binding Updates that it has sent, then it MUST retransmit those Binding Updates according to the retransmission algorithm specified in the base Mobile IPv6 document. 4. Message Extension 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. 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 ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IP address assigned to the sending interface Destination Address The address of the Access Router Hop Limit 255 Design Team 11 Internet Draft Fast Handovers for MIPv6 February 2001 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. 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 PrRtAdv 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 PrRtAdv is not received by the time the mobile node disconnects from oldAR, Fast Handover can Design Team 12 Internet Draft Fast Handovers for MIPv6 February 2001 not be performed and the mobile node SHOULD revert back to normal MIPv6. 4.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. ICMP Fields: Type TBA Code 0 - Handover Information 1 - No change of COA required 2 - New Attachment Point not known Checksum The ICMP checksum. See [ICMPv6]. Identifier Copied from Router Solicitation for Proxy or set to Design Team 13 Internet Draft Fast Handovers for MIPv6 February 2001 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 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 sateful configuration, this option MUST be sent to allocate an address on behalf of the Access Router this message is proxied for. 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 newCOA for the duration of the handover. If not sent the requesting node SHOULD compute the newCOA using the Interface ID from the Destination Address of this message. 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 PrRtAdv with Code 0 but without a New COA Option means that the mobile node SHOULD construct a newCOA out of its Interface ID (used in the Destination Address in this PrRtAdv) and the Prefix in the Prefix Information Option. A PrRtAdv with Code 0 and a New COA Option means that the mobile node SHOULD use the COA indicated as a newCOA at the new Access Router. This MUST used when Stateful COA configuration is in use and MAY be used to help the oldAR and MN calculate the same newCOA when Stateless COA configuration is used. Design Team 14 Internet Draft Fast Handovers for MIPv6 February 2001 A PrRtAdv 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 PrRtAdv with Code 2 means that the oldAR is not aware of the Prefix Information requested. The MN 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 RtSolPr received. 4.3. 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 Design Team 15 Internet Draft Fast Handovers for MIPv6 February 2001 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. 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 HACK message is not received as a response to this message. the HI 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 HACK means that no fast handover can be performed. The purpose of this message is to notify the newAR about the upcoming handover and establish a valid newCOA for the mobile node. If the S flag is SET this message requests an Design Team 16 Internet Draft Fast Handovers for MIPv6 February 2001 address from the newAR to be assigned statefully. If the new COA option is included the oldAR requests the newAR to confirm that this is a valid newCOA. 4.4. 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 HI Message this message is in response to. Destination Address Copied from the source address of the HI 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 Design Team 17 Internet Draft Fast Handovers for MIPv6 February 2001 129-Administratively prohibited 130-Insufficient resources Checksum The ICMP checksum. See [ICMPv6]. Identifier Copied from the corresponding field in the HI 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 HI 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 HI the newAR MUST respond with an HACK. If the S flag is SET in the HI, the newAR SHOULD include the new Care of Address option and a Code of 3. If the S flag is not SET in the HI, the newAR SHOULD check the validity of the newCOA sent with the HI and reply accordingly. If the newCOA is valid and the handover the newAR SHOULD insert the newCOA in its Neighbor Cash 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 newAR. If the newCOA is not valid or not assigned (Stateful) the newAR SHOULD insert a host route, pointing to its mobility interface the mobile node is expected to connect to, for the mobile's oldCOA. The newAR can always refuse the handover in which case it should indicate the reason in one of the available Code values. 4.5. 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]. Design Team 18 Internet Draft Fast Handovers for MIPv6 February 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 | 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 PrRtAdv and HACK messages only contain the newCOA while the HI message may include both newCOA and oldCOA. 4.6. 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Design Team 19 Internet Draft Fast Handovers for MIPv6 February 2001 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. 4.7 Modified Binding Update Option Two flags B, U are added to the flag bits in the Binding Update Option. The mobile node sets the B flag in the Binding Update, to indicate that the mobile node would like the AR to do bicasting. The mobile node sets the U flag in the Binding Update to indicate that Design Team 20 Internet Draft Fast Handovers for MIPv6 February 2001 the mobile node would like the AR to do buffering. Finally the AR MAY honor the bicasting and buffering requests or reject them silently. Thus, the Binding Update Option under Fast Handovers for Mobile IPv6 will show as below: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|B|U|r|r| Prefix Length ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B The mobile node is requesting the AR to do bicasting. U The mobile node is requesting the AR to do buffering. r reserved and it MUST be set to 0. The rest of the flag bits and the other fields are as defined in [MIPv6]. Description This message MUST be send by the mobile node to the old Access Router so that the latter can redirect traffic to the mobile node by the way of the new Access Router. The message SHOULD be sent while the mobile node is still connected to the oldAR and a BACK SHOULD be received at the same place. If that is not possible, due to link layer conditions, the BU MUST be send or resend at the newAR and the BACK MUST be received before the mobile node can use the newCOA. The initial retransmission timer for the BU in this particular case should be very short but no less than 1.5 worst case RTTs of the link layer after the MN connects to the newAR. The BU SHOULD be resent using exponential backoff but only once or at most twice more. If that does not yield a BACK the mobile node MUST give up the attempt for a fast handover and revert back to normal MIPv6. DISCUSSION: The design team has recently come to the conclusion that a different TYPE should be used for the Fast Handoff BU and BACK (maybe we will call the new messages FBU and FBACK). This new TYPE would ensure that the oldAR will only make a routing change, after reception of a FBU AND a HACK as opposed to the regular BU which does not require a HACK. In an effort to catch the I-D submission deadline, however, we have postponed this change for after the IETF meeting. Design Team 21 Internet Draft Fast Handovers for MIPv6 February 2001 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 MN's address is duplicated or not, before the MN 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 MN'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 MN would have to perform DAD after moving to the new subnet. To avoid delays due to performing DAD, it is suggested that the MN performs DAD while using its oldCOA. This is possible since the framework described in this specification allows packet redirection based on the oldCOA encapsulated into the newAR IP address. So, if the newAR cannot confirm the validity of the newCOA address included in the HI message but is never the less willing to serve the MN it can describe that in the HACK message and install a host route towards its mobility interface regarding the MN's oldCOA. The oldAR on reception of this type of HACK replies with a BUNACK to the BU sent by the MN attempting to registers is newCOA. The oldAR now forwards packets for this MN to the newAR which will decapsulates and due to the host route installed earlier it can forward these packets to the mobile. The MN will at some point, either at the old or at the newAR receive the BUNACK and thus attempt to get a newCOA. If the MN does not receive the BACK or BUNACK at the oldAR and after connecting to the newAR it still does not receive it in a short time frame (X sec) it can assume that the BU was not received by the oldAR and it MUST retransmit it. The source address used in this BU SHOULD be the Design Team 22 Internet Draft Fast Handovers for MIPv6 February 2001 newCOA, which is not yet confirmed, to avoid ingress filtering. If the newCOA is not valid the oldAR will send (or resend) a BUNACK to the oldAR, encapsulated in the address of the newAR and thus it will safely be received by the MN. 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 oldAR and the MN, as well as between the old and newARs. Providing the above is true then, routing is only changes by a BU from the MN, which MUST be authenticated. It is also highly recommended that RtSolPr and PrRtAdv messages are also authenticated since they are between oldAR and MN 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. [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. Design Team 23 Internet Draft Fast Handovers for MIPv6 February 2001 [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 24 ---------------------------------end--------------------------------------