INTERNET DRAFT Gopal Dommety, Cisco Category: Standards Track Title: draft-dommety-mobileip-lma-ipv6-00.txt Madhavi Subbarao, Cisco Raj Patil, Nokia July 2000 Expires December 2000 Local Mobility Agents in IPv6 draft-dommety-mobileip-lma-ipv6-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 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 is better integrated into IPv6, thereby obviating the need for Foreign Agents (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. The other advantage is Authentication in Local Domain. The other reason is that in any commercial operators network you will need a controlling element for mobile users/stations. 1. Introduction Mobile IPv6 is better integrated into IPv6, thereby obviating the need for Foreign Agents (FA) in IPv6. In IPv6 most if not all of the functions of the Mobile-IPv4 FA 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 introduces the concept of Local Mobility Agents (LMA)in Mobile IPv6 Architecture. LMA is an optional entity. The main advantage of having LMA is that it enables the feasibility of fast handoffs (Similar to the proposal [4]. The other advantage is Authentication in Local Domain (Similar to the proposal []). In wide area deployment, the handoff latencies of the current mobileip could be high. In a mobile environment, it is very important to limit the delay experienced in communication when a mobile moves from base station\access point to another. Introduction of LMA in Mobile IPv6 Architecture enables fast handoffs. 1.1 Problem Description Mobility agents similar to Foreign Agents in Mobile IPv4 do not exist in Mobile IPv6. Although there is no need for such agents for the operation of mobile IP, in certain scenarios they help solve the problem of Fast Handoffs and provide a agent for Authentication in local Domain. Other advantages will be discussed later. A) Handoff: When a Mobile moves from one subnet to another the break in communication perceived by the user has to be low. This is especially important for voice applications. Having a Local Mobility Agent provides an advantage due to the following reasons: 1. It provides an option of using LMACoA (LMA CareofAddress). This eliminates one round trip if using DHCPv6 [6] or Autoconfiguration [11] (more than one round trip?) to obtain the COA. 2. It introduces the possibility of performing handoffs locally by performing quick rerouting. Examples of such mechanisms are Local Anchoring [], Regionalized Tunnels [], and Proactive Handoffs[]. NOTE: Fast Handoff in the case where L2 permits wireless access to more than one access point can be done with simultaneous bindings. So, might not need LMAs for this case. B) Authentication in the local Doamin. The Mobile has to authenticate to the Foreign Domain. C) Other potential advantages: 2. Solution 2.1 Network Model The network model being considered is illustrated in Fig 1. +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | | | | | | | MN |-------------| LMA |-------------------------|HA/CN | | | | | | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | +----------------+ | +-------+ | | | LMA | | | | | | | | | | | +-------+ | +----------------------------------+ Fig 1: Network Model An optional entity referred to as LMA has a link layer connectivity to the Mobile. It is also possible to have an additional LMA without link layer connectivity to the mobile (Similar to Anchor FA [] or GFA [] in IPv4 or MAP in IPv6). There are procesing differences between the LMA if it has link layer connectivity to the Mobile and the LMA that does not. 2.2 Enhancements The neighbor discovey is proposed to be enhanced to send the LMACoA (Care Of Address) in the router Advertisement message. Binding Update is proposed to be enhanced to be able to send a Binding Update to the LMA which is then relayed to the destination. This is a one-phase approach by which bindings at the LMA and the HA/CN can be updated in one phase. It is also possible to have a Two-Phase Binding Update. In this approach a Binding Update is first sent to the LMA (Local Mobility Agent) and Once the Binding Update is accepted by the LMA the Mobile can send Biding updates to HA (and possibly CNs). Two-Phase Binding update may incur higher latency than the one-phase. 2.2.1 Neighbour Discovery Extension The LMAs send router advertisements with this following new option. This is borrowed from Agent Advertisement of Mobile IPv4. 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). LMA CoA is the address of the LMA that this mobile can use as CoA in its Binding update. Currently all the LMA CoA have link layer connectivty to the Mobile. TBW (To be Worked on) If there are multiple LMAs on the Link. 2.2.2 Binding Update and Binding Update Acknowledge Usage In this proposal the Binding Updates are encapsulated Since AH and ESP are used for Authentication in Mobile IP v6, the actual binding update between the Mobile Node and the HA/CN will be encapsulated in binding update sent to the LMA. (Note: only one binding update needs to go through this way,rest of then can go to the CNs with the LMA CoA as the CoA in the Binding Updte). +----------------------------------//-----+ | Original | | | | Original Packet Payload | | Header | w BU DH | | +----------------------------------//-----+ < Binding Update between MN and HA/CN > | v < Original Packet > +---------+ - - - - - +-------------------------//--------------+ | IPv6 | IPv6 | | | | Extension | Original Packet with Binding Update | | Header | Headers | | +---------+ - - - - - +-------------------------//--------------+ < Binding Update with the original binding update Tunneled > BU: Binding Update DH: Destination Header NOTE: The Original Binding Update that is encapsulated is a entire Binding Update with all the necessary extensions []. Similar to the Binding Update Binding Update Acknowledge can also be Tunneled. Using this tunnenling mechanisim a static/dynamic hierarchy can be created as required[][]. 3 Processing Considerations 3.1 Mobile Node 3.2 Local Mobility Agent 3.2.1 LMA with Link Layer connectivity 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. It enters the binding update request in its pending binding update table. LMA relays the packet with the destination header extension to the mobile node. If the LMA receives a tunneled packet is decapsulates and sends it to the mobile much like a FA in Mobile IPv4 Architecture. 3.2.2 LMA with out link Layer connectivity Tunnels the packet to the registered CoA in the Binding Update. It additionally authenticates the Binding updates and sends tunneled Binding Updates/Acknowledgements. 3.3 Home Agent and Correspondent 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 [] 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 [] as used to protect all the binding update and reply mesages. 7. IANA Considerations 8. 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. 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