INTERNET DRAFT Category: Standards Mohamed Khalil Title: draft-mkhalil-mobileip-ipv6-handoff-00.txt Haseeb Akhtar Date: October 2000 Krish Pillai Expires: March 2001 Emad Qaddoura Nortel Networks AAA Interface for IPv6 Handoff Status of this Memo This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@ipass.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 draft outlines a protocol to achieve minimal disruption during Mobile IPv6 handoff. Minimal disruption during handoff is required by Mobile IPv6 to reduce the window of data loss experienced by a MN (Mobile Node) when moving between access networks that may belong to same or different administrative domains. Khalil et al. expires March 2001 [Page 1] INTERNET DRAFT October 1999 Table of Contents 1.0 Introduction 1.1 Copyright Statement 1.2 Requirements language 1.3 Terminology 2.0 Objective 3.0 Definition of Handoff Delay 4.0 Proposed System Architecture 4.1 Control Plane 4.2 Data Plane 5.0 Intrdomain Initial Registration 6.0 Reactive Intradomain Handoff 7.0 Proactive Intradomain Handoff 8.0 Interdomain Initial Registration 9.0 Reactive Interdomain Handoff 10.0 Proactive Interdomain Handoff 11.0 References 12.0 Acknowledgements 13.0 Author Information 14.0 Full Copyright Statement Khalil et al. expires March 2001 [Page 2] INTERNET DRAFT October 1999 1.0 Introduction This draft outlines a protocol to achieve minimal disruption during Mobile IPv6 handoff. Minimal disruption during handoff is required by Mobile IPv6 to reduce the window of data loss experienced by a MN when moving between access networks that may belong to same or different administrative domains. In this draft we consider two types of handoff. First, the reactive handoff where the MN does not have a knowledge of the sub- network it is moving to until it receives a router advertisement. Second, the proactive handoff where the MN has the knowledge about the sub- network it is moving to before its L2 (layer two) connectivity is established. Since a AAA (Authentication, Authorization and Accounting) protocol will be used in the future to provide authentication, authorization and accounting functions, our proposed solution takes into account of the existence of AAA. 1.1 Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. 1.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [13]. 1.3 Terminology This document frequently uses the following terms: MM (Mobility Manager) An MM (Mobility Manager) is an entity in the mobility service provider domain which communicates with the AAA in the current adomain,llocate a mobility router (HA) to route the traffic destined to the MN while it is away from home. It may also have an access to the authentication and key generation centers to authenticate the user as well as generate session keys. The MM will act as a temporary agent to forward the data traffic to the MN until the registration process is completed with with the HMM (MM at the home domain). HMM (Home Mobility Manager) It is the MM at home domain. Khalil et al. expires March 2001 [Page 3] INTERNET DRAFT October 1999 SMM (Serving Mobility Manager) It serves the function of the MM within a foreign domain. 2.0 Objective The proposed solution for handoff is designed with the following objectives. 1 - The control and data plane are two separate entities. The session setup and management are performed in the control plane, whereas the data transfer between a CN (Correspondent Node) and a MN is done in the data plane. 2 - The data transfer (for data plane only) between a CN and a MN should not go through any additional functional blocks that are not defined in the Mobile IPv6 support [1]. Adding these type of nodes to the network present the following disadvantages: a - prove to be a bottle neck in the system. b - complicate the architecture thorough an increase in component count. c - potential single point of failure, unless made robust through high availability. d - may force traffic to flow along non-optimal routes to allow control action by such nodes. 3 - The proposed solution should require only minimal extensions to the IPv6 protocol [1] and should fully exploit and track the evolving routing and addressing capabilites offered by IPv6. 4 - The proposed solution should be generic enough and independent of the type of wireless technology or access medium. 5 - The proposed solution should fuly support, and be consistent with a AAA architecture. 6 - The proposed solution should optimize air-interface usage for efficiency. The current IPv6 protocol requires n+4 number of messages to be sent in case of a handoff: n being the number of Binding Update messages sent to n CNs, 2 round trip messages sent to the DHCPv6 server, 1 round trip message sent to the HA (Home Agent), and another round trip message to the HA on the previous foreign sub-network to establish forwarding from the previous COA (Care-Of Address). Khalil et al. expires March 2001 [Page 4] INTERNET DRAFT October 1999 7 - The proposed solution should offer protection against IPv6 address hogging by malicious MNs. 3.0 Definition of Handoff delay Handoff delay time defines the granularity with which the mobility infrastructure can maintain network reachability to a MN as it moves across access regions. Handoff delay should be, to the furthest possible extent, independent of the traffic flowing to and from the MN. In other words, the handoff delay should be definable for an idle MN since it is ideally a network attribute, and not a host attribute. The proposed definition of "Handoff delay" is as follows: It is the time in milliseconds required from the transmission of an Agent Advertisement to the transmission of a Registration Reply from the network to the N. The architecture should ensure that all Mintermediate routability information has been updated in the interim period. 4.0 Proposed System Architecture The following is the high level view of the proposed system ----- ------ |FAAA| |------| |HAAA| |--------| ---- ----- /|DHCPv6| ------ /| DHCPv6 | |MN| | / |------| | / |--------| ---- | / | / | | | | ------ ------ -- |SMM | | HMM | ----- ------- | | ------------ ------------ | | | | | | HA1 HA2 HAn HA1 HA2 HAn Figure 1: Functional Components 4.1 Control Plane As mentioned earlier, the proposed solution makes a distinction between the Control Plane and the Data Plane. The Control Plane deals with all the interactions required for a MN to connect to its subnetwork point of attachment (such as AAA interactions, router advertisements, establishing binding and routing information etc.). The Control Plane signals are divided into two types. Khalil et al. expires March 2001 [Page 5] INTERNET DRAFT October 1999 a - Resource Management Plane allocates and manages all the network resources needed for serving the MN (such as the AAA functions, transfer of user status and context information, IP address management, distribution of session keys etc.). b - Routing Plane sets up the basic data path between a CN and a MN. It manages the binding between the MN and the network. The Mobile IPv6 messages described in [1] are used in this plane. 4.2 Data Plane The Data Plane provides the basic IP layer routing of data packets between a CN and a MN as described in [1]. 5.0 Intradomain Initial Registration This section shows the registration flow for a scenario where the MN powers up in a foreign sub-network, within a foreign domain. MN SMM DHCPv6 HMM HAn | RegReq | | | | | | | | | |-------->|DHCPv6Req| | | | |-------->| | | | |DHCPv6Rep| | | | RegRes |<--------| | | |<--------| | | | | | | | | | | BU | | | |----------------------------->| BU | | | | |------>| | | BA | |<------| |<-----------------------------| BA | | | | | | Figure 2: Intradomain Initial Registration 1 - MN constructs a local IP address (ensuring uniqueness) and sends a Registration Request to the MM located at the foreign sub-network, requesting allocation of a globally routable long-term IP address for the MN on the current foreign sub-network. The MN also provides some form of coincidental information which helps to verify the identity of the MN. The MM successfully validates the identity of the MN prior to issuing a request to the DHCPv6 server to allocate an IP address to the MN, acting as a relay agent. The MM replies to the request of the MN with the allocated IPv6 address. Khalil et al. expires March 2001 [Page 6] INTERNET DRAFT October 1999 This address is used as the COA of the MN. 2 - The MN sends a BU (Binding Update) [1] to the HMM. The HMM may allocate a serving HA for the MN and subsequently send a BU to register the MN with this HA. 3 - The allocated HA registers the MN and responds with a BA message to the HMM, which in turn triggers a BA message back to the MN. As stated in [1], the BU messages are secured through IPSec tunnels established between the MN and the HMM, and between the HMM and various HAs. 6.0 Reactive Intradomain Handoff This section shows the registration flow where the MN performs an handoff from one subnetwork to another within the home domain. MN nSMM DHCPv6 oSMM HAn HMM HAm CNn | RegReq | | | | | | | |-------->|DHCPv6Req| | | | | | | |-------->| | | | | | | |DHCPv6Res| | | | | | | RegRes |<--------| | | | | | |<------- | | | | | | | | | System Handoff Req | | | | | | |------------------->| | | | | | | | | BU | | | | | | | |------>| | | | | | System Handoff Res |<------| | | | | |<-------------------| BA | | | | | | | BU | | | | | |------------------------------------------------>| | | | | | | | | BU | | | | | | | |--->| | | | | | | | BA | | | | | BA | | |<---| | |<------------------------------------------------| BU | | | | | | | |--------->| | | | | | | BA | | | | | | | |<---------| Figure 3: Reactive Intradomain Handoff 1 - MN constructs a local IP address (ensuring uniqueness) and sends a Registration Request to the MM located at the foreign Khalil et al. expires March 2001 [Page 7] INTERNET DRAFT October 1999 sub-network, requesting allocation of a globally routable long-term IP address for the MN on the current foreign sub-network. The MN provides some form of coincidental information which helps to verify the identity of the MN. The MM successfully validates the identity of the MN prior to issueing a request to the DHCPv6 server to allocate an IP address to the MN, acting as a relay agent. The MM replies to the request of the MN with the allocated IPv6 address. This address is used as the COA of the MN. 2 - The new SMM (nSMM) issues a System Handoff Request to the old SMM (oSMM). Upon receiving the System Handoff request, the oSMM requests a HA to perform packet forwarding from the previous COA to the new COA [1]. To do so, the oFMM sends a BU to the allocated HA along the link on which the previous COA is located [1]. The oSMM sends a System Handoff Reply back to the requesting nSMM providing a user context, composed of information such as session keys or the type of services granted for the user. 3 - Upon being assigned a new COA, the MN sends a BU to the HMM which includes a list of IP addresses of all CNs the MN has been communicating with at that instant. Upon receiving the BU, the HMM first allocates a HA to serve the MN, and then forwards the BU to the newly designated HA. The new HA processes the BU as stated in [1]. The HMM then updates all the CNs entered in the CN list with the MN's new COA. 7.0 Proactive Intradomain Handoff This section shows the registration flow where the MN has the knowledge that it is moving to an new sub-network but it does not have any L2 connectivity with that new sub-network. The new and the old sub-networks that the MN is roaming about belongs to same administrative domains. The following steps are performed. Khalil et al. expires March 2001 [Page 8] INTERNET DRAFT October 1999 MN nSMM DHCPv6 oSMM HAn HMM HAm CNn | | | | | | | | | System Handoff Req | | | | | |------------------------------>| | | | | | | Handoff And | | | | | | | ContextTrans Req | | | | | | |<-------------------| | | | | | |DHCPv6Req| | | | | | | |-------->| | | | | | | |DHCPv6Res| | | | | | | |<--------| | | | | | | | Handoff And | | | | | | | Context Trans Res | | | | | | |------------------->| BU | | | | | | | |------>| | | | | | | | BA | | | | | System Handoff Res |<------| | | | |<------------------------------| | | | | | | | BU | | | | | |------------------------------------------------->| | | | | | | | | BU | | | | | | | |--->| | | | | | | | BA | | | | | BA | | |<---| | |<-------------------------------------------------| BU | | | | | | | |--------->| | | | | | | BA | | | | | | | |<---------| Figure 4: Proactive Intradomain Handoff 1 - When the MN detects that it is moving to another new sub- network that belongs to the same domain of the current sub-network, it sends a System Handoff Request to the current SMM (oSMM). 2 - The oSMM sends a Handoff And Context Transfer Request to the new SMM (nSMM). 3 - The nSMM allocates a new COA to the MN and returns back a Handoff And Context Transfer Response to the oSMM. 4 - The oSMM allocates an HA for the MN to bicast the data destined to the MN to both old and new COA. The oSMM sends a System Handoff Response to the MN confirming the completion of the handoff process. Khalil et al. expires March 2001 [Page 9] INTERNET DRAFT October 1999 5 - When the MN receives the System Handoff Response from the oSMM and establishes a L2 connectivity with the new sub-network it sends a BU to the HA to update the current binding with the new COA [1]. If the MN didnot receive a System Handoff Response from the oSMM due to a L2 disconnection with the new foreign sub-network, it then goes through the Reactive Intradomain Handoff process as mentioned in the previous section. 8.0 Interdomain Initial Registration This section shows the registration flow for a scenario where the MN powers up on a foreign domain. In this scenario the MN has to register through the FAAA. MN nSMM DHCPv6 FAAA HAAA HMM HAm | | | | | | | | RegReq | | | | | | |-------->|DHCPv6Req| | | | | | |-------->| | | | | | |DHCPv6Res| | | | | | IPOffer |<--------| | | | | |<--------| | | | | | | | AAA Reg Req | | | | | |--------------->| | | | | | | AAA Reg Req | | | | | | |------->| | | | | | | |RegReq| | | | | | |----->| | | | | | |RegRes| | | | | | |<-----| | | | | AAA Reg Res | | | | | | |<-------| | | | | AAA Reg Res | | | | | |<---------------| | | | | Reg Res | | | | | | |<--------| | | | | | | --------------------BU------------------------>| |<--------------------BA-------------------------| Figure 5: Interdomain Initial Registration The following steps are performed: 1 - MN sends a Registration Request to the SMM located at the foreign subnetwork. 2 - The SMM verifies the received message, and allocates a Khalil et al. expires March 2001 [Page 10] INTERNET DRAFT October 1999 co-located COA for the MN using DHCPv6. The SMM also constructs a AAA Registration Request and sends it to the FAAA. 3 - The FAAA forwards the request to the HAAA based on the realm portion of the user's NAI. 4 - When the HAAA receives the AAA Registration Request, it attempts to authenticate the MN. If the MN's authentication and authorization are affirmative, the request is forwarded to the HMM for further processing. 5 - If requested, the HMM allocates a home IP address to the MN. If the home network is provisioned with multiple HAs for load distribution, the HMM may also allocate a HA to serve the MN. The HMM then constructs a Registration Response and subsequently forwards it back to the MN via the HAAA and FAAA. 6 - Once the MN receives a successful registration Reply from the network, it proceeds with the regular MIPv6 registration as stated in [1]. The detailed structure of Registration Request, AAA Registration Request, Regitration Response and AAA Registration Response messages are outside the scope of this document. 9.0 Reactive Interdomain Handoff This section shows registration flow for a scenario where the MN does a handoff on a new foreign domain. In this scenario the MN has to register through the FAAA. The following steps are performed. Khalil et al. expires March 2001 [Page 11] INTERNET DRAFT October 1999 MN nSMM DHCPv6 nFAAA oFAAA oFMM HAk HAAA HMM HAm | | | | | | | | | | | RegReq | | | | | | | | | |-------->|DHCPv6Req| | | | | | | | | |-------->| | | | | | | | | |DHCPv6Res| | | | | | | | | IPOffer |<--------| | | | | | | | |<--------| | | | | | | | | | | AAA Sys Handoff Req | | | | | | | |-------------------x----x--->|BU | | | | | | | | | |-->| | | | | | | | | |BA | | | | | |AAA Sys Handoff Res| | |<--| | | | | |<------------------x----x----| | | | | | | AAA Reg Req | | | | | | | | |------------------------------------------->| | | | | | | | | | |RegReq| | | | | | | | | |----->| | | | | | | | | |RegRes| | | | | | | | | |<-----| | | | AAA Reg Res | | | | | | | | |<-------------------------------------------| | | | Reg Res | | | | | | | | | |<--------| | | | | | | | | | ----------------------------------BU----------------------------->| |<----------------------------------BA------------------------------| Figure 6: Reactive Interdomain Handoff 1 - MN sends a Registration Request to the SMM located at the foreign subnetwork. 2 - The SMM at the current subnetork sends System Handoff Request to the old SMM to allocate an HA within the old foreign sub-network. This shall establish forwarding of packets from the previous COA address to the new COA. The lifetime of this binding shall equal the execution time for the events 3-7 to occur. 3 - The SMM verifies the received message, and allocates a co-located COA for the MN using the DHCPv6 service. The SMM also constructs a AAA Registration Request and subsequently sends the request to the FAAA. 4 - The FAAA forwards the request to the HAAA based on the realm part of the user's NAI. 5 - Upon receiving the AAA Registration request, the HAAA Khalil et al. expires March 2001 [Page 12] INTERNET DRAFT October 1999 attempts to authenticate the MN. If MN passes the authentication and the autherization successfully, the request is forwarded to the HMM. 6 - If requested, the HMM allocates a home IP address to the MN. If the home network is provisioned with multiple HAs for load distribution, the HMM may also allocate a HA to serve the MN. The HMM then constructs a Registration Response and subsequently forwards it back to the MN via the HAAA and FAAA. 7 - Once the MN receives a successful Registration Response from the network, it proceeds with the regular MIPv6 registration as stated in [1]. The detailed structure of Registration Request, AAA Registration Request, Regitration Response and AAA Registration Response messages are outside the scope of this document. 10.0 Proactive Interdomain Handoff This section shows the registration flow for a MN that has the knowledge that it is moving to an new sub-network but it does not have the L2 connectivity with that new sub-network. The new and the old sub-networks that the MN is roaming about belongs to different administrative domains. The following steps are performed. Khalil et al. expires March 2001 [Page 13] INTERNET DRAFT October 1999 MN nSMM DHCPv6 nFAAA oFAAA oSMM HAk HAAA HMM HA | | | | | | | | | | | System Handoff Req | | | | | | | |-------------------------------------->| | | | | | | AAA Handoff And | | | | | | | | Context Trans Req | | | | | | | |<------------------x----x----| | | | | | |DHCPv6Req| | | | | | | | | |-------->| | | | | | | | | |DHCPv6Res| | | | | | | | | |<--------| | | | | | | | | | AAA Handoff And | | | | | | | | Context Trans res| | | | | | | |-------------------x----x--->| | | | | | | | | | |BU | | | | | | | | | |-->| | | | | | | | | |BA | | | | | | | | | |<--| | | | | System Handoff Res | | | | | | | |<--------------------------------------| | | | | | Reg Req | | | | | | | | | |-------->| | | | | | | | | | | AAA Reg Req | | | | | | | | |-------------------x----------------------->| | | | | | | | | | |RegReq| | | | | | | | | |----->| | | | | | | | | |RegRes| | | | | | | | | |<-----| | | | AAA Reg Res | | | | | | | | |<------------------x------------------------| | | | Reg Res | | | | | | | | | |<--------| | | | | | | | | | ----------------------------------BU----------------------------->| |<----------------------------------BA------------------------------| Figure 7: Proactive Interdomain Handoff 1 - When the MN detects that it is moving to a new sub- network that belongs to a different administrative domain, it sends a System Handoff request to the old SMM (oSMM). 2 - The oSMM sends a AAA Handoff And Context Transfer Request to the new SMM (nSMM) via the AAA infrastructure (marked x in the figure). 3 - The nSMM allocates new COA to the MN and returns back a AAA Handoff And Context Transfer Response to the oSMM, again via the Khalil et al. expires March 2001 [Page 14] INTERNET DRAFT October 1999 AAA infrastructure (marked x in the figure). 4 - The oSMM allocates an HA for the MN to bicast the data destined to the MN to both old and new COA. The oSMM sends a System Handoff Response to the MN confirming the completion of the handoff process. 5 - When the MN receives the System Handoff Response from the oSMM and establishes a L2 connectivity with the new sub-network it sends a Registration Request to the nSMM. 6 - The nSMM contructs a AAA Registration Request and sends it to the HAAA via the FAAA (marked x in the figure). 7 - When the HAAA receives the AAA Registration Request, it attempts to authenticate the MN. If the MN's authentication and authorization are affirmative, the request is forwarded to the HMM for further processing. 8 - The HMM updates the user state information. It then constructs a Registration Response message and subsequently forwards to the MN via the HAAA and the FAAA. 9 - Once the MN receives a successful Registration Response from the network, it proceeds with the regular MIPv6 registration as stated in [1]. The detailed structure of Registration Request, AAA Registration Request, Regitration Response and AAA Registration Response messages are outside the scope of this document. 10.0 References [1] David B. Johnson, Charles Perkins, Mobility Support in IPv6 draft-ietf-mobileip-ipv6-12.txt 11.0 Acknowledgements 13.0 Author Information: Mohamed Khalil Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 685-0564 E-mail: mkhalil@nortelnetworks.com Haseeb Akhtar Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-8850 E-mail: haseeb@nortelnetworks.com Krish Pillai Nortel Networks Inc 2201 Lakeside Blvd Richardson, TX Khalil et al. expires March 2001 [Page 15] INTERNET DRAFT October 1999 75082-4399 Phone: +1 972 685-5917 E-mail: pkrish@nortelnetworks.com Emad Qaddoura Nortel Networks Inc 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-2705 E-mail: emadq@nortelnetworks.com 14.0 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Khalil et al. expires March 2001 [Page 16]