INTERNET DRAFT Gopal Dommety, Cisco Systems Category: Standards Track Madhavi W. Subbarao, Cisco Systems Kent Leung, Cisco Systems Raj Patil, Nokia Title: draft-dommety-mobileip-lma-ipv6-01.txt July 2000 Expires December 2000 Local Mobility Agents in IPv6 draft-dommety-mobileip-lma-ipv6-01.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 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 atany 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 is better integrated into IPv6, thereby obviating the need for Foreign Agents (FA) in IPv6 [5]. In IPv6 most, if not all, ofthe functions of the Mobile IPv4 FA [1] are assumed by other parts of the Mobile IPv6 architecture. Specifically, all routers send Router Advertisements and the Mobile Node (MN) does its own detunneling and Routing Header processing. This draft proposes the concept of Local Mobility Agents (LMA) in Mobile IPv6 Architecture. LMA is an optional entity. The main advantage is that it enables the feasibility of fast handoffs. Other advantages include Authentication in Local Domain and satisfying the need of commercial operators to have a central/controlling element for mobile users/stations in their networks. 1. Introduction Mobile IPv6 is better integrated into IPv6, thereby obviating the need for FA in IPv6 [5]. In IPv6 most, if not all, of the functions of the Mobile IPv4 FA [1] are assumed by other parts of the Mobile IPv6 architecture. Specifically, all routers send Router Advertisements and the MN does its own detunneling and Routing Header processing. This draft proposes the concept of Local Mobility Agents (LMA) in Mobile IPv6 Architecture. LMA is an optional entity. The main advantage is that it enables the feasibility of fast handoffs. Other advantages include Authentication in Local Domain and satisfying the need of commercial operators to have a central/controlling element for mobile users/stations in their networks. In wide area deployment, the handoff latencies in current Mobile IP could be high. In a mobile environment, it is important to limit the delay experienced in communication as a MN moves from one base station/access point to another. The introduction of LMA into the Mobile IPv6 Architecture enables fast handoffs. 1.1 Problem Description Mobility agents similar to FA in Mobile IPv4 do not exist in Mobile IPv6. Although there is no need for such agents for the operation of Mobile IP in IPv6, in certain scenarios they help solve the problem of fast handoffs and provide an agent for Authentication in Local Domain. Other advantages will be discussed later. A) Handoff: As a MN moves from one subnet to another, the break in communication perceived by the user must be low. This is especially important for real-time data services and voice applications. Having a Local Mobility Agent provides an advantage for the following reasons: 1. It provides the option of using a LMA CoA (LMA Care of Address). This eliminates at least one round trip time if using DHCPv6 [6] or Autoconfiguration with Duplicate Address Detection (DAD) [11] to obtain the COA. (It might be possible to perform Stateless Autoconfiguration without DAD.) 2. It introduces the possibility of managing handoffs locally by performing quick rerouting. Examples of such mechanisms are Local Anchoring [15], Regionalized Tunnels [12], and Proactive Handoffs[13]. By using LMA, a MN can send a Binding Update to the Home Agent (HA)/Corresponding Node (CN) through encapsulation via the LMA. Thus, the waiting time incurred by the MN in transmitting sequential bindings is eliminated. LMA can be used to create a hierarchy either dynamically or statically. NOTE: Fast Handoff in the case where L2 permits wireless access to more than one access point can be done with simultaneous bindings, and thus, may not need LMAs. B) Authentication in the Local Domain. The Mobile has to authenticate to the Foreign Domain. C) Other potential advantages: To Be Discussed Later 2. Solution 2.1 Network Model The network model being considered is illustrated in Figure 1. +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | | | | | | | MN |-------------| LMA |-------------------------|HA/CN | | | | | | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | +----------------+ | +-------+ | | | LMA | | | | | | | | | | | +-------+ | +----------------------------------+ Figure 1: Network Model There are two types of LMAs possible: LMA that has link Layer connectivity to the MN (similar to FA) and LMAs that do not have link layer connectivity to the MN at that instant of time (similar to Anchor FA[15] or GFA[12]). There are processing differences between the LMA that has link layer connectivity to the MN and the LMA that does not. Using the basic LMA framework, various handoff schemes can be realized. The figures below illustrate the LMA placement: Option 1: +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ | | +------+ | | | | | | | | | | | MN |-----------------------------------------------|HA/CN | | | | | | | | | | | +------+ | | +------+ | | | | | | | +----------------+ +----------------------------------+ Fig 2: Basic Operation (HA tunnels the packets to MN or CN source routes the packets to MN). Option 2: +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | | | | | | | MN |*************| LMA |-------------------------|HA/CN | | | | | | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | +----------------+ +----------------------------------+ Fig 3: Operation with Link Connected LMA (****** denotes Link Layer connectivity). In this configuration, LMA advertises the LMA CoA, which is used by the MN in its encapsulated Binding Updates (see Section 2.2.2). (1) HA tunnels packets for MN to LMA and LMA forwards packets to MN, or (2) CN source routes the packets to MN via LMA. Option 3: +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ +-----+ | | +------+ | | | | | | | | | | | | | | | MN |*****|LC-LMA |--|LMA 1| -----------------------|HA/CN | | | | | | | | | | | | | | | +------+ +-------+ +-----+ | | +------+ | | | | | | | +----------------+ +----------------------------------+ Fig 4: Operation with Link Connected LMA and another LMA The LC-LMA advertises both LC-LMA CoA and LMA 1 CoA. The MN sends encapsulated Binding Updates as follows (see Section 2.2.2): (i) Inner Most Binding Update: LMA 1 CoA to HA/CN. (ii) Outer-1 Binding Update: LC-LMA CoA to LMA 1 (iii) Outer Most Binding Update: LC-LMA CoA to LC-LMA LC-LMA maintains visitor mapping of MN home address with LC-LMA CoA. LMA 1 maintains visitor mapping of MN home address with LMA 1 and LC-LMA CoA. When a packet for MN comes to LMA 1 (either tunneled from HA or sourced by CN), it verifies that the MN is visiting on it's network, and then tunnels the packets to LC-LMA CoA. Option 4: +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | | | | | | | MN |-------------| LMA |-------------------------|HA/CN | | | | | | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | +----------------+ +----------------------------------+ Fig 4: Operation with LMA that is not Link Connected All routers on the link advertise the LMA CoA, which they learn from LMA advertisements. The MN uses the LMA CoA in its encapsulated Binding Updates (see Section 2.2.2). (1) HA tunnels packets for MN to LMA and LMA forwards packets to MN, or (2) CN source routes the packets to MN via LMA In both cases, LMA tunnels packets to MN. 2.2 Enhancements The neighbor discovery phase is proposed to be enhanced to send the LMA CoA in the Router Advertisement message. An enhancement is proposed where a MN can either send a Binding Update to the HA/CN in a one-phase or two-phase approach. In the one-phase approach, bindings at the LMA and HA/CN can be updated in a single transmission by the MN, where the MN sends an encaspulated Binding Update to the LMA, which is then detunneled and relayed to the HA/CN. In the two-phase approach, a Binding Update is first sent to the LMA and once the Binding Update is acknowledged by the LMA, the MN sends a Binding Update to HA/CN. Two-Phase Binding Update is similar to MAP [4] and may incur higher latency than the one-phase approach. 2.2.1 Neighbour Discovery Extension The LMAs send Router Advertisements with the following new option, which is borrowed from Mobility Agent Advertisement Extensions of Mobile IPv4 [1]. 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Lifetime | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + LMA CoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | More LMA Care of Addresses | + + Fields: Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). Sequence Number The count of Agent Advertisement messages sent since the agent was initialized (Similar to Sequence Number in Mobile IPv4). Binding Lifetime Longest lifetime (in seconds) that the LMA is willing to accept in any Binding Update. LMA CoA is the address of the LMA that the MN can use as the CoA in its Binding Updates. For LMA that do not have link layer connectivity, additional addresses need to be advertised. TBW (To be Worked on) If there are multiple LMAs on the Link. 2.2.2 Binding Update and Binding Update Acknowledgement Usage Since IP Authentication Headers (AH) are used for authentication in Mobile IPv6, the Binding Update between the MN and HA/CN is encapsulated within a Binding Update sent to the LMA. The inner Binding Update contains all of the necessary extensions [5], including IPv6 headers. It is necessary to encapsulate the Binding Update between the MN and HA/CN so that proper authentication will pass at the HA/CN. Note that the LMA cannot simply create a Binding Update on behalf of the MN since authentication at the HA/CN would fail. (Note: If a MN is communicating with multiple hosts, only one Binding Update needs to be transmitted in this manner. The rest of the Binding Updates can go to the CNs with the LMA CoA as the CoA in the Binding Update, i.e., if the MN has to send multiple BUs only one of the BU needs to go through this procedure). +----------------------------------//-----+ | Original | | | | Original Packet Payload | | Header | | | w BU DH | | +----------------------------------//-----+ | v < Original Packet > +---------+ - - - - - +-------------------------//--------------+ | IPv6 | IPv6 | | | | Extension | Original Packet with Binding Update | | Header | Headers | | +---------+ - - - - - +-------------------------//--------------+ < Binding Update with original Binding Update Encapsulated > BU: Binding Update DH: Destination Header Using this tunneling mechanisim a static/dynamic hierarchy can be created as required [12][15]. 3 Processing Considerations 3.1 Mobile Node The MN behaves as a regular Mobile IPv6 node using a CoA. The variation is that the MN uses a LMA CoA instead of a co-located CoA and sends its Binding Updates to the HA/CN via a LMA. Note that if the MN should desire, it may use a co-located CoA and register via the LMA. In this case, the LMA simply forwards packets destined for the MN to the co-located CoA. (Although using a LMA CoA reduces latency, this draft allows for using co-located CoA and sending Binding Update via LMA. Mobile can always send a Binding Update directly with its co-located CoA). The MN learns of the LMA CoA either by listening to Router Advertisements or performing Router Solicitation as specified in [5]. The MN sends a Binding Update to the HA/CN via the LMA as follows. The MN creates a Binding Update to the HA/CN with CoA set to the LMA CoA, IPv6 Destination Address set to HA/CN address, and IPv6 Source Address set to MN home address. The MN will include the necessary extensions so that the HA/CN can properly authenticate the Binding Update when it is relayed by the LMA. The MN encapsulates this Binding Update within another Binding Update destined to the LMA. For hierarchical network configurations (e.g., Option 3 in Section 2.1), further encapsulation is done. MN receives packets via the LMA with an IPv6 Routing Header set to LMA CoA and IPv6 Destination Address set to MN address. (If a CN does not have a binding cache entry, the packet is routed via the MN's home network and the the IPv6 Destination Address will be the MN's home address.) 3.2 Local Mobility Agent 3.2.1 LMA with Link Layer connectivity As described in Section 2.2.2, the Binding Update to the HA/CN is encapsulated within a Binding Update sent to the LMA. Flow with LMA with Link Layer Connectivity: MN Advertisement LMA HA/CN |<--------------------- | | | Binding Update | | |---------------------->| Binding Update | | |---------------------->| | | | | | | | | Binding Ack | | Binding Ack |<----------------------| |<----------------------| | The Binding Update Acknowledgements are encapsulated: inner Binding Acknowledgement has Destination Address = MN home address and Source Address = HA/CN address. Outer Binding Acknowledgement has Destination Address = LMA address and Source Address = HA/CN address. When the Binding Update Acknowledgement for the encapsulated Binding Update, i.e., between MN and HA/CN, is received, the MN can assume that the Binding Update for the LMA was also received. (Since the encapsulated Binding Update could not have been received by the HA/CN unless the outer Binding Update was received by the LMA.) The LMA will send periodic Router Advertisements as defined in Section 2.2.1 to facilitate neighbor discovery. If the LMA receives a Router Solication message, it will respond by sending a LMA Router Advertisement. When the LMA receives a Binding Update from a MN, it checks that the proper authentication is present. If the Update is valid, the LMA strips off the tunnel headers and forwards the internal Binding Update packet to the HA/CN. It enters the Binding Update Request in its Pending Binding Update table. When a LMA receives a packet for the MN, it relays the packet after adjusting the Routing Header extension and sends it to the MN much like a FA in Mobile IPv4 Architecture. 3.2.2 LMA with out link Layer connectivity When LMA receives packets, it tunnels these packets to the registered CoA in the Binding Update (the registered CoA could be LC-LMA CoA or co-located CoA). It additionally authenticates the Binding Updates and sends tunneled Binding Updates/Acknowledgements. This operation is similar to the operation of a HA in IPv6 (The other alternative is to change the Routing Header and the Destination Header. One needs to take caution that the order of headers for IP Sec is preserved before delivering the packet to the MN in this case ). 3.3 Home Agent Th Home Agent is a regular IPv6 Home Agent. 3.4 Correspondent Node The Correspondent node behaves like a regular IPv6 node. 4 How Existing Handoff Proposals for IPv4 apply to IPv6 To Be Discussed Later 5. How Local Authentication can be performed in IPv6 To Be Discussed Later 6. Synergies and differences between MAP [4] and this draft The approach described herein does not require the MN to obtain a co-located CoA (using either DHCP or Autoconfiguration). The MN registers back with the HA using the LMA CoA, and anchors with the LMA as it moves in foreign domains. Hence, the latency involved with the MN acquiring a co-located CoA is avoided. Since the Binding Update is forwarded to the HA/CN directly by the LMA, the delay in the MN waiting for a Binding Acknowledgement from the LMA and then registering back with the HA/CN using the LMA CoA is also avoided. The reduction in latency will aid in the efficiency of fast handoffs. 6. Security Considerations Security associations as specified in [5] are used to protect all the binding update and reply mesages. 7. IANA Considerations 8. Acknowledgments The authors would like to thank Steve Deering for his suggestions and helpful discussion. 9. References [1] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [2] S. Deering. ICMP Router Discovery Messages. Request for Comments (Proposed Standard) 1256, Internet Engineering Task Force, September 1991. [3] E. Gustafsson, et. al. Mobile IP Regional Tunnel Management. draft-ietf-mobileip-reg-tunnel-01.txt, August 1999. [4] H. Soliman and K. El Malki, Hierarchical Mobile IPv6 and Fast Handoffs. draft-soliman-mobileip-hmipv6-00.txt, June 2000. [5] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-10.txt, February 2000. [6] Jim Bound and Charles Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6), February 1999. Work in progress. [7] Alex Conta and Stephen Deering. Generic packet tunneling in IPv6 specification. RFC 2473, December 1998. [8] Alex Conta and Stephen Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6) specification. RFC 2463, December 1998. [9] Stephen E. Deering and Robert M. Hinden. Internet Protocol version 6 (IPv6) specification. RFC 2460, December 1998. [10] Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December 1998. [11] Susan Thomson and Thomas Narten. IPv6 stateless address autoconfiguration. RFC 2462, December 1998. [12] Eva Gustafsson, et. al. Mobile IP Regional Tunnel Management. draft-ietf-mobileip-reg-tunnel-01.txt, August 1999. [13] J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off, draft-calhoun-mobileip-proactive-fa-01.txt, June 2002 [14] N. Asokhan et. al, AAA for IPv6 Network Access, draft-perkins-aaav6-00.txt, March 2000. [15] G. Dommety and T. Ye, "Local and Indirect Registration for Anchoring Handoffs", draft-dommety-mobileip-anchor-handoff-01.txt(work in progress), July 2000. Dommety [Page 4] Internet Draft Authors Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Madhavi W. Subbarao Cisco Systems, Inc. 7025 Kit Creek Road RTP, NC 27709 e-mail: msubbara@cisco.com Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: kleung@cisco.com Raj Patil Nokia Notes: 1. Do we need other options of IPv4 adv 2. How does IPv6 MN IP address 3. Do we use constant Src address for IP 4. Route Processing 5. IPv4 tunnels 6. How does the IPv6 Binding update sent? Appendix: Three options of sending Binding Updates via the LMA. 1. Sequential Bindings (Similar to MAP[4]) MN Advertisement LMA HA/CN |<--------------------- | | | Binding Update | | |---------------------->| | | Binding Ack | | |<----------------------| Binding Update | |---------------------------------------------->| | Binding Ack | |<----------------------------------------------| The problem in this case is the latency incurred by sequential transmissions. 2. LMA Relays Bindings to HA/CN MN Advertisement LMA HA/CN |<--------------------- | | | Binding Update | | |---------------------->| Binding Update | | |---------------------->| | | | | | | | | Binding Ack | | Binding Ack |<----------------------| |<----------------------| | In this case MN sends a Binding Update to LMA, and LMA sends a Binding Update to HA/CN on behalf of MN. If the Binding Update is required to be acknowledged, LMA waits for the Binding Update Ack from the HA/CN and once it receives the Ack, it sends an Ack for the original Binding Update from the MN. The problem in this case, however, is that the HA/CN will not be able to authenticate the Binding Update sent by the LMA on behalf of the MN. 3. Encapsulated Bindings MN Advertisement LMA HA/CN |<--------------------- | | | Binding Update | | |---------------------->| Binding Update | | |---------------------->| | | | | | | | | Binding Ack | | Binding Ack |<----------------------| |<----------------------| | In this case MN sends a Binding Update to LMA with the Binding Update for HA/CN encapsulated. Once the LMA authenticates the MN, the LMA relays the inner Binding Update to HA/CN. The HA/CN sends a Binding Ack back to the MN encapsulated within a Binding Ack to the LMA.