G. Dommety Editor A. Yegin C. Perkins G. Tsirtsis K. El-Malki M. Khalil Internet Draft Title: draft-ietf-mobileip-fast-mipv6-04.txt Category: Standard Track March 2002 Expires : Sept 2002 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@sunroof.eng.sun.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 AR to another, a process referred to as handover. During this process, there is a time period during which the Mobile Node is unable to send or receive IPv6 packets. This time period is referred to as handover latency. In certain scenarios, the handover latency resulting from standard Mobile IPv6 handover procedures could be greater than what is acceptable to support real-time or delay sensitive traffic. The intent of this document is to describe Design Team 1 Internet Draft Fast Handovers for MIPv6 March 2002 protocol enhancements that can be used to minimize handover latency, thereby making Mobile IPv6 better equipped to support real-time traffic. 1. Introduction.....................................................3 1.1. Terminology...................................................4 1.2. Standards Language............................................6 2. Protocol Overview................................................7 3. The Handover Mechanisms.........................................11 3.1. Anticipated Handover.........................................11 There are two sub-cases, depending on which participant in the handover has predictive information about the nAR:.................11 3.1.1. Anticipated Handover Overview.............................12 3.1.2. Network Initated Handover.................................14 3.1.3. Stateless nCoA Configuration..............................14 3.1.4. Stateful nCoA Configuration...............................16 3.1.5. Failure of nCoA Establishment (Use of Old CoA)............16 3.1.6. Mobile Initiated Handover.................................16 3.1.7. Three Party Handover......................................17 3.1.8. Completing nCoA Establishment.............................18 3.1.9. Features Enabling Partial Handover Optimization...........18 3.2. Tunnel-based Handover........................................19 3.2.1. L2 Triggers...............................................20 3.3. Two Party Handover...........................................21 3.4. Three Party Handover.........................................25 3.4.1. Renewal or Termination of Tunneling Service...............31 3.5. Termination of BETH..........................................31 3.5.1. BET End of Life or Premature BET Termination..............32 3.5.2. MN Decision to Obtain a nCoA..............................33 4. Interoperability of Handover Mechanisms.........................34 4.1. Initial Exchange of Supported Handover Mechanism Information.34 4.2. Signaling Suppression for Standard Mobile IPv6 Handover......35 4.3. Transition Between Handover Coverage Areas...................35 4.3.1. Transition between Fast Handover and Standard Mobile IPv6 Areas 36 4.3.2. Transition between Tunnel-based and Anticipated Areas.....36 5. Message Definitions and Option Formats..........................36 Design Team 2 Internet Draft Fast Handovers for MIPv6 March 2002 5.1. New Neighbor Discovery Messages..............................37 5.1.1. Router Solicitation for Proxy (RtSolPr)...................37 5.1.2. Proxy Router Advertisement (PrRtAdv)......................38 5.1.3. Fast Neighbor Advertisement (F-NA) Message Format.........40 5.2. Inter-Access Router Messages.................................42 5.2.1. Handover Initiation (HI)..................................42 5.2.2. Handover Acknowledgement (HACK) Message...................45 5.2.3. Handover To Third (HTT)...................................47 5.3. New Destination Options......................................48 5.3.1. Fast Binding Update (F-BU) Destination Option.............48 5.3.2. Fast Binding Acknowledgement (F-BACK) Destination Option..50 5.4. New ICMP options.............................................52 5.4.1. IP Address Option.........................................53 5.4.2. Link-layer Addresses (LLA)................................53 5.4.3. Lifetime Option...........................................54 5.4.4. Neighbor Advertisement Acknowledgement (NAACK)............55 5.4.5. Handover Capabilities Extension...........................56 6. Error Cases and Other Issues....................................57 6.1.1. DAD Handling..............................................57 6.1.2. Fast or Erroneous Movement................................58 7. Neighbor Cache Considerations...................................59 8. Security Considerations.........................................59 8.1. Security Considerations for Anticipated Handover.............59 8.2. Security Considerations for BETH.............................60 8.2.1. MN to AR Connection.......................................60 8.2.2. AR to AR Connection.......................................60 9. Acknowledgements................................................60 10. References.....................................................61 11. Addresses......................................................61 1. Introduction Mobile IPv6 describes how a Mobile Node can change its point of subnet attachment from one Access Router to another, a process referred to as handover. During this process, there is a time period during which the Mobile Node is unable to send or receive IPv6 packets due to the lack of a solid Layer 2 connection and to the time required at Layer 3 to re-establish the mobile node's care-of address on the new subnet. This time period is referred to as handover latency. In certain scenarios, the handover latency resulting due to the standard Mobile IPv6 handover could be greater than what is Design Team 3 Internet Draft Fast Handovers for MIPv6 March 2002 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 handover latency, thereby making Mobile IPv6 better equipped to support real-time traffic. The actual latency involved in handover is the result of a number of factors and depends on implementation and deployment circumstances. Here is a short but not exhaustive list of factors: 1. The element (Network or Mobile Node) that makes the handover decision, 2. The amount of information about the network entities involved in the handover that is available, for example knowing the IP and MAC address of the new Access Router (AR), 3. The extent of Layer 2 support for providing Layer 3 with information on the sequence of events involved during handover. 4. The period of time Layer 3 can learn of a pending Link Layer handover in advance of the actual handover. 5. The amount of time involved in performing Neighbor Discovery and Duplicate Address Detection, or stateful address configuration, for the Mobile Node's Care of Address. Note that some of these factors are strictly related to Layer 2 and therefore not under the influence of Layer 3, while others are directly related to Layer 3. In this document, two handover mechanisms are described: 1. Anticipated Handover: Layer 3 initiates handover to the new Access Router while the Mobile Node still has Layer 2 connectivity to the current Access Router. In this scenario, either the Mobile Node or the current Access Router have predictive information in advance of the actual Layer 2 handover about where the Mobile Node will be moving, or the Mobile Node or current Access Router can actually force handover to a particular new Access Router. 2. Tunnel-based Handover: The Mobile Node defers Layer 3 handover until it is on the new Access Router, or possibly later. The current Access Router tunnels packets to the Mobile Node under its old Care of Address until the Mobile Node performs Layer 3 handover. If the Mobile Node moves again without performing Layer 3 handover, the tunnel is moved by the old and new Access Routers to accommodate the Mobile Node's movement. 1.1. Terminology Design Team 4 Internet Draft Fast Handovers for MIPv6 March 2002 This section introduces some terminology used throughout the draft. MN - A Mobile Node is a Mobile IPv6 host capable of moving its point of attachment to the Internet. 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. 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. Design Team 5 Internet Draft Fast Handovers for MIPv6 March 2002 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. 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 Design Team 6 Internet Draft Fast Handovers for MIPv6 March 2002 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 handover mechanisms is described. +------+ |CN/HA |________ +------+ ^ | ... | v +------+ +------+ | oAR |.------->| nAR | +------+ +------+ ^_____ | wireless link v movement +------+ ---------> | MN | +------+ An Access Router is the last hop router between the network and the Mobile Node. Under normal conditions (i.e. not in a handover situation), 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 the Mobile IPv6 specification. From the point of view of an upcoming handover, the old Access Router (oAR) is the router to which the Mobile Node is currently attached and the new Access Router (nAR) 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 nAR, packets destined to the MN via the cCoA are delivered via the nAR. In order to route these packets, the oAR uses proxy Neighbor Discovery to intercept any IPv6 packets addressed to the oCoA on the MN's old link, and routes each intercepted packet to the MN. The end-point of this tunnel depends on whether the MN is successful in obtaining a nCoA while it is attached to oAR. If the MN is able to obtain a nCoA, the packets are routed to the nCoA of the MN on the new link. Otherwise, the packets are Design Team 7 Internet Draft Fast Handovers for MIPv6 March 2002 tunneled to the nAR address and the nAR decapsulates and delivers the packets to the MN via Link Layer mechanisms. According to the Mobile IPv6 specification, whenever possible, the MN SHOULD obtain a nCoA and send Binding Updates (BUs) to update the binding information with the nCoA information to the Correspondent Nodes (CN) and the Home Agent (HA). If the MN is unable to send BUs to the CNs and HA, and the MN is forced to handover, the MN needs to receive continued service under its oCoA. 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 parties may be involved in a handover if an MN that has not updated its CoA after a move must move again. The three parties in this case are the current, or old, Access Router (oAR), the nAR, and the anchor AR (aAR) which is the AR that routes to the subnet on which the MN's current CoA is located. In this case, in order to for the MN to continue receiving service, the aAR moves the tunnel to route the packets via the nAR. The Three Party handover 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 | +------+ Design Team 8 Internet Draft Fast Handovers for MIPv6 March 2002 Initially, the MN is attached to the aAR and moves to a link attached to oAR. While it is on oAR's link, traffic is routed via the oAR to the MN through Bidirectional Tunnel 1 (BT-1 in the figure). If the MN moves before it completes a Mobile IPv6 registration on oAR, the packets destined to the MN are routed via the BT-2 from aAR to nAR. Design Team 9 Internet Draft Fast Handovers for MIPv6 March 2002 In anticipated handover, the MN begins the process of obtaining its nCoA on oAR. If this process does not complete by the time the MN moves to nAR, or if the MN moves again before the process completes, the MN continues to receive traffic through the bi-directional edge tunnels until it has time to complete nCoA establishment. In tunnel- based handover, the MN does not begin nCoA establishment on oAR, but rather deliberately delays nCoA establishment because of an ongoing real-time traffic stream, or for other reasons. Prior to the handover or possibly after a handover to a third AR, when its traffic or movement pattern dictates or when required by the network, the MN establishes a nCoA. In both cases, during the time the MN maintains its oCoA on a new subnet, the MN's traffic is delivered from the aAR to the MN via bi-directional edge tunnels. The following list provides an overview of the messages involved in Mobile IPv6 fast handover. These messages are defined in detail in later sections, together with a number of new options for existing messages. The use of these messages to achieve a fast handover in the various scenarios is explained in later section. Router Solicitation for Proxy (RtSolPr) - - Sent by the MN to the oAR when the MN has information that it is about to be handed over to another AR. 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 oAR to the MN either in response to RtSolPr or as a result of information available to the MN that the MN is about to be handover to another AR. 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 an 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) - Indicates that the old Access Router is trying to facilitate a fast handover of the MN to the new Access Router. Handover Acknowledgement (HACK) - Indicates what the new Care of Address should be at the new Access Router and is sent as an Acknowledgement to the HI message. It is also used to indicate acceptance of tunnel establishement. Design Team 10 Internet Draft Fast Handovers for MIPv6 March 2002 Handover to the Third (HTT) - An instance of the HI or HACK message used to indicate that the wireless link end of a bi- directional tunnel should be moved to a third Access Router. Fast Binding Update (F-BU) - - Sent from the MN to the old or anchor AR. The Fast Binding Update indicates the new Care of Address binding is valid and that the old or anchor AR should forward any packets under the old Care of Address to the new Care of Address. Fast Binding Acknowledgement (F-BACK) - - Sent from the old or anchor AR to the MN. The Fast Binding Acknowledgement indicates whether the Fast Binding Update was successful. A negative acknowledgement may indicate that the new Care of Address is invalid or that the Fast Binding Update failed in some other way. Fast Neighbor Advertisement (F-NA) - - Sent from MN to newAR. The MN sends a Fast Neighbor Advertisement to the new AR to announce its arrival. This message also triggers a response in the form of a Router Advertisement that indicates whether the Fast Binding Update was successful for the new Care of Address or whether the old Care of Address should continue in use. 3. The Handover Mechanisms 3.1. Anticipated Handover Anticipated handover involves initiating Layer 3 handover to the nAR while the MN still has Layer 2 connectivity to the oAR. The primary characteristic is that it preserves the standard Mobile IPv6 handover property requiring the MN to make the final decision about to which nAR it will move. There are two sub-cases, depending on which participant in the handover has predictive information about the nAR: 1. Network Initiated Handover - In network initiated handover, the oAR has predictive information about the new point of attachment to which the MN will move prior to the actual movement of the Layer 2 connection. The oAR initiates signaling to the MN and nAR to start the Layer 3 handover. 2. Mobile Initiated Handover - In mobile initiated handover, the MN has predictive information about the new point of attachment to which it will move, or it chooses to force movement to a new point of attachment. The MN initiates signaling to the oAR to start the handover. There are two possible ways of handling CoA configuration in the new subnet: 1. Addresses on the new subnet may be allocated using IPv6 stateless address autoconfiguration [AUTO]. Design Team 11 Internet Draft Fast Handovers for MIPv6 March 2002 2. Addresses may be allocated statefully using DHCPv6 [DHCP]. Anticipated handover accommodates both. In addition, depending on whether the MN has time to complete nCoA establishment on the oAR, the MN can either use the nCoA immediately upon movement to the new subnet, or it can continue to use the oCoA until the process of establishing a nCoA completes.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.1.1. Anticipated Handover Overview In anticipated handover, a handover is initiated when either the MN or the oAR have predictive information about the next point of attachment to which the MN will move. If the MN has such information, or it chooses to force a handover to a new subnet, it sends a RtSolPr to the oAR, and receives a PrRtAdv in response, providing the MN with the Layer 3 information, such as the subnet prefix, required for the MN to establish a nCoA on the new subnet. If the oAR receives predictive information, it sends an unsolicited PrRtAdv to the MN. The PrRtAdv indicates one of the three possible conditions relating to the Layer 3 handover: 1. If the oAR does not know about the nAR, it will respond indicating that the new point of attachment is unknown. 2. If the new point of attachment is under the same AR as the old, the oAR will respond indicating that the point of attachment is known and is connected through the same access router, namely itself. This could happen, for example, when the wireless access points are bridged into a wired network and the MN receives predictive handover information about the next access point rather than the next access router. 3. If the new point of attachment is known and the oAR has information on it, the oAR responds indicating that the point of attachment is known. The message also contains the CoA that the MN should use or information on the network prefix that should be used to form a CoA. The method by which ARs exchange information about their neighbors and thereby allow construction of PrRtAdvs with information on the new subnet is out of scope of this document. When the oAR receives an indication from Layer 2 that the MN will be moving or a RtSolPr from the MN indicating that the MN wants to move, the oAR exchanges messages with nAR in order to obtain or validate the new CoA for the MN. The oAR sends a Handover Initiate (HI) message to the nAR. The HI message contains the requested nCoA on the Design Team 12 Internet Draft Fast Handovers for MIPv6 March 2002 new subnet, if stateless address configuration is in use, and the oCoA being used at the oAR. When the nAR receives HI, it does the following: 1. If the HI message does not have a nCoA, it allocates a nCoA. 2. If the HI message contains a proposed nCoA, the nAR validates the nCoA. The nAR replies to the oAR with a Handover Acknowledgement (HACK) message containing either the nCoA allocated by it, or an indication whether the nCoA proposed by the oAR is valid. The timing of when the oAR sends the PrRtAdv to the MN depends on whether stateless or stateful address configuration is in use. In the case of stateful address allocation, the oAR obtains the nCoA from nAR through HI/HACK message exchange, exactly as described above, so the HI/HACK messaging MUST be completed before transmitting the PrRtAdv to the MN. In the case of stateless address configuration, the oAR MAY send the PrRtAdv prior to completing the HI/HACK message exchange. As soon as the MN received confirmation of a pending Layer 3 handover through the PrRtAdv and has an nCoA, the MN sends a Fast Binding Update (F-BU) to oAR, using its nCoA, as the last message before the Layer 2 handover is executed. On receipt and validation of the F-BU, the oAR responds with a Fast Binding Acknowledgement (F-BAck). The oAR waits for a F-BU from the MN before actually forwarding packets. On receipt of the F-BU, the oAR forms a temporary tunnel for the lifetime specified in the F-BAck, and the F-BAck is sent through the tunnel to the MN on the new link. The F-BAck MAY also be sent to the MN over its old link, in case the MN has not yet moved. When the MN arrives on the nAR and its Layer 2 connection is ready for Layer 3 traffic, it sends a Fast Neighbor Advertisement (F-NA)_ to initiate the flow of packets that may be waiting for it. The nAR MAY deliver packets to the MN as soon as it receives an indication from Layer 2 that the link is solid enough for it to begin sending packets, or it MAY start packet delivery when it receives a F-NA from the mobile node. The oAR is responsible for forwarding any packets that arrive for the MN under its oCoA after the MN has moved. If the HACK message indicated that the nCoA was accepted by nAR, the oAR forwards packets to the nCoA. If the nCoA was rejected by the nAR, the oAR sets up a temporary tunnel to forward packets to the nAR. The nAR takes care of delivering packets on the last hop link. In either case, the oAR MUST NOT forward packets until it has received a F-BU from the MN. The temporary tunnel has a lifetime defined by the lifetime option in the HI message. The MN uses the following procedures to deal with error conditions: Design Team 13 Internet Draft Fast Handovers for MIPv6 March 2002 1. If the MN does not receive a response to an initial RtSolPr, it MUST resend. 2. If the MN does not receive a response to its F-BU, it MUST send a F-NA to the nAR. It MUST also re-send the F-BU in order to start the forwarding of packets from oAR. The anticipated handover mechanism is based on having information on the handover target AR enough in advance of the actual Layer 2 handover so that it is possible for the MN and oAR to exchange RtSolPr, PrRtSol, and possibly F-BU and F-BACK. Also, for the stateful address case, the oAR and nAR must exchange a HI/HACK prior to the oAR sending the PrRtSol to the MN. The protocol works in the limit if the MN moves immediately after it sends the F-BU without receiving the F-BACK. Good results should also be seen even if the MN moves as soon as it sends a PrRtSol, for mobile initiated handover, or if it moves just after it receives the PrRtAdv, for network initiated handover, since the time consuming address autoconfiguration process is bypassed at the nAR. The MN MUST receive a Layer 2 trigger when it attaches to the nAR in order to complete the Layer 3 handover. When the MN detects that the new link is up, it MUST either send a standard Neighbor Advertisement if it has already received the F-BU, or a F-NA if it has not. Additionally, a similar (but optional) trigger on the AR side MAY allow the nAR to detect the arrival of a MN, and therefore change the MN's neighbor cache state to REACHABLE without waiting for a Neighbor Advertisement or F-NA. The nAR SHOULD begin forwarding packets to the MN if it receives such a trigger. 3.1.2. Network Initated Handover In network initiated handover, the oAR receives an indication that the MN is about to move and information on the nAR to which the MN will be moved. Both stateless and stateful nCoA configuration are supported, as is use of the oCoA. 3.1.3. Stateless nCoA Configuration When the oAR receives information that a MN must move to a nAR, it MUST construct a nCoA based on the MNĘs interface ID and the nARĘs subnet prefix. It then MUST send a PrRtAdv to the MN containing the proposed nCoA and the nAR's IP address and Link Layer Address. At the same time the oAR MUST send the HI message to the nAR, indicating the MNĘs oCoA and the proposed nCoA. Figure 1 illustrates. Upon receipt of the HI message, the nAR MUST first establish whether the nCoA is a valid address on its subnet, performing checks to ensure that it is not a duplicate. If the nCoA is legal and acceptable to the nAR, the nAR MUST add the nCoA to the Neighbor Cache for a short time period so it can defend it. The nAR then MUST respond with a HACK, indicating that the proposed nCoA is valid. If Design Team 14 Internet Draft Fast Handovers for MIPv6 March 2002 the nCoA is not valid, due to it being used by another node, for example, the nAR MUST add a host route for the oCoA pointing to its mobility interface, for a short time period and MUST respond to the oAR with a HACK indicating that the proposed nCoA is not valid. MN oAR nAR | | | |<------PrRtAdv-------|--------HI--------->| |-------F-BU--------->|<-------HACK--------| Disconnect <-F-BACK-|-F-BACK-> | | | | | forward | | packets===============>| | | | |------------------F-NA-----------> | | | deliver |<=====================================Packets Figure 1: Network Initiated Handover for Stateless Address Autoconfiguration Upon receipt of the HACK, if the HACK indicates that the nCoA is valid, the oAR MUST prepare to forward packets for the MN to the nCoA. If the HACK indicates the nCoA is not valid, the oAR MSUT prepare to tunnel packets for the MN to the oCoA at nAR. The oAR MUST NOT not make any routing changes for the MN until it receives a F-BU from the MN confirming the handover. If permitted by Layer 2 conditions at the time of handover, the F-BU SHOULD be sent to the oAR while the MN is still connected to the oAR. If this is not possible, the F-BU MUST be sent after the MN connects to the nAR. Upon receipt of the F-BU, the oAR MUST send a F-BACK message to the MN at its nCoA on nAR. It MAY also send the F-BACK to the MN on the old link, in case the MN is still lingering there. Upon receipt of the F-BU and providing the HACK has also been received, the oAR MUST either forward packets originally destined to the MNĘs oCoA to the nCoA, if it was validated, or it must tunnel packets to the MN's oCoA at the nAR. Additionally, and if the link layer supports such indications, the oAR MAY delay the routing change until it determines that the MN has disconnected. On the MN, the MN MUST NOT use the nCoA address as a source address until it receives a F-BU from the oAR. If the F-BU is received while the MN is still connected to the oAR, the MN MUST only announce itself to the nAR by sending a Neighbor Advertisement. If the F-BU is not received at the oAR, there SHOULD be a copy of it waiting for the MN at the nAR, but the MN MUST announce itself to the nAR using the F-NA. If the F-BU is not received at all, the MN MUST re-send the F- BU to the oAR and be prepared to receive packets on nAR under its oCoA. Design Team 15 Internet Draft Fast Handovers for MIPv6 March 2002 3.1.4. Stateful nCoA Configuration If stateful address configuration is being performed, the nCoA is returned by the nAR instead of being proposed by the oAR. The HI/HACK message exchange preceeds the PrRtAdv transmission from the oAR to the MN, because the nAR allocates the address. The rest of the process is identical to the stateless approach. Figure 2 illustrates. MN oAR nAR | | | | |--------HI--------->| | |<-------HACK--------| |<------PrRtAdv-------| | | | | Figure 2: Network Determined for Stateful Address Configuration 3.1.5. Failure of nCoA Establishment (Use of Old CoA) If the nCoA is not successfully established for some reason, the oAR MUST tunnel packets originally destined to the oCoA to the nAR, and nAR MUST deliver the packets to the MN. Similarly, the nAR MUST tunnel packets from the MN with the source address being oCoA back to oAR, and oAR MUST route them out as if they originated on its subnet. This method operates exactly the same as tunnel-based handover, except that that MN immediately begins the process of establishing a nCoA on the nAR instead of deferring nCoA establishment according to its traffic and movement pattern. Explicit option in the F-BU indicating that the mobile prefers to use oCoA is not covered in this specification and could be worth exploring. 3.1.6. Mobile Initiated Handover The main difference between mobile intiated network initiated handover is that, in mobile initiated handover, MN receives predictive information about the Layer 2 handover. The MN MUST send a RtSolPr message to the oAR to trigger the PrRtAdv. In the RtSolPr message, the MN MUST indicate the Link Layer Address or the Identifier of the Attachment Point to which it wants to move. After that, the rest of the message sequence duplicates the network initiated handover sequence, with both stateless and stateful cases covered as above. The oAR MUST reply with a PrRtAdv that contains the same information as in the network initated handover, described in Section 3.1.2 above. Figure 3 illustrates. Design Team 16 Internet Draft Fast Handovers for MIPv6 March 2002 MN oAR nAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------|--------HI--------->| |------F-BU---------->|<------HACK---------| Disconnect <--F-BACK--|--F-BACK--> | | | | | forward | | packets===============>| Connect | | |----------------F-NA-------------> | | | Deliver |<=====================================Packets Figure 3: Mobile Initiated Handover 3.1.7. Three Party Handover If the MN's movement is so fast that it is unable to complete Layer 3 handover on nAR, it may move to a third AR. In anticipated handover, a tunnel chain may occur. Tunnel chaining may not be desirable because it increases the latency of packet delivery due to additional processing at each of the ARs, may result in routing loops, and opens up the potential for multiple points of failure. To remove the possibility of tunnel chaining, a three party handover procedure can be used to anchor the tunnel at the original AR, called the anchor AR (aAR). Figure 4 illustrates three party anticipated handover. MN nAR oAR aAR | | | | |------RtSolPr----------------->| | | |<-------------| | | | HI | | | | | | | |------------> | | | | HACK | | |<-----PrRtAdv------------------| | | | | | |----------------------F-BU--------------------->| | | | | | | |<+++++F-BAck++++| | | | | |<------------------F-BAck-----------------------| | | | | | | forward packets | | |<============================= | Connect | | | |---F-NA-------->| | | Deliver | |<===============Packets | Design Team 17 Internet Draft Fast Handovers for MIPv6 March 2002 Figure 4 - Anticipated Three Party Handover 3.1.8. Completing nCoA Establishment To complete the process of establishing the nCoA on the nAR, the MN MUST send a BU to its HA. It also may need to send a F-BU to its oAR, unless it has a positive indication that the oAR already has made the appropriate binding cache modifications. The typical form of such a positive indication is a F-BU sent from the oAR to the MN; if the MN expects but does not receive the acknowledgement, then it MUST resend the F-BU one more time. The MN MUST complete the details of establishing the nCoA on the new link prior to sending a BU to the HA or F-BU to the oAR. These details may include Duplicate Address Detection and receipt of a Router Advertisement from nAR, but the actual details may not require full IPv6 link configuration. When the nAR receives any packet from the MN to be forwarded elsewhere, it means that the MN considers the nAR to be its default router, and thus that link establishment is complete from the point of view of the MN. If the F-BU was received, then the MN only has to send the BU to its home agent. In that case, that Binding Update would be sent through the MN's default router; that is, the nAR. If the MN has not yet received a F-BU from the oAR, then the MN SHOULD arrange for oAR to receive an appropriate F-BU associating the MN's oCoA to its nCoA. The MN MUST also send a F-NA to nAR, announcing itself on the new link. The F-NA message MUST contain both the nCoA and oCoA, as well as the MNĘs link layer address. The nAR checks the link layer address to see if it has a mapping in its Neighbor Cache. The nAR SHOULD first check for a mapping to the oCoA, if that doesn't exist, a mapping to the nCoA should be checked. If there is no mapping available for either address, the nAR MUST send a Router Advertisement to the MN using the oCoA as the destination address. The Router Advertisement includes the NAACK option as described in 4.4.3. If a mapping is found with the nCoA or the oCoA, the nAR MUST change the cache entry to REACHABLE and send a Routing Advertisement with the NAACK option. The MN SHOULD send data packets immediately following the F-NA message, without waiting for the reaction of the nAR. Such packets MUST use the oCoA as source address and the implementer should be aware that if the nAR is not aware of the mobile, these packets are likely to be dropped. 3.1.9. Features Enabling Partial Handover Optimization Design Team 18 Internet Draft Fast Handovers for MIPv6 March 2002 The following related but seperable features enable various facets of optimizing connectivity between the MN and the nAR: 1. The MN may be able to discover the IP address of the nAR. 2. The MN may be able to discover the MAC address of the nAR. 3. The MN may be able to direct the nAR to determine the uniqueness of its nCoA before establishing connectivity with the nAR. 4. The MN may be able to send a BU to the oAR before breaking the old connection. 5. The MN may be able to receive the F-BACK for the F-BU sent to the oAR before breaking the old connection. 6. The MN may fail to receive the F-BACK for the F-BU sent to oAR before breaking the old connection. But the MN may receive the F-BU on the new link after attaching to nAR. All of these operations are possibly both in the network initiated and the mobile initiated cases. If (1), (2), and (3) hold, the MN can begin to use the nAR as its default router as soon as Layer 2 connectivity is established. Thus, in this optimal circumstance, any necessary BUs can be delivered without any additional delay as soon as the MN gets to the new network. If any of (1), (2) or (3) do not hold, then the MN is required to perform some combination of Neighbor Discovery and Duplicate Address Detection when it arrives at the nAR's subnet. For all of cases (4), (5), and (6), a simple rule is effective. If the MN does not receive a F-BACK for the F-BU, then it MUST retransmit the F-BU. 3.2. Tunnel-based Handover In tunnel-based handover, the mobile is moved to its nAR by Layer 2, without the involvement of Layer 3 on the MN or ARs. The oAR and the nAR set up routing, based on information on handover sequencing received by the ARs from Layer 2, so that the MN continues to receive its packets without the MN having to change its CoA. Bi-directional edge tunnels between the ARs assure that packets are delivered tothe MN and sent to the CNs through the topologically correct subnet. Signaling between the MN and various network elements over the radio link is avoided since the ARs exchange signaling over the wired network. The MN may delay obtaining a nCoA until its 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. Design Team 19 Internet Draft Fast Handovers for MIPv6 March 2002 This approach allows the MN to move rapidly across a connected series of subnets without any MIP-related signaling traffic over the air. Figure 5 illustrates the basic idea behind Layer-2 Handover. Because tunnel-based handover depends on bi-directional edge tunnels for routing, it is called Bi-directional Edge Tunnel Handover (BETH). +------+ | CN | +------+ ^ | ... | v BET +------+ +------+ | aAR |<@@@@@@@@>| AR | +------+ +------+ ^ | wireless link v movement +------+ ---------> | MN | +------+ Figure 5 - BETH Concept BETH leverages off the BET 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 BET 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 BET to it. The network end of the BET remains anchored at aAR until the MN changes CoA. 3.2.1. L2 Triggers BETH requires an L2 trigger at oAR prior to L2 handover start (L2-ST) or an L2 trigger at nAR prior to L2 handover completion (L2-TT). It also requires an L2 trigger at oAR when the old link to the MN is severed (L2-LD), and an L2 trigger on nAR and MN immediately upon completion of L2 handover (L2-LU). Table 1 contains the triggers. The abbreviations are used in message flow diagrams to simplify referring to L2 triggers. The oAR and nAR MUST support at least one of L2-ST or L2-TT. The nAR SHOULD support L2-LU, oAR SHOULD support L2-LD. The MN MUST support Design Team 20 Internet Draft Fast Handovers for MIPv6 March 2002 L2-LU and SHOULD support L2-LD. The oAR MAY use the L2-LD as the equivalent of L2-ST, and nAR MAY use the L2-TT as L2-LU. 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. 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 6 - Two Party Handover The following describes the progress of a two party handover. The numbered items refer to steps in Figure 6. 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. Design Team 21 Internet Draft Fast Handovers for MIPv6 March 2002 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 MUST send a HI to the other AR. There two cases: a. If oAR is sending the HI, the H bit MUST be set, indicating it is based on source trigger. The HI MUST contain a Lifetime option, an IP address option containing the MN's home address, an IP address option containing the MN's oCoA, and an Link Layer Address (LLA) option containing the MN's L2 address. The Lifetime option MUST contain the amount of time the oAR is willing to extend tunnel service to the MN's packets before the nAR must renew the BET. If the lifetime is zero, the oAR is not willing to tunnel any packets for MN. b. If nAR is sending the HI, the T bit MUST BE set, indicating it is based on a target trigger. The HI MUST contain 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 MUST contain a request for the amount of time the oAR should extend tunnel service for the MN's packets. 3. The AR receiving the HI MUST send a HACK to the other AR. There are two cases: a. If oAR is sending the HACK, the T bit MUST be set. The HACK MUST contain 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 MUST contain 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 MUST be 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 MUST begin forwarding MN-bound packets through the BET to nAR. Design Team 22 Internet Draft Fast Handovers for MIPv6 March 2002 b. When the nAR receives the L2-LU trigger, it MUST begin delivering packets to the MN and MUST forward any outbound packets from MN through the BET to oAR. c. Based on its current movement traffic pattern, MN MAY either defer obtaining a nCoA or begin the process of obtaining an nCoA as described in Section 3.5.2. 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 MUST cancel the BET by sending an HI with R bit set to nAR and a Lifetime option having value zero. In this case, the oAR simply continues delivering packets to MN on the old link exactly as if no handover had been pending. The actual timing of BET placement depends on the available L2 triggers. The BET is SHOULD be placed between oAR and nAR using the IPv6 tunneling procedure described in [TUNL]. Alternative tunneling procedures having different traffic engineering properties are also possible. With optimal L2 trigger information, as described above, the BET SHOULD 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 MUST act as the trigger for BET placement. Particular implementation and deployment scenarios MAY require techniques 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. The forward and reverse tunnels are established as follows: 1. The forward tunnel MUST be established by oAR when oAR 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 MUST de- tunnel them and MUST send them to MN. 2. The reverse tunnel MUST be established by nAR when 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 MUST de-tunnel the packets and MUST route them to the original destination address, as if the packet had been sent on oAR's subnet. Once the BET between aAR and the current AR is in place, it MUST be torn down by one of the following events: Design Team 23 Internet Draft Fast Handovers for MIPv6 March 2002 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 7 and 8 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two party handover, respectively. MN nAR oAR | | | | | |<~~~ L2-ST | |<------------------| | | HI(s) | | | | | |------------------>| | | HACK(s) | | | | --------------------------------------------<~~~ L2-LD L2 Handover --------------------------------------------<~~~ L2-LU | | | | | | | | | | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 7 - Two Party Source Trigger Handover Timing Design Team 24 Internet Draft Fast Handovers for MIPv6 March 2002 MN nAR oAR | | | | L2-TT ~~~>| | | |------------------>| | | HI(t) | | | | | |<------------------| | | HACK(t) | | | | --------------------------------------------<~~~ L2-LD L2 Handover --------------------------------------------<~~~ L2-LU | | | | | | | | | | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 8 - 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 9 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 25 Internet Draft Fast Handovers for MIPv6 March 2002 +------+ +--->| 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 9 - 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/HACK sequence with aAR in order to move the BET to nAR. When the L2 handover is complete, oAR sends an HI to aAR to terminate the BET. The following describes the progress of a three party handover. The numbered items refer to steps in Figure 9. 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 MUST send HTT to nAR containing the IP address of aAR and two LLAs. The first LLA MUST contain the L2 address of the MN, the second MUST contain the L2 address of the aAR. This is enough Design Team 26 Internet Draft Fast Handovers for MIPv6 March 2002 information for nAR to perform a target trigger handover with aAR. The nAR MUST respond with a HACK. b. The L2 trigger is an L2-TT. The nAR MUST send a HI to oAR, exactly as if a two party target triggered handover were occurring. The oAR MUST responds with HTT containing the IP address of aAR and two LLAs. The first LLA MUST contain the L2 address of the MN, the second MUST contain the L2 address of the aAR. This is enough information for nAR to perform a target trigger handover with aAR. 3. The nAR MUST first check its routing tables to see whether it is already tunneling for MN. If so, Step 6 is performed. If not, nAR MUST perform a target trigger handover with aAR, exactly as in Section 3.3, exchanging a HI/HACK pair. Because aAR receives no L2 trigger indicating when to start handover, it MAY place the BET to nAR upon transmission of the HACK, or alternatively it MUST 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 MUST exchange a HI/HACK pair with aAR with a Lifetime option having value 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. 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 MUST begin delivering packets to the MN, and MUST tunnel any CN-bound packets from the MN to aFA. b. Based on its current movement and traffic pattern, MN MAY either defer obtaining a nCoA or begin 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/HACK with itself in Step 3. Upon receipt of the L2-LU trigger on handover completion, the aAR MUST begin routing packets directly to MN and the tunnel to nAR MUST be torn down. The AR MUST still exchangesthe HI/HACK with oAR in Step 4b because oAR can't know a priori that aAR and nAR are the same, but aAR MUST NOT need not gate old tunnel tear down or delivery of MN packets on this exchange. Design Team 27 Internet Draft Fast Handovers for MIPv6 March 2002 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 MAY 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 MUST 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 MAY contine tunnel service with oAR if 1) is selected, until the HI 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 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 network can 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 10 and 11 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three party handover, respectively. Design Team 28 Internet Draft Fast Handovers for MIPv6 March 2002 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 10 - Three Party Source Trigger Handover Timing Design Team 29 Internet Draft Fast Handovers for MIPv6 March 2002 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 11 - Three Party Target Trigger Handover Timing Design Team 30 Internet Draft Fast Handovers for MIPv6 March 2002 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 MUST 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 12 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 MUST occur when the HI contains a zero lifetime. Eventual termination SHOULD occur when the HI 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 gives the number of seconds until the tunnel will be terminated. Extension SHOULD occur when the HI originates with the MN's current AR and it contains a nonzero lifetime. The lifetime of the tunnel is negotiated between the two ARs during handover, and MUST be the shorter of the two lifetime values in the HI/HACK exchange. HI(r) +------+ <-------- +------+ | AR(2)| ---------> | AR(1)| +------+ HACK(r) +------+ Figure 12 - 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 Router Advertisement 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 31 Internet Draft Fast Handovers for MIPv6 March 2002 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 anticipated handover. 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 sub-cases: 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 Router Advertisement 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 anticpated handover to a different AR capable of handling the MN's traffic, if possible. Design Team 32 Internet Draft Fast Handovers for MIPv6 March 2002 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 SHOULD 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 Solicitation for Router Advertisement 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 oAR 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 33 Internet Draft Fast Handovers for MIPv6 March 2002 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 anticipated 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 anticipated handover to a second interface. 4. Interoperability of Handover Mechanisms Depending on deployment, it is possible that a geographic area covered by a wireless network could consist of a mosaic of coverage areas, where each coverage area supports a different mix of handover mechanisms. In addition, MNs supporting different mixes of handover mechanisms could appear in a particular wireless network. Such situations could arise as a result of an incremental upgrade of a network or of MNs from the default Mobile IPv6 handover mechanism to the fast handover mechanisms described in this document, or as a result of a decision by a network operator to deploy ARs or host MNs that support only one or two of the handover mechanisms. In order to handle this case, it is necessary for both the network and the MN to know about the handover mechanisms supported by the other, and to smooth transition between coverage areas from one handover mechanism to another. In addition, if either the network or the MN only support standard Mobile IPv6 handover, the signaling involved in fast handover must be suppressed to avoid unnecessary consumption of wireless spectrum resources. 4.1. Initial Exchange of Supported Handover Mechanism Information When an MN capable of performing fast handover comes up, it is necessary for the MN and the network to exchange some signaling to indicate what handover mechanisms are supported. This exchange MUST take place after the MN has negotiated standard IPv6 Neighbor Discovery [ND], address configuration (either stateless or stateful), and Mobile IPv6 CoA aquisition (if the network is a foreign network). This exchange utilizes the RtSolPr and PrRtAdv in the following way: 1. The MN MUST send a RtSolPr to the current AR with the current AR's own address as the new attachment point link layer address. The MN includes a Handover Capabilities Extension indicating whether tunnel-based handover or anticipated handover should be used. 2. The current AR MUST respond with a PrRtAdv including its link layer address and extension, and a Handover Capabilities Extension indicating what type of handover the AR supports. The AR recognizes that the RtSolPr is an exchange of handover capabilities information and not a request for handover by the fact that the current AR's own link layer address is included in the RtSolPr. The MN receiving the RtSolPr in Design Team 34 Internet Draft Fast Handovers for MIPv6 March 2002 reply MUST NOT issue a F-BU or any other signaling for handover, since the exchange is just to establish handover capabilities and not to perform a handover. There are three possible outcomes of this exchange: 1. If both the MN and AR request tunnel-based handover, then the network will perform tunnel-based handover on behalf of the MN. 2. If the MN requests tunnel-based handover but the AR replies that it is only willing to support anticipated handover, then the MN MUST use anticipated handover. 3. If the MN requests anticipated handover but the AR replies that it is capable of tunnel-based handover, then the network MUST use anticipated handover. An MN and an AR realize capabilities for fast handoff support only via the exchange of the RtSolPr and PrRtAdv messages. 4.2. Signaling Suppression for Standard Mobile IPv6 Handover If a MN supporting the standard Mobile IPv6 mechanism [MIPv6] moves into or comes up in a network that supports the fast handover mechanisms described in this document, then it will not issue a RtSolPr nor will it respond to a PrRtSol with a F-BU. If such a situation arises, the AR MUST suppress any further fast handover signaling, and it SHOULD attempt to inform other ARs in the fast handover coverage area that the MN does not support fast handover, in an attempt to suppress extraneous signaling over the wireless network. The mechanism by which the AR informs the other ARs in the coverage area of this fact is outside the scope of this document. If an MN capable of fast handover moves into or comes up in a network that supports only the standard Mobile IPv6 mechanism [MIPv6], the MN will not receive a reply to its RtSolPr. If the MN does not receive a reply to a RtSolPr, it MUST discontinue performing fast handover, assume that the AR does not support fast handover, and revert to the standard Mobile IPv6 handover mechanism. 4.3. Transition Between Handover Coverage Areas While moving across a wireless network, an MN may encounter a transition between coverage areas in which the wireless network on both sides of the coverage area boundary supports different handover mechanisms. If such a transition occurs, the MN needs to be informed about the transition, in order to assure that handover happens as quickly as the supported mechanism allows. Note that for this to be possible, the ARs on the coverage area boundary must be able to determine what the handover capabilities of the ARs are on the other side. Exactly how this is done is outside the scope of this document. Design Team 35 Internet Draft Fast Handovers for MIPv6 March 2002 4.3.1. Transition between Fast Handover and Standard Mobile IPv6 Areas When a MN performing fast handover (both anticipated and tunnel- based) is about to move into a coverage area in which only the standard Mobile IPv6 mechanism is supported, the AR on the boundary of the fast handover coverage area MUST issue a PrRtAdv including the link layer address and other information for the nAR, and a Handover Capabilities extension indicating that the new AR is only capable of supporting standard Mobile IPv6 handover. If the MN has sent a RtSolPr, then the Handover Capabilities extension is included in the reply. When the MN moves to the nAR, it SHOULD issue an IPv6 Solicitation for Router Advertisement as soon as it gets the L2-LU trigger, if such a trigger is available, to reduce the amount of latency in standard Mobile IPv6 handover. When a MN moves from a standard Mobile IPv6 coverage area into a fast handover coverage area, the AR on the boundary MUST issue a RtSolPr with its own link layer address and other information, and a Handover Capabilities Extension, after the MN has performed standard Mobile IPv6 handover with the boundary AR. The MN recognizes that this is a handover capabilities update by the fact that the RtSolPr contains the current AR's information, and MUST NOT issue a F-BU in response. If the Handover Capabilities Extension indicates that the AR is in an anticipated handover coverage area, then the MN MUST begin to perform anticipated handover. If the Handover Capabilities Extension indicates that the AR is in a tunnel-based coverage area, then the MN MAY perform tunnel-based handover, or it MAY perform anticipated handover by issuing a RtSolPr when it detects that a handover to another AR is pending. 4.3.2. Transition between Tunnel-based and Anticipated Areas If a MN performing tunnel-based handover reaches the boundary of a coverage area and is about to transition into a coverage area where anticipated handover is used, the boundary AR MUST issue a PrRtAdv with the link layer address and other information for the nAR, and a Handover Capabilities extension with the handover capability of the nAR. The MN MUST immediately switch to performing anticipated handover. If a MN performing anticipated handover reaches a boundary of a coverage area where tunnel-based handover is available, the boundary AR includes a Handover Capabilities extension in the PrRtAdv issued to the MN informing it of the handover. The MN MAY switch to tunnel- based handover by suppressing any further anticipated handover signaling (i.e. not sending the F-BU), or it MAY continue to perform anticipated handover. 5. Message Definitions and Option Formats In this section, message and option formats are specified. Design Team 36 Internet Draft Fast Handovers for MIPv6 March 2002 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 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: Design Team 37 Internet Draft Fast Handovers for MIPv6 March 2002 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 for which the MN requests routing advertisement information. 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. The MN MUST send this message if it wants to initiate an anticipated fast handover. It indicates its destination with the New Attachment Point Link-Layer Address. A Proxy Router Advertisement message should be received in response. If such message is not received in a short time period but no less than 2 times the typical round trip time (RTT) over the access link or 100msec if RTT is not known, it SHOULD resend it once or at most twice (after the same waiting time). If the Proxy Router Advertisement is not received by the time the MN disconnects from oAR, Fast Handover can not be performed and the MN SHOULD revert back to the standard Mobile IPv6 algorithm. 5.1.2. Proxy Router Advertisement (PrRtAdv) Routers send out Proxy Router Advertisement message unsolicited if the network is controlling an anticipated handover or in response to a Router Solicitation for Proxy message from a MN. 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 Design Team 38 Internet Draft Fast Handovers for MIPv6 March 2002 interface from which this message is sent. Destination Address The Source Address of an invoking Router Solicitation for Proxy or the address of the node the Access Router is instructing to handover. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 0 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. Design Team 39 Internet Draft Fast Handovers for MIPv6 March 2002 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 nAR). 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 nCoA for the duration of the handover. If not sent the requesting node SHOULD compute the nCoA using the Interface ID from the Destination Address of this message. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. A Proxy Router Advertisement with Code 0 but without a New CoA Option means that the MN SHOULD construct a nCoA 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 MN SHOULD use the CoA indicated as a nCoA at the nAR. The CoA MUST be used when Stateful CoA configuration is indicated and MAY be used to help the oAR and MN calculate the same nCoA 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 oAR is not aware of the Prefix Information requested. The MN MUST give up its attempt to perform fast handover to this new attachment point. Normal MIPv6 MAY be used instead. No options are required in this case. 5.1.3. Fast Neighbor Advertisement (F-NA) Message Format A node sends a Fast Neighbor Advertisement to announce itself to the nAR Design Team 40 Internet Draft Fast Handovers for MIPv6 March 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + NewCOA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + OldCOA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An address assigned to the interface from which the advertisement is sent. Destination Address Typically the all-nodes multicast address. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBD Code 0 Checksum The ICMP checksum. See [ICMPv6]. Reserved 32-bit unused field. It MUST be initialized to Design Team 41 Internet Draft Fast Handovers for MIPv6 March 2002 zero by the sender and MUST be ignored by the receiver. NewCOA The nCoA given to the MN in the Proxy Router Advertisement Old Care-of-Address The oCoA of the MN. 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. The Fast Neighbor Advertisement is sent to the nAR as soon as the MN gains connectivity on the new link and Fast Binding Acknowledgement has not been received. The Fast Neighbor Advertisement is issued because the MN is still unsure about the nCoA it should be using at the nAR. The message contains both new and oCoAs as well as the MNĘs link layer address. The nAR checks the link layer address to see if it has a mapping in its Neighbor Cache. The nAR SHOULD check for mappings to the oCoA of the MN first and if such a mapping does not exist it SHOULD check for a mapping to the nCoA. If there is mapping for either, the nAR MUST send a Router Advertisement on the link to the MN but using the oCoA as destination address. This Router Advertisement MUST include the NAACK option as described in NAACK. If a mapping is found with the nCoA then, the nAR or oCoA MUST change the cache entry to REACHABLE and send a Routing Advertisement with the NAACK option as described in 4.3.3. Note that it is possible for the MN to send data packets immediately following the F-NA message, without waiting for the reaction of the nAR. Such packets MUST use the oCoA as source address and the implementer should be aware that if the nAR is not aware of the mobile, these packets are likely to be dropped. 5.2. Inter-Access Router Messages 5.2.1. Handover Initiation (HI) The Handover Initiation message is a new ICMPv6 message sent by an Access Router to another Access Router to initiate the process of the MN's handover. In the case of anticipated handover, it is sent from the oAR to the nAR. In the case of tunnel-based handover, 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. Design Team 42 Internet Draft Fast Handovers for MIPv6 March 2002 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 to which this message is sent 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 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. Design Team 43 Internet Draft Fast Handovers for MIPv6 March 2002 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 MN The link-layer address of the MN that is being handed of to the destination. This options SHOULD be included to help the destination recognize the MN when it will be connected to it. MUST be present if the H, T, or R bits are set. Old Care-of-Address The IP address used by the MN while attached to the originating router. This option MUST be included so packets to this MN can be redirected to the destination even if the nCoA is not acceptable. MUST be Present if the H or R bits are set. New Care-of-Address The IP address the MN wants to use when connected to the destination. In Stateless configuration this option indicates the new Care of Address the MN will be using when connected to the destination. Lifetime Option Design Team 44 Internet Draft Fast Handovers for MIPv6 March 2002 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. If Handover Acknowledgement message is not received as a response to this messag, 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 nAR about the upcoming handover and, in anticpated handover, to establish a valid nCoA for the MN. If the S flag is SET this message requests an address from the nAR to be assigned statefully. If the new COA option is included the oAR requests the nAR to confirm that this is a valid nCoA. 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. 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 to which this message is a response. 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 to which this message is a response. 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. Design Team 45 Internet Draft Fast Handovers for MIPv6 March 2002 Hop Limit 255 Authentication Header A Security Association MUST exists between the sender and the destination address. This messages MUST be authenticated and so the authentication header MUST be used when this message is sent ICMP Fields: Type TBA Code 0-Handover Accepted, newCOA valid 1-Handover Accepted, newCOA not valid 2- -Handover Accepted, newCOA in use 3- -Handover Accepted, newCOA assigned (Stateful) 4- -Handover Accepted, newCOA not assigned (Stateful) 128-Handover Not Accepted, reason unspecified 129- -Administratively prohibited 130-Insufficient resources Checksum The ICMP checksum. See [ICMPv6]. 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 nCoA the MN should use when connected to this router. Design Team 46 Internet Draft Fast Handovers for MIPv6 March 2002 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. On reception of Handover Initiation the nAR MUST respond with an Handover Acknowledgement. If the S flag is SET in the Handover Initiation, the nAR SHOULD include the new Care of Address option and a Code of 3. If the S flag is not SET in the Handover Initiation, the nAR SHOULD check the validity of the nCoA sent with the Handover Initiation and reply accordingly. If the nCoA is valid, the new access router SHOULD insert the nCoA in its Neighbor Cache and defended on behalf of the mobile for a short period of time, with a default value of 1 second, during which the MN is expected to connect to the nAR. If the nCoA is not valid or not assigned, the nAR SHOULD insert a host route for the mobile node's oCoA in its routing table. This route entry will not be used until nAR receives an indication that MN 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 HTT is triggered by an L2-ST, then it is an extension of HI. If HTT is sent in response to an HI with T bit set, 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 set 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. Design Team 47 Internet Draft Fast Handovers for MIPv6 March 2002 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 MN to notify an oAR that is about to move to a nAR. 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 MN according to [MIPv6]. The Fast Binding Update 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 MN 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 MN on the home link. The home agent becomes the home agent not only for the individual home address given in this binding, but Design Team 48 Internet Draft Fast Handovers for MIPv6 March 2002 also for all other home addresses for this MN 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 MN 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 such address as part of the home registration processing (before returning the Binding Acknowledgement), if the Duplicate Address Detection (D) bit is set in the Binding Update; it is not necessary to perform Duplicate Address Detection individually on each of these addresses, since address uniqueness here is determined solely by the identifier. 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 Update. Each Fast Binding Update sent by a MN 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 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 MN 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. encoding and format of defined sub- options described in [MIPv6]. The following sub- options are valid in a Fast Binding Update option: - Unique Identifier Sub-Option Design Team 49 Internet Draft Fast Handovers for MIPv6 March 2002 - 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 MN 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 CoA for the binding given in the Fast Binding Update option is the nCoA given to the MN by the Proxy Router Advertisement message and is included in the Alternate Care-of Address sub-option in the Fast Binding Update option. The Alternate Care-of Address sub-option 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 MN MUST be deleted. In this case, a Binding Cache entry for the MN 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 MN in its Fast Binding Update List entry for that destination; the last Sequence Number value received from a MN in a Fast Binding Update is stored by the AR in its Binding Cache entry for that MN. Thus, the MN's and the AR's knowledge of the last sequence number expire at the same time. If the sending MN has no Fast Binding Update List entry, the Sequence Number may start at any value; if the receiving AR has no Binding Cache entry for the sending MN, it MUST accept any Sequence Number value in a received Fast Binding Update from this MN. The three highest-order bits of the Option Type indicate specific processing of the option. For the Binding Update option, these three bits are set to XXX, specifying that any IPv6 node processing this option that does not recognize the Option Type must discard the packet. If the packet's Destination Address is not a multicast address, the receiving node returns an ICMP Parameter Problem, Code 2, message to the packet's Source Address. 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 sent by the AR to acknowledge receipt of a Fast Binding Update option. When the AR receives a packet containing a Fast Binding Update option, with the AR's address being the destination address on the packet (only the destination node processes the option since it is a destination Design Team 50 Internet Draft Fast Handovers for MIPv6 March 2002 option), the AR MUST return a Binding Acknowledgement to the source of the packet, if the Acknowledge (A) bit is set in the Fast Binding Update. The Fast Binding Acknowledgement MUST NOT be send to the MN before the oAR receives a Handover Acknowledgement from the nAR. If the Handover Acknowledgement contains a validation of the nCoA, the Fast Binding Acknowledgement MUST be send with the MNĘs nCoA as the destination address. If the Handover Acknowledgement does not contain a validation of the nCoA, the Fast Binding Acknowledgement MUST be sent with the MNĘs tunneled to the nAR. The Fast Binding Acknowledgement MAY also be send to the MNĘs on the old link, to assure that the MN receives it. 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 nCOA is invalid Values of the Status field greater than or equal to 128 Design Team 51 Internet Draft Fast Handovers for MIPv6 March 2002 indicate that the Binding Update was rejected by the receiving node. The following such Status values are currently defined: 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Incorrect interface identifier length Up-to-date values of the Status field are to be specified in the most recent "IANA 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 MN 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 MN in its Binding Cache. If the node sending the Binding Acknowledgement is serving as the MN's home agent, the Lifetime period also indicates the period for which this node will continue this service; if the MN requires home agent service from this node beyond this period, the MN 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 Design Team 52 Internet Draft Fast Handovers for MIPv6 March 2002 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]. 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 Initiation and Handover Acknowledgement messages. The Proxy Router Advertisement and Handover Acknowledgement messages only contain the nCoA while the Handover Initiation message may include both nCoA and oCoA. 5.4.2. Link-layer Addresses (LLA) This extension is based on the [MIER] format. 0 1 2 3 Design Team 53 Internet Draft Fast Handovers for MIPv6 March 2002 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option (including the type, sub-type and length fields) in units of 8 octets. Sub-Type 1 for the Link-layer Address of the new Attachment Point. 2 for the Link-layer Address of the MN. 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. The New Attachment Point Link Layer address contains the link-layer address of the attachment point for which handover is about to be attempted. This is used in the Router Solicitation for Proxy message. The MN Link-Layer address option contains the link-layer address of a MN. It is used in the Handover Initiation message. The Proxied Originator Link-Layer address option contains the Link Layer address of the Access Router for which the Proxy Router Solicitation message refers. These options MUST be silently ignored if attached to 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 Lifetime option is used in tunnel-based handover to indicate the lifetime of the tunnel. The following defines the Lifetime option: Design Team 54 Internet Draft Fast Handovers for MIPv6 March 2002 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 nCoA is valid 1 The oCoA is valid 128 Link Layer Address unrecognized Design Team 55 Internet Draft Fast Handovers for MIPv6 March 2002 Up-to-date values of the Status field are to be specified in the most recent "IANA Assigned Numbers". The NAACK is included by the nAR in a Router Advertisement sent in response to a Fast Neighbor Advertisement. The NAACK indicates to a MN if the nCoA is valid. The same information is given to the MN in the Fast Binding Acknowledgement message that the oAR sends in response to an Fast Binding Update. An implementation of a nAR MAY recognize that the Fast Binding Acknowledgement is in a buffer ready to be send to the MN, and it may cancel sending the Routing Advertisement with NAACK in response to a F-NA. In all other cases, the Routing Advertisement with the NAACK message MUST be send. If the nCoA is valid, the Routing Advertisement MUST use the nCoA as the destination address and the MN SHOULD use it as its CoA as defined in [MIPv6]. If the oCoA is valid, the Routing Advertisement MUST use the oCoA as destination address and the MN MAY use this address as source address and SHOULD start the process of obtaining a nCoA at the nAR. If the NAACK indicates that the Link Layer Address is unrecognized the MN MUST NOT use the nCoA or the oCoA and SHOULD start immediately the process of acquiring a nCoA at the nAR. 5.4.5. Handover Capabilities Extension The Handover Capabilities extension is an extension to the IPv6 Router Advertisement Solicitation and Proxy Router Advertisement that indicates which handover capabilities are supported by the MN, current AR, or nAR. 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 - Indicated node is capable of anticipated handover. 2 - Indicated node is capable of tunnel-based handover. 3 - Indicated node is capable of standard Mobile IPv6 handover only Reserved: Must be set to zero. Design Team 56 Internet Draft Fast Handovers for MIPv6 March 2002 A code of 3 is only sent if the Proxy Router Advertisement is for handover to an AR in a coverage area where only standard Mobile IPv6 is supported. 6. Error Cases and Other Issues In this section, some common error cases affecting the performance and/or reliability of the mechanisms described in this specification are examined. These cases apply to anticipated handover only. 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 is very low, however it can not be ignored. In this draft certain precautions are proposed to minimize the effects of a duplicate address occurrence. On links wherein the uniqueness of the interface identifier is ensured within the subnet (by means beyond the scope of this document), DAD handling procedures SHOULD be avoided. In some cases the nAR may already have the knowledge required to assess whether the MN's address is a duplicate or not before the MN moves to the new subnet. For example, the nAR can have a list of all nodes on its subnet, perhaps for access control, and by searching this list, it can confirm whether the MN's address is duplicated. The result of this search can be sent back to the old AR in the HACK message. If such knowledge is not available in the nAR, the MN must perform DAD after moving to the new subnet unless other measures are taken. To avoid delays due to performing DAD, it is suggested that the MN perform DAD while using its oCoA. This is possible since the framework described in this specification allows packet redirection based on the oCoA encapsulated into the nAR IP address. So, if the nAR cannot confirm the validity of the nCoA address included in the Handover Initiation message but it is never-the-less willing to serve the MN, it can indicate that in the Handover Acknowledgement message and install a host route towards its mobility interface for the MNĘs oCoA. The oAR, on reception of a Handover Acknowledgement in which the nCoA is not validated but the nAR is prepared to accept the MN, sends the MN a BACK having status code 1 as a response to the MN's Fast Binding Update. The oAR now tunnels packets for the MN to the nAR. The nAR de-tunnels the packets and, due to the host route installed earlier, forwards these packets to the mobile. Design Team 57 Internet Draft Fast Handovers for MIPv6 March 2002 The MN will, at some point, either at the oAR or the nAR receive the BUNACK and thus attempt to get a nCoA. If the MN does not receive the F-BACK or BUNACK at the oAR or within a short time (X sec) after has connecting to the nAR, it can assume that the Fast Binding Update was not received by the oAR and it MUST retransmit it. The source address used in this Fast Binding Update SHOULD be the nCoA, which is not yet confirmed, to avoid ingress filtering. If the nCoA is not valid, the oAR will tunnel a BUNACK to the oCoA via the nAR and thus the BUNACK should be safely be received by the MN. 6.1.2. Fast or Erroneous Movement Although specification is for fast handover, the protocol has its limits in terms of how fast a MN can move. A special case of fast movement is ping-pong, were a MN moves between the same two access points rapidly. Another instance of the same problem is erroneous movement i.e.: the MN receives information prior to a handover that it is moving to a new access point and but it is either moved to a different one or it 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 for the MN to update the binding of, at least, its HA and preferably that of every CN with which it is in communication. A MN that moves faster than necessary for this signaling to complete may start losing packets and ultimately connectivity. The signaling overhead over the air and in the network may increase significantly especially in the case of rapid movement between two ARs. To avoid the signaling overhead, the following measures are suggested. A MN returning to the oAR before updating the necessary bindings in the nAR MUST send a Binding Update with Home Address equal to the MNĘs oCoA and a lifetime of zero, to the oAR. The MN should have a security association with the oAR since it performed a fast handover from it to the nAR. The oAR 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 MN and start delivering packets directly to the node instead. The MN SHOULD NOT make any attempt to use any of the fast handover mechanisms described in this specification and SHOULD revert back to standard 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 MN to update all its active bindings. A long life times increases the chance of a Design Team 58 Internet Draft Fast Handovers for MIPv6 March 2002 circular tunnel from AR1 to AR2 and back again to AR3 which could essentially result in a routing loop, especially if the oCoA is used with tunnels between ARs themselves, rather than forwarding to nCoA. Erroneous movement is not likely to damage the network but it may cause loss of packets since routing can change and the oAR may forward packets towards another AR before the MN actually connects to that AR. If the MN discovers itself on the wrong AR, a Fast Binding Update or even a standard Binding Update to the oAR 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 MN. No attempt should be made to recover packets from the AR the MN was supposed to connect to. 7. Neighbor Cache Considerations When an AR receives a Handover Initiation message it checks if the nCoA indicated is already in use by another node. If not, a new cache entry is created with the nCoA and the MN's link layer address also included in the Handover Initiation message. If the nCoA is already in use, the cache entry is created for the oCoA of the MN instead. In either case, AR 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. - It sends any packet queued for the neighbor. 8. Security Considerations 8.1. Security Considerations for Anticipated Handover The security needed for anticipated fast handover is similar to that needed for handling Binding Updates in IPv6. If a handover could be initiated by a node masquerading as the MN, a range of undesirable effects might result. The malicious node could usurp traffic destined from the MN, diverting it to a nearby router and possibly an unauthorized care-of-address. The exact effects would depend on the kinds of handover data available as part of the fast handover process. The adaptive fast handover method assumes that a security association exists between the oAR or aAR and the MN, as well as between the oAR or aAR and the nARs. Providing the above is true then, routing is only changed by receipt of a Fast Binding Update from the MN, which MUST be authenticated. Router Solicitation for Proxy and Proxy Router Design Team 59 Internet Draft Fast Handovers for MIPv6 March 2002 Advertisement messages SHOULD also be authenticated since they are between oAR and the MN, which have a security association. 8.2. Security Considerations for BETH There are two areas of possible security concern: 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 Layer 3 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. In order for the Layer 2 to be secure, it is sufficient that the L2 trigger information received by the oAR, MN, and nAR not be subject to tampering by a third party, i.e. the L2 trigger mechanism MUST NOT allow a third party to substitute the MN or AR L2 addresses in the triggers. This will allow the nAR to ensure that that packets coming from the MN with a particular L2 address match a MN qualified to send them identified by a secure L2 trigger, and for the MN to ensure that the L2 address on packets coming from the nAR match the nAR address in the secure L2 trigger. If the nAR detects a mismatch, it should initiate security measures. If the MN detects a mismatch, it should sever the connection and initiate standard Mobile IPv6 handover with another AR. Furthermore, any authentication or security information involved in providing the MN with Layer 3 service MUST be available to the nAR so that nAR can determine whether the MN is authorized for such service. If the MN is not authorized for such service, packets addressed to or coming from it should be dropped, and the Layer 2 connection severed. 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 association MUST exist between ARs, and the HI, HACK, 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. Design Team 60 Internet Draft Fast Handovers for MIPv6 March 2002 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. [DHCP] R. Droms, editor, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," draft-ietf-dhc-dhcpv6-20.txt, a work in progress. [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, March 1982. [MIER] M.Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, Mobile IP Extensions Rationalization (MIER)(work in progress). draft-ietf-mobileip-mier-05.txt, December 1999. [MIPv6] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. [ND] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [TUNL] A. Conta, and S. Deering, "Generic Packet Tunneling in IPv6 Specification," RFC 2473, December, 1998. 11. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Design Team 61 Internet Draft Fast Handovers for MIPv6 March 2002 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 authors of 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 Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 George Tsirtsis, Flarion Technologies, G.Tsirtsis@flarion.com Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone:+1 408 525 1404 EMail: gdommety@cisco.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 62