Network Working Group V. Narayanan Internet-Draft Qualcomm, Inc. Expires: January 6, 2008 D. Thaler Microsoft M. Bagnulo Huawei Lab at UC3M H. Soliman Elevate Technologies July 5, 2007 IP Mobility and Multi-homing Interactions and Architectural Considerations draft-vidya-ip-mobility-multihoming-interactions-01 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 January 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A number of protocols have been defined at the IETF to handle IP mobility and multi-homing - each of the defined protocols satisfies a Narayanan, et al. Expires January 6, 2008 [Page 1] Internet-Draft IP Mobility and Multi-homing Interations July 2007 different set of requirements - however, there is an overlap on some of the requirements and features among many of these protocols. In practice, a combination of the protocols are likely to be deployed in a system. There are various such combinations plausible, but some combinations are more realistic than others. This document analyzes the overall mobility and multi-homing architecture and highlights some key points to consider while deploying an architecture consisting of one or more of these protocols. The protocols considered in scope for this document include Mobile IPv4 (MIPv4), Mobile IPv6 (MIPv6), Hierarchical Mobile IPv6 (HMIPv6), Fast Mobile IPv6 (FMIPv6), Network-based Local Mobility Management (NetLMM), MOBIKE, Host Identity Protocol (HIP), and Shim6. Narayanan, et al. Expires January 6, 2008 [Page 2] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IP Mobility and Multi-homing - Relative Analysis . . . . . . . 7 4. Protocol Sub-classes . . . . . . . . . . . . . . . . . . . . . 10 4.1. Node-based Mobility and Multihoming . . . . . . . . . . . 10 4.1.1. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. Hiearchical Mobile IP . . . . . . . . . . . . . . . . 11 4.1.3. Fast Mobile IP . . . . . . . . . . . . . . . . . . . . 12 4.1.4. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.5. SHIM6 . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.6. HIP . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Network-based Mobility . . . . . . . . . . . . . . . . . . 14 5. Mobility Architectures . . . . . . . . . . . . . . . . . . . . 15 5.1. Architectural Entities . . . . . . . . . . . . . . . . . . 15 5.2. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 18 6. Protocol Interactions, Usage Models and Architectural Implications . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Multi-Level Node-based Mobility and Multihoming . . . . . 20 6.1.1. MIP, HMIP, and FMIP . . . . . . . . . . . . . . . . . 21 6.1.2. MIP and MOBIKE . . . . . . . . . . . . . . . . . . . . 25 6.1.3. MIP and SHIM6 . . . . . . . . . . . . . . . . . . . . 27 6.1.4. MIP and HIP . . . . . . . . . . . . . . . . . . . . . 27 6.1.5. SHIM6 and MOBIKE . . . . . . . . . . . . . . . . . . . 27 6.1.6. SHIM6 and HIP . . . . . . . . . . . . . . . . . . . . 27 6.1.7. HIP and MOBIKE . . . . . . . . . . . . . . . . . . . . 27 6.1.8. MIP, SHIM6 and HIP . . . . . . . . . . . . . . . . . . 27 6.2. Node-based and Network-based Mobility . . . . . . . . . . 28 6.2.1. Security Implications . . . . . . . . . . . . . . . . 29 6.2.2. Multihoming Implications . . . . . . . . . . . . . . . 30 6.2.3. Network-based mobility for non-MIP nodes . . . . . . . 32 6.2.4. Other Analysis . . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Narayanan, et al. Expires January 6, 2008 [Page 3] Internet-Draft IP Mobility and Multi-homing Interations July 2007 1. Introduction Over the years, several protocols have been defined at the IETF to handle changes to IP addresses of endpoints in a seamless fashion and preserving communications established using a given IP address across changes in the IP points of attachment. Essentially, all of the proposed mechanisms provide IP address permanence at some level to layers above. Some protocols go beyond support for just single- interfaced endpoints and allow multi-homing and IP address permanence to applications on infrastructure sites, servers, gateways, etc. "Permanence" as used here is typically bound by some length of time and hence is not quite permanent in the literal sense. The idea is for the IP address, as observed by layers above IP, to stay constant within that duration, even if the endpoint changed its IP point of attachment or added an interface within that time. The existing documents on these protocols provide sufficient details for the individual protocol operation itself, but do not touch on architectural aspects. In practice, a combination of the protocols are likely to be deployed in an architecture. There are various such combinations plausible, but some combinations are more realistic than others. Also, various considerations come into play while defining an overall architecture that encompasses IP mobility and multi- homing. Often, a network may need to support a variety of such protocols to satisfy the varying needs of the different nodes that attach to it. Also, a given node would often support multiple such protocols for various reasons. This document analyzes the overall mobility architecture and highlights some key points to consider while deploying an architecture consisting of one or more of these protocols. The protocols considered in scope for this document include Mobile IPv4 (MIPv4), Mobile IPv6 (MIPv6), Hierarchical Mobile IPv6 (HMIPv6), Fast Mobile IPv6 (FMIPv6), Proxy Mobile IPv6 (PMIPv6), MOBIKE, Host Identity Protocol (HIP), and Shim6. 2. Terminology The key words "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 [1]. This document follows the terminology that has been defined in the normative references included in this document. In addition, the following terminology is used in this draft. Narayanan, et al. Expires January 6, 2008 [Page 4] Internet-Draft IP Mobility and Multi-homing Interations July 2007 IP Mobility IP mobility refers to changes in the IP point of attachment of a node. As a consequence of this change, a node may obtain a different (topologically meaningful) address. The result is that a mobile node or network, as it moves, may obtain different topologically meaningful IP addresses that it can use for IP-based communications. Some protocols allow the nodes to maintain the same IP address as they move across different IP points of attachment. IP Mobility Protocol An IP mobility protocol provides transparency to layers above IP from the changes in the IP addresses resulting from IP mobility. In particular, such protocols allow nodes to continue IP communications independent of the current IP point of attachment and to preserve established communications across any corresponding IP address changes. A key element of an IP mobility protocol is to detect movement and do what is needed to allow communication continuity. IP Multi-addressing A node or a network is multi-addressed when it simultaneously has multiple topologically meaningful addresses or prefixes. Note that nodes and networks can be multi-addressed even if they only have a single network attachment point. This is typically true for IPv6 nodes for example, since interfaces can have both link- local and global addresses. IP Multi-homing A network is multihomed when it has multiple network (not necessarily physical) attachment points. From an IP perspective, these multiple attachment points typically imply that the node or network is also multi-addressed. There are some exceptions, however, (e.g., with Provider Independent (PI) addressing), where multihoming does not translate to having a meaningful address/ prefix from each of the providers. Similarly, a node is multihomed when it has multiple network interfaces IP Multi-addressing Protocol An IP multi-addressing protocol provides transparency to upper layers from changes in the IP address actually used to exchange packets by presenting a constant IP address. A key element of an IP multi-addressing protocol is to detect the reachability status Narayanan, et al. Expires January 6, 2008 [Page 5] Internet-Draft IP Mobility and Multi-homing Interations July 2007 of the different addresses and do what is needed to allow communication continuity. Node-based Mobility Node-based mobility is defined as an IP mobility mechanism where the mobility management signaling is performed by the node requiring mobility itself. Mobile nodes include end hosts and routers that may be mobile. Network-based Mobility Network-based mobility is defined as an IP mobility mechanism where the mobility management signaling is performed by a network entity on behalf of the node requiring mobility itself. Local Mobility For the purpose of this document, local mobility is defined as mobility within a given domain. Local mobility protocols allow at least one IP address of a node to remain constant within the local domain. Continuity of sessions using that IP address in the local domain is a goal for these protocols. The term "domain" is quite loosely used to indicate a region within which it is practical to expect end-to-end security associations between the mobility signaling endpoints. Typically, this is limited to a single administrative domain. Depending on the protocol used, this may mean mobility within an access technology or may also involve inter-technology handoffs. Global Mobility For the purpose of this document, global mobility is defined as mobility within a larger geographic area. Typically, this includes mobility across heterogeneous technologies and inter- administrative domains. Global mobility protocols allow at least one IP address of a node to remain constant across any handoffs. Continuity of sessions using that IP address across handoffs is a goal for these protocols. Global Roaming This term is used to refer to the availability of a set of services to a node from anywhere, at any time. Maintenance of IP address or session continuity is not a goal for this. This term encompasses the cases of a node roaming world-wide and accessing a set of services from anywhere. Narayanan, et al. Expires January 6, 2008 [Page 6] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Correspondent Node Any entity that communicates with a mobile node is referred to as a correspondent node. Access Router An Access Router is defined as the first hop IP router for a mobile node at its point of attachment. This entity typically serves as the default router for the mobile node. Access Network An access network is typically the edge network to which a mobile node attaches. An access network typically comprises of one or more physical and link layer attachment points, as well as one or more access routers. 3. IP Mobility and Multi-homing - Relative Analysis IP mobility and multi-homing are closely related in one sense and somewhat different in another sense. Protocols that handle IP mobility and multi-homing can be used together in a competing or complementary fashion. All IP mobility protocols support basic host multi-homing or multi-addressing functions. There are protocols that further support site multi-homing, that can be leveraged for mobility to a certain extent. A system looking at using the various available components should look at the scope of each and the requirements at hand to see how best to fit these together. This section provides an analysis on the relative scope and requirements handled by each suite of protocols. Narayanan, et al. Expires January 6, 2008 [Page 7] Internet-Draft IP Mobility and Multi-homing Interations July 2007 ---------------- ---------------- |Remote Network 1| |Remote Network 2| ---------------- ---------------- | | | | ----------------------------- --------------- | |---| Home Network 1| | | --------------- | Backbone | --------------- | |---| Home Network 2| | | --------------- ----------------------------- | | | | ---------------- ---------------- | Local Network 1| | Local Network 2| ---------------- ---------------- \ / \ / ------ | Node | ------ Figure 1: End Node and Multi-Network Associations Figure 1 shows a multi-network setup with local networks, remote networks and home networks, all inter-connected in some fashion. The main idea is that these networks can communicate via a backbone of some form. There are three classes of networks illustrated here: Local Networks A local network is an access network to which a node is attached at any given time. The node may or may not have a long term association with that network. The local network often defines the actual IP point of attachment of a node and may change over time. Home Networks A home network is one with which a node has a long term association (this is not to be confused with the "home network" in the context of Mobile IP or related protocols). While that is certainly one example of a home network, the various provider networks in the SHIM6 context may also be home networks from an association point of view. Networks with which a node has a VPN relationship may also fall under this category. Narayanan, et al. Expires January 6, 2008 [Page 8] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Remote Networks A remote network is one with which a node has no association. A remote network may become a local network at some point of time. A node with certain local and home networks may communicate with any of the networks. For generality, everything except the local and home networks may be viewed as a remote network. Given all the networks, there are several mobility, multihoming, and multi-addressing relations that can be drawn from here. Note that the nodes within a multihomed network will be exposed to multiple prefixes and they will then configure multiple global topologically meaningful addresses. The result is that nodes within a multihomed network are multi-addressed, as are nodes which are themselves multihomed. Even if the former type of nodes access the Internet through a single interface, the use of different addresses implies different paths (because each address is associated to a different point of attachment of the multihomed network to the Internet). Both types of nodes encounter similar problems and also benefit from a multi-addressing support protocol. The multihoming aspects may vary due to mobility or due to network unreachability. The former may cause more frequent changes in the multihoming state than the latter. Also, a node may be multihomed both in the local and home networks. For instance, a mobile node with cellular and WLAN accesses may be associated with two ISPs or with an ISP and an enterprise network. The local multihoming situation may change relatively frequently based on the rate of mobility of the node, while the multihoming situation with multiple home networks may remain fairly stable. Correspondent nodes may be located in the local, home, or remote networks. While it is technically feasible for communication with the correspondent node to happen using any of the IP addresses owned by the node, there may be some practical considerations with respect to making IP address changes known to the correspondent nodes and its impact to applications in use. Using DNS updates or SIP Re-invite like mechanisms, IP address changes can be made visible to the correspondent nodes. For some applications, such transitions may be seamless enough, while it may not be the case for some other applications. The alternative to DNS updates or SIP Re-invites and affecting applications with IP address changes and reachability issues is to provide an unchanging address to the applications and handle actual IP address changes at a lower layer. This is the approach taken by IP mobility and multihoming protocols, although in different ways. Narayanan, et al. Expires January 6, 2008 [Page 9] Internet-Draft IP Mobility and Multi-homing Interations July 2007 IP mobility protocols achieve this property via tunneling mechanisms. A centralized entity keeps track of the current location of the mobile node, so that data can be appropriately forwarded to the node. IP multihoming protocols like SHIM6 achieve this property via a shim layer between the IP and transport layers that perform address translation, thereby avoiding tunnels. IP mobility protocols developed at the IETF thus far are scoped to solve both mobility and multihoming in the context of a single home network. In other words, local multihoming (attachment to multiple local networks) is handled by extensions to Mobile IP, for instance. Some rudimentary local multihoming is also feasible by the basic Mobile IP class of protocols without extensions. This provides seamlessness to the applications using the address of the end node associated with one home network for communication. IP multihoming protocols developed at the IETF thus far are scoped to solving site multihoming in the context of one or more local and/or home networks. The main difficulty that multi-addressed nodes face when managing their multiple addresses, is that the reachability status of the addresses may vary during the lifetime of a communication (e.g. because of outages) and it may be required to use a different address for continuing an established communication, since the original one has become unreachable. While address unavailability and additions may be caused by mobility, solving node mobility is not a goal of the protocol. Section 6.1.3 provides details on how IP mobility and multihoming protocols can be architecturally combined. 4. Protocol Sub-classes 4.1. Node-based Mobility and Multihoming 4.1.1. Mobile IP Mobile IP (v4 and v6) provides a mechanism by which a node can maintain the same IP address as it changes its IP point of attachment. This is enabled by having a Home Address which is on the prefix of a Home Agent and a Care-of-Address which is the topologically correct local address at the point of attachment. The Home Agent maintains the mapping between the Home Address and the Care-of-Address. The Mobile Node is responsible for updating the binding between the Home Address and Care-of-Address at the Home Agent. All packets sent to the Home Address of the mobile node will be received by the Home Agent and tunneled or forwarded to the mobile node at its Care-of-Address. The packets sent from the mobile node Narayanan, et al. Expires January 6, 2008 [Page 10] Internet-Draft IP Mobility and Multi-homing Interations July 2007 may be sent directly or reverse tunneled through the Home Agent. Mobile IPv4 (MIP4) additionally provides a mode of operation with a Foreign Agent in the local network. The Foreign Agent makes conservation of IP space possible by allowing multiple mobile nodes on its link to share the same Care-of-Address. The Care-of-Address in this case is the IP address of the Foreign Agent. The Mobile IP tunnel in this case terminates at the Foreign Agent and the Foreign Agent forwards packets to the mobile node based on the Home Address in the packets. Mobile IPv6 (MIP6) additionally provides the capability of route optimization. Here, the mobile node may provide the Home Address- Care-of-Address binding to a correspondent node (CN) so that the CN sends packets directly to the Care-of-Address bypassing the Home Agent. Mobile routers may be supported using Network Mobility (NEMO), where, in addition to a Home Address, a prefix owned by the node is also bound to the Care-of-Address at the Home Agent or CN. Multi-homing for the Care-of-Addresses may be supported in MIP6 using extensions being defined in [2]. This allows multiple Care-of- Addresses for an mobile node to be bound to a given Home Address. There are extensions being proposed to use multiple Care-of-Addresses simultaneously based on flow mapping information - [2], for instance. One Care-of-Address is registered as a primary Care-of-Address and is used by default. Multiple Care-of-Addresses are also supported in MIP4 (simultaneous bindings), although data is duplicated to every Care-of-Address registered [3]. 4.1.2. Hiearchical Mobile IP Hierarchical Mobile IPv6 (HMIPv6) [4] provides a means of local mobility management for mobile nodes. Essentially, it is a variant of MIP6 that provides more efficient mobility within a local domain. In this case, the mobile node obtains a Regional Care-of-Address (RCoA) in the prefix of a Mobility Anchor Point (MAP) and a Local Care-of-Address (LCoA) which is the topologically correct IP address at the point of attachment. The mobile node is responsible for updating the binding between the LCoA and RCoA at the MAP. HMIPv6 may be used independent of the use of MIP6. This results in a deterministic delay for routing updates due to the MN's movement, when compared to the variation in delays when relying on updating the HA (which can be anywhere on the Internet). HMIPv6 also reduces the number of binding updates sent as a result of movement to one. A similar concept for Mobile IPv4, regional registration, has been Narayanan, et al. Expires January 6, 2008 [Page 11] Internet-Draft IP Mobility and Multi-homing Interations July 2007 proposed [5]. In Regional Registration, a Generic Foreign Agent is used in place of the MAP to hide the local mobility from the Home Agent. Unlike HMIPv6, regional registration relies on the presence of Mobile IP as a higher level mobility management protocol in the system. In general, all the extensions defined for MIP6 may be used with HMIPv6 as well. Hence, NEMO and multiple Care-of-Address binding would also be supported in HMIPv6. Similarly, MIP4 extensions may be used with regional registration mechanisms as well. 4.1.3. Fast Mobile IP Fast Mobile IP (v4 and v6) provides a means of local mobility management at the edge for mobile nodes. FMIP is designed to provide temporary mobility management across Access Routers for faster and low latency handoffs. Here, a previous Care-of-Address (pCoA) is bound to a new Care-of-Address (nCoA) at the previous Access Router (pAR), after the mobile node has left the pAR and attached itself to a new Access Router (nAR). Effectively, data is tunneled from the pAR to the mobile node at its nCoA FMIPv4 also supports the Foreign Agents, in keeping with MIP4. In addition to FMIPv4, some low latency extensions to MIP4 have also been proposed in [6]. 4.1.4. MOBIKE MOBIKE provides mobility and multi-homing capabilities to IKEv2. When IKEv2 is used to create IPsec Security Associations between a node and a VPN gateway, the node may change its IP point of attachment, causing a change to the IP address which was used in IKEv2. Further, the node and the VPN gateway may be multi-homed with multiple IP addresses. MOBIKE allows a node to update its IP address on the IKE SA and correspondingly change the IPsec tunnel outer addresses. Hence, a node may change IP addresses without having to re-establish the IKE and IPsec SAs. Packets sent to the tunnel inner address of the node are tunneled to the appropriate outer address. Since IKEv2 is defined in an IP version agnostic manner, MOBIKE also applies equally to IPv4 and IPv6. 4.1.5. SHIM6 In order to preserve global routing system scalability, the Site Multi-homing by IPv6 Intermediation (Shim6) approach proposes that multihomed sites obtain multiple globally routable prefixes, one from each of their ISPs. In this configuration, each prefix assigned to a Narayanan, et al. Expires January 6, 2008 [Page 12] Internet-Draft IP Mobility and Multi-homing Interations July 2007 multihomed site can be aggregated into the prefix of the correspondent ISP, eliminating the contribution of multihomed sites to the global routing table. The result is that interfaces within multihomed sites will configure one address per prefix that is available in the site. In this setup, each address is reachable as long the corresponding path is working, so in order to preserve established communications through outages, it may be necessary to change the address used for exchanging packets during the lifetime of the communication. This is achieved using the Shim6 protocol. The Shim6 protocol provides a means by which two nodes with more than one IP address pair can change the address used to exchange packets during the lifetime of a communication without impacting the applications. Shim6 introduces the concept of an Upper Layer Identifier (ULID), and allows the IP address chosen by applications to persist, while using different addresses (called locators) to actually exchange packets below IP, based on their reachability status. A shim sub-layer located within the IP layer, between the IP endpoint sub-layer (handling fragmentation and IPSec functions among others) and the IP forwarding sublayer provides this transparency. The ULIDs used by Shim6 are in the form of an IPv6 address and contain cryptographic information that is used to secure the binding between the ULID and its locator set. The Shim6 architecture has two main components. The Shim6 protocol that is used to create and manage the Shim6 context between the endpoints containing ULID pair and locator set information for the peers. The other component is the failure detection and alternative path exploration protocol (called REAP), that allows the peers to detect failures along the currently used path and explore alternative locator pairs to divert the communication through. 4.1.6. HIP The Host Identity Protocol (HIP) [RFC4423] is a new architecture that separates the identity and the locator functions currently performed by the IP address in the Internet architecture. It does so by creating a new namespace for the identity of the network layer endpoints. The new identity namespace is cryptographic in nature, since the Host Identities (HI) are public keys that are associated to the hosts they represent. In order to be backward compatible with current transport and application layers, the HIP architecture does not impose the direct usage of the HI by the upper layers, but provides a compact representation of the Host Identities, namely the Host Identity Tag, which are 128 bits long hashes of the actual HI. The result is that transport and application layer communications are bound to the HI/HIT while the actual packets are routed at the IP layer using routable IP addresses. The HIP sub-layer located in the IP layer securely performs the translation between the host identity Narayanan, et al. Expires January 6, 2008 [Page 13] Internet-Draft IP Mobility and Multi-homing Interations July 2007 and the routable locators. The HIP architectures provides built-in security features. Essentially, HIP can be seen as a key exchange protocol, through which the keys associated to the the HI/HITs are negotiated prior of the beginning of the communication. Actual data packets are carried encapsulated with ESP protection. So, the HIP architecture naturally provides the means to establish secure communication channels between the peers. Moreover, since the endpoint identity space is cryptographic in nature, the HIP architecture intrinsically provides the means to proof identity ownership without requiring any additional infrastructure. Such capability enables alternative means to support mobility and multihoming, as described in [7]. Essentially, mobility and multihoming support for the HIP protocol relies on conveying alternative locator information in HIP signaling messages called UPDATE messages. Such UPDATE messages are protected using the trust acquired while the initial HIP key exchange. In order to support simultaneous movement and initial contact after movement, the HIP architecture relies on Rendez-Vous server defined in [8]. 4.2. Network-based Mobility Network-based mobility provides a means of mobility management for nodes without involving the nodes themselves in the signaling. This is done by making IP mobility transparent to the nodes. Network- based Local Mobility Management (NetLMM) is essentially a concept of providing local mobility using network-based mobility management protocols. Here, a Mobility Access Gateway (MAG), often located at the Access Router (AR), updates a Local Mobility Agent (LMA) with the location of a mobile node. A mobile node acquires an IP address in the NetLMM domain, which remains the same as long as the mobile node remains within that domain. Hence, the changes in the IP point of attachment do not cause IP address changes. By definition, NetLMM allows an IP prefix to span multiple links. By assigning a unique prefix for every mobile node and by employing virtual point-to-point link semantics for link local behavior, it is possible to avoid the issues of multi-link subnets [9] in NetLMM. Also, by definition, NetLMM provides mobility for a given IP address or prefix of a node. If a node is multi-addressed, mobility for each address or prefix will be handled separately in the NetLMM domain. While it is feasible to identify the multiple IP addresses or prefixes as belonging to the same node using other identifiers, it is not possible to provide transparency of such addresses to correspondent nodes or applications. Narayanan, et al. Expires January 6, 2008 [Page 14] Internet-Draft IP Mobility and Multi-homing Interations July 2007 5. Mobility Architectures This section provides an overall picture of all the elements involved in an overall mobility architecture. It also provides a description of where the various IP mobility functions fit in the stack relative to other protocols. 5.1. Architectural Entities Narayanan, et al. Expires January 6, 2008 [Page 15] Internet-Draft IP Mobility and Multi-homing Interations July 2007 ====================================== | Home Network | ================ | ------ ----------- | | Remote Network | | | CN | | HIP RVS | | | | | ------ ----------- | | | | ------ -------- ------- | | | | | MIP | | VPN GW | | Shim6 | | | | | | HA | |(Mobike)| | Node | |--------| ------ | | ------ -------- ------- | | | CN | | | | | ------ | ====================================== | | | | | | | | ============================================== | ------- | | Local Network | | | Shim6 | | | ------ | | | Node | | | | CN | | | ------- | | ------ | | | | -------------------------------------- | | | | | | | | | | | ------ ------ -------- | | | | | | | HMIP | |NetLMM| | VPN GW | | |----| | | | | MAP | | LMA | |(Mobike)| | | | | | | ------ ------ -------- | | | | | | | | ================ | -------------------------------------- | | | | | | | | -------------------------------------- | | | | | | | ------ ------ --------- | | | | |NetLMM| | MIP4 | |FMIP/HMIP| | | | | | MAG | | FA | | AR | | | | | ------ ------ --------- | | | | Access Network | | | | | | | -------------------------------------- | | | ============================================== | | ------ | Node | ------ Figure 2: Architectural Entities in IP Mobility and Multi-homing Narayanan, et al. Expires January 6, 2008 [Page 16] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Figure 2 shows a potential network architecture with various components of IP mobility management entities. The figure follows the local, home and remote network models shown in Figure 1. As shown, a part of the local network may be the edge or access network to which a node attaches. The access network typically consists of the first hop IP routers that nodes can attach to. The access network also provides the physical point of attachment (wired or wireless access with L1/L2 points of attachment such as access points) for the nodes. Depending on the system, there may or may not be mobility management elements in the local network. Also, depending on the system, there may not be a home network at all. For completeness, the figure shows the possible IP mobility management entities. All the elements shown are logical elements and some of them may be physically collocated in a system. As shown in the figure, the Mobility Access Gateway, the Foreign Agent, and the Access Router are all functions residing on the MN's first hop router. The MAG is responsible for playing the role of a network-based mobility client. The Foreign Agent provides MIP4 services and the Access Router plays a role for FMIP and HMIP. In FMIP, the Access Router is responsible for assisting the MN in predicting the handover, in addition to handling of edge tunnels upon handoff of a node and in HMIP, the Access Router is responsible for advertising the MAP in the IPv6 Router Advertisements. While all these elements can technically co-exist in the same access network and in the same physical box, there are some considerations that need to be taken into account when these do co-exist. Such considerations are outlined in Section 6. When the local network supports mobility management, there may be other entities such as a Mobility Anchor Point (MAP), a Local Mobility Agent (LMA), a VPN gateway supporting MOBIKE, or even a Home Agent present in the local network. One or more of these may serve a node from a mobility management perspective. Some of these interact with some of the elements in the access network to support IP mobility for the end node. As in the case of the access network elements, one or more of these logical functions may be present in the local network and may be collocated in the same physical entity. Some interactions are studied in Section 6. When involved in mobility management, a home network may host a Home Agent or a VPN Gateway supporting MOBIKE. Local mobility management entities may be present in a home network, where the home network is also a local network. Note that the sub-divisions of local, home and remote network, etc. are with respect to the end node - for e.g., a network that is remote for one node may be a local network for a different node. Narayanan, et al. Expires January 6, 2008 [Page 17] Internet-Draft IP Mobility and Multi-homing Interations July 2007 The end node itself may be multi-homed in a couple of different ways - it may have multiple addresses from the home or local network. The node may have multiple interfaces that attach to different access networks within the same or different local network. Further, the node may also have connectivity to multiple home networks, as discussed in Section 3 - for instance, it may be served by different Home Agents or VPN Gateways for access to specific services in each home network. The node may use Shim6 for multi-homing - it may correspond with other Shim6 nodes in other networks. Even though a Shim6 node is shown separately in the home and remote networks, any of the other entities may also be Shim6 capable. One aspect not indicated in the figure is connectivity to the "Internet" or other networks. It can be assumed that any of the networks provide connectivity to the Internet. The home network can also be expected to provide connectivity to other networks that offer some services to the end node. 5.2. Protocol Stacks With so many IP mobility management protocols, all potentially solving slightly different problems, it is interesting to see how these fit together in the stack. The following figure shows the stack diagram for the protocols discussed in this document. Narayanan, et al. Expires January 6, 2008 [Page 18] Internet-Draft IP Mobility and Multi-homing Interations July 2007 ========================================================= | -------- | | | IKEv2/ | ---------------- --------- | | | MOBIKE | | MIP4 signaling | | NetLMM | | | -------- ---------------- --------- | ========================================================= |------------------------------- | | ========================================================= | | Transport Layer | | | ----- ----- | | | | TCP | | UDP | | | | ----- ----- | | ========================================================= | |------------------------------| | | ========================================================= | | IP Layer | | | | | | ===================================================== | | | | IP endpoint sublayer | | | | | | | | | | ---------- ------ | | | | | ---- --------- | Frag/ | | Dst. | | | | | | | AH | | ESP/HIP | | Re-assly | | Opt. | | | | | | ---- --------- ---------- ------ | | | | ===================================================== | | | | | | ------- | | | | Shim6 | | | | ------- | | | | | | ----- ------ ------ ------ | | | | MIP | | FMIP | | HMIP | | PMIP | | | | ----- ------ ------ ------ | | | | | | ===================================================== | | | | IP forwarding sublayer | | | | | | | | | ===================================================== | | | | | ========================================================= | | | ------- ------- ------- ------------- | | Link1 | | Link2 | ... | Linkn | |Link (Tunnel)|--- ------- ------- ------- ------------- Narayanan, et al. Expires January 6, 2008 [Page 19] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Figure 3: Stack Diagram Figure 3 above shows a stack diagram of how the various IP mobility and multihoming components fit in a stack with respect to some other layers. A node may have various link layers as indicated. The IP layer is indicated in three parts. One is the IP forwarding sublayer that sits right above the link layer. In many of these protocols, there may be IP-in-IP tunneling. This is indicated in the figure by "Link (Tunnel)" - this layer would essentially wrap around the IP layer as a loopback, as shown. Typically, IP addressing is done on a per-link basis. Any virtual interfaces/links are assumed to still be a separate link. The Shim6 layer has two possible locations in the stack - it may be above or below the "Mobile IP family" of protocols. Since the Mobile IP family of protocols (MIP, FMIP, HMIP, PMIP) involve mapping between two IP addresses, Shim6 can be invoked as a multi-homing solution for either of those addresses. More about this interaction will be described in Section 6.1.3 below. The figure shows MIP generically at the IP layer and MIP4 specifically over the transport layer. MIP4 signaling runs over UDP, while the MIP4 data tunnel is an IP-in-IP tunnel. For sake of completeness, the figure shows MIP4 signaling also over UDP, for the signaling portion. The IPsec components (AH and ESP) may either be part of the tunnel (shown as a link) or the actual IP layer above the MIP family of protocols when IP-in-IP encapsulation (with reverse tunneling) is used for the MIP data path. This depends on which address is used for IPsec purposes. However, it should be noted that MIP6 is operated with Route Optimization, the IPsec components are always above the MIP components in the header. IKEv2 (and by definition, MOBIKE) run over UDP. IKEv2/MOBIKE is the signaling mechanism that ultimately affects the IPsec tunnel endpoints - hence, as in the case of MIP4, it is only the signaling that is layered over a transport protocol. AH and ESP may also be used in transport or tunnel mode and hence may be part of the tunnel or the regular IP layer. All of the elements shown are optional elements and the existence of any of this depends on the protocols used in the system. 6. Protocol Interactions, Usage Models and Architectural Implications 6.1. Multi-Level Node-based Mobility and Multihoming This section is intended to discuss the various viable combinations of node-based mobility and multihoming protocols and also point out Narayanan, et al. Expires January 6, 2008 [Page 20] Internet-Draft IP Mobility and Multi-homing Interations July 2007 any problematic combinations. This is a work in progress and is expected to be more detailed in later versions. 6.1.1. MIP, HMIP, and FMIP Depending on the mobility needs of a system, one or more of these protocols may be deployed. Typically, this is a two level mobility management mechanism, with additional edge mobility. However, multiple modes of combining FMIP and HMIP are also feasible. A few different modes of using these protocols together is explained below. It should be noted that it is feasible to run any of these modes with just a subset of these three protocols. It should further be noted that while this section focuses on the v6 versions of these protocols, similar combinations are also feasible with the v4 versions of the same - there may be additional modes of interest with MIP4, given the Foreign Agent mode of operation; however, that is left for further study. Alternatively, the same result can be obtained for both MIPv4 and MIPv6 using one version of MIP. This can be done using Dual Stack MIP v4 or v6 as presented in [10] and [11]. ---------- | HA | ---------- / \ / \ Home Network -------------------------------|--------------------------------- Local Network 1 / | \ Local Network 2 / | \ --------- | ---------- | MAP1 | | | MAP2 | --------- | ---------- /\ | /\ / \ | / \ / \ | / \ / \ | / \ / \ | / \ ------ ------ | ------ ------ | AR11 | ... | AR1n | | | AR21 | ... | AR2n | ------ ------ | ------ ------ | | | | ------ | | MN | ----> | ------ | | Narayanan, et al. Expires January 6, 2008 [Page 21] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Figure 4: MIP, HMIP, and FMIP Figure 4 shows an architecture with a MIP Home Agent, an HMIP MAP and Access Routers that perform FMIP operation. Upon first entering the network, the mobile node obtains an IP address on the prefix served by an Access Router. Using the MAP advertised by the Access Router, the mobile node may perform an HMIP registration, using that IP address as its Local Care-of-Address (LCoA) and an IP address obtained in the MAP's prefix as its Regional Care-of-Address (RCoA). The mobile node may further obtain a Home Address from the Home Agent and use that for mobility across MAPs. In this case, the HMIP RCoA is registered as the MIP6 Care-of-Address of the mobile node. In the presence of a Home Address, the mobile node would typically use this address for application connectivity. However, there may be certain other considerations in choosing the right address for communication. More on that in Section 6.1.1.3. The combination of HMIP and FMIP may also be done in a few different ways. When the mobile node moves from one Access Router to another, it may use FMIP for faster handoffs. FMIP may be used within a MAP or across MAPs between Access Routers. It is also feasible to use FMIP on the previous MAP, when the mobile node moves across MAP boundaries. This would often be more efficient in such border cases than setting up the FMIP session between the Access Routers. In a tree topology, it may always be more efficient to allow the MAP to perform FMIP services. In these cases, the "PAR (Previous Access Router)" functionality of FMIP is performed by the MAP. When the mobile node moves across Access Routers within a MAP, the FMIP tunnel is set up with the previous and new LCoAs as the FMIP PCoA and NCoA respectively. When the mobile node moves across MAPs and uses FMIP on the MAP, the previous and new RCoAs are treated as the FMIP PCoA and NCoA respectively. The FMIP tunnel is viewed as a temporary, short-lived tunnel used to help mobile nodes receive packets while waiting for the HMIP or MIP registration to complete. When FMIP is not in use, such a two-level mobility management mechanism leads to two IP tunnels on every data packet. For the period where FMIP is also in use, every packet is tunneled thrice. For a packet sent from the mobile node, this tunneling results in something as shown in Figure 5. The figure shows source and destination addresses of each IP header present in the packet. The oringinal packet is sourced using the Home Address to a correspondent node. This is first encapsulated in the Mobile IP tunnel, followed by the HMIP tunnel and finally followed by the FMIP tunnel. For a packet received by the mobile node from a CN, the tunneling is similar in the reverse direction. Narayanan, et al. Expires January 6, 2008 [Page 22] Internet-Draft IP Mobility and Multi-homing Interations July 2007 +---------+---------------+--------------+-------+---------- | S=NCoA | S=LCoA(=PCoA) | S=CoA(=RCoA) | S=HoA | Payload | D=PAR | D=MAP | D=HA | D=CN | +---------+---------------+--------------+-------+---------- Figure 5: Packet Tunneling with MIP, HMIP, and FMIP A simple superimposition of all protocols (i.e. when the three protocols are in use) would lead the mobile node to perform signaling for FMIP and HMIP upon handoff within a given local network and for FMIP, HMIP and MIP upon handoff across local networks. However, there are other modes of integration that would not result in such inefficiency. For instance, HMIP and FMIP can be combined such that binding updates are only sent to the MAP, while FMIP is used to anticipate the movement of the mobile node. This would eliminate the tunnel between the old and new AR. 6.1.1.1. Security Implications In this model, the mobile node is responsible for all of the signaling. Each protocol requires a specific security association that is tied with the address for which the binding needs to be created. This ensures that the mobile node cannot redirect traffic meant for some other node. When all the three protocols are in use, this implies that the mobile node may share a Security Association with the PAR tied to the PCoA, which is also the HMIP LCoA, a Security Association with the MAP tied to the RCoA (which is also the MIP Care-of-Address), and a Security Association with the Home Agent tied to the Home Address. Depending on the choice of security protocol used by each of these mobility management protocols, these security associations may be IPsec security associations or something else. However, as mentioned above the security association between the MN and any AR can be eliminated in this configuration. 6.1.1.2. Multihoming Implications The mobile node may be attached to multiple Access Routers, thereby having multiple LCoAs. The mobile node may register multiple LCoAs with the MAP in that case. Further, the mobile node may actually be attached to multiple MAPs (if there are overlapping MAP regions as described in Section 6.1.1.3), in which case, it possesses multiple RCoAs. The mobile node may then use MIP to register multiple Care- of-Addresses (each RCoA would be registered as a MIP Care-of-Address) with the Home Agent. Multihoming with connectivity to multiple Home Agents is discussed in Section 6.1.3. Narayanan, et al. Expires January 6, 2008 [Page 23] Internet-Draft IP Mobility and Multi-homing Interations July 2007 6.1.1.3. Other Analysis It is important to look at system requirements before determining whether all the protocols are needed. For many practical needs of mobile nodes, it is possible that only a subset of these protocols are needed. For instance, both FMIP and HMIP address the latency involved in MIP registrations - FMIP allows reception of packets at new location before the registration with the Home Agent completes. HMIP ensures that the MIP registrations need not be that frequent - hence, the latency really comes into play only upon crossing MAP boundaries. If something like FMIP is needed for fast handoff purposes anyway, HMIP may not be needed as an intermediate level of mobility management. Depending on the location of the MAP and the kind of interconnectivity that is present between the Access Routers, it may also be the case that the latency involved in HMIP registrations and FMIP tunnel setup are comparable. In such cases, it may be feasible to avoid the use of FMIP in the system. The use of HMIP permits a not-so-transient local address (RCoA) that can be used for communication. When there is no need for a really long-lived IP address, it may not be necessary to have a global mobility management mechanism. This basically allows the data path latency to be lower, since the MAP is meant to be geographically closer to the mobile node. When Route Optimization is used for MIP, this data path latency is not an issue. However, even when Route Optimization is used, HMIP is useful to ensure that frequent registrations with the correspondent node are not needed. Registrations with the correspondent node will need to be modified only upon handoff to a new MAP. In reality, the local network regions managed by MAPs is likely to be overlapping, in which case, make-before-break HMIP transitions can be made. This is especially feasible with HMIP, since there is no requirement on trust relationships between the Access Routers and the MAP. Once the mobile node possesses a security association with the MAP, it can register any LCoA with it. The overlapping MAP boundaries may be indicative of a geographically closer MAP, implying a MAP transition for more optimal communication. Such an overlap provides the mobile node the opportunity to bootstrap the HMIP session with the new MAP before switching the data path to it. However, this places a requirement on the mobile node to be able to handle multiple HMIP sessions simultaneously for a short period of time. It must be noted that an overlap is harder for inter-administrative domains, since even though there is no trust relationship requirement between the Access Routers and the MAPs, the Access Routers are required to advertise the presence of the MAPs to the mobile nodes. When the three protocols are all used, the mobile node has several IP addresses to choose from for communication purposes. For really Narayanan, et al. Expires January 6, 2008 [Page 24] Internet-Draft IP Mobility and Multi-homing Interations July 2007 long-lived connections, it is always better to use the most permanent IP address - this would be the Home Address of the mobile node. However, the mobile node may be running some latency sensitive applications that are not necessarily long-lived. Voice over IP is one such application. In those cases, tunneling all the data packets through the Home Agent may introduce unacceptable latency for the application. When Route Optimization is used, it is feasible to avoid such tunneling - however, route optimization support may not be available and it may also be considered expensive in some cases. For such cases, it would be an option to use the HMIP RCoA as the IP address for applications. Especially in situations of overlapping HMIP coverage as discussed above, the transition from one HMIP RCoA to another may be made seamlessly via SIP Re-Invite messages for the purposes of applications such as VoIP. Such a transition would be needed when the application persists while the mobile node is moving across MAP boundaries. It is also feasible to continue keeping the association with the old MAP until the end of the application, if it was going to only be short-lived. 6.1.2. MIP and MOBIKE One method of combining MIP and MOBIKE is described for MIP4 in [12]. In that model, MIP is used for mobility inside a given secure network, while MOBIKE with a VPN gateway is used for mobility outside the secure network. The general goal there is to allow enterprise mobile devices to keep the same IP address while roaming in and out of the enterprise network. There are other possible combinations as well. There is the question of the usefulness of MOBIKE when MIP6 is employed. MIP6 inherently provides a means of updating the IKE endpoint IP address when the mobile node registers a new Care-of- Address for itself. This functionality is supported by indicating the need for dynamic key management in the MIP6 binding update sent by the mobile node with a new Care-of-Address. This is functionality that would be duplicated by MOBIKE if both protocols were to be used in conjunction. By using a MIP6 Home Agent as also a VPN gateway, it is then feasible to just use MIP6 for mobility and still provide protected access. However, in addition to allowing changes to the local IP address of the initiator (typically the MIP6 mobile node), MOBIKE also allows the responder (typically the MIP6 Home Agent) to be multihomed and change the IP address used in a security association - this is not functionality supported by MIP6. Hence, depending on the requirements, it may make sense to run MIP6 and MOBIKE together or not in a given system. Further, if the goal is to provide support for mobile devices roaming in and out of enterprise networks, it is likely that both protocols Narayanan, et al. Expires January 6, 2008 [Page 25] Internet-Draft IP Mobility and Multi-homing Interations July 2007 are needed, unless detection of protected vs. unprotected network can happen through other means. This is due to the fact that in the MIP6-only mode, the Home Agent is made reachable from inside and outside the protected network. Hence, if the policy to use IPsec for data traffic only applies when the client is outside the protected network, the client must be able to securely determine whether it is attached to the protected network or not. If not, an impersonating element in the access network will successfully cause the mobile node to send sensitive data without any protection. In the model described in [12], the Home Agent is not reachable from an external network and hence, that provides a rather secure means of ensuring that unprotected data exchange does not occur while the MN is attached to an untrusted network. Future revisions of this document will address this kind of combination in greater detail. 6.1.2.1. Security Implications As in the case of multi-level node-based IP mobility management, this mechanism also requires the mobile node to possess appropriate security associations with the Home Agent and the VPN gateway performing MOBIKE. The security association for MIP must be tied to the home address, while the IPsec selectors for the security association created or modified using MOBIKE will depend on the type of protection that is intended using that SA. Additionally, the security of the internal IP addressing semantics of a protected network may be important to consider while designing a solution that requires both VPNs and mobility support. For example, the VPN gateway, in many networks, is the only reachable device from an unprotected network. If a MIP6 Home Agent was made reachable from an external network, it may be exposed to additional threats than the case where the Home Agent is "behind" the VPN gateway and only accessible from the protected network. Also, another consideration while deciding to choose between a MIP6-only with data protection and a combined MIP6-MOBIKE solution with separate VPN gateway and Home Agent, is ensuring the ability to securely detect the connectivity to an untrusted network to avoid sending unprotected sensitive data over the untrusted network. An alternative would be to always require that data be sent in a protected manner, irrespective of the location of the mobile node. However, that adds a lot of load on the Home Agent/VPN Gateway device to process a lot more protected traffic and is often unnecessary. Narayanan, et al. Expires January 6, 2008 [Page 26] Internet-Draft IP Mobility and Multi-homing Interations July 2007 6.1.3. MIP and SHIM6 As described in Section 3, MIP and SHIM6 can either be deployed in a complementary or competing fashion. The mobile node may be multi- addressed in the local networks by virtue of either the local network being multi-homed or attaching to multiple local networks. In such cases, if MIP is employed to handle mobility, it is easier for the local multi-addressing to be handled as part of mobility. In other words, the mobile node may register multiple Care-of-Addresses tied to the same Home Address with the HA. The mobile node may then use any Care-of-Address to send or receive data. However, when the mobile node is multi-addressed with IP addresses from multiple home networks, even if MIP is used in each home network, it only ties each Home Address with one or more of the Care- of-Addresses that the mobile node possesses. So, while multiple Home Addresses can each be bound to multiple (same or different) Care-of- Addresses, MIP does not facilitate tying the Home Addresses itself together. This is due to the fact that MIP requires a central entity (Home Agent) for address mappings and each such entity can only handle IP addresses belonging to it. SHIM6 is a potential solution to handle such multihoming. Using SHIM6, both Home Addresses can be tied together by providing a common ULID to a correspondent node. Hence, the correspondent nodes may reach the mobile node via either Home Addresses, and this helps to ensure reachability even when one of the home networks is down. Some of this concept is covered in [13]. Future revisions of this document will provide more details. 6.1.4. MIP and HIP TBD 6.1.5. SHIM6 and MOBIKE TBD 6.1.6. SHIM6 and HIP TBD 6.1.7. HIP and MOBIKE TBD 6.1.8. MIP, SHIM6 and HIP TBD Narayanan, et al. Expires January 6, 2008 [Page 27] Internet-Draft IP Mobility and Multi-homing Interations July 2007 6.2. Node-based and Network-based Mobility ---------- | HA | ---------- / \ / \ Home Network -------------------------------|--------------------------------- Local Network 1 / | \ Local Network 2 / | \ --------- | ---------- | LMA1 | | | LMA2 | --------- | ---------- /\ | /\ / \ | / \ / \ | / \ / \ | / \ / \ | / \ ------- ------- | ------- ------- | MAG11 | ... | MAG1n | | | MAG21 | ... | MAG2n | ------- ------- | ------- ------- | | | | ------ | | MN | ----> | ------ | | Figure 6: MIP and NETLMM This section describes how node-based global mobility and network- based local mobility can co-exist in an architecture. Figure 6 shows an architecture that has a MIP Home Agent as part of the home network and network-based mobility entities, LMA and MAG in the local network. Network-based mobility discussions in this section apply equally to solutions described in [14], [15], and [16]. The term NetLMM is used to refer to any of these solutions in a generic manner. Figure 6 shows the architectural entities involved in the two protocols. While this is architecturally similar to the MIP/HMIP overlay described in Section 6.1.1, there are some significant Narayanan, et al. Expires January 6, 2008 [Page 28] Internet-Draft IP Mobility and Multi-homing Interations July 2007 differences arising due to the fact that the local mobility here happens without mobile node involvement. Conceptually, there are similarities between this model and the MIP/ HMIP overlay model. The MAP and LMA are equivalent in function and scope - the LMA keeps track of the mobility of the mobile node within the local network. However, an important difference is that local mobility is achieved here by preserving the same local address for the mobile node within the local network, as described in Section 4.2. The mobile node may register such a local address anchored at the LMA as its Care-of-Address with the Home Agent - MIP updates are then only necessary when the mobile node associates with a new LMA. As in the case of the MIP/HMIP overlay, it is feasible to have one of the local networks as the Mobile IP home network of the mobile node. In such a case, the LMA and Home Agent for a given mobile node would be collocated in that local network and the mobile node would be "home" from a MIP perspective while attached to that network. MIP operation is then only needed when the mobile node is not attached to that network. However, this model has some security implications that are worth noting and those are captured in Section 6.2.1. In addition to the security implications, this model may also lead to some race conditions which are analyzed in Section 6.2.4. As the mobile node moves within a local network, its current location will be updated at the LMA by the appropriate MAG. A separate protocol between the mobile node and the MAG may be employed to detect the attachment of an mobile node to a MAG. Alternately, some technologies may allow mobile node movement detection at the network and trigger a context transfer between MAGs to provide the necessary information to complete the new location registration. 6.2.1. Security Implications The node-based mobility here is handled by the mobile node and Home Agent and the network-based mobility is handled by the MAG and LMA. The mobile node needs to possess a security association with the Home Agent tied to its Home Address for MIP operation, as is normally the case. For the NetLMM operation, there must be a Security Association between the MAG and the LMA. This security association provides the needed data origin authentication. However, it does not guarantee the attachment of the mobile node with that particular MAG. Without mobile node involvement or some authorization checks involving an entity such as a AAA server, it is not feasible to provide any guarantees about the actual presence of the mobile node at that MAG. Hence, a malfunctioning or compromised MAG would be able to redirect traffic meant for that mobile node by creating an incorrect binding Narayanan, et al. Expires January 6, 2008 [Page 29] Internet-Draft IP Mobility and Multi-homing Interations July 2007 at the LMA. However, such a threat can be limited in scope by ensuring that a MAG is only capable of updating bindings for addresses that are valid in that local domain. This requires appropriate prefix partitioning and verification of the address claimed by the LMA for the mobile node against the prefix it is authorized to serve. In such a case, the MAG would be unable to redirect traffic of an mobile node that is not within its local network. An additional security implication is when one of the local networks is considered to be the MIP home network, making the local address acquired by the mobile node in that network its MIP Home Address. In this case, while the mobile node is within that domain, the security risks are analogous to what has been described so far. However, it is feasible for a MAG to redirect traffic belonging to a mobile node even when the mobile node is no longer in that local network. Even if the redirection is not successful in some cases, it is capable of leading to ambiguity in mobile node's current location at the LMA/ Home Agent. This is due to the fact that the MAG and the mobile node are both authorized to perform updates corresponding to the same IP address. This would basically result in the security guarantees of MIP being affected by the use of NetLMM. Such a threat may be mitigated by requiring the LMA to reject any updates to the mobile node's local address (which is the same as the Home Address in this case) by a MAG when there is an existing binding for that address created by the mobile node. However, this leads to some undesirable inter-dependencies between the two protocols and also may lead to less than ideal mobility management, as described in Section 6.2.4. 6.2.2. Multihoming Implications Unlike the HMIP case, multi-homing at the local networks level cannot be handled by the NetLMM class of solutions. For instance, the mobile node may be multihomed by virtue of attachment to two MAGs within the same LMA or under different LMAs. An IP node will obtain a distinct global IP address on each of its interfaces (physical or virtual) - hence, if the mobile node is attached to two MAGs at any given time, it will acquire separate IP addresses. NetLMM provides mobility to each IP address and by itself, has no means of tying the multiple IP addresses to the same mobile node. Hence, mobility for these IP addresses will be handled independently by default. However, certain technologies may have the capability to identify (say, via L2 mapping) that a given set of IP addresses belong to the same mobile node. In such a case, it is feasible for this to be known at the LMA. However, even so, it is not feasible for these IP addresses to be associated with any per-packet identifier. Unlike the ULID in SHIM6 or RCoA in HMIP, NetLMM does Narayanan, et al. Expires January 6, 2008 [Page 30] Internet-Draft IP Mobility and Multi-homing Interations July 2007 not have anything available for the mobile and correspondent nodes to use for communication. Extracting from the above, in terms of data flow, these addresses are practically independent and the ability to correlate multiple IP addresses belonging to the same mobile node at the LMA is of little use. In other words, it is unlike the case where the correspondent nodes pick one IP address of the mobile node to get the data to the LMA, with multiple possible paths available to the mobile node from there. In this case, the correspondent node and the mobile node need to pick a particular mobile node address to correspond with. Note that when MIP is used, this correspondent node may actually be the Home Agent. Hence, when the mobile node has multiple IP addresses, the decision of picking an address to correspond with is still left to the application and not handled by NetLMM. Extending this analysis to multihoming for mobile nodes with multi- radio capabilities, it is not even feasible for the network to provide any correlation between IP addresses of the mobile node, given that there is no common L2 identifier. With involvement on the mobile node's part, it may be feasible to obtain an access agnostic identity to correlate with the multiple IP addresses. However, that would be defeating one of the motivations of having network-based mobility transparent to the mobile node. It is conceivable that the same global IP address is assigned to the mobile node for multiple interfaces - however, that requires a fundamental change to the functioning of regular IP nodes. Further, it also places restrictions on the simultaneous use of such multiple interfaces. It also requires intelligence below the IP layer to pick the correct interface for different packets sent with the same IP address, which would typically not be needed. The above analysis leads to the following conclusions. o Without an out-of-band mechanism, it is not feasible for the MAG or LMA to correlate multiple IP addresses as belonging to the same mobile node. o Even with such correlation, there is no means of presenting a single IP address to applications with multiple paths over the network. Hence, applications are exposed to multiple IP addresses by default. o Providing the same global IP address to multiple interfaces would require undesirable changes to mobile nodes and places restrictions on simultaneous use of the interfaces. Narayanan, et al. Expires January 6, 2008 [Page 31] Internet-Draft IP Mobility and Multi-homing Interations July 2007 By this analysis, it appears that network-based mobility management is not well-suited to handle any kind of multi-homing of a mobile node. The mobile node is in the best position to determine the availability and connection capabalities of its various interfaces and hence, multi-addressing and multi-homing is best handled using node-based mobility management. 6.2.3. Network-based mobility for non-MIP nodes We have analyzed the co-existence of node and network-based mobility for a given mobile node for two-level mobility management thus far. The other model is where network-based mobility is only intended for nodes that are incapable of mobility management on their own, such as legacy mobile devices. In that case, a given network must support network-based mobility for such devices and let other mobile nodes handle their own mobility. In the NetLMM class of solutions, the entire local network is made to appear as having the same IP prefix - this is achieved by advertising the same prefix to the mobile node as it moves within the local network. By virtue of such a protocol, it is not feasible to differentiate between MIP-capable and non-MIP- capable endpoints using functionality provided in the protocol itself. Such detection is only feasible via some out-of-band mechanism. In some systems, it may be feasible for the network to know the capabilities of the nodes that attach to it. If the network is aware of the capabilities, it would be feasible to present an unchanging IP address or prefix throughout the local network only to devices that need network-based mobility. 6.2.4. Other Analysis This section provides additional analysis on the scenario where network-based local mobility is used on the mobile node's home network to make the entire local network appear to the mobile node as its Mobile IP home network. Section 6.2.1 describes the security implications of the model and shows that it is essential to ensure that a network-based mobility binding for the mobile node's Home Address is only accepted when there is no current binding for that address created by the mobile node itself. That will ensure that the MIP security guarantees are still available to the mobile node. However, that may lead to a less than ideal mobility solution for the mobile node. It is possible that a registration from the network node arrives at the entity serving as the LMA/Home Agent before the mobile node has a chance to de-register with the Home Agent. In that case, such a registration will be rejected until the mobile node is successfully de-registered from a MIP perspective and its binding is removed at the Home Agent. This may result in undesirable handoff latency for the mobile node, when the mobile node is moving in and out of its home network. Narayanan, et al. Expires January 6, 2008 [Page 32] Internet-Draft IP Mobility and Multi-homing Interations July 2007 This further introduces the need for some inter-dependency between the node and network-based mobility protocols. Specifically, the NetLMM solution must be able to detect the presence of a MIP binding for a given IP address before accepting a certain registration for an mobile node. When the NetLMM solution used is PMIP, this may be less painful - nevertheless, it is still undesirable behavior. Overall, systems evaluating such an approach must take such shortcomings into account before using it. The use of this approach allows data exchange in this extended home network without additional tunnel overhead (as MIP6 would have) between the mobile node and the Access Router. It is important to evaluate the need for this, along with the other solutions such as header compression (say, RoHC) that may be deployed in the system. RoHC, for instance handles two IP headers as easily as it does one - hence, if RoHC is needed anyway, the tradeoffs of using this approach may not be worth it. 7. Security Considerations For security considerations on the protocols described in this document, please refer to the appropriate protocol documents. For the architectural combinations described here, security implications have been discussed in the corresponding sections. Future revisions of this document will have a more comprehensive security analysis. 8. IANA Considerations This document has no actions for IANA. 9. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-soliman-monami6-flow-binding-04 (work in progress), March 2007. [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. Narayanan, et al. Expires January 6, 2008 [Page 33] Internet-Draft IP Mobility and Multi-homing Interations July 2007 [5] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007. [6] El Malki, K., "Low-Latency Handoffs in Mobile IPv4", RFC 4881, June 2007. [7] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-05 (work in progress), March 2007. [8] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-05 (work in progress), June 2006. [9] Thaler, D., "Multilink Subnet Issues", draft-iab-multilink-subnet-issues-03 (work in progress), January 2007. [10] Tsirtsis, G., "Dual Stack Mobile IPv4", draft-ietf-mip4-dsmipv4-02 (work in progress), May 2007. [11] Soliman, H., "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-04 (work in progress), March 2007. [12] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE", draft-ietf-mip4-mobike-connectivity-03 (work in progress), March 2007. [13] Bagnulo, M. and J. Abley, "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", draft-ietf-shim6-applicability-02 (work in progress), October 2006. [14] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-02 (work in progress), March 2007. [15] Bedekar, A., "A Protocol for Network-based Localized Mobility Management", draft-singh-netlmm-protocol-02 (work in progress), March 2007. [16] Giaretta, G., "The NetLMM Protocol", draft-giaretta-netlmm-dt-protocol-02 (work in progress), October 2006. [17] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in Narayanan, et al. Expires January 6, 2008 [Page 34] Internet-Draft IP Mobility and Multi-homing Interations July 2007 IPv6", RFC 3775, June 2004. [18] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [19] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [20] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work in progress), April 2007. [21] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", draft-ietf-mip4-fmipv4-07 (work in progress), May 2007. [22] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work in progress), September 2006. [23] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-02 (work in progress), March 2007. Authors' Addresses Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Email: vidyan@qualcomm.com Dave Thaler Microsoft One Microsoft Way Redmond, WA USA Email: dthaler@microsoft.com Narayanan, et al. Expires January 6, 2008 [Page 35] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Marcelo Bagnulo Huawei Lab at UC3M Email: marcelo@it.uc3m.es Hesham Soliman Elevate Technologies Email: Hesham@elevatemobile.com Narayanan, et al. Expires January 6, 2008 [Page 36] Internet-Draft IP Mobility and Multi-homing Interations July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Narayanan, et al. Expires January 6, 2008 [Page 37]