Personal G. Tsirtsis Editor A. Yegin C. Perkins G. Dommety H. Soliman M. Khalil Internet Draft Title:draft-designteam-fast-mipv6-00.txt Category: Informational January 2001 Expires : June 2001 Fast Handovers for Mobile IPv6 draft-designteam-fast-mipv6-00.txt Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document specifies protocol enhancements to MIPv6 that enable mobile nodes to more quickly become connected at new points of attachment to the Internet. These protocol enhancements are intended to minimize the time during which the mobile node is unable to send or receive IPv6 packets (i.e., the handover latency). This Internet Draft is intended to become a standards track document after completion of sections on message flows and formats. Design Team 1 Internet Draft Fast Handovers for MIPv6 January 2001 1. Introduction This draft presents the initial output of the MIPv6 Design Team on Fast Handovers with Mobile IPv6. The design team has significant background information and discussion that will be added in a future version of this document. For now, the draft only contains the solution sections so that the working group can focus on comments to this part of the document. 2. Message Flows for Fast Handover In this section, we display some proposed message flows to take care of the most important scenarios and sub-scenarios examined. The design decision has been taken not to consider scenarios in which the handoff cannot be initiated until the mobile node has layer-2 connectivity to the new access router, since these are covered adequately by the base Mobile IPv6 Specification [MIPv6]. In scenarios which the handoff can be initiated while the mobile node still has layer-2 connectivity at the previous access router, another design decision has been taken. Since this specification deals with layer-3 issues, the handover is considered to require some layer three information relevant to the new access router. Specifically, the handover at layer 3 requires a new care-of address on the new link, as well as prefix lifetime information and possibly other link parameters typically advertised by the new access router. Situations where the mobile node would be expected to acquire this information from advertisements from the new access router while still maintaining layer-2 connectivity with the previous access router are excluded from consideration in this specification. Otherwise, the protocol would actually become a special case of again the base MIPv6 specification. This Fast Handover proposal uses the IP layer messages/flows in the following subsections. Some of these messages are optional and their exact use depends on the specific sub-case of the scenario. Some messages, as will be indicated whenever appropriate, may be replaced by suitable L2 messages when these are available in specific systems. 3. General Framework for Message Flows The aim of this general framework is to be flexible and yet deterministic and robust. There does not seem to be a single well-defined set of flows that can solve the Fast Handover problem in all cases. Instead a framework is defined which a network administrator can configure in a number of different ways to get the desirable result for a particular scenario. Design Team 2 Internet Draft Fast Handovers for MIPv6 January 2001 The most important differences between the scenarios covered in this section are the level of dependence on L2 capabilities, and the way the newCOA is generated. MN oldAR newAR | | | |-----RtSolPr-------->| | | | | |<------PrRtAdv-------| | | | | |----------BU-------->|--------HI--------->| |<--------BUAck-------|<-------HAck--------| | forward | | packets===============>| | | | |--------------------BU/ND--------> | | | deliver |<=====================================Packets 3.1. Messages in this specification The following messages are used in this specification and are defined in detail in later sections: - Router Solicitation Proxy (RtSolPr) - MN to oldAR (Optional - Can be replaced by L2 message from MN or Network Management) - Proxy Router Advert (PrRtAdv) - oldAR to MN (Optional - Can be replaced by L2 trigger) - Binding Update (BU) - MN to oldAR (Compulsory when C=0 in PrRtAdv; optional when C=1) - Binding Ack (BUAck) - oldAR to MN (Mandatory if A Flag is SET in BU) - Handoff Initiate (HI) - oldAR to newAR (Mandatory) - Handoff Ack (HAck) - newAR to oldAR (Mandatory if A Flag is SET in HI) For BUAck, HAck, and BUAck a new NAck Code is needed: "DAD Failed". Design Team 3 Internet Draft Fast Handovers for MIPv6 January 2001 3.2. Observation about the PrRtAdv message The PrRtAdv message is used to inform the MN of alternative ARs and provide information so the MN can configure a newCOA before it moves. This message can be triggered by one of the following mechanisms: 3.2.1. RtSolPr Message This is a special IPv6 Router Solicitation Message with different subtype indicating that the MN is looking for alternative ARs. MN oldAR newAR | | | |-----RtSolPr-------->| | | | | 3.2.2. L2 Trigger This can be a L2 message from the MN or a network management station in the network indicating the same think as the RtSol message. MNs using a layer 2 technology or service that has this capability may not need to send RtSol messages. MN oldAR newAR | | | |-----L2 Trigger----->| | | | | OR MN oldAR Management Station | | | | |<---L2 Net Trigger--| | | | In any case if the MN is going to create a newCOA before it moves the PrRtAdv message will be send from the oldAR to the MN. The details of how the oldAR gets the information required to construct the PrRtAdv message are implementation specific and not part of this specification. The following two subsections specify different ways the PrRtAdv message can be configured and the effects this will have on the handover process. Design Team 4 Internet Draft Fast Handovers for MIPv6 January 2001 3.3. Network Determined Handover In this case the PrRtAdv message has the following settings: - C Flag is SET to indicate that the mobile node is instructed to change Access Routers. - The Prefix field contains exactly one entry. This may be a /64 or shorter Prefix, in which case the MN will use stateless address auto-configuration to configure the newCOA. Alternatively, the field may contain a 128-bit address, in which case this is stateful address configuration and the MN will have to use the given address as its new care-of address. In the general case the oldAR SHOULD immediately send a HI message to the newAR. The HI informs the newAR of the details of the MN coming its way and after the HAck is being received (if requested) the oldAR will start forwarding packets for the MN towards it newCOA. In combination with some L2 technologies the oldAR MAY be able to postpone the time when it starts forwarding packets to the newAR for when the MN is actually disconnected from it. Note that the oldAR MAY be configured to buffer and/or bicast packets to the MN to minimize packet loss, especially in cases were the L2 technology does not give clear indications when the MN disconnects from the oldAR. The newAR may also be configured to buffer packets to the MN's newCOA until the MN actually connects to the newAR again to minimize packet loss. Bicasting and buffering details are implementation depended and out of scope for this specification. MN oldAR newAR |<------PrRtAdv-------| | Disconnect |--------HI--------->| | |<-------HAck--------| | forward | | packets===============>| Connect | | |-------------------BU/ND-----------> | | | Deliver |<=====================================Packets The handover is completed when the MN connects to the newAR. Depending on the circumstances the MN may be able to just send a BU to its Home Agent or go through Neighbor Discovery before that (see discussion in 3.6). Either way this enables the newAR to forward packets redirected by the oldAR to the MN. The MN will now have to register its new COA to its Home Agent as normal so the redirect path can be dropped. Design Team 5 Internet Draft Fast Handovers for MIPv6 January 2001 An alternative message sequence has HI/HAck message exchange proceeds the PrRtAdv message send from the oldAR to the MN. This provides a way to retrieve the correct contents for the PrRtAdv from the newAR when this information is not available to the oldAR by other means. MN oldAR newAR | | | | |--------HI--------->| | |<-------HAck--------| |<------PrRtAdv-------| | | | | | forward | | packets===============>| Disconnect | | | | | | | | Connect | | |-----------------BU/ND------------> | | | Deliver |<=====================================Packets Different types of new COA allocation are possible using the above message sequences and they are expressed as a combination of the newCOA field and the S flag in the HI message. S Flag (Stateful) in the HI message signifies the following. If S=1 the HI requests a full address. In particular a. newCOA = 0 & S=1 newAR should return a newCOA b. newCOA!= 0 & S=1 oldAR has assigned a newCOA c. newCOA = 0 & S=0 oldAR should return a Prefix d. newCOA!= 0 & S=0 not allowed - error 3.4. Mobile Determined Handover In this case, although the PrRtAdv message is being triggered exactly the same way as in section 3.3, the message can be used in different configurations. In particular: - The C Flag is zero (0), indicating "Optional". - The Prefix field contains one or more Prefixes, potentially from a number of different ARs. Design Team 6 Internet Draft Fast Handovers for MIPv6 January 2001 The MN can now configure addresses using stateless address auto-configuration and the Prefixes provided. To initiate handover the MN MUST send a BU message indicating the newCOA that is going to be using out of the choice of Prefixes that it was provided with. On reception of the BU message the oldAR immediately sends an HI message to the newAR. As in section 3.3, the HI informs the newAR of the details of the MN coming its way and after the HAck is being received (if requested) the oldAR will start forwarding packets for the MN towards its newCOA. As before, in combination with some L2 technologies the oldAR MAY delay forwarding packets to the newAR until after the MN is actually disconnected from it. For that the BAck from the oldAR SHOULD be bicasted to the old and newCOAs of the MN to increase the chances of it being received by the MN. Note that this is about bicasting of the BAck ONLY. Unlike section 3.3 the MN has the ability to request general Bicasting and/or buffering by the oldAR by setting the B/U Flags in the BU message (see section 4.3). The oldAR, however, should be able to ignore/supersede the request based on local policy. The setting of the U (buffer) flag in the BU messages SHOULD be maintained in the HI message. The newAR, however, SHOULD also be able to ignore/supersede the request. MN oldAR newAR |<-----PrRtAdv--------| | |--------BU---------->| | Disconnect |-------HI---------->| | |<------HAck---------| | forward | | packets===============>| Connect | | |------------------BU/ND-------------> | | | Deliver |<=====================================Packets The handover is completed when the MN connects to the newAR and by a combination of BUs and Neighbor Discovery (see discussion in 3.6). This enables the newAR to forward packets redirected by the oldAR to the MN. Finally note that MN controlled handoffs supercede network controlled handoffs which means that the Binding entries done by MNs should not be overwritten by binding entries done by the ARs. Design Team 7 Internet Draft Fast Handovers for MIPv6 January 2001 3.4.1. Mobile Determined with DAD Request In this case the PrRtAdv message has the DAD flag NOT SET indicating that DAD should be performed in this handover. The MN constructs a BU message the same way as before but also SETs the A flag requesting a BUAck. MN oldAR newAR |<-----PrRtAdv--------| | |--------BU---------->| | | |-------HI---------->| | |<------HAck---------| |<------BUAck---------| | Disconnect forward | | packets===============>| Connect | | |--------------------BU/ND-------> | | | Deliver |<=====================================Packets The oldAR sends the HI message to the newAR also indicating that DAD and HAck is required. The newAR performs DAD on behalf of the MN on the newCOA and returns the result to the oldAR in the BUAck. The oldAR can now reply to the MN confirming or not the newCOA. To make the protocol more robust the BUAck MAY be sent to both the oldCOA and the newCOA. As before the oldAR SHOULD immediately assume the MN is now disconnected, unless the particular L2 technology used can signal detachment explicitly. Bicasting and/or buffering can also be used as before. 3.5. Layer 2 Assisted Variation In this case we use the advanced capabilities of some L2 technologies to minimize traffic over the air and speed up the process even further. The mechanism described here is entirely optional and may not be applicable to some L2 technologies. If available, however, this mechanism can be used either on its own for a handover that is fully depended on L2 or as a fall-back to the mechanisms described above. In this scenario there are no L3 messages over the air interface but these are replaced exclusively by L2 messages. So, while the MN is connected to the oldAR a L2 trigger/message from the MN itself or from the network (details are L2 technology specific and out of scope of this specification) triggers the oldAR to send a HI message to the newAR. This HI, however, indicates to the newAR that an MN is coming its way that will attempt to retain its oldCOA. This can be achieved by setting the HI as follows: Design Team 8 Internet Draft Fast Handovers for MIPv6 January 2001 MN oldCOA: MN's COA in the oldAR MN Link Layer Address: L2 Address of the MN U Flag: Buffering Flag A Flag: BUAck Required Flag MN oldAR newAR | | | | L2 Trigger | Disconnect |--------HI--------->| | |<-------HAck--------| | forward | | packets===============>| Connect | | | | L2 Trigger | | Deliver |<=====================================Packets | | | The handover is completed by the MN connecting to the newAR which, again will get a L2 technology specific indication of that. This triggers the newAR to forward packets redirected by the oldAR to the MN. The newAR will now also send a Routing Advertisement to the MN so that it can get a newCOA. The MN will register the COA to its Home Agent as normal and the redirect path will be dropped some time later. 3.6. Sending Binding Updates at the New Access Router When the mobile node move to a new access router, it needs to send a Binding Update to its home agent. It also may need to send a Binding Update to its old access router, unless it has a positive indication that the old access router already has made the appropriate binding cache modifications. The typical form of such a positive indication is a Binding Acknowledgement send from the old access router to the mobile node; if the mobile node expects but does not receive the acknowledgement, then it must effectively carry out the retransmission algorithm for Binding Updates, as specified in [MIPv6]. In this section, it is considered that all necessary link establishment details have been completed. This may possibly include Duplicate Address Detection, and/or reception of a Router Advertisement from the new access router. Those events may not always have to occur, and when they are needed they must have occurred before the transmission of Binding Updates messages. Design Team 9 Internet Draft Fast Handovers for MIPv6 January 2001 When the new access router receives any packet from the mobile node to be forwarded elsewhere, it means that the mobile node considers the new access router to be its default router, and thus that link establishment is complete from the point of view of the mobile node. If the Binding Acknowledgement was received, then the mobile node only has to send the Binding Update to its home agent. In that case, that Binding Update would be sent through the mobile node's default router--that is, the new access router. If on the other hand the mobile node has not yet received a Binding Acknowledgement from the old access router, then the mobile node SHOULD arrange for oldAR to receive an appropriate Binding Update associating the mobile node's new care-of address to its new care-of address (as specified in [MIPv6]). Therefore, we specify that if the mobile node knows the address of the newAR, it should first send any necessary Binding Update packet to its old access router, before sending the Binding Update packet to its home agent. Furthermore, alternative encapsulation strategies, which would allow both Binding Update options to be sent with a single transmission over the air from the mobile node, are the subject of current discussion in the design team. If the mobile node does not know the address of the new access router, Neighbor Discovery will have to take place before the Binding Update is send. In some circumstances, packets sent by the mobile node to the previous access router just before handover may have been dropped. If this information contained directives to the oldAR to initiate the smooth handover, the new access router may not have taken any steps to speed up the handover before the mobile node arrives. In this case, the mobile node may assume that the new access router is ready to provide connectivity, and then send a Binding Update through the new access router before Duplicate Address Detection has been accomplished for the new care-of address. In this case, the new access router is expected to send a (perhaps newly defined) ICMP message back to the mobile node. After taking care of the necessary processes to protect its link-local address on the network at the new point of attachment, the mobile node MAY resend the same Binding Update packet(s) to the new access router, and/or home agent without any recalculation. 3.6.1. Features enabling Partial Handover Optimization The following features are related, and yet able to be separated, and enable various facets of connectivity between the mobile node and the new access router. 1. The mobile node may be able to discover the IP address of the new access router Design Team 10 Internet Draft Fast Handovers for MIPv6 January 2001 2. The mobile node may be able to discover the MAC address of the new access router. 3. The mobile node may be able to direct the new access router to ascertain the uniqueness of its new care-of address before establishing connectivity with the new access router 4. The mobile node may be able to send a Binding Update to its previous access router before breaking the previous connection 4a. The mobile node may be able to receive the Binding Acknowledgement for the Binding Update sent to the old access router before breaking the old connection. 4b. The mobile node may fail to receive the Binding Acknowledgement for the Binding Update sent to the previous access router before breaking the old connection. All of these operations are possibly both in the network-determined and the mobile-determined scenarios. If (1), (2), and (3) hold, then the mobile node can begin to use the new access router as its default router as soon as layer-2 connectivity is established. Thus, in this optimal circumstance, any necessary Binding Updates can be delivered without any additional delay as soon as the mobile node gets to the new network. If any of (1), (2) or (3) do not hold, then the mobile node is required to perform some combination of Neighbor Discovery and Duplicate Address Detection when it arrives at the new access router's area. For all of cases 4, 4a, 4b, a simple rule is effective. If the mobile node does not receive a Binding Acknowledgement for the Binding Updates that it has sent, then it MUST retransmit those Binding Updates according to the retransmission algorithm specified in the base Mobile IPv6 document. 4. Message Extension and Option Formats In this section, message and option formats are specified. The description for each message extension and option will specify which message or option it may be used with. Design Team 11 Internet Draft Fast Handovers for MIPv6 January 2001 4.1. Router Solicitation for Proxy (RtSolPr) Hosts send Router Solicitation for Proxy in order to prompt routers to generate Proxy Router Advertisements quickly. RtSolPr is identical to Router Solicitation message in [ND] with the following differences IP Fields: Source Address The MN's COA Destination Address The address of the oldAR ICMP Fields: Type TBA NOTE: New TYPE ensures that ARs that do not support it will ignore it! The MN will naturally revert back to one of the other scenarios or just basic MIPv6. Possible options: Link-layer address of originator The link-layer address of the originating node. 4.2 Proxy Router Advertisement Message Format Routers send out Router Advertisement message periodically, or in response to a Router Solicitation. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|C|D| Resv | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Design Team 12 Internet Draft Fast Handovers for MIPv6 January 2001 ICMP Fields: Type TBA C 1-bit 'compulsory handoff' flag. When set, hosts SHOULD configure a newCOA according to PREFIX and attempt to handover to newAR D 1-bit 'DAD' Flag. When set DAD is required for the newCOA Resv A 4-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Router Lifetime 16-bit unsigned integer. This should indicate the time in which the node needs to confirm the contents of this message from the newAR. Possible options: Link-layer address of originator The link-layer address of the newAR to which this PrRtAdv relates to. Prefix Information Indicates one or more prefix(es) of the new AR. For stateful configuration there should be exactly one, 128bits long, address in this field. 4.3 Modified Binding Update Option Three bit B, U, F are added to the flag bits in the Binding Update Option. The mobile node sets the B flag in the Binding Update, to indicate that the mobile node would like the AR to do bicasting. The mobile node sets the U flag in the Binding Update to indicate that the mobile node would like the AR to do buffering. Finally, the mobile node sets the F flag to indicate that the mobile node would like the AR to start forwarding the data towards the mobile node. The AR MAY honor the previous requests or reject them silently. Thus, the Binding Update Option under Fast Handovers for Mobile IPv6 will show as below: Design Team 13 Internet Draft Fast Handovers for MIPv6 January 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|B|U|r|r| Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- B The mobile node is requesting the AR to do bicasting. U The mobile node is requesting the AR to do buffering. r reserved and it MUST be set to 0. The rest of the flag bits and the other fields are as defined in [MIPv6]. 4.3. Handover Initiation (HI) Option The Handover Initiation destination option is sent by the old Access Router to new Mobility Access router to initiate the process of Mobile Node's handover from one sub-network to a new sub-network. 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. The Handover Initiation option is encoded 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Sub Type |A|D|U|S| Rsv | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Option Type TBA Design Team 14 Internet Draft Fast Handovers for MIPv6 January 2001 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 4 plus the total length of all sub- options present, including their Sub-Option Type and Sub- Option Len fields. Opt Sub Type 1 for Handover Initiation option. Acknowledge (A) The Acknowledge (A) bit is set by the sending mobile node or Mobility Access Router to request a Handover Acknowledgement be returned upon receipt of the Handover Initiation message. Duplicate Address Detection (D) If this flag is set, Duplicate Address Detection is required for the newly assigned COA by the destination node. Request For Buffering (U) If this flag is set, buffering for data destined to mobile node is requested. Should be copied from BU message if MN determined handoff. Stateful Indicator (S) This flag will indicate that the AR is requested to allocate a Care-of address on behalf of the mobile node. Rsv This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Sequence Number It is a monotonically increasing counter value used by the receiving node to sequence the Handover Initiation Request and by the sending node to match a returned Handover Initiation Acknowledgement with this Handover Initiation. Sub-Options Additional information, associated with this Handover Initiation option: - Old CoA - New COA (if a full COA has been assigned) - Home Address - MN's L2 address Design Team 15 Internet Draft Fast Handovers for MIPv6 January 2001 4.4. Handover Acknowledgement (HACK) Option The Handover Acknowledgement destination option is used to acknowledge receipt of a Handover Initiation option. When a node receives a packet containing a Handover Initiation option, with this node being the destination of the packet, this node MUST return a Handover Acknowledgement to the source of the packet, if the Acknowledge (A) bit is set in the Handover Initiation. As 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. The Handover Acknowledgement is encoded 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Sub Type | Status | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Option Type As in 4.1 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 4 plus the total length of all sub- options present, including their Sub-Option Type and Sub- Option Len fields. Opt Sub Type 2 for Handover Acknowledgment option Status 8-bit unsigned integer indicating the disposition of the Handover Initiation Request. Values of the Status field less than 128 indicate that the Handover Initiation Request was accepted by the receiving node. The following such Status values are currently defined: 0 Handover Initiation 128 Reason unspecified 130 Administratively prohibited 131 Insufficient resources 132 Duplicate Address Detection failed Up-to-date values of the Status field are to be specified in the most recent "Assigned Numbers" [AssNum]. Design Team 16 Internet Draft Fast Handovers for MIPv6 January 2001 Sequence Number The Sequence Number in the Handover Acknowledgement is copied from the Sequence Number field in the Handover Initiation Request being acknowledged, for use by the old Access Router in matching this acknowledgement with an outstanding Handover Initiation Request . Sub-Options newCOA (if newCOA=0 & S=1 in HI) 4.5. Generalized IP Address Sub-Option: This section defines the Generalized IP Address Sub-Options, which may be used by any Mobile IPv6 destination options such as Handover Initiation Request, Handover Request and Handover Initiation Acknowledgement destination options. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 17 octets Sub-Type This field contains the IP address sub-type. The following sub-types are defined: 0 undefined 1 Old Care-of Address 2 New Care-of Address 3 Alternative Care-of address [MIPv6] IPv6 IP address The IP address for the unit defined by the Sub-type field. Design Team 17 Internet Draft Fast Handovers for MIPv6 January 2001 4.6 Generalized Link Layer Address Sub-Options: This section defines the Generalized Link Layer Address Sub-Options, used by Binding Update that needs to communicate Link Layer addresses. The format of the extension follows [MIER], and each sub- type of link-layer address defines its own sub-structure. This section defines three sub-types, the cdma2000 IMSI and the Ethernet Address and the Global ID. Future RFCs should allocate their own sub-type and define their own address formats. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Opt Type | Length | Sub-Type | GLLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length The length of the Link Layer Address + the one octet Sub-Type field Sub-Type This field contains the Link Layer sub-type identifier GLLA Contains the Link Layer Address In this document, three subtypes are defined: 1 cdma2000 International Mobile Station Identity [IMSI] 2 Ethernet 48 bit MAC address [MAC] 3 64 bit Global ID, EUI-64 [EUI] 4.6.1. cdma2000 Link Layer Address Sub-Option The cdma2000 Link Layer Address Extension contains the International Mobile Station Identity, as defined in [IMSI]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Opt Type | Length | Sub-Type | IMSI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Design Team 18 Internet Draft Fast Handovers for MIPv6 January 2001 Length The length of the IMSI field including the Sub-Type field Sub-Type 1 IMSI Contains the IMSI. Where the is an ASCII-based representation of the International Mobile Station Identifier. 4.6.2. Ethernet Link Layer Address Sub-Option The Ethernet Link Layer Address Extension contains the 48 bit Ethernet MAC Address, as defined in [MAC]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Opt Type | Length | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 7 (includes the Sub-Type field) Sub-Type 2 MAC Contains the 48 bit Ethernet MAC Address. 4.6.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension The 64-Bit Global Identifier (EUI-64) Address Extension contains the 64 bit address, as defined in [EUI]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Opt Type | Length | Sub-Type | EUI-64 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Design Team 19 Internet Draft Fast Handovers for MIPv6 January 2001 Sub-Opt Type TBD Length 9 (includes the Sub-Type field) Sub-Type 3 EUI-64 Address Contains the 64-Bit Global Identifier Address. 5. Error Cases and other issues In this section we are going to examine some common error cases that may affect the performance and/or reliability of the mechanisms described in this specification. Error cases may occur due to either operation problems (duplicate addresses, ping pong etc) or loss of signaling messages. **This section is not yet complete but provides an idea of the error cases that may need to be considered** 5.1. DAD handling Duplicate Address Detection (DAD) was defined in [AUTO] to avoid address duplication on links when stateless address autoconfiguration is used. The use of DAD to verify the uniqueness of a statelessly configured IPv6 address may add delays to a MIPv6 handoff. The probability of an interface identifier duplication on the same subnet can be considered very low, however it can not be ignored. In this draft certain precautions are proposed to minimize the effects of a duplicate address occurrence. In some cases the new AR may already have the knowledge required to assess whether the MN's address is duplicated or not, before the MN moves to the new subnet. For example, the AR can have a list of all nodes on its subnet (may be used for access control) and by searching this list it can confirm whether the MN's address is duplicated. The result of this search can be sent back to the old AR in the HAck message. If such knowledge is not available in the new AR, the MN would have to perform DAD after moving to the new subnet. To avoid delays due to performing DAD, it is suggested that the MN performs DAD while using the new address. The aim is to reduce disruption of services while not disturbing other MNs traffic. This is described below in more detail. Design Team 20 Internet Draft Fast Handovers for MIPv6 January 2001 5.1.1. Perform DAD in parallel with normal operation In this scenario, a MN may choose to continue sending and receiving packets using its new COA while performing DAD in parallel. If DAD succeeds, then the MN will continue on using its new COA, otherwise the MN MUST follow the rules in [AUTO]. Although at first sight this method may seem unreliable, several assumptions may be made for certain scenarios which may allow this method to become more reliable. These assumptions are shown below: - While DAD MUST be done, the probability of collisions between two IPv6 addresses can be considered very low. - An AR will only overwrite a neighbor cache entry for a MN only if another MN sends a Neighbor Advertisement with the "O" flag set. Therefore a MN SHOULD not set the "O" flag in a Neighbor A Advertisement sent immediately after a handover, hence minimizing the chance of disrupting other MNs' traffic. - In some scenarios where the MN has an SA with the AR, ND messages can be authenticated to stop any node from overwriting another node's entry in the AR's Neighbor Cache. Hence, an AR would know which MN owns an address, and will not permit the a MN to overwrite another MN's address. 5.2. Anchor Chaining------TBD------- 5.3. Ping-Pong Effect-----TBD---- 5.4. Network Determined Handover Here we examine the effects of loss of signaling in the network determined case. - PrRtAdv does not reach the MN. MN oldAR newAR | X---PrRtAdv-------| | Disconnect |--------HI--------->| | |<-------HAck--------| | forward | | packets===============>| Connect | | |--------------------RtSol---------------->| |<-------------------RtAdv-----------------| | | Deliver |<=====================================Packets Design Team 21 Internet Draft Fast Handovers for MIPv6 January 2001 The HI/HAck messages actually have actually completed the handoff. i.e: the newAR has state regarding the MN or its new binding if PrRtAdv was attempting stateful address allocation. Nevertheless the MN is not aware of it so it attempts to get Routing Advert from the newAR. The Router Advert returned by the newAR should contain the same information the PrRtAdv sent by the oldAR earlier. This way the handoff will complete and any buffered data will be delivered. For this to work the newAR must be able to recognize the MN so. The MN should add its L2 address sub-option to the RtSol [ND]. If the newAR can not recognize the MN or the MN does not announce itself at the newAR then some loss of data may occur (fall back to basic MIPv6). Note that in this case a BU to the oldAR after the MN connects to the newAR will not enable a smooth handoff. - The HI does not reach the newAR MN oldAR newAR |<------PrRtAdv-------| | Disconnect |--------HI------X | | | | Connect | | |--------------------BU--------------------+ | |<-------------------+ The MN has a new binding but this was not conveyed to the newAR. In this case the newAR will not be able to recognize the MN. The MN should attempt to send a BU to the oldAR which may be able to produce a smooth handoff. Note that in the case of stateful address configuration the sequence is HI, HAck and then PrRtAdv, in which case loss of HI means that the MN falls back to simple MIPv6. 5.5. Mobile Determined Handover Here we examine the effects of loss of signaling in the mobile determined case. - The PrRtAdv does not reach the MN The MN can not compile a new address and thus can not send a BU. HI/HAck messages are never triggered the MN falls back to simple MIPv6 - The HI message does not reach the newAR Same with corresponding case in 5.4. Design Team 22 Internet Draft Fast Handovers for MIPv6 January 2001 - The BU never reaches the oldAR This has exactly the same effect with the HI no reaching the newAR - The BUAck is lost In this case the MN is not sure if the BU was received or whether the HI was sent, therefore it may not be able to receive packets. To be able to deal with this case the retransmission timer for the BU should be set to a small value (e.g.: the L2 propagation delay period. I.e.: the time it takes for the message to get to the AR when sent by the MN). Also, the oldAR should send the BAck to the old and new link. If no BAck arrives at the old link before the MN disconnects and no BAck arrives at the new link, the MN resends the BU to the old AR as per MIPv6 from the newAR. See discussion in 3.6. 5.6. Mobile Determined with DAD Request In the stateful case, loss of BU means that no BUAck will be received at the old link. The MN will have to send the BU again from the newAR. 6. Security Considerations The security needed for fast handover is almost the same as is needed for handling Binding Updates in IPv6. If a handover could be initiated by a node masquerading as the mobile node, a range of undesirable effects might result. The malicious node could usurp traffic destined from the mobile node, diverting it to a nearby router and possibly an unauthorized care-of address. The exact details of the possible effects would depend on the kinds of handover data available as part of the fast handover process. 7. Acknowledgements Thanks to Basavaraj Patil and Phil Roberts for supporting this effort and the whole Mobile IP WG for participating in the initial discussion. Design Team 23 Internet Draft Fast Handovers for MIPv6 January 2001 References [ASSNUM] J. Reynolds, J. Postel, Assigned Numbers, Request For Comments (Standards Track) 1700. October 1994. [AUTO] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [IMSI] TIA/EIA/IS-95-B [MAC] D. Plummer, "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1982. [MIER] M.Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, Mobile IP Extensions Rationalization (MIER)(work in progress). draft-ietf-mobileip-mier-05.txt, December 1999. [MIPv6] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. [ND] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Design Team 24 Internet Draft Fast Handovers for MIPv6 January 2001 The authors of this document are: Alper Yegin Sun Alper.Yegin@eng.sun.com Charles E. Perkins Nokia charliep@iprg.nokia.com George Tsirtsis Flarion G.Tsirtsis@flarion.com Gopal Dommety Cisco gdommety@cisco.com Hesham Soliman Ericsson Hesham.Soliman@era.ericsson.se Mohamed Khalil Nortel mkhalil@nortelnetworks.com --------------------------end-------------------------------------------