NETLMM BOF S. Gundavelli Internet-Draft K. Leung Expires: May 12, 2006 Cisco Systems November 8, 2005 Localized Mobility Management using Proxy Mobile IPv6 draft-gundavelli-netlmm-mip6-proxy-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on May 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Localized Mobility Management (LMM) requires mobility support for a mobile station within a restricted and topologically localized portion of the network. Mobile IPv6 is a standardized mobility protocol for IPv6 that can be extended to address the local mobility management requirements. This document describes a solution based on Proxy Mobile IPv6 scheme by introducing new functional entities and extensions to the protocol and by restricting the mobility signaling to only certain entities in the network. Gundavelli & Leung Expires May 12, 2006 [Page 1] Internet-Draft LMM using MIPv6 November 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Overview of Proxy Mobile IPv6 . . . . . . . . . . . . . . . . 5 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. LMM Domain Architecture . . . . . . . . . . . . . . . . . 7 3.3. New Functional Elements . . . . . . . . . . . . . . . . . 9 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . . 10 4.2. Proxy Binding Acknowledgement . . . . . . . . . . . . . . 11 4.3. Binding Cache Confirmation Option . . . . . . . . . . . . 11 5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Binding Acknowledgement Status Values . . . . . . . . . . 12 6. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Network Access Authentication . . . . . . . . . . . . . . 14 6.2. Router and Neighbor Discovery with Local Network Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Address Configuration . . . . . . . . . . . . . . . . . . 16 6.4. Resource Cleanup . . . . . . . . . . . . . . . . . . . . . 20 7. Mobility Proxy Agent Operation . . . . . . . . . . . . . . . . 21 7.1. Conceptual Data Structures at the MPA . . . . . . . . . . 21 7.2. Mobility Signaling for Mobile Station . . . . . . . . . . 22 7.3. Establishment of Bi-Directional Tunnel . . . . . . . . . . 23 8. Mobile Station Operation . . . . . . . . . . . . . . . . . . . 23 8.1. Booting up in a LMM Domain . . . . . . . . . . . . . . . . 24 8.2. Moving to a New MPA . . . . . . . . . . . . . . . . . . . 24 8.3. Packet forwarding . . . . . . . . . . . . . . . . . . . . 25 8.4. Moving to a New LMM Domain . . . . . . . . . . . . . . . . 26 9. LMAP Operation . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Processing Proxy Binding Update . . . . . . . . . . . . . 26 9.2. Packet interceptions . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 13. Normative References . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Gundavelli & Leung Expires May 12, 2006 [Page 2] Internet-Draft LMM using MIPv6 November 2005 1. Introduction The need for Localized Mobility Management is justified in [5] and the issues are identified in [4]. In brief, a solution is needed to provide mobility for a Mobile Station that minimizes handover latency, avoids signaling overhead on the air-link, and hides handover event within LMM domain from global mobility. These objectives should be achieved without host support in the mobility signaling or complex security interactions between the host and network. The solution described in this document accomplishes the feats by introducing a proxy Mobility Agent, called Mobile Proxy Agent (MPA), that signals to a Local Mobility Agent Point (a.k.a. Home Agent) to set up a tunnel between them for traffic to and from the Mobile Station. An crude analogy is a Mobile Router - which happens to be the fixed Access Router with MPA function - that registers a Host- Specific-Prefix (i.e. ::/128) to its Home Agent whenever the Mobile Router detects a Local Fixed Node with a different prefix than the attached Mobile Network Prefix [14]. In this case, the host has no idea that it is moving. In actuality, the MPA is spoofing the host (to believe that it remains on the same network) and updating the host's location to the Local Mobility Agent Point, a node that is typically dynamically assigned by the network to be near the host. 2. Conventions used in this document The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. The following new terminology and abbreviations are introduced in this document and all other general mobility related terms as defined in Mobile IPv6 specification [2]. Mobility Station (MS) Any IPv6 host that has the ability to physically roam across different networks. The Mobile Station is not required to have the Mobile IPv6 protocol stack. Local Mobility Anchor Point (LMAP) Gundavelli & Leung Expires May 12, 2006 [Page 3] Internet-Draft LMM using MIPv6 November 2005 The Mobile IPv6 entity which functions as a local Home Agent to anchor data traffic for a Mobile Station. Mobility Proxy Agent (MPA) The Mobile IPv6 entity that offers proxy mobility service for a Mobile Station by performing registration function on the host's behalf. The MPA function is provided by the Access Router, which the Mobile Station is attached to in the access network. Base Station (BS) A Layer 2 bridging device connected to the MPA offering wireless connectivity to the Mobile Station. Local Network Prefix (LNP) The network prefix that is assigned to a mobile station in a LMM domain. This prefix is attached to the interface of the Mobile Station's LMA. Note that the LNP is analogous to the Home Link Prefix in MIPv6. Local Address (LoA) The address that is owned by the Mobile Station in a LMM domain. The address belongs to the prefix owned by the Mobile Station's LMAP. The Mobile Station will be able to use this address for roaming within the LMM domain. Note that the LoA is analogous to the Home Address in MIPv6. Local Home Network (LHN) The Mobile Station in a LMM domain is logically anchored to a LMAP and the Local Address of the Mobile Station belongs to a prefix owned by the LMA. The prefix is attached to the interface of the LMAP and that is the Local Home Network for the Mobile Station. Note that the LHN is analogous to the Home Link in MIPv6. Proxy Binding Update (PBU) A Binding Update message from the MPA instructing the Mobile Station's LMAP to register the current location information. Proxy Binding Acknowledgment(PBA) Gundavelli & Leung Expires May 12, 2006 [Page 4] Internet-Draft LMM using MIPv6 November 2005 A Binding Acknowledgment message from the LMAP to the MPA in response to the PBU message. 3. Overview of Proxy Mobile IPv6 3.1. Design Goals Proxy Mobile IPv6 is designed to satisfy the requirements of LMM [5]. In addition, the solution leverages well-studied specification and highly available implementations. Only incremental enhancements are added to Mobile IPv6 protocol to enrich its breadth to support both global mobility and local mobility. For example, a Home Agent can anchor Mobile Stations roaming within an LMM domain and Mobile Nodes roaming into other domains. The Localized Mobility Management solution defined in this document has the following design goals: 1. Handover Performance Improvement The Layer 1 and Layer 2 issues involved in handover should be covered in IEEE 802.21 which interacts with the IETF Detecting Network Attachment WG. It is assumed that these layers can provide optimized handover performance, and such functions are outside the scope of this document. From the network layer perspective, the Mobile Station is always authenticated when accessing the network (ASSUMPTION). When authentication completes for access or handover, this triggers the MPA to notify the LMAP. The important factor is the proximity of the LMAP to the MPA. In this scheme, the LMAP is dynamically assigned based on the location of the MS. The AAA Server can index the MPA's address to find the nearest LMAP for assignment, or the MPA is provisioned with its nearest LMAP, or some other scheme. Further optimization such as MPA to MPA tunneling is not required in the base LMM solution. 2. Reduction in Handover-related Signaling Volume Mobility-related signaling over the air-link is eliminated. The Mobile Station performs normal IPv6 network attachment activities and learns that it remains on the same network, the Local Home Network which is anchored by LMAP. 3. Location Privacy Gundavelli & Leung Expires May 12, 2006 [Page 5] Internet-Draft LMM using MIPv6 November 2005 The corresponding nodes that are communicating or have established flows with the Mobile Station must not be able to determine the current location information of the Mobile Station. Since the LMAP is anchoring the Local Address, movement within the LMM domain is hidden from the corresponding node. 4. Efficient Use of Wireless Resources There is no mobility signaling or tunneling header on the air- link. All signaling and tunneling are inside the network and only the original packet traverse the air-link. 5. Reduction of Signaling Overhead in the Network When a Mobile Station moves to a new MPA, the minimal number of messages are used to update the location on the LMAP and release the resources on the previous MPA. Due to the event driven states (e.g. MS is at MPA or arrived at another MPA), there is no need for chatty binding refresh messages. This method can significantly reduce the number of signaling messages compared to Mobile IPv6. 6. No Extra Security Between the Mobile Node and Network Because the Mobile Station is not participating in the mobility signaling, there is no need to set up any security credentials to mobility authorization. The network nodes, MPA and LMAP, are in the same LMM domain and securing the signaling is simplified. 7. Support for Heterogeneous Wireless Link Technologies Proxy Mobile IPv6 is based on a heterogeneous mobility protocol. 8. Support for Unmodified Hosts The Mobile Station should use DHCP to obtain an IP address and network prefix and operate as a compliant IPv6 host. The MPA and LMAP spoofs the MS to believe it is stationary, while allowing movement within the LMM network. 9. Support for IPv4 and IPv6 Another advantage of leveraging a standard protocol is adapting new ideas which goes through judicious debates in a public forum. Supporting an IPv4 host with Proxy Mobile IPv6 involves adapting the works in [14]. Gundavelli & Leung Expires May 12, 2006 [Page 6] Internet-Draft LMM using MIPv6 November 2005 3.2. LMM Domain Architecture The following illustration represents the LMM Domain model. A LMM domain have the following properties: a. A LMM domain is a topologically localized portion of the network. Movement by the Mobile Station within a LMM domain will get full mobility support and the mobility agents in the LMM network exchange control messages for mobility without the need for the MS to participate in the signaling. b. As the Mobile Station move outside the boundary of the LMM domain, global mobility is required. The Mobile Station can function as a Mobile Node in accordance to Mobile IPv6 [2]. d. Each Mobile Station in its home LMM domain is anchored by a LMAP. The security credentials and the policy data for it will be typically managed by a AAA Server residing locally in that LMM domain. When a Mobile Station moves out of its LMM domain, it may be assigned a new LMAP in the visiting domain and that entity will manage the mobility within the new LMM domain. e. Each LMM domain will have the following functional elements, LMAP, MPA, MS and AAA. The following illustrates a LMM domain model: Gundavelli & Leung Expires May 12, 2006 [Page 7] Internet-Draft LMM using MIPv6 November 2005 |<-- Global Mobility -->| |<- Local Mobility ->| |<- Local Mobility ->| ----------- ----------- / \ / \ / HA \ / HA \ | AAA | | AAA | | LMAP | | LMAP | | MPA | | MPA | \ MS / \ MS / \ /\ / \ / ----------- \ / ----------- LMM Domain#1 \ / LMM Domain#2 ---------- | Internet | / \ ---------- | | | | | Global Mobility ----------- | / \ | / HA \ | | AAA | \ / | LMAP | | MPA | \ MS / \ / ----------- LMM Domain#3 |<- Local Mobility ->| Figure 1: LMM Domain Model The following illustrates the network in a LMM domain: Gundavelli & Leung Expires May 12, 2006 [Page 8] Internet-Draft LMM using MIPv6 November 2005 +----+ +----+ |AAA |-----|DHCP| +----+ | +----+ | / \ / | \ / | \ / | \ / | \ +----+ +----+ +----+ |LMAP| |LMAP| |LMAP| +----+ +----+ +----+ / \ / \ / \ / \ / \ / \ +----+ +----+ +----+ +----+ |MPA | |MPA | |MPA | |MPA | +----+ +----+ +----+ +----+ / \ / \ / \ / \ / \ / \ / \ / \ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ |BS| |BS| |BS| |BS| |BS| |BS| |BS| |BS| +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | | /:\ /:\ : : : : +--+ +--+ |MS| |MS| +--+ +--+ Figure 2: Network in a LMM domain 3.3. New Functional Elements The LMM scheme introduces two new functional elements, Local Mobility Anchor Point (LMAP) and Mobility Proxy Agent (MPA). The following section explains the scope and the role of these entities. Local Mobility Anchor Point LMAP functionally is a MIPv6 Home Agent as per the base Mobile IPv6 specification [3]. It is the logical anchor point for the Mobile Station. The Local Address of the Mobile Station belongs to the Local Network Prefix owned by the LMAP. When the Mobile Station is roaming in the LMM network, its LMAP intercepts all Gundavelli & Leung Expires May 12, 2006 [Page 9] Internet-Draft LMM using MIPv6 November 2005 packets destined to the Mobile Station and tunnels them to its attached MPA. The packets from the MS are decapsulated and routed normally. Mobile Proxy Agent The MPA is the Proxy Mobility Agent. This is the entity that enables the Mobile Station on one of its link to use the assigned Local Address and roam in the LMM network without having to participate in mobility related signaling. It registers the location of the MS to the LMAP and establishes a tunnel for receiving packets sent to the Mobile Station. Packets from the MS are put into the tunnel to the LMAP. 4. Message Formats This section defines extensions to the MIPv6 Binding Update message. 4.1. Proxy Binding Update 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Proxy Binding Update Message A new flag, the 'P' flag, is added to the Binding Update message. The P flag indicates that the registration is a Proxy registration. When a MPA sends a registration with the LMAP, the P flag MUST be set to 1 indicate to the LMAP that this registration is a proxy registration sent by a MPA on behalf of a Mobile Station. Gundavelli & Leung Expires May 12, 2006 [Page 10] Internet-Draft LMM using MIPv6 November 2005 4.2. Proxy Binding Acknowledgement 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Proxy Binding Acknowledgement Message Proxy Registration Flag (P) The Proxy Registration Flag is set to indicate that the LMAP that processed the Proxy Binding Update supports Proxy Registration. It is set to 1 only if the corresponding Binding Update had the Proxy Registration Flag set to 1. 4.3. Binding Cache Confirmation 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A 8-bit field indicating the type of the mobility option. Length A 8-bit field indicating the length of the option. Set to 0. The Binding Cache Confirmation option is included in the Proxy Gundavelli & Leung Expires May 12, 2006 [Page 11] Internet-Draft LMM using MIPv6 November 2005 Binding Update sent by the MPA when it does not know the Local Address of the Mobile Station. Typically, this happens after network access authentication informs that the Mobile Station arrived at the MPA and triggers the registration. 5. Error Codes 5.1. Binding Acknowledgement Status Values The following status code values are defined for using them in the Binding Acknowledgement message when using LMM protocol. 140: Proxy Registration not supported 141: Binding Cache Entry missing The value allocation for this usage needs to be approved by the IANA and must be updated in the IANA registry. 6. Proxy Mobile IPv6 This section describes Local Mobility Management using Proxy Mobile IPv6 support. In this model, a Mobile Station roaming in a LMM network is not involved in any mobility related signaling. The following sequence of steps happens when a Mobile Station attaches to the network: network access authentication and authorization, Router and Neighbor Discovery, and address acquisition. During network access authentication, the MPA obtains the Mobile Station's profile from the AAA server. The attributes may include the IP address and virtual MAC address of the LMAP, Local Network Prefix (for dynamic LMAP resolution), assigned Local Address, and DHCP server. The MPA attempts to register the Mobile Station with its LMAP immediately after successful network access authentication and when the address acquisition is detected. A Mobile Station that boots up on the network will be anchored after obtaining a Local Address. Whereas a roaming Mobile Station's location is registered when network access authentication completes. Mobility support for the Mobile Station is achieved by the registration message exchange between MPA and LMAP. Gundavelli & Leung Expires May 12, 2006 [Page 12] Internet-Draft LMM using MIPv6 November 2005 For Router and Neighbor Discovery, the Mobile Station is spoofed by the MPA to be on the same link, which is the Local Network Prefix, when attached to the LMM network even if the MPA changed during handovers. The virtual LMAP MAC address is used by the MPA in Router Advertisement and Neighbor Advertisement to the Mobile Station. The Router Advertisement contains the Local Network Prefix. There are several methods for the Mobile Station to obtain an IP address: manual configuration, stateless auto-configuration, and stateful DHCP. For DHCP, the MPA tags the DHCP Request with the Local Network Prefix to ensure address allocation from the designated address pool. When DHCP Reply is received, the MPA registers the assigned IP address as the Local Address with the LMAP. For stateless auto-configuration, the MPA registers the IP address when Neighbor Solicit DAD message is received from the Mobile Station. In addition, any packet from the Mobile Station can trigger a registration with Local Address set to the Source IP address. This would be the same case for manually configured MS. Typically, this type of trust relationship with the Mobile Station (i.e. allowing MS to dictate its Local Address) would not be permitted or only when authorized by the AAA server. When the Mobile Station obtains an IP address (used for all communication sessions), the tunnel between MPA and LMAP is set up. All packets sent to the Mobile Station from the corresponding nodes will get intercepted at the LMAP and tunneled to the MPA, the MPA will decapsulate the packet and forward to the MN. Any packets sent to the corresponding node from the Mobile Station will get intercepted at the MPA and will be tunneled to the LMAP, where the packet is decapsulated the packet before being routed to the corresponding node. Gundavelli & Leung Expires May 12, 2006 [Page 13] Internet-Draft LMM using MIPv6 November 2005 6.1. Network Access Authentication MS MPA LMAP AAA |Access | | | |Initiation | | | 1)o---------->| | | | | | | | | AAA request | 2)| o---------------------->| | | | | MS 3)| | | o Authenti | | | | -cated | | AAA reply | 4)| |<----------------------o | | | | |Access |MPA obtains| | |Authenti o MN's | | | -cation| profile | | 5)|<----------o | | | | Proxy | | | | Binding | | | | Update | | 6)| o---------->| | | | | | | | | | | | |Look up BCE| 7)| | o by NAI, | | | | success | | | | if found | | | Proxy | | | | Binding | | | | Ack | | 8)| o<----------| | | | | | | |Setup | | | |LMAP-MPA | | 9)| o tunnel | | | | if success| | | | code in BA| | Figure 6: Network Access Procedure Control Flows Gundavelli & Leung Expires May 12, 2006 [Page 14] Internet-Draft LMM using MIPv6 November 2005 The network access authentication and authorization procedure permits a valid Mobile Station connectivity in the network. Upon successful authentication by the AAA server, the MPA retrieves the MS's profile containing NAI and the assigned LMAP (steps #1 through #5). It's possible that such information is obtained by some other methods, but that is out of scope of this document. Note that the LMAP is on the Local Network Prefix, so Once the NAI of the Mobile Station and assigned LMAP are known, the MPA sends a Proxy Binding Update to the LMAP (in step #6). The message includes the Mobile Node Identifier Option [11] to deliver the NAI information to the LMAP. If the Local Address or Local Network Prefix is assigned by the AAA server, the Assigned Home Address Option [10]is also included in the Proxy Binding Update. Otherwise, the Binding Cache Confirmation Option is appended in the message to request the LMAP to check if BCE exists (indexed by the NAI) for the Mobile Station (in step #7). In the case of Home Address Option, the LMAP creates or updates the BCE and sets up tunnel to the MPA for the Mobile Station before acknowledging the MPA. When Binding Cache Confirmation Option is received, the LMAP checks if the BCE exists or not. If the BCE is found, the LMAP adds the Assigned Home Address Option to the successful Proxy Binding Acknowledgement. Otherwise, the error code "Binding Cache Entry missing" is set in the reply message. The Proxy Binding Acknowledgement is sent to the MPA (in step #8). When MPA receives a successful reply, the tunnel and routing is set up for the Mobile Station (in step #9). Note when LMAP is on the Local Network Prefix, so the MPA is aware of the Local Network Prefix for the Mobile Station to partake in the Router and Neighbor Discovery process. 6.2. Router and Neighbor Discovery with Local Network Spoofing Gundavelli & Leung Expires May 12, 2006 [Page 15] Internet-Draft LMM using MIPv6 November 2005 MS MPA LMAP AAA |LLA DAD | | | 1)o---------->| | | | | | | 2)| o Normal DAD| | | | operation | | | | | | | | If dup | | | | addr, send| | | | NA | | 3)|<----------o | | | | | | |RS | | | 4)o---------->| | | | | | | | RA | | | 5)|<----------o | | Figure 7: MPA Behavior in Router and Neighbor Discovery Router and Neighbor Discovery between the Mobile Station and MPA is different than conventional IPv6 because the MPA is spoofing as the LMAP is advertising the Local Network Prefix directly to the Mobile Station. When MS sends Neighbor Solicitation for Link-Local Address Duplicate Address Detection (DAD) [RFC 2462], MPA performs normal DAD functions and responds accordingly (in steps #1 through #3). When duplicate addresses are detected on the link, recovery mechanisms are specified in RFC 2462. The Mobile Station sends a Router Solicitation to MPA (in step #4). The MPA sets the link prefix information in the advertisement message to the Local Network Prefix for the Mobile Station. The Router Advertisement contains the Prefix Information option with the "on-link" (L) flag set to zero to inform the Mobile Station to send to packets to the default router, which is the LMAP [RFC 2461]. The Router Advertisement is sent directly to the MAC address of the Mobile Station (in step #5). The Mobile Station sends Neighbor Solicitation to learn the MAC address of the default gateway (i.e. LMAP). MPA sends Neighbor Advertisement with the virtual MAC address of the LMAP which it uses to receive packets from MS. 6.3. Address Configuration The LMM scheme allows the Mobile Station to operate as a normal IPv6 Gundavelli & Leung Expires May 12, 2006 [Page 16] Internet-Draft LMM using MIPv6 November 2005 host using the standard IPv6 address configuration schemes. From the Mobile Station's perspective, there are three methods to obtain an IP address: manual configuration, DHCP, or stateless auto- configuration. 1. Manual Configuration: In this case, the Local Address, Local Network Prefix, and the LMAP address are manually configured on the Mobile Station as the IP address, Link Prefix, and Default Gateway, respectively. The Mobile Station does not depend on the Router Advertisements or on DHCP for address configuration. The static IP address of the Mobile Station is used for network connectivity. The configuration must match the parameters assigned to the Mobile Station in the LMM network for mobility support. This method is detected by the network in the same manner as the stateless auto-configuration. 2. Stateless Address Auto Configuration: Upon receiving a Router Advertisement with the "Managed" bit not set, the Mobile Station (operating as a normal IPv6 host) performs Stateless Auto-Configuration to obtain the host configuration. The LMM network detects the IP address of the Mobile Station from DAD or IP packets received from the MS. Figure 8 illustrates this scenario. 3. Using DHCPv6 for Address Configuration: Upon receiving a Router Advertisement with the "Managed" bit set, the Mobile Station (operating as a normal IPv6 host) uses DHCP to obtain the host configuration. The LMM network assigns the IP address using AAA server, DHCP server, or LMAP. When Local Address is assigned by a non-DHCP server, renewal still requires DHCP server to interact with the DHCP client in the MS. Gundavelli & Leung Expires May 12, 2006 [Page 17] Internet-Draft LMM using MIPv6 November 2005 MS MPA LMAP DHCP Server |LoA DAD or | | | |IP packet | | | 1)o---------->| | | | | | | | | Proxy | | | | Binding | | | | Update | | 2)| o---------->| | | | | | | | | | | | | Create BCE| 3)| | o for MS | | | Proxy | | | | Binding | | | | Ack | | 4)| o<----------| | Figure 8: Stateless Auto-Configuration The Mobile Station sends Neighbor Solicitation for Local Address DAD or any other IP packet will trigger MPA to learn and register the MS's Local Address (in step #1). MPA sends a Proxy Binding Update with Assigned Home Address Option and Mobile Node Identifier Option (in step #2). The former option contains the Local Address and the latter option contains the NAI. LMAP creates the BCE and sets up tunnel for the MS (in step #3). The Proxy Binding Acknowledgement is sent to the MPA (in step #4). Gundavelli & Leung Expires May 12, 2006 [Page 18] Internet-Draft LMM using MIPv6 November 2005 MS MPA LMAP DHCP Server |DHCP Req | | | 1)o---------->| | | | | | | | |Normal | | | |Relay Agent| | 2)| o---------------------->| | | | DHCP Reply| 3)| |<----------------------o | | | | 4)|<----------o | | | | | | | | Proxy | | | | Binding | | | | Update | | 5)| o---------->| | | | | | | | | | | | | Create BCE| 6)| | o for MS | | | Proxy | | | | Binding | | | | Ack | | 7)| o<----------| | Figure 9: Stateful DHCP The Mobile Station initiates the DHCP process after link comes up. The MPA operates as a normal DHCP Relay Agent and forwards requests from the Mobile Station to the DHCP Server. The DHCP Relay-Forward message is tagged with Local Network Prefix information for the DHCP Server to assign the IP address from the designated address pool. The DHCP server sends DHCP Reply to the MPA, which forwards to the MS (in steps #1 through #4). When MPA learns the assigned IP address, it sends a Proxy Binding Update with Assigned Home Address Option and Mobile Node Identifier Option (in step #5). The former option contains the Local Address and the latter option contains the NAI. LMAP creates the BCE and sets up tunnel for the MS (in step #6). The Proxy Binding Acknowledgement is sent to the MPA (in step #7). Gundavelli & Leung Expires May 12, 2006 [Page 19] Internet-Draft LMM using MIPv6 November 2005 6.4. Resource Cleanup MS New MPA LMAP Previous MPA | | Proxy | | | | Binding | | | | Update | | 1)| o---------->| | | | | | | | | Update | | | | existing | 2)| | o BCE for MS| | | | | | | | Proxy | | | | Binding | | | | Revocation| 3)| | o---------->| | | | | 4)| | | o Remove visitor | | | | entry for MS | | | | | | | | Proxy Binding | | | | Revoc Ack 5)| | |<----------o | | | | | | Proxy | | | | Binding | | | | Ack | | 6)| o<----------o | Figure 10: Binding Revocation for Previous MPA MPA which no longer serve the Mobile Station needs to remove any associated mobility states and relinquish resources which are no longer needed. When LMAP receives a Proxy Binding Update for a Mobile Station with an existing BCE, a Registration Revocation [13] is sent to the previous MPA (in steps #1 through #3). The MPA removes the visitor entry for the Mobile Station before sending acknowledgement to the LMAP (in steps #4 and #5). In parallel, the LMAP sends the Proxy Binding Acknowledgement to the new MAP (in step #6). At the end of sequence of events, only states in the LMM network are in the MPA Gundavelli & Leung Expires May 12, 2006 [Page 20] Internet-Draft LMM using MIPv6 November 2005 where MS is attached and the LMAP. 7. Mobility Proxy Agent Operation The MPA function has two parts. For data path, MPA provides the same role as a Foreign Agent in Mobile IPv4 [RFC 3344]. It encapsulates and decapsulates packets to and from the LMAP, respectively. The other function of this entity is to signal to the LMAP to set up the tunnel for the data path when the Mobile Station is visiting. When the mobile station using a wireless link attaches to a LMM network, it attempts to authenticate to the network using the enforced Layer-2 authentication protocol and the MPA on the link on detecting this new mobile station will trigger the Layer-3 mobility signaling. The MPA on the link will identify the mobile station and will download its profile from the Policy Enforcement Point. The profile typically will contain the contain the Local Network Prefix, Local Address and the supported IPv6 Address Configuration mode and the Default Router on its link. Following is the typical configuration that is maintained by the AAA server for each Mobile Station: 1. NAI 2. Authentication Credentials 3. LMAP Address 4. Local Network Prefix (Optional) 5. Local Address (Optional) 6. Default Gateway Address (Optional) Once the MPA downloads the Mobile Station's profile, it will respond to the Router Solicitation messages received from the Mobile Station with a Router Advertisement reflecting the Mobile Station's home link and thus making the Mobile Station to believe it's on the home link. 7.1. Conceptual Data Structures at the MPA Each MPA must maintain a Visitor List. Each entry in the list represents an attached Mobile Station and its parameters: Gundavelli & Leung Expires May 12, 2006 [Page 21] Internet-Draft LMM using MIPv6 November 2005 o The NAI of the Mobile Station. This is obtained from the network access authentication messages. The NAI is the identifier that will be used by the MPA to download the MS's profile. o MAC Address of the Mobile Station, obtained by the MPA during the network access authentication procedure. o Local Address of the Mobile Station, obtained by the MS using DHCP. However, the network can assign the Local Address using one of the following methods: downloaded from the AAA server along with other attributes, assigned by the LMAP in the registration process, and learned from DAD sent by the Mobile Station. o Local Network Prefix of the Mobile Station obtained from either the AAA or LMAP. o IP address and virtual MAC address of the LMAP obtained from the AAA as part of the profile download. o Source address of the tunnel between the MPA and LMAP. This is either the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present in the Proxy Binding Update. o Destination address of the tunnel between the MPA and LMAP. This is the Destination Address field in the IPv6 header of the Proxy Binding Update. o Registration lifetime that is established with the Mobile Station's LMAP. o DHCP Server address assigned by the AAA server. MPA sends DHCP messages to this DHCP Server when the Mobile Station performs either stateless or stateful DHCP procedure. 7.2. Mobility Signaling for Mobile Station After network access authentication, MPA sends Proxy Binding Update to the LMAP. The MPA uses the Local Network Prefix for the Mobile Station to advertise the link prefix information to the Mobile Station. The Router Advertisement contains the Prefix Information option with the "on-link" (L) flag set to zero to inform the Mobile Station to send packets to the default router, which is the LMAP [RFC 2461]. Gundavelli & Leung Expires May 12, 2006 [Page 22] Internet-Draft LMM using MIPv6 November 2005 7.3. Establishment of Bi-Directional Tunnel After receiving a successful Binding Acknowledgement for the Proxy Binding Update, the MPA sets up a tunnel to the Mobile Station's LMAP. The bi-directional tunnel between the MPA and the LMAP allows packets to flow in both directions, while the mobile station is connected to its visited link. The tunnel endpoints are the LMAP and the MPA. All IPv6 traffic to and from the Mobile Station is sent through this bi-directional tunnel. While the MPA is serving a Mobile Station, it MUST be able to intercept all packets sent from the Mobile Station and forward them out the MPA-LMAP tunnel created for supporting that Mobile Station. Any packets received on the tunnel from LMAP, the MPA decapsulates before forwarding to the Mobile Station on its link. 8. Mobile Station Operation As per this specification, a mobile station present in a LMM domain would function as a normal IPv6 host. The required behavior of the node will be consistent with the base IPv6 specification [1]. The mobile station in a LMM domain will have the ability to retain its IPv6 address as it moves from one point of network attachment to the other with out ever requiring it to participate in any mobility related signaling. The mobile station when boots up for the first time in a LMM domain, would be assigned a Local Home Network prefix and can obtain an IPv6 address from that Prefix in one or more ways. Once the mobile station obtains an IPv6 address, it will have the ability to move with in this LMM network and with out having to obtain a new address. The LMM network entities will ensure the mobile station gets seamless mobility with in the boundaries of this LMM network. However, the mobile station when roaming across LMM domains MAY use Mobile IPv6 signaling, if it requires IPv6 mobility. As the mobile station roams with in the LMM network, moving from one link to the other, it always detects its local home network. The MPA on the attached link emulates the home link behavior for the mobile station. It makes the mobile station believe its on its home link. The Router Solicitation messages will result in a Router Advertisement with its home prefix, default router and other Gundavelli & Leung Expires May 12, 2006 [Page 23] Internet-Draft LMM using MIPv6 November 2005 configuration parameters that the LMM entities make sure remain consistent with the home link properties. If the node address configuration policy on the mobile station's home link requires the mobile station to depend on DHCP for obtaining address configuration, LMM entities will ensure, the mobile station using DHCP protocol will obtain its assigned local address. Further, the mobile station will be able to use the Neighbor discovery protocol as it would on its home link. 8.1. Booting up in a LMM Domain When the Mobile Station enters a LMM domain for the first time and attaches to a link on the MPA, it will present its identity in the form of NAI to the network as part of the network access authentication process. After a succesful authentication, the mobile station will send a Router Solicitation message. The MPA on the link will respond to the Router Solicitation message with a Router Advertisement. The Router Advertisement will have the mobile station's home prefix, default router and other configuration parameters. The address configuration parameters such as Managed Address Configuration, Stateful Configuration flag values will be consistent with the home link policy. If the Router Advertisement has the Managed Address Configuration flag set, the mobile station, as it would normally do, will send a DHCP Request and again the LMM entities will ensure, the mobile station gets its local address as a lease from the DHCP server. If the Router Advertisement does not have the Managed Address Configuration flag set, the mobile station can autoconfigure itself by appending its link-layer address (EUI-64 format) to the advertised local home network prefix. Once the address configuration is complete, the Mobile Station will always be able to use that IP address anywhere in that LMM domain. Further, the Mobile Station may get the same Local Address even after a reboot. In the current context, usage of the word "Local Address" is not related to "Link-Local Address", but instead refers to an invariant IPv6 address that the Mobile Station owns throughout its presence in the LMM domain. 8.2. Moving to a New MPA When a Mobile Station moves to a new MPA from another MPA, the following occurs: The Mobile Station will perform a network access authentication with Gundavelli & Leung Expires May 12, 2006 [Page 24] Internet-Draft LMM using MIPv6 November 2005 the attached MPA. If the authentication fails, the Mobile Station will not be able to use the link. After a succesful authentication, the MPA will have the identifier and the other profile data of the Mobile Station. Once the network access authentication process is complete, the Mobile Station sends a multicast Router Solicitation message to the All-Routers multicast address on that new link, either using the Link-Local address or the using the unspecified address (::) as the Source Address in the IPv6 header. The Access Router with the MPA function on receiving this Router Solicitation message will respond with a Router Advertisement. The reply is sent to the unicast Link-Local Address or All-Nodes Multicast Address depending if the Source Address is Link-Local Address or unspecified address, respectively. The Destination Address is in compliance to IPv6. However, the Destination MAC address in the Router Advertisement MUST always be set to the Source MAC address of the Router Solicitation. If the Router Advertisement has the Managed Address Configuration flag set, the mobile station, as it would normally do, will send a DHCP Request and again the LMM entities will ensure, the mobile station gets its local address as a lease from the DHCP server. If the Router Advertisement does not have the Managed Address Configuration flag set, the mobile station can autoconfigure itself by appending its link-layer address (EUI-64 format) to the advertised local home network prefix. 8.3. Packet forwarding All packets that are be sent from the Mobile Station to the corresponding node will be sent as normal IPv6 packets setting the Source Address of the IPv6 header to the Local Address and the Destination Address to the corresponding node's IP address. The default gateway for the Mobile Station will always be its LMAP. The Neighbor Cache Entry for LMAP address is a pseudo LMAP MAC address. Similarly, all packets sent to the Mobile Node's Local Address by the corresponding node will be received by the Mobile Station in the original form (without any tunneling overhead) on its link. No special operation is required by the Mobile Station to either send or receive packets. Gundavelli & Leung Expires May 12, 2006 [Page 25] Internet-Draft LMM using MIPv6 November 2005 8.4. Moving to a New LMM Domain The LMM scheme defined in this document, provides mobility support to the Mobile Station within that LMM domain. Once the Mobile Station obtains an assigned Local Address, it can continue to use the same address roaming between MPAs in the network with its LMAP providing the topological anchor point for that address. However, the Mobile Station while roaming across LMM domains is required to have the Mobile IPv6 stack and operate as a normal MIPv6 mobile node to achieve mobility across LMM domains. 9. LMAP Operation LMAP is functionally a MIPv6 Home Agent. It is the topological anchor point for the Mobile Station's Local Network Prefix. When a Mobile Station enters a LMM domain for the first time, a LMAP and a Local Network Prefix gets assigned to that Mobile Station. The following section explains the LMAP function: 9.1. Processing Proxy Binding Update Upon the receipt of a Proxy Binding Update from a MPA, the LMAP checks if the Binding Cache Confirmation Option is included. If so, LMAP looks up the BCE indexed by the NAI. If BCE exists, LMAP sends a Proxy Binding Acknowledgement with Assigned Home Address Option. The Local Address in the BCE is set in the appended option. The Local Home Prefix is in the prefix length field of the option. In this case, LMAP updates the Care-of Address in the BCE to the MPA that sent the PBU. If there is no BCE for the MS, then LMAP sends PBA with error code "Binding Cache Entry missing" in the message. 9.2. Packet interceptions When the LMAP intercepts a packet sent to the mobile station's home address, it tunnels the packet to the attached MPA of the mobile station. The encapsulated packet will contain the following. Outer IPv6 Header: Gundavelli & Leung Expires May 12, 2006 [Page 26] Internet-Draft LMM using MIPv6 November 2005 The source address is the LMAP's address and the destination address is the Mobile Station's Care-of Address (i.e. the MPA's address). Inner IPv6 Header: The source address is the corresponding node's address and the destination address is the Mobile Station's Local Address. 10. IANA Considerations This document defines a new Mobility Header Option, the Binding Cache Confirmation Option. The type value for this option MUST be assigned from the same space used by the mobility options defined in [1]. This document defines a new flag (P) to the Binding Update and Binding Acknowledges messages specified in [2]. This document also defines new Binding Acknowledgement status values as described in Section 4.5. The status values MUST be assigned from the same space used for Binding Acknowledgement status values in [2]. 11. Security Considerations This document introduces new mobility entities, LMAP and MPA. These are the entities that are involved in the signaling for providing Layer-3 mobility to a Mobile Station. The protocol requires these entities to have established security associations for securing the signaling traffic. The messages MUST be protected by IPSec or using an Authentication Option [12]. 12. Acknowledgements 13. Normative References [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Gundavelli & Leung Expires May 12, 2006 [Page 27] Internet-Draft LMM using MIPv6 November 2005 [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [4] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for IP Local Mobility". draft-kempf-netlmm-nohost-ps-00, June 2005. [5] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Requirements and Gap Analysis for IP Local Mobility". draft-kempf-netlmm-nohost-req-00, June 2005. [6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [10] Devarapalli, V. et. al., "Mobile IPv6 Bootstrapping for the Authentication Option Protocol", draft-devarapalli-mip6-authprotocol-bootstrap-00.txt, November 2005. [11] Patel, A. et. al., "Mobile Node Identifier Option for MIPv6", draft-ietf-mip6-mn-ident-option-03, September 2005. [12] Patel, A. et. al., "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth-protocol-07.txt, September 2005. [13] Haley, B., Gundavelli, S., "Mobility Header Signaling Message", draft-haley-mip6-mh-signaling-01.txt, October 2005. [14] Soliman, S., Tsirtsis, G., "Dual Stack Mobile IPv6", draft-soliman-v4v6-mipv4-02.txt, July 2005. [15] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. Gundavelli & Leung Expires May 12, 2006 [Page 28] Internet-Draft LMM using MIPv6 November 2005 Authors' Addresses Sri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: sgundave@cisco.com Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: kleung@cisco.com Gundavelli & Leung Expires May 12, 2006 [Page 29] Internet-Draft LMM using MIPv6 November 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gundavelli & Leung Expires May 12, 2006 [Page 30]