Personal G. Dommety Editor A. Yegin C. Perkins G. Tsirtsis K. El-Malki M. Khalil Internet Draft Title: draft-ietf-mobileip-fast-mipv6-03.txt Category: Informational July 2001 Expires : December 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 Mobile IPv6 describes how a mobile node can change its point of attachment from one access router to another (this process is referred to as Handoff). During this process, there could be a time period during which the mobile node is unable to send or receive IPv6 packets. This time period is referred to as handoff latency. In certain scenarios, the handoff latency resulting due to procedures described in Mobile IP v6 could be greater than what is acceptable to support real-time or delay sensitive traffic. The intent of this Design Team 1 Internet Draft Fast Handovers for MIPv6 July 2001 document is to describe protocol enhancements that can be used to minimize handoff latency, thereby making mobile IP v6 better equipped to support real-time traffic. 1. Introduction.....................................................3 1.1. Terminology...................................................4 1.2. Standards Language............................................6 2. Protocol Overview................................................6 3. Supported scenarios.............................................10 3.1. Predictive Handoff Scenario..................................10 3.1.1. Predictive Handoff Overview...............................11 3.1.2. Network Determined Handover...............................14 3.1.3. Stateless new Care-of-Address Configuration...............15 3.1.4. Stateful new Care-of-Address Configuration................16 3.1.5. Use of Old CoA............................................17 3.1.6. Mobile Determined Handover................................17 3.1.7. Three Party Handover......................................18 3.1.8. Sending BUs, F-BUs and F-NAs at the New Access Router.....19 3.1.9. Features enabling Partial Handover Optimization...........21 3.2. Layer-2 Trigger based Handoff Scenario (BETH)................22 3.2.1. L2 Triggers...............................................23 3.3. Two Party Handover...........................................23 3.4. Three Party Handover.........................................28 3.4.1. Renewal or Termination of Tunneling Service...............34 3.5. Termination of BETH..........................................34 3.5.1. BET End of Life or Premature BET Termination..............35 3.5.2. MN Decision to Obtain a nCoA..............................36 4. Interoperability of different Fast Handoffs Methods.............37 5. Message Definitions and Option Formats..........................38 5.1. New Neighbor Discovery messages..............................38 5.1.1. Router Solicitation for Proxy (RtSolPr)...................38 5.1.2. Proxy Router Advertisement (PrRtAdv)......................40 5.1.3. Fast Neighbor Advertisement (F-NA) Message Format.........42 5.2. Inter-Access Router Messages.................................45 5.2.1. Handover Initiation (HI)..................................45 5.2.2. Handover Acknowledgement (HACK) Message...................47 5.2.3. Handover To Third (HTT)...................................50 5.3. New Destination Options......................................50 Design Team 2 Internet Draft Fast Handovers for MIPv6 July 2001 5.3.1. Fast Binding Update (F-BU) Destination Option.............50 5.3.2. Fast Binding Acknowledgement (F-BACK) Destination Option..53 5.4. New ICMP options.............................................55 5.4.1. IP Address Option.........................................55 5.4.2. Link-layer Addresses (LLA)................................56 5.4.3. Lifetime Option...........................................57 5.4.4. Neighbor Advertisement Acknowledgement (NAACK)............58 5.4.5. Handover Capabilities Extension...........................59 6. Error Cases and other issues....................................60 6.1.1. DAD handling..............................................60 6.1.2. Fast and erroneous movement...............................61 7. Neighbor Cache Considerations...................................62 8. Security Considerations.........................................63 8.1. Security Considerations for Predictive Handoff...............63 8.2. Security Considerations for BETH.............................63 8.2.1. MN to AR Connection.......................................63 8.2.2. AR to AR Connection.......................................63 9. Acknowledgements................................................64 10. References.....................................................64 11. Addresses......................................................65 1. Introduction Mobile IPv6 describes how a mobile node can change its point of attachment from one access router to another (this process is referred to as Handoff). During this process, there could be a time period during which the mobile node is unable to send or receive IPv6 packets. This time period is referred to as handoff latency. In certain scenarios, the handoff latency resulting due to procedures described in Mobile IP v6 could be greater than what is acceptable to support real-time or delay sensitive traffic. The intent of this document is to describe protocol enhancements that can be used to minimize handoff latency, thereby making mobile IP v6 better equipped to support real-time traffic. There are several factors that determine the handoff procedure to be used in a certain scenario. Some of these factors are: 1. The element (Network or Mobile) that makes the handoff decision. Design Team 3 Internet Draft Fast Handovers for MIPv6 July 2001 2. The amount of information about the handoff that is available. For example knowing the IP and MAC address of the new Access Router (AR) 3. The extent of Link Layer support (the amount of coupling between the Link Layer and Network Layer) and the type of Link Layer Triggers that are available during the handoff. 4. The amount of prediction that is possible. If the movement of the mobile can be predicted the in advance (i.e. before the handoff), it is possible to achieve a lower latency handoff. 5. The type of link layer. For example if a link layer supports connecting to two Access Routers at the same time, it is possible to achieve a lower latency handoff. This document describes two of the three different handoff scenarios: 1. Predictive Handoff: Scenario in which the network layer handoff to the New Access Router is initiated while the Mobile Node still has Layer-2 connectivity to the current access router and about to move to a new access router. In this scenario, it is assumed that there is knowledge of the new Access Router to which the mobile is likely to connect to (or there is ability to request the mobile to connect to a certain new Access Router). 2. Layer-2 Trigger based Handoff (also called BETH: Bi-Directional Edge Tunnel Handoff): Scenario in which the Network determines the new Access Router to which the mobile is to be connected and performs the handoff procedures without the involvement of the mobile node. 3. Scenario in which the mobile realizes that the mobile has lost Link Layer connectivity to the Old Access Router and acquires Link Layer Connectivity to the New Access Router. This scenario is covered in Mobile IPv6 [MIPv6]. 1.1. Terminology This section introduces some terminology used throughout the draft. MN - Mobile Node or Mobile Station. AR - An access router is the last router between the network and the mobile node, i.e., the MN has link Layer connectivity to the Access Router. oAR - old Access Router, the AR involved in handling a MN's traffic prior to an L2 handover. nAR - new Access Router, the AR anticipated to be handling a MN's traffic after completion of an L2 handover. aAR - anchor Access Router where the MN originally established its aCoA (the CoA that is known to the HA and the Correspondent nodes). It is the AR that is currently handling the network end of the BET. Design Team 4 Internet Draft Fast Handovers for MIPv6 July 2001 cCoA - - Current Care of Address, the Care of Address to which the HA and the Correspondent Nodes forward the data destined to the MN. oCoA - old Care of Address, the Care of Address prior to the MN's first movement. In this document, it may be reused until the MN determines an appropriate time to change it, even if the MN changes subnet. nCoA - new Care of Address, the Care of Address in the new subnet. In this document, configuration with a nCoA may be delayed while the MN is engaged in latency-sensitive real time traffic or is rapidly moving across a series of ARs. aCoA - anchor Care of Address, the Care of Address after a MN has moved and elected not to establish a nCoA at nAR. HI Designates a Handover Initiate message. HI(s), HI(r), and HI (t) are HI message with s, r, or t bits set respectively. HAck Designates a Handover Acknowledgement message. HAck(s), HAck(r), and HAck(t) are HAck message with s, r, or t bits set respectively. HTT - - Designates Handover To Third. An HTT message is exchanged between an oAR/aAR and an nAR (the "third" in the name) when a tunnel is already established for the MN to an aAR and the MN is using an aCoA. The HTT sent as a request is a variant of the HI message while the HTT sent as a reply is a variant of the HACK. Uni-directional Tunnel - - A Uni-directional tunnel placed between the AR where the MN first established its current CoA and the new CoA obtained by the MN. The traffice destined to the MN is tunneled through this tunnel. The traffic originating from the MN will not be encapsulated through this tunnel. The MN uses the new CoA and therefore does not run the risk of ingress or egress filtering. bi-directional tunnel (BT/BET) - A bi-directional tunnel placed between the AR where the MN first established its current CoA and a new AR to which the MN is attached, where the CoA would be topologically incorrect if used. The new AR tunnels packets from the MN and having the source address as the MN's old CoA to the old AR. The old AR tunnels packets to the MN and having the destination address as the MN's old CoA to new AR. The new AR detunnels the MN-directed packets and sends them over the radio link to the MN (and hence there is no BET tunnel overhead on the air link). The old AR detunnels CN- directed packets and sends them into the subnet where the old CoA is topologically correct. BTs allow use of the old CoA without running the risk of ingress or egress filtering. Design Team 5 Internet Draft Fast Handovers for MIPv6 July 2001 L2 handover - Movement of a MN's point of Layer 2 (L2) connection from one wireless access point to another. Depending on the L2, an L2 handover may traverse both a wireless and a wired link, or just a wired link. L3 handover - The process by which a MN obtains a new CoA from the AR, thus updating its routing reachability. L3 handover may occur partially before and partially after L2 handover, or it may occur entirely after L2 handover. L2 trigger - Information from L2 that informs L3 of the detailed events involved in handover sequencing at L2. L2 triggers are not specific to any particular L2, but rather represent generalizations of L2 information available from a wide variety of L2 protocols. source trigger - An L2 trigger that occurs at oAR, informing the oAR that L2 handover is about to occur. target trigger - An L2 trigger that occurs at nAR, informing the nAR that an MN is about to be handed over to nAR. edge network - A collection of interconnected subnets within a local routing domain that connect directly with the wireless network via wireless access points. IP address identifier - An IP address of a MN or AR, or an L2 identifier that allows an AR to deduce the IP address of a MN or AR. If it is an L2 identifier, the identifier is specific to the L2 technology. ping-ponging - - Rapid back and forth movement between two wireless access points due to failure of L2 handover. Ping- ponging can occur if radio conditions for both the old and new access points are about equivalent and less than optimal for establishing a good, low error L2 connection. 1.2. Standards Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 2. Protocol Overview In this section a high level overview of the fast handoff procedure is described. Design Team 6 Internet Draft Fast Handovers for MIPv6 July 2001 +------+ |CN/HA | +------+ ^ | ... | v +------+ +------+ | cAR |.------->| nAR | +------+ +------+ ^ | wireless link v movement +------+ ---------> | MN | +------+ Figure 1: High Level Overview of Fast Handoff An access router is the last router between the network and the mobile node. Under normal conditions (i.e, not in a handoff state), when an MN is attached to a foreign link connected to the Current AR (i.e., the mobile is away from its home link) MN receives packets routed to the Current CoA (cCoA) as specified in Mobile IP v6 specification. 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, cAR) and the new Access Router (newAR) is the router to which the mobile node is about to move. This document primarily specifies methods by which, when a MN moves to the new AR, packets destined to the MN via the current CoA (cCoA) are delivered via the nAR. In order to route these packets destined to the MN, the cAR creates a tunnel and uses proxy Neighbor Discovery to intercept any IPv6 packets addressed to the cCoA on the above mentioned foreign link, and tunnels each intercepted packet. The end-point of this tunnel depends on whether the MN is successful in obtaining a new CoA. If MN is able to obtain a new CoA, the packets are tunneled to the new CoA. Otherwise, the packets are tunneled to the nAR address and the nAR decapsulates and delivers the Packets to the MN via Link Layer mechanisms. Design Team 7 Internet Draft Fast Handovers for MIPv6 July 2001 Whenever the MN can it SHOULD obtain a new CoA and send Binding Updates to update the binding information with the nCoA information to the correspondent nodes and the Home Agent as specified in Mobile IPv6. If the MN is unable to send Binding updates to the correspondent nodes/Home Agent( for various reasons, one of the reasons being that of not being able to obtain a new CoA) and the MN has to handoff, three parties are involved in this handover (refer to this handoff as three party handoff). The inability to perform MIP registration may result from either a specific decision by the MN due to an ongoing real time media stream, or it may result from rapid movement between oAR and nAR that does not allow enough time for the registration to complete. Three party handoff occurs when the MN is on aAR (i.e., packets destined to the MN are routed to aCoA), then moves to oAR, then moves to nAR before completing MIP registration at oAR. In this case, in order to route packets to the MN, the aAR moves the tunnel to route the packets via the nAR. The Three Party handoff is shown below. +------+ |CN/HA | +------+ ^ | ... | v BT-2 +------+ <-------------------> +------+ | aAR | +------+ | nAR | +------+ <------> | oAR | +------+ BT-1 +------+ ^ ^ | | | v | first movement(BT-1)+------+ | ---------> | MN | | +------+ | v Second movement(BT-2) +------+ ---------> | MN | +------+ Figure 2: High Level Overview of Fast Handoff to the Third Design Team 8 Internet Draft Fast Handovers for MIPv6 July 2001 Initially the MN is attached to the aAR and moves to a link attached to oAR, during that time the traffic is routed via the oAR to the MN (the BT/UT is between the aAR and the oCoA). Before the MN performs a Mobile IP v6 registration with the oCoA, if it moves to plans/supposed to move to nAR, the packets destined to the MN are routed via the nAR (the BT/UT is between the aAR and the nCoA. In both the predictive and L2 trigger based handoffs the concepts are similar, the exact procedures will vary depending on the specific scenario. The messages described below are used in this specification and are defined in detail in later sections together with a number of new options. The use of these messages to achieve a fast handoff in the various scenarios is explained in later section. - Router Solicitation for Proxy (RtSolPr) - - Sent by the MN to the older. The Router Solicitation for Proxy is 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. - Proxy Router Advertisement (PrRtAdv) - - Sent by the oldAR to the MN. 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. - Handover Initiate (HI) - The Handover Initiate message indicates that this access router is trying to facilitate a fast handover of the MN to the new access Router. - Handover Acknowledgement (HAck) - The Handover Acknowledgement message indicates what the new care-of-address should be in the new Access Router and is sent as an Acknowledgement to the HI message. - Handover to the Third (HTT)- is a instance of HI or HAck message depending on the usage as explained later. - Fast Binding Update (F-BU) - - from the MN to the older or Anchor AR. The Fast Binding Update indicates the Binding that the mobile node wants the access router to make. It also indicates to the network that the mobile is moving and that it wants its packets forwarded. Design Team 9 Internet Draft Fast Handovers for MIPv6 July 2001 - Fast Binding Acknowledgement (F-BACK) - - from the older/Anchor AR to the MN. 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. - Fast Neighbor Advertisement (F-NA) - - from MN to newAR. 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. The exact behavior of the entities involved in the exchange are described in the sections below. 3. Supported scenarios 3.1. Predictive Handoff Scenario This describes the scenario in which the network layer handoff to the New Access Router is initiated while the Mobile Node still has Layer- 2 connectivity to the current access router and about to move to a new access router. This method covers the following sub-scenarios: 1. Network Determined Handoff versus Mobile Determined Handoff. 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. 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. 2. New Care-of-Address Versus the Old CoA. This proposal facilitates 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 on connection with new access router. The areas of preparation are new care-of-address configuration, Duplicate Addressing avoidance and Neighbor Discovery. This specification also permits the movement without obtaining a new CoA, when a valid CoA cannot be obtained from the new AR (i.e, the mobile node uses the old CoA). 3. Stateful new CoA Configuration versus Stateless new CoA configuration. This method 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 10 Internet Draft Fast Handovers for MIPv6 July 2001 3.1.1. Predictive Handoff Overview MN oldAR newAR | | | 1 |------RtSolPr------->| | 2 |<-----PrRtAdv--------|--------HI--------->|3 4 |------F-BU---------->|<------HACK---------|5 Disconnect 6<--F-BACK--|--F-BACK--> 6 | | | | | forward | | packets===============>|7 Connect | | |----------------F-NA-------------> 8 | | | Deliver 9|<=====================================Packets Figure 3: Predictive Handoff Overview 1. In the scenario the MN initiates a fast handoff by sending a Router Solicitation for Proxy (RtSolPr)to the old access router to the older. This message is 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. The Router Solicitation Proxy contains identification of the new AR. 2. In response to the RtSolPr the old AR sends a Proxy Router Advertisement message to the MN. This message is used to indicate one of the three possible outcomes: a) Point of attachment is unknown. If it does not understand the access network information it will respond saying that the access network information is unknown. b)The point of attachment is known and is connected through the same access router. 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. Design Team 11 Internet Draft Fast Handovers for MIPv6 July 2001 c) The Point of attachment is known. The message also contains the CoA the MN should use or information of the network prefix that should be used to form the CoA. 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. 4. The mobile node sends a Fast Binding Update using its newly formed COA as the last message before it executes the handover. 6. On receipt of the Fast Binding Update and validation, the old AR responds with a Fast Binding Ack. The old access router waits for a Fast Binding Update from the mobile node before actually forwarding packets. On receipt of the Fast Binding Update the old AR forms a temporary Tunnel (for the lifetime specified in the Fast Binding Ack). 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. 8. 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 waits for a Fast Binding Update from the mobile node before actually forwarding packets. On receipt of the Fast Binding Update the old AR forms a temporary Tunnel (for the lifetime specified in the Fast Binding Ack). 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. 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. In order to obtain a new CoA for the MN or to establish a temporary tunnel the old access router sends HI to the new Access Router. When the new access router receives a Handover Initiate message it does the following: 1. If the HI message does not have 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. Design Team 12 Internet Draft Fast Handovers for MIPv6 July 2001 2. 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. a. 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. b. If no valid new care-of-address is determined, then the new AR will expect the old AR to tunnel the packets destined to the mobile to its address, i.e., a tunnel is established between the old AR and the new AR to forward traffic. In this case the old AR forwards the packets through the tunnel (i.e, encapsulates the packets destined to the mobile and sends them to the new AR) and the new access router 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 (issue with the expiry of this tunnel). 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. The temporary tunnel has a lifetime defined by the lifetime option in the HI message. 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 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 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 Design Team 13 Internet Draft Fast Handovers for MIPv6 July 2001 temporary tunnel that is constructed and to the mobile node over its old link. The mobile uses the following procedures to deal with 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. - 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 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. 3.1.2. Network Determined Handover 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. Design Team 14 Internet Draft Fast Handovers for MIPv6 July 2001 In this scenario both stateless and stateful care-of-address configuration is supported. The scenario where the Old CoA is used is also supported. 3.1.3. 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 4: Network Determined and Stateless Handover 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. Design Team 15 Internet Draft Fast Handovers for MIPv6 July 2001 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. The Mobile node might form the address from the prefix of the new AR and use that in the Binding Update (verify that this will work). The Old AR sends the HI to the new AR (if the old AR is un-sure of the uniqueness of the newly chosen CoA. If ). The old AR receives the HAck either confirming or denying the the uniqueness of the address in the New network. This is simailr to the case explain above, with the difference that in this the mobile chooses the CoA from the Prefix. 3.1.4. 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 Design Team 16 Internet Draft Fast Handovers for MIPv6 July 2001 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 5: Network Determined and Stateful Handover The rest of the process is identical to the stateless approach 3.1.5. Use of Old CoA In the above describe procedures, if the nCoA is not successfully established for some reason, the aAR or oAR tunnels the packets to the nAR, and nAR delivers the packets to the mobile. This Tunnel unlike other tunnel is a Bi-Directional Tunnel. This method operates similar to the L2 Trigger Based with the exception that that mobile sends a BU and that is used as a trigger to form tunnels and also forward data. The Tunnel is deleted on the expiry of the lifetime timer, which is set according to the lifetime option in the HI/HAck messages. When a mobile moves to a third AR, the Tunnel is anchored instead of being chained, as specified later in this document. Explicit option in the F-BU for the usage of old CoA: This option is not covered in this specification. Need to be explored further. 3.1.6. 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 Design Team 17 Internet Draft Fast Handovers for MIPv6 July 2001 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 6: Mobile Determined Handover 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.1.7. Three Party Handover When a MN moves from one AR to another AR with out performing a Mobile IP registration, a Tunnel chain is created by the predictive handoff method explained above. This Chaining might not be desirable for the reasons of 1) additional processing at each of the ARs, 2) Design Team 18 Internet Draft Fast Handovers for MIPv6 July 2001 the potential of creating loops, 3) the multiple points of failure. In order to avoid this problem the Tunnel could be anchored instead of chained. Three party handoff occurs when the MN is on aAR (i.e., packets destined to the MN are routed to aCoA), then moves to oAR, then moves to nAR before completing MIP registration at oAR. In this case, in order to route packets to the MN, the aAR moves the tunnel to route the packets via the nAR. The Three Party handoff is shown below. MN nAR oAR aAR | | | | |------RtSolPr----------------->| | | |<-------------| | | | HI | | | | | | | |------------.| | | | HAck | | |<-----PrRtAdv------------------| | | | | | |----------------------F-BU--------------------->| | | | | | | |<+++++F-BAck++++| | | | | |<------------------F-BAck-----------------------| | | | | | | forward packets | | |<============================= | Connect | | | |---F-NA-------->| | | Deliver | |<===============Packets | Figure 7 - Three Party Handover 3.1.8. Sending BUs, F-BUs and F-NAs at the New Access Router Design Team 19 Internet Draft Fast Handovers for MIPv6 July 2001 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. 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 Design Team 20 Internet Draft Fast Handovers for MIPv6 July 2001 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.1.9. 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. 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 Design Team 21 Internet Draft Fast Handovers for MIPv6 July 2001 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. 3.2. Layer-2 Trigger based Handoff Scenario (BETH) In this scenario, the Network determines the new Access Router to which the mobile is to be connected and performs the handoff procedures without the involvement of the mobile node. In this method when a Mobile Node (MN) moves between subnets, signaling between the MN and various network elements over the radio link is avoided and the Old CoA is used to send and receive traffic from Corresponding Nodes (CNs) and its Home Agent (HA). In this approach the CoA change is delayed until IP traffic, and in particular real time IP traffic, is reduced or is absent, or until the MN is moving slowly enough that it has time to obtain a new CoA. If the MN moves while still using its old CoA, the ARs on its path set up a bi-directional tunnels between an anchor AR and the AR handling the MN to assure that the MN's traffic is routed properly. This approach allows the MN to move rapidly across a connected series of subnets without any MIP-related signaling traffic over the air. Figure 1 illustrates the basic idea behind Layer-2 Handoff. +------+ | CN | +------+ ^ | ... | v BET +------+ +------+ | aAR |<@@@@@@@@>| AR | +------+ +------+ ^ | wireless link v movement +------+ ---------> | MN | +------+ Figure 8 - BETH Concept Design Team 22 Internet Draft Fast Handovers for MIPv6 July 2001 BETH leverages off the BT established during fast handover to remove all MIP-related radio link signaling. Rather than performing signaling to establish the nCoA, the MN defers nCoA establishment and continues to use the BT and the aCoA established at the aAR. If the MN moves to another AR before establishing a nCoA, the AR to which the MN will attach signals aAR to move the wireless link end of the BT to it. The network end of the BT remains anchored at aAR until the MN changes CoA. 3.2.1. L2 Triggers This method requires an L2 trigger at oAR prior to L2 handover start (L2-ST) or an L2 trigger (L2-TT) prior to L2 handover completion at nAR, and an L2 trigger at oAR (L2-LD), nAR (L2-LU), and MN immediately upon completion of L2 handover. The following abbreviations are used in message flow diagrams to simplify referring to L2 triggers. For this method, it MUST support at least one of L2-ST or L2-TT, and L2-LU, it SHOULD also support L2-LD. For an MN, it MUST support L2-LU and it SHOULD support L2-LD. L2 Trigger Abbreviation ---------- ------------ Source Trigger L2-ST Target Trigger L2-TT Link Down L2-LD Link Up L2-LU Table 1 - L2 Triggers 3.3. Two Party Handover Two party handover involves handover between oAR and nAR when MN is using a CoA associated with oAR's subnet, and the handover occurs the first time an MN moves after having established a CoA at oAR. In this method, the MN delays establishing a nCoA if latency-sensitive real time traffic is underway. Design Team 23 Internet Draft Fast Handovers for MIPv6 July 2001 1a) L2-ST ~~~~> +------+ 2) HI +------+ <~~~ 1b) L2-TT | oAR |<-------->| nAR | 4a) L2-LD~> +------+ 3) HAck +------+ <~~~ 4b) L2-LU ^ ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 4c) L2-LU ---> | MN | ---------> +------+ Figure 9 - Two Party Handover The following describes the progress of a two party handover. The numbered items refer to steps in Figure 2. 1) Either the oAR or nAR receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are: a) The L2 trigger is a source trigger (L2-ST) at oAR. The trigger contains the MN's L2 address and an IP identifier (L2 address that can be mapped to an IP address or the IP address directly) for nAR. b) The L2 trigger is a target trigger (L2-TT) at nAR. The trigger contains the MN's L2 address and an IP identifier for oAR. 2) The AR receiving the trigger sends a Handover Indication (HI) to the other AR. There two cases: a) If oAR is sending the Handoff Initiate (HI), the H bit is set, indicating it is based on source trigger. The HI contains a Lifetime option, an IP address option containing the MN's home address, an IP address option containing the MN's oCoA, and an LLA option containing the MN's L2 address. The Lifetime option contains the amount of time the oAR is willing to extend tunnel service to the MN's packets before the nAR must renew the BT. If the lifetime is zero, the oAR is not willing to tunnel any packets for MN. b) If nAR is sending the Handoff Initiate, the T bit is set, indicating it is based on Target trigger. The HI contains a Lifetime option, and an LLA option containing the MN's L2. Neither the MN's home address nor the MN's oCoA are sent because neither are known. The Lifetime option contains a request for the amount of time the oAR should extend tunnel service for the MN's packets. Design Team 24 Internet Draft Fast Handovers for MIPv6 July 2001 3) The AR receiving the HI sends a Handover Acknowledgement (HAck) to the other AR. There are two cases: a) If oAR is sending the HAck, the T bit is set. The HAck contains a Lifetime option, an IP address option containing the MN's home address, an IP address option containing the MN's oCoA, and an LLA containing the MN's L2 address. The Lifetime option contains the amount of time the oAR is willing to extend tunnel service to the MN's packets before nAR must renew the request. If the lifetime is zero, the oAR is not willing to extend tunnel service to the MN. b) If nAR is sending the HAck, the H bit is set. No additional information is required, the sequence number identifies the reply. 4) Start of L2 handover is signaled by an L2-LD trigger at oAR and MN. Completion of L2 handover is signaled by an L2-LU trigger at nAR and MN. Each handles the trigger in the following way: a) When the oAR receives the L2-LD trigger, it begins forwarding MN-bound packets through the BET to nAR. b) When the nAR receives the L2-LU trigger, it begins delivering packets to the MN and forwards any outbound packets from MN through the BET to oAR. c) Based on its current movement traffic pattern, MN either defers obtaining a nCoA or begins the process of obtaining an nCoA. 5) The oAR becomes an aAR if MN should move again without having changed CoA to nAR's subnet, oCoA becomes aCoA, and nAR becomes oAR. 6) Should L2 handover fail in Step 4 and a ping-pong situation arise, the oAR can cancel the BT by sending an HI with R bit set to nAR with lifetime zero. In this case, the oAR simply continues delivering packets to MN exactly as if no handover had been pending. The actual timing of BT placement depends on the available L2 triggers. The BT is placed between oAR and nAR using the IPv6 tunneling procedure. With optimal L2 trigger information, as described above, the BT can be arranged immediately at the point of L2 handover, when the link to the MN goes down. In the absence of optimal L2 trigger information, the HAck acts as the trigger for BET placement. Particular implementation and deployment scenarios may require that techniques be employed to smooth handover by providing for a means to convey packets arriving during the unavailability of L3 service to the MN. The exact techniques involved in smoothing are currently under discussion in the working group and are outside the scope of this document. Design Team 25 Internet Draft Fast Handovers for MIPv6 July 2001 The forward and reverse tunnels are established as follows: 1) The forward tunnel is established by oAR, when it begins tunneling packets with MN's oCoA as the destination address to nAR. If the nAR receives any tunneled packets from the oAR with the MN's oCoA as the original destination, nAR de-tunnels them and sends them to MN. 2) The reverse tunnel is established by nAR, when it nAR begins tunneling packets from the MN with oCoA as the source address to oAR. If the oAR receives any tunneled packets from nAR with the MN's oCoA as the source address on the encapsulated packet, it de-tunnels the packets and routes them to the original destination address, as if the packet had been sent on oAR's subnet. Once the BT between aAR and the current AR is in place, it is torn down by one of the following events: 1) The aAR decides to stop tunneling because the lifetime it sent expires and was not renewed, or the aAR or current AR decide to terminate tunnel service for some other reason. 2) The MN completes the process of obtaining an nCoA through nAR. 3) The MN moves to a third AR. Sections 3.4.1 and 3.5 discuss Cases 1 and 2 in more detail, Case 3 is discussed in Section 3.4. Figures 3 and 4 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two party handover, respectively. Design Team 26 Internet Draft Fast Handovers for MIPv6 July 2001 MN nAR oAR | | | | | |<~~~ L2-ST | |<------------------| | | HI(s) | | | | | |------------------>| | | HAck(s) | | | | --------------------------------------------<~~~ L2-LD L2 Handover --------------------------------------------<~~~ L2-LU | | | | | | | | | | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 10 - Two Party Source Trigger Handover Timing Design Team 27 Internet Draft Fast Handovers for MIPv6 July 2001 MN nAR oAR | | | | L2-TT ~~~>| | | |------------------>| | | HI(t) | | | | | |<------------------| | | HAck(t) | | | | --------------------------------------------<~~~ L2-LD L2 Handover --------------------------------------------<~~~ L2-LU | | | | | | | | | | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 11 - Two Party Target Trigger Handover Timing 3.4. Three Party Handover Three party handover occurs when the MN is on aAR, then moves to oAR, then moves to nAR before completing MIP registration at oAR. The lack of MIP registration may result from either a specific decision by the MN due to an ongoing real time media stream, or it may result from rapid movement between oAR and nAR that does not allow enough time for the registration to complete. This situation is shown in Figure 5 below. In this case, oAR must inform nAR to contact aAR about moving the radio directed end of the tunnel. This is performed with the Handover To Third (HTT) message. Design Team 28 Internet Draft Fast Handovers for MIPv6 July 2001 +------+ +--->| aAR |<---+ | +------+ | 4b) HI(r) | | 3) HI(t) HAck (r) | | HAck(t) | | v 2a) HI v 1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT | oAR |<-------->| nAR | 4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU ^ HAck ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 5b) L2-LU ~~~> | MN | ---------> +------+ Figure 12 - Three Party Handover The general idea behind the three party handover procedure is that the oAR supplies nAR with the same information it would have obtained via an L2-TT if handover had occurred with aAR, then the nAR performs an HI(t)/HAck(t) sequence with aAR in order to move the BET to nAR. When the L2 handover is complete, oAR sends an HI(r) to aAR to terminate the BET. The following describes the progress of a three party handover. The numbered items refer to steps in Figure 5. 1) Either the oAR or nAR receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are: a) The L2 trigger is a source trigger (L2-ST) at oAR. The trigger contains the MN's L2 address and an IP identifier (L2 address that can be mapped to an IP address or the IP address directly) for nAR. b) The L2 trigger is a target trigger (L2-TT) at nAR. The trigger contains the MN's L2 address and an IP identifier for oAR. 2) The oAR and nAR exchange a HTT/HI or HAck/HTT pair. There are two cases: a) The L2 trigger is an L2-ST. The oAR sends HTT to nAR containing the IP address of aAR and two LLAs. The first LLA contains the L2 address of the MN, the second contains the L2 address of the aAR. This is enough information for Design Team 29 Internet Draft Fast Handovers for MIPv6 July 2001 nAR to perform a target trigger handover with aAR. The nAR responds with a HAck(s). b) The L2 trigger is an L2-TT. The nAR sends HI(t) to oAR, exactly as if a two party handover were occurring. The oAR responds with HTT containing the IP address of aAR and two LLAs. The first LLA contains the L2 address of the MN, the second contains the L2 address of the aAR. This is enough information for nAR to perform a target trigger handover with aAR. 3) The nAR first checks its routing tables to see whether it is already tunneling for MN. If so, Step 6 is performed. If not, nAR performs a target trigger handover with aAR, exactly as in Section 3.3, exchanging a HI(t)/HAck(t) pair. Because aAR receives no L2 trigger indicating when to start handover, it may place the BET to nAR upon transmission of the HAck(t), or alternatively it may wait to establish the BET with nAR until oAR signals that L2 handover has begun in Step 4. 4) At the start of L2 handover, aAR and oAR exchange messages canceling tunnel service between aAR and oAR and allowing aAR to start the tunnel with nAR. a) The start of L2 handover is signaled at oAR by L2-LD. b) The oAR exchanges a HI(r)/HAck(r) pair with aAR with lifetime zero. This cancels tunnel service between oAR and aAR. If aAR has not already placed a BET to nAR, it must do so immediately upon receipt of the HI(r). 5) Completion of L2 handover is signaled by an L2-LU trigger at nAR and MN. The nAR and MN handle the trigger in the following ways: a) The nAR begins delivering packets to the MN, and tunnels any CN-bound packets from the MN to aFA. b) Based on its current movement and traffic pattern, MN either defers obtaining a nCoA or begins the process of obtaining an nCoA. 6) In the special case where nAR and aAR are the same, aAR recognizes that it is tunneling to oAR when it checks its routing tables in Step 3. In this case, there is no need for aAR to send the HI(t)/HAck(t) with itself in Step 3. Upon receipt of the L2-LU trigger on handover completion, the aAR begins routing packets to MN and the tunnel to nAR is torn down. The AR still exchanges the HI(r)/HAck(r) with oAR in Step 4b because oAR can't know a priori that aAR and nAR are the same, but aAR need not gate old tunnel tear down or delivery of mobile node packets on this exchange. Design Team 30 Internet Draft Fast Handovers for MIPv6 July 2001 Unlike two party handover, the timing of BET establishment between aAR and nAR cannot fully depend on the availability of L2 trigger information because aAR does not receive an L2 trigger when L2 handover begins. The two timing extremes at which aAR can place the BET with nAR are: 1) At the earliest, aAR can establish the BET with oAR after sending the HAck(t) to nAR in response to the request for target-triggered handover, 2) At the latest, aAR can establish the BET with nAR and tear down the BET with oAR when receiving the HI(r) from oAR indicating the L2 handover has begun. In addition, aAR has the option of continuing tunnel service with oAR if 1) is selected, until the HI(r) is received. If 1) is selected and the aAR continues to tunnel to oAR, the result may be duplicated packets at the MN, because the MN will receive packets through oAR on the old L2 until L2 handover begins. If 2) is selected, the additional latency of the HI(r) added to the L2 handover latency may result in additional packets being dropped while the MN is not receiving L3 networking service. Of course, aAR can choose to place the BET some time between 1) and 2) if the the network to give reasonable bounds. The exact selection of when to establish the BET is likely to be influenced by network engineering and implementation considerations, including whether a handover smoothing solution is deployed, and is beyond the scope of this specification. Figures 6 and 7 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three party handover, respectively. Design Team 31 Internet Draft Fast Handovers for MIPv6 July 2001 MN nAR oAR aAR | | | | | | L2-ST ~~~~~> | | | | | | | |<-------------| | | | HTT | | | | | | | |------------->| | | | HAck(s) | | | | | | | | | | | |------------------------------>| | | HI(t) | | | | | | | |<------------------------------| | | HAck(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 Handover | HI(r) | | | |<---------------| | HAck(r) | | | ----------------------------------<~~~ L2-LU | | | | | | | | | |<-------------->| | | | MN's traffic | | | | on aCoA | | | | | | | Figure 13 - Three Party Source Trigger Handover Timing Design Team 32 Internet Draft Fast Handovers for MIPv6 July 2001 MN nAR oAR aAR | | | | | |<~~~ L2-TT | | | | | | | |------------->| | | | HI(t) | | | | | | | |<-------------| | | | HTT | | | | | | | | | | | |------------------------------>| | | HI(t) | | | | | | | |<------------------------------| | | HAck(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 Handover | HI(r) | | | |<---------------| | HAck (r) | | | ----------------------------------<~~~ L2-LU | | | | | | | | | |<-------------->| | | | MN's traffic | | | | on aCoA | | | | | | | Figure 14 - Three Party Target Trigger Handover Timing Design Team 33 Internet Draft Fast Handovers for MIPv6 July 2001 3.4.1. Renewal or Termination of Tunneling Service Prior to the lifetime of a BET expiring, the MN's current AR must signal the aAR to either renew or terminate the BET. If no such signal is received, the aAR will terminate the BET when the lifetime expires, cutting off the MN's traffic potentially prematurely. In addition, aAR MAY terminate the BET prior to the lifetime expiring, perhaps to shed load or for some other reason. In order to avoid error conditions in which tunnels do not expire even though the MN to which they apply has for some reason disappeared, ARs SHOULD set the tunnel lifetime to some value other that 0xffff, which indicates "good until cancelled". Figure 8 illustrates the message exchange that occurs between the AR needing to terminate or extend the tunnel (designated AR(1) in the figure) and the other AR (designated AR(2) in the figure). Immediate termination occurs when the HI(r) contains a zero lifetime. Eventual termination occurs when the HI(r) originates with aAR unsolicited and has a lifetime that is shorter than the remaining lifetime known to the MN's current AR. The lifetime value in the HI(r) gives the number of seconds until the tunnel will be terminated. Extension occurs when the HI(r) originates with the MN's current AR and it contains a nonzero lifetime. The aAR has veto power over a request from the current AR to extend the lifetime of the tunnel. HI(r) +------+ <-------- +------+ | AR(2)| ---------> | AR(1)| +------+ HAck(r) +------+ Figure 15 - BET Renewal or Termination Note that, if the current AR or aAR need to terminate the tunnel for some reason (shedding load, going down, etc.) and they have not received definitive notification that the MN has a nCoA, they SHOULD send out a tunnel extension indication (if necessary) or an eventual termination indication, respectively, with enough time left for the process of nCoA establishment to be completed, if that can be determined. The current AR SHOULD then send a RtAdv to the MN, informing the MN that it MUST start the process of nCoA establishment. The current AR and aAR SHOULD NOT send out an immediate termination request unless definitive evidence is available that the MN has a nCoA. The current AR SHOULD NOT send an immediate termination indication unless definitive evidence (L2 trigger, BU, etc.) is available that the MN is no longer reachable on the current AR's link. 3.5. Termination of BETH There are three possible events that can lead to the need to terminate tunneling service to the MN and therefore require the MN to obtain a nCoA. These three are: Design Team 34 Internet Draft Fast Handovers for MIPv6 July 2001 1) The end of life for the BET is pending and a request by the current AR to aAR for renewal has been denied, or, alternatively, the current AR or aAR must terminate the BET prematurely for some other reason (load shedding, etc.). 2) The MN decides, based on its movement and traffic patterns, to establish a nCoA. 3) The MN comes to the edge of a BETH coverage area. The next AR to which the MN will be handed over does not support BETH, although it may support Predictive Fast Handoff. There are two possibilities: a) The MN's current AR has information about the handover capabilities of new AR. b) The MN's current AR has no information about the handover capabilities of the new AR. These cases are considered in the following subsections. 3.5.1. BET End of Life or Premature BET Termination BET end of life and premature BET termination are both cases where the BET is terminated by the network due to some event unrelated to the MN. There are three possible subcases: 1) BET end of life is pending and aAR has refused a request to extend the life time, 2) The current AR has received a notification from aAR that the BET will terminate prematurely, 3) The current AR must terminate the BET prematurely itself. When it learns of a pending BET termination, the current AR MUST inform the MN enough in advance of the actual termination that the MN can obtain a nCoA without disruption in service. Similarly, if the aAR must prematurely terminate the BET, it SHOULD send an eventual termination notice with enough time remaining so that the MN has an opportunity to establish a nCoA. The aAR SHOULD NOT send an immediate termination notice unless it has been informed by the MN that the MN already has a nCoA. The current AR MUST initiate the process of nCoA establishment, by either sending a RtAdv or sending a PrRtAdv (even though the AR is sending its own address in this case and is not really proxying). If the current AR MUST also terminate the radio link to the MN for some reason, it MUST begin the process of Predictive Fast Handoff handover to a different AR capable of handling the MN's traffic if possible. Design Team 35 Internet Draft Fast Handovers for MIPv6 July 2001 In the case where the network terminates the BET, there is no requirement for signaling from the MN to cause tunnel tear-down. 3.5.2. MN Decision to Obtain a nCoA If real time traffic ceases or the MN stops moving quickly, the MN MAY decide that the radio channel is free enough to obtain a nCoA. Although there is no L3 signaling to indicate that the MN has moved ARs, the L2-LD and L2-LU triggers provide that indication, along with the L2 address of the nAR. By comparing the nAR L2 address delivered through the L2 trigger with the L2 address of its oAR, the MN can determine if obtaining a nCoA is necessary. In any event, the MN MUST always keep track of the aAR L2 address where it originally got its aCoA, and SHOULD keep track of the aAR IP address so it can inform the aAR of a change in CoA through a BU. The MN begins the process of establishing a nCoA through the mechanisms outlined in MIPv6 for standard MIPv6 movement detection. The MN MUST send a RtSol to the current AR. The MN continues the process of obtaining a nCoA, stateless or stateful address autoconfiguration, sending BUs to the HA and any remaining CNs, etc. When sending BUs to the HA and any CNs, the MN SHOULD set the 'A' (Acknowledge) bit so that it is informed through a BAck from nodes with which it currently does not have an active session when the binding update is complete. The MN MUST also establish a security association with its current AR, sufficient to allow the current AR (which now becomes the aAR) to receive and authenticate a BU from the MN. The exact mechanism for establishing such a security association is currently under discussion in the working group and is beyond the scope of this document. When the MN has completed obtaining a nCoA, it SHOULD wait until it has received the last BAck from the nodes to which it has sent a BU before sending a binding update to the aAR. The BAck will typically arrive as a destination option in the first packet from a CN sent to the nCoA, thereafter, the MN and CN will use the nCoA for communication and no more packets will be sent to the oCoA. At this point, it is safe for oAR and nAR to tear down the tunnel, the MN MUST send the BU, suitably authenticated, to the oCoA to initiate tunnel tear-down. If for some reason, the MN must terminate the radio link, it SHOULD either establish a nCoA on the link prior to terminating it, or, alternatively, cancel the binding at the aAR so the tunnel will be torn down. An example of such a case is if the MN enters dormant mode. This assures that no tunnel state lingers on the ARs after the MN has disappeared. An alternate case is when the MN has a second radio interface and has detected an AR on that interface to which it would like to handover. Specifically, when the MN decides to hand over to another interface, Design Team 36 Internet Draft Fast Handovers for MIPv6 July 2001 it issues a RtSolPr to the AR that is handling the active interface, requesting handover to the AR handling the new interface. Upon receipt of the RtSolPr, the current AR proceeds to do an Predictive Fast handover to the nAR, issuing a HI/HACK, and sending the PrRtAdv to the MN. Upon receipt of the PrRtAdv, the MN proceeds to configure its IP stack so that its home address is on the new interface, then it does F-BU and F-NA. Note that this procedure is exactly the same as for an Predictive Fast handover to a second interface. 4. Interoperability of different Fast Handoffs Methods Depending on network and MN preferences there could be domains and MNs with varying degree of Fast Handoff support. Depending on the capability of the various ARs and MNs the actual handoff that is used will be determined. In order to exchange the handoff capabilities, a new extension is used to the IPv6 Router Advertisement Solicitation and to the IPv6 Router Advertisement for use by the MN and AR to exchange information on handover capabilities, the Handover Capabilities extension. The extension is described in Section 5.4.5. The extension provides a code for the MN to inform the AR whether it is Predictive Handoff capable, and also whether it is BETH capable. Absence of this extension indicates that the MN does not support Fast Handoff at all. The AR replies with an extension in the Router Advertisement to indicate to the MN what kind of handover it MUST use. In the network initiated Handoff, the network indicates the capabilities through the Router Advertisement. The standard procedure for an MN that initially enters active mode is to send an IPv6 Router Advertisement Solicitation, and for the AR to reply with an IPv6 Router Advertisement. After that, the MN is free to begin establishing a co-located CoA through stateless or stateful address configuration. Fast Handoff Aware elements add a new extension to the IPv6 Router Advertisement Solicitation and to the IPv6 Router Advertisement for use by the MN and AR to exchange information on handover capabilities. A MN SHOULD include the handover capabilities exchange option in the Router Advertisement Solicitation indicating the types of Fast handoffs it supports. It SHOULD include multiple of the options in the order it prefers if more that one type fast Handoff is supported. When an AR receives a Router Advertisement Solicitation with the Predictive Handoff and/or BETH code set. The AR decides which of the methods it prefers and responds with that in the Router Advertisement. If the Code is that of the Predictive Handoff the MN is expected to perform the Predictive Handoff Procedures. If the Extension in the Router Advertisement contains the BETH code, it is an indication to the MN that AR will perform L2 Trigger Based handoff. In the absence of the handover extension a Mobile IP v6 Design Team 37 Internet Draft Fast Handovers for MIPv6 July 2001 Handoff is performed. The choice of Fast Handoff Method is the AR configuration dependent. If an AR that supports Fast Handoff receives a Router Advertisement Solicitation with no extension, it MUST NOT perform Fast Handoff signaling. It MUST assume that the MN cannot perform Fast Handoff and it MUST allow the MN to perform standard MIPv6 handover. If the AR has information available that would allow it to optimize standard MIPv6 handover, it SHOULD use that information to speed up sending the Router Advertisement when an MN arrives on its link. Because all handover signaling between the MN and the network is suppressed during BETH, a procedure is required that allows the MN and network to indicate whether BETH coverage is desired. If both the MN and network support BETH, then coverage is provided until either side signals to terminate. 5. 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. 5.1. New Neighbor Discovery messages 5.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 ... +-+-+-+-+-+-+-+-+-+-+-+- 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 Design Team 38 Internet Draft Fast Handovers for MIPv6 July 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. Handover Capabilities Extension One or more of this Extension SHOULD be included to indicate the capabilities and the order of the Extensions indicated the preference the earlier option indicates a higher preference. 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 Proxy Router Advertisement message should be received in Design Team 39 Internet Draft Fast Handovers for MIPv6 July 2001 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. 5.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. ICMP Fields: Type TBA Design Team 40 Internet Draft Fast Handovers for MIPv6 July 2001 Code 0 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. Handover Capabilities Extension One or more of this Extension SHOULD be included to indicate the capabilities and the order of the Extensions indicated the preference the earlier option indicates a higher preference. 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. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize Design Team 41 Internet Draft Fast Handovers for MIPv6 July 2001 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. 5.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 42 Internet Draft Fast Handovers for MIPv6 July 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 Design Team 43 Internet Draft Fast Handovers for MIPv6 July 2001 Checksum The ICMP checksum. See [ICMPv6]. Reserved 32-bit unused field. It MUST be initialized to 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 44 Internet Draft Fast Handovers for MIPv6 July 2001 5.2. Inter-Access Router Messages 5.2.1. Handover Initiation (HI) The Handover Initiation message is a new ICMPv6 message sent by the an Access Router to another Access Router to initiate the process of Mobile Node's handover. In the case of predictive handoff it is sent from the old Access Router to the new Access Router. In BETH, it is sent by the recipient of an L2-ST or L2-TT trigger, or by an AR when it wants to cancel or extend tunneling service. 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|H|T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address The IP address of the Router sending this message. If H bit is set, the IP address of the AR receiving the L2-ST. If T bit is set, the IP address of the AR receiving the L2-TT. If the R bit is set, the IP address of the AR wishing to extend or cancel tunnel service. Destination Address The IP address of the Router this message is sent To. If the H or T bits are set, the IP address of the AR whose L2 address is contained in the L2 trigger. If the R bit is set, the IP address of the AR extending tunnel service. Hop Limit 255 Authentication Header Design Team 45 Internet Draft Fast Handovers for MIPv6 July 2001 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. Unset if the H, T, or R bit are set. U Buffer flag. The destination SHOULD buffer any packets towards the node indicated in the options of this message. Unset if the H, T, or R bit are set. H Set if the message was triggered by an L2-ST in a two party handover. All other bits are unset. T Set if the message was triggered by an L2-TT. All other bits are unset. R Set if a request to extend or cancel tunnel service. All other bits are unset. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: The message MUST contain the following options in the indicated order if the specified bits are set: 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. MUST be present if the H, T, or R bits are set. Design Team 46 Internet Draft Fast Handovers for MIPv6 July 2001 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. MUST be Present if the H or R bits are set. 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. Lifetime Option Present if the H, T, or R bits are set. The lifetime, in seconds, for which the requestor would like tunnel service extended. If the field is zero, the request is to cancel tunnel service. If the field is 0xffffffff, the request is for infinity. The lifetime option is described in Section ?? 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. 5.2.2. Handover Acknowledgement (HACK) Message The Handover Acknowledgement message is a new ICMPv6 message that MUST be sent in reply to the Handover Initiate message. Design Team 47 Internet Draft Fast Handovers for MIPv6 July 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |H|T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address Copied from the destination address of the Handover Initiate Message this message is in response to. If T bit is set, the address of oAR or aAR. If H bit is set, the IP address of nAR. If the R bit is set, the IP address of the AR extending tunnel service. Destination Address Copied from the source address of the Handover Initiate Message this message is in response to. If the T bit is set, the IP address of nAR. If the H bit is set, the IP address of oAR. If the R bit is set, the IP address of the AR that requested extending or canceling tunnel service. 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 Design Team 48 Internet Draft Fast Handovers for MIPv6 July 2001 Checksum The ICMP checksum. See [ICMPv6]. Identifier Copied from the corresponding field in the Handover Initiate message this message is in response to. H Set if in response to HRqst(s) in a two party handover. All other bits are unset. T Set if in response to an HRqst(t) in a two party handover, or when sent by aAR in a three party handover. All other bits are unset. R Set if in response to a HRqst(r). All other bits are unset. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: The message MUST contain the following options in the indicated order if the specified bits are set: 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. Lifetime Option Present if the H, T, or R bits are set. The lifetime, in seconds, for which the sender is willing to grant tunnel service. If the field is zero, the request for tunnel service is denied. If the field is 0xffffffff, the tunnel service is guaranteed until cancelled. The lifetime option is described in Section 5.4.3. IP Address Option containing MN's old Care of Address Present if the T or R Bit is set. 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. Design Team 49 Internet Draft Fast Handovers for MIPv6 July 2001 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. 5.2.3. Handover To Third (HTT) The HTT message is an extension of both HI and HACK. If it is triggered by an L2-ST, then it is an extension of HI. If it is sent in response to an HI(t), then it is an extension of the HACK. The message can be distinguished as an HTT because it has both the H and T bits set regardless of whether it is received as a request or sent as a reply. No other bits are sent in HTT. In addition, the HTT MUST contain the following options in the specified order: Valid Options: IP Address Option containing aAR's Address. LLA Option containing the L2 address of the MN. LLA Option containing the L2 address of aAR. 5.3. New Destination Options 5.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/Anchor 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) format as follows: Design Team 50 Internet Draft Fast Handovers for MIPv6 July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 the Binding Acknowledgement), if the Duplicate Address Design Team 51 Internet Draft Fast Handovers for MIPv6 July 2001 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 option is the new care-of-address given to the mobile node by the Proxy Router Advertisement message and is included in the Alternate Design Team 52 Internet Draft Fast Handovers for MIPv6 July 2001 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. 5.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 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- Design Team 53 Internet Draft Fast Handovers for MIPv6 July 2001 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 7 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: 128 Reason unspecified Design Team 54 Internet Draft Fast Handovers for MIPv6 July 2001 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. 5.4. New ICMP options 5.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]. Design Team 55 Internet Draft Fast Handovers for MIPv6 July 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 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. 5.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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Design Team 56 Internet Draft Fast Handovers for MIPv6 July 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. 5.4.3. Lifetime Option The following defines the Lifetime option: Design Team 57 Internet Draft Fast Handovers for MIPv6 July 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 | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 8 Subtype: TBD Reserved: Must be set to zero. Lifetime: Four octet positive integer giving the lifetime of the Tunnel, in seconds. 5.4.4. 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 Design Team 58 Internet Draft Fast Handovers for MIPv6 July 2001 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 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.4.5. Handover Capabilities Extension The Handover Capabilities extension is an extension to the IPv6 Router Advertisement Solicitation and IPv6 Router Advertisement that indicates which handover capabilities the MN and AR (respectively) support. The extension has the standard TLV 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 | Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 4 Code: 0 - Sending node is capable of Predictive Fast handover. Design Team 59 Internet Draft Fast Handovers for MIPv6 July 2001 2 - Sending node is capable of L2 Trigger Based Fast Handoff (BETH). Reserved: Must be set to zero. 6. 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. 6.1.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. Links wherein the uniqueness of the interface identifier is ensured within the subnet (by means beyond the scope of this document), DAD handling procedures could be avoided. 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. 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. Design Team 60 Internet Draft Fast Handovers for MIPv6 July 2001 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. 6.1.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 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 Design Team 61 Internet Draft Fast Handovers for MIPv6 July 2001 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 short 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. 7. 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. 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. Design Team 62 Internet Draft Fast Handovers for MIPv6 July 2001 - It sends any packet queued for the neighbor. 8. Security Considerations 8.1. Security Considerations for Predictive Handoff The security needed for Predictive fast handoff 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 Predictive Fast Handover method assumes that a security association exists between the old/Anchor access router and the mobile node, as well as between the old/Anchor 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. 8.2. Security Considerations for BETH There are two areas of possible security concerns: the MN to AR connection, and the AR to AR connection. 8.2.1. MN to AR Connection The intent of the protocol is to eliminate any L3 signaling traffic related to subnet movement in order to eliminate any latency in starting up real time traffic on nAR. This includes any traffic related to authentication. As a consequence, the L2 protocol MUST support some means for an MN to authenticate the radio access point with which it is connecting during an L2 handover, and for the radio access point to authenticate the MN. Furthermore, any authentication or security information involved in providing the MN with L3 service MUST be available to the nAR so that nAR can determine whether the MN is authorized for such service. The exact mechanism by which this information is made available to the nAR is outside the scope of this document. 8.2.2. AR to AR Connection Handover involves changing routing for a particular MN, and any compromise of security in the AR to AR connection could result in the MN's traffic being diverted or cut off. As a consequence, a security Design Team 63 Internet Draft Fast Handovers for MIPv6 July 2001 association MUST exist between ARs, and the HRqst, HRply, and HTT messages MUST contain an IPSEC AH header. In the event the handover messages are routed over a public data network, such as might occur during a handover between two different administrative domains, the messages SHOULD also be encrypted. 9. 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. The WG would like to Thank James Kempf, Pat Calhoun, Gopal Dommety, Sebastian Thalanany, Ajoy Singh, Peter J. McCann and Tom Hiller for proposing the BETH method. 10. 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. [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. Design Team 64 Internet Draft Fast Handovers for MIPv6 July 2001 [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. 11. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto Systems,Inc 6000 Connection Drive 20251 Century Blvd M/S M8-540 Irving, Texas 75039 Germantown, MD 20874 USA USA Phone: +1 972-894-6709 Phone: +1 301-444-1700 Fax : +1 972-894-5349 Fax: +1 301-515-3675 E-Mail: Basavaraj.Patil@nokia.com E-Mail: proberts@megisto.com The Editor of this document is: Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone:+1 408 525 1404 EMail: gdommety@cisco.com The Contributers to this document are: Alper E. Yegin Sun Microsystems 901 San Antonio Rd, UMPK17-202 Palo Alto, CA, 94303,USA Phone: +1 650 786 4013 Email: alper.yegin@sun.com Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone:+1 408 525 1404 EMail: gdommety@cisco.com Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 Design Team 65 Internet Draft Fast Handovers for MIPv6 July 2001 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 George Tsirtsis, Flarion Technologies, G.Tsirtsis@flarion.com Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 E-mail: Karim.El-Malki@era.ericsson.se Mohamed Khalil, Nortel Networks, mkhalil@nortelnetworks.com Design Team 66