INTERNET DRAFT Gopal Dommety, Cisco Systems Category: Standards Track Madhavi W. Subbarao, Cisco Systems Title: draft-dommety-mobileip-lma-ipv6-02.txt Kent Leung, Cisco Systems Raj Patil, Nokia July 2000 Expires December 2000 Local Mobility Agents in IPv6 draft-dommety-mobileip-lma-ipv6-02.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 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. The main advantage is that LMAs facilitate fast handoffs and provide an inter-network mechanism between IPv6 and IPv4 networks. Other advantages include aiding in Authentication in Local Domain, satisfying the need of commercial operators to have a central/controlling element for mobile users/stations in their networks through access control, and localizing signalling. LMA is an optional entity. 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. LMAs are analogous to FAs in Mobile IPv4. The main advantage is that LMAs facilitate fast handoffs and provide an inter-network mechanism between IPv6 and IPv4 networks. 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. LMA is an optional entity. 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 access point/base station to another. The introduction of LMA into the Mobile IPv6 Architecture enables fast handoffs. Moreover, the evolution of the Internet to IPv6 will be gradual. LMAs provide the capability of establishing either a IPv6 tunnel between the Home Agent (HA) and LMA, or an IPv4 tunnel to support legacy systems. 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, the introduction of LMAs into the Mobile IPv6 Architecture has several advantages: A) Fast 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 LMA provides advantages for the following reasons: 1. It provides the option of using a LMA Care of Address (CoA). 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 may 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 [14], Regionalized Tunnels [3], and Proactive Handoffs[12]. By using LMA, a MN can send a Binding Update BU to a HA or Corresponding Node (CN) through encapsulation via the LMA. Thus, the waiting time incurred by the MN in transmitting sequential bindings is eliminated. LMAs can be used to create a hierarchy either dynamically or statically. NOTE: Fast Handoff in the case where the Link Layer permits wireless access to more than one access point can be done with simultaneous bindings. By using hierarchies, LMAs can still reduce signalling back to the HA, thereby speeding up a handoff. B) Inter-network mechanism between IPv6 and IPv4: LMAs provide the option of establishing either an IPv6 tunnel or IPv4 tunnel between the HA and LMA, depending on the network. This enables the operation of Mobile IPv6 over the existing Internet, which is predominently IPv4 and will most likely evolve gradually to IPv6. C) Authentication in the Local Domain. The Mobile has to authenticate to the Foreign Domain. LMA's aiding in Authentication in Local Domain and satisfying the need of commercial operators to have a central/controlling element for mobile users/stations in their networks through access control. D) Useful in Creating Static or Dynamic Hierarchies. 2. Solution 2.1 Network Model The network model being considered is illustrated in Figure 1. +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ | IPv6 or IPv4 | +------+ | | | | | | | tunnel to HA | | | | | | MN |-------------| LMA |-------------------------|HA/CN | | | | | | |-------------------------| | | | +------+ +-------+ | | +------+ | | | | | | | +----------------+ | +-------+ | | | LMA | | | | | | | | | | | +-------+ | +----------------------------------+ Figure 1: Network Model The above figure shows a new element LMA in the IPv6 mobility architecture. There are two types of LMAs possible depending on the palcement of the LMA relative to the mobile. 1. LMA that has Link Layer connectivity to the MN (similar to FA in Mobile IPv4). 2. LMAs that do not have Link Layer connectivity to the MN at that instant of time (similar to Anchor FA[14] or GFA[3]). There are processing differences between the LMA that has Link Layer connectivity to the MN and the LMA that does not. Using the LMA framework, static or dynamic hierarchies can be created, and various handoff schemes can be realized. The scenarios described below illustrate the working of IPv6 in the presence of LMAs. The details are provided in Sections 2.2 and 3. Option 1: Scnario with out a LMA (Basic Operation of Mobile IPv6): +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ | | +------+ | | | | | | | | | | | MN |-----------------------------------------------|HA/CN | | | | | | | | | | | +------+ | | +------+ | | | | | | | +----------------+ +----------------------------------+ Fig 2: Basic Operation of Mobile IPv6 without LMA In this option, the IP packets destined to the mobiles are routed as follows: 1. If the CN has a biniding cache for the mobile, source routes the packets to the MN 2. If the CN does not have a biniding cache, the packets are routed to the HA and the HA tunnels the packets to MN. Option 2: Scenario with LMA that has link layer connectivity with the MN (henceforth this type of LMA is referred to as LC-LMA). +----------------------------------+ +----------------+ | 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 (BU) (see Section 2.2.2). (1) HA tunnels packets for MN to LMA and LMA detunnels and forwards packets to MN, or (2) CN source routes the packets to MN via LMA. LMA can also optionally advertise an IPv4 option if it can support an IPv4 tunnel. If IPv4 option is present in BU, HA determines whether to establish IPv6 or IPv4 tunnel to the LC-LMA (depending on HA capabilities). Option 3: Scenario with a LC-LMA and an LMA with out direct link layer connectivity to the mobile. +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ +-----+ | | +------+ | | | | | | | | | | | | | | | MN |****|LC-LMA |---|LMA 1| -----------------------|HA/CN | | | | | | |---| | -----------------------| | | | +------+ +-------+ +-----+ | | +------+ | | | | | | | +----------------+ +----------------------------------+ Fig 4: Operation with Link Connected LMA and another LMA (hierarchy) In this scenario, a hierarchy is either a statically or dynamically established using Local Mobility Agents (Section 4). 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. (1) When packets for MN arrive at LMA 1 (via either tunneling from HA or source routed from CN), it verifies that the MN is visiting on its network, and then tunnels the packets to LC-LMA CoA. (2) LC-LMA detunnels and forwards packets to MN. Depending of the capabilities of the various Agents, whenever tunelling is performed, IPv6 or IPv4 tunnel is established between entities. Option 4: Scenario with LMA that does not have link layer connectivity with the MN. +----------------------------------+ +----------------+ | Visited | | | | Network | | | | | | | | +------+ +-------+ | | +------+ | | | | | | | | | | | | | MN |-------------| LMA |-------------------------|HA/CN | | | | |-------------| |-------------------------| | | | +------+ +-------+ | | +------+ | | | | | | | +----------------+ +----------------------------------+ Fig 4: Operation with LMA that is not Link Connected In this sceanrio, the Mobile is assumed to know the LMA. Possible methods by which the mobile learns of the LMA are: A. 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). B. An LMA discovery procedure is followed C. The Mobile has knowledge of the LMA. For example, when performing anchoring the mobile knows the previous LC-LMA. Once the appropriate tunnels/binding caches are established. The routing of packets is as follows: (1) HA tunnels packets for MN to LMA and LMA Tunnels packets to Co-located CoA of the MN, or (2) CN source routes the packets to MN via LMA, and LMA Tunnels packets to Co-located CoA of the MN. In both cases, LMA tunnels packets to MN. 2.2 Enhancements In order to facilitate the above described scenarios, the following enhancements are proposed: 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 the procedure described in [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. 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 |C|L| 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. C Bit if not set indicates that the first LMA CoA is that of LC-LMA, i.e., the mobile can use this CoA with out acquiring its own CoA. L Bit indicating whether the LMA can support a IPv4 tunnel. Bit when set indicates the support to terminate a IPv4 tunnel. TBW (To be Worked on) Multiple LMAs on the link. 2.2.2 Binding Update and Binding Update Acknowledgement Usage In order to create a hierarchy, encapsulated binding updates are sent as shown in the figure below. A Binding Update has the format specified in [5] with the addition of a new bit following the 'Duplicate Address Detection' (D) bit: L Bit indicating that the MN is requesting a IPv4 tunnel. In order for the MN to set this bit, an LMA advertisement with the L bit set must have been heard. A new header extension (TBD) will be used in the Binding Update Acknowledgement to indicate the preference of the HA. Note: That most of the time the MN is aware of the HA's capabilities and will request the appropriate tunnel type. +----------------------------------//-----+ | 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 [3][14]. (See Section 4.) 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, i.e., BU between MN and HA/CN, 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. If a MN is communicating with multiple hosts, only the first Binding Update needs to be transmitted in this manner. This establishes the visitor binding at the LMA. The remaining Binding Updates can be transmitted directly to the CNs with the LMA CoA as the CoA in the Binding Update. 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 also send a Binding Update directly with its co-located CoA.) The MN learns of the LMA CoA and IPv4 tunnel options provided by the LMA 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. If the LMA advertises an IPv4 option, the MN sets the 'L' bit in both Binding Updates if it desires an IPv4 tunnel. For hierarchical network configurations (e.g., Option 3 in Section 2.1), further encapsulation is done as described in Section 4. The 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 Signaling Flow: MN Advertisement LMA HA/CN |<--------------------- | | | Binding Update | | |---------------------->| Binding Update | | |---------------------->| | | | | | | | | Binding Ack | | Binding Ack |<----------------------| |<----------------------| | 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. As described in Section 2.2.2, the Binding Update to the HA/CN is encapsulated within a Binding Update sent to the LMA. When the LMA receives a Binding Update from a MN, it checks that the proper authentication is present. If the Binding 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. 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 CoA and Source Address = HA/CN address. When the MN receives the Binding Update Acknowledgement for the encapsulated Binding Update, i.e., between MN and HA/CN, the MN can assume that the Binding Update to 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.) 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 IPSec is preserved before delivering the packet to the MN in this case ). 3.3 Home Agent Th Home Agent is much like a regular IPv6 HA, except that the HA may choose between establishing an IPv6 or IPv4 tunnel depending on the request from the MN and the HA capabilities. If the 'L' bit is set in the received Binding Update and the HA can support an IPv4 tunnel, the HA may set up an IPv4 tunnel between the HA and CoA. 3.4 Correspondent Node The Correspondent node behaves much like a regular IPv6 node. If the CN receives a Binding Update with the 'L' bit set and does not understand this option, the CN simply ignores the bit and processes the Binding Update as usual, i.e., assumes the BU is a regular IPv6 BU and the bit is not set. 4. Creating a Hierarchy using LMAs With LMAs, either a static hierarchy or dynamic hierarchy (Section 2.1, Option 3, Fig. 4) can be formed using encapsulated Binding Updates. 4.1 Static Hierarchy In a static hierarchy, the LMA 1 announces its capabilities in its LMA advertisements. The LC-LMA advertises both LC-LMA CoA and LMA 1 CoA. Thus, the MN learns of the static hierarchy structure via the LC-LMA advertisements. When the MN first enters a foreign domain, the MN sends encapsulated Binding Updates as follows: (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 As the MN moves from an LC-LMA to a 'new' LC-LMA still within the domain of LMA 1, it need only register back with the 'new' LC-LMA. Thus, the signaling all the way back to the HA/CN is reduced (the implicit and valid assumption is that the 'previous' LC-LMA and 'new' LC-LMA are in closer proximity). 4.2 Dynamic Hierarchy A dynamic hierarchy can be formed using various approaches. Th main idea is that the MN remembers the LMA CoA and IPv4 options of the last LMA to which it was attached. When the MN determines that it has moved to the domain of another LMA, the MN registers back with the 'previous' LMA, creating a dynamic set of tunnels. The tunnel between the HA and 'previous' LMA is still maintained, and a new tunnel is established between the 'new' LMA and 'previous' LMA. The LMA sends LMA advertisements as described in Section 2.2.1, with the inclusion of any necessary extensions for building the dynamic hierarchy. Similarly, the MN sends encapsulated Binding Updates in the same manner as described for Static Hierarchy (Section 4.1), with the inclusion of any necessary extensions. The details of the scheme will depend on the specific dynamic hierarchy scheme being employed. As an example using Local Anchoring [14], the LMAs will include the necessary extensions in the LMA advertisements to announce the anchoring capability. The MN maintains an anchor LMA within a zoned region (domain), and as it moves within the domain, it registers back with the anchor LMA. It includes the necessary anchor extensions in its Binding Updates to the 'new' LMA and anchor LMA, i.e., BU (ii) and (iii) from Section 4.1. As the MN moves from one zoned region to another, the existing dynamic hierarchy can be dismantled and a new dynamic hierarchy can be established. 5. How Existing Handoff Proposals for IPv4 apply to IPv6 To Be Discussed Later 6. How Local Authentication can be performed in IPv6 To Be Discussed Later 7. 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 can use the LMA to create either a static or dynamic hierarchy. Hence, the latency involved with the MN acquiring a co-located CoA is avoided. Moreover, by using hiearchies, the signaling all the way back to the HA each time 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] J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off, draft-calhoun-mobileip-proactive-fa-01.txt, June 2002 [13] N. Asokhan et. al, AAA for IPv6 Network Access, draft-perkins-aaav6-00.txt, March 2000. [14] 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 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 drawback 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.