Internet Draft J. Kempf, Editor Document: draft-ietf-netlmm-nohost-req-04.txt August, 2006 Expires: Feburary, 2007 Goals for Network-based Localized Mobility Management (NETLMM) (draft-ietf-netlmm-nohost-req-04.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. Contributors Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and Marco Liebsch all contributed major effort to this document. Their names are not included in the authors' section due to the RFC Editor's limit of 5 names. Abstract In this document, design goals for a network-based localized mobility management protocol are discussed. Table of Contents 1.0 Introduction............................................2 2.0 Goals for Localized Mobility Management.................2 3.0 IANA Considerations....................................10 4.0 Security Considerations................................10 5.0 Acknowledgements.......................................11 Kempf, editor Expires December, 2006 [Page 1] Internet Draft NETLMM Goals June, 2006 6.0 Author's Addresses.....................................11 7.0 Informative References.................................12 8.0 Appendix: Gap Analysis.................................13 9.0 IPR Statements.........................................23 10.0 Disclaimer of Validity.................................23 11.0 Copyright Notice.......................................23 1.0 Introduction In [9], the basic problems that occur when a global mobility protocol is used for managing local mobility are described, and two basic approaches to localized mobility management - the host-based approach that is used by most IETF protocols, and the proprietary WLAN switch approach used between WLAN switches in different subnets - are examined. The conclusion from the problem statement document is that none of the approaches has a complete solution to the problem. While the WLAN switch approach is most convenient for network operators and users because it requires no software on the mobile node other than the standard drivers for WiFi, the proprietary nature limits interoperability and the restriction to a single wireless link type and wired backhaul link type restricts scalability. The IETF host-based protocols require host software stack changes that may not be compatible with all global mobility protocols, and also require specialized and complex security transactions with the network that may limit deployability. The use of an IGP to distribute host routes has scalability and deployment limitations. This document develops more detailed goals for a network-based localized mobility management protocol. In Section 2.0, we review a list of goals that are desirable in a network-based localized mobility management solution. Section 3.0 briefly outlines security considerations. More discussion of security can be found in the threat analysis document [20]. The architecture of the NETLMM protocol for which the goals in this document have been formulated is described in Section 5 of [9]. 1.1 Terminology Mobility terminology in this draft follows that in RFC 3753 [13] and in [9]. 2.0 Goals for Localized Mobility Management Section 2 of [9] describes three problems with using a global mobility management protocol for localized mobility management. Any localized mobility management protocol must naturally address these three problems. In addition, the side effects of introducing such a solution into the network need to be limited. In this section, we address goals on a localized mobility solution including both Kempf, editor Expires December 2006 [Page 2] Internet Draft NETLMM Goals June, 2006 solving the basic problems (Goals 1, 2, 3) and limiting the side effects (Goals 4+). Some basic goals of all IETF protocols are not discussed in detail here, but any solution is expected to satisfy them. These goals are fault tolerance, robustness, interoperability, scalability, and minimal specialized network equipment. A good discussion of their applicability to IETF protocols can be found in [3]. Out of scope for the initial goals discussion are QoS, multicast, and dormant mode/paging. While these are important functions for mobile nodes, they are not part of the base localized mobility management problem. In addition, mobility between localized mobility management domains is not covered here. It is assumed that this is covered by the global mobility management protocols. 2.1 Handover Performance Improvement (Goal #1) Handover packet loss occurs because there is usually latency between when the wireless link handover starts and when the IP subnet configuration and global mobility management signaling completes. During this time the mobile node is unreachable at its former topological location on the old link where correspondents are sending packets and to which they are being forwarded. Such misrouted packets are dropped. This aspect of handover performance optimization has been the subject of an enormous amount of work, both in other SDOs, to reduce the latency of wireless link handover, in the IETF and elsewhere, to reduce the latency in IP handover. Many solutions to this problem have been proposed at the wireless link layer and at the IP layer. One aspect of this goal for localized mobility management is that the processing delay for changing the forwarding after handover must approach as closely as possible the sum of the delay associated with link layer handover and the delay required for active IP layer movement detection, in order to avoid excessive packet loss. Ideally, if network-side link layer support is available for handling movement detection prior to link handover or as part of the link handover process, the routing update should complete within the time required for wireless link handover. This delay is difficult to quantify, but for voice traffic, the entire handover delay including Layer 2 handover time and IP handover time should be between 40-70 ms to avoid any degradation in call quality. A goal of the protocol is to reduce the loss of accurate forwarding to reduce interruptions which may cause user-perceptible service degradation for real time traffic such as voice. 2.2 Reduction in Handover-related Signaling Volume (Goal #2) Considering Mobile IPv6 as the global mobility protocol (other mobility protocols require about the same or somewhat less), if a mobile node using address autoconfiguration is required to Kempf, editor Expires December 2006 [Page 3] Internet Draft NETLMM Goals June, 2006 reconfigure on every move between links, the following signaling must be performed: 1) Link layer signaling required for handover and reauthentication. For example, in 802.11 [6] this is the Reassociate message together with 802.1x [7] reauthentication using EAP. 2) Active IP level movement detection, including router reachability. The DNA protocol [4] uses Router Solicitation/Router Advertisement for this purpose. In addition, if SEND [1] is used and the mobile node does not have a certificate cached for the router, the mobile node must use Certification Path Solicitation/Certification Path Advertisement to obtain a certification path. 3) Two Multicast Listener Discovery (MLD) [19] REPORT messages, one for each of the solicited node multicast addresses corresponding to the link local address and the global address, 4) Two Neighbor Solicitation (NS) messages for duplicate address detection, one for the link local address and one for the global address. If the addresses are unique, no response will be forthcoming. 5) Two NS messages from the router for address resolution of the link local and global addresses, and two Neighbor Advertisement messages in response from the mobile node, 6) Binding Update/Binding Acknowledgement between the mobile node and home agent to update the care of address binding, 7) Return routability signaling between the correspondent node and mobile node to establish the binding key, consisting of one Home Test Init/Home Test and Care of Test Init/Care of Test, 8) Binding Update/Binding Acknowledgement between the correspondent node and mobile node for route optimization. Note that Steps 1-2 may be necessary, even for intra-link mobility, if the wireless link protocol doesn't provide much help for IP handover. Step 3-5 will be different if stateful address configuration is used, since additional messages are required to obtain the address. Steps 6-8 are only necessary when Mobile IPv6 is used. The result is approximately 18 messages at the IP level, where the exact number depends on various specific factors such as whether the mobile node has a router certificate cached or not, before a mobile node can be ensured that it is established on a link and has full IP connectivity. The goal is that handover signaling volume from the mobile node to the network should be no more than what is needed for the mobile node to perform secure IP level movement detection, in cases where no link layer support exists. If link layer support exists for IP level movement detection, the mobile node may not need to perform any additional IP level signaling after handover. 2.3 Location privacy (Goal #3) Kempf, editor Expires December 2006 [Page 4] Internet Draft NETLMM Goals June, 2006 Although location privacy issues for Mobile IPv6 have been discussed in [12], the location privacy referred to here focuses on the IP layer. In most wireless IP network deployments, different IP subnets are used to cover different geographical areas. It is therefore possible to derive a topological to geographical map, in which particular IPv6 subnet prefixes are mapped to particular geographical locations. The precision of the map depends on the size of the geographic area covered by a particular subnet: if the area is large, then knowing the subnet prefix won't provide much information about the precise geographical location of a mobile node within the subnet. When a mobile node moves geographically, it also moves topologically between subnets. In order to maintain routability, the mobile node must change its local IP address when it moves between subnets. If the mobile node sources packets with its local IP address in the clear, for example through route optimization in Mobile IPv6, the correspondent node or an eavesdropper can use the topological to geographical map to deduce in real time where a mobile node - and therefore its user - is located. Depending on how precisely the geographical location can be deduced, this information could be used to compromise the privacy or even cause harm to the user. The geographical location information should not be revealed to nor be deducible by the correspondent node or an eavesdropper without the authorization of the mobile node's owner. The threats to location privacy come in a variety of forms. One is a man in the middle attack in which traffic between a correspondent and the mobile node is intercepted and the mobile node's location is deduced from that. Others are attacks in which the correspondent itself is the attacker, and the correspondent deliberately starts a session with the mobile node in order to track its location by noting the source address of packets originating from the mobile node. Note that the location privacy referred to here is different from the location privacy discussed in [12]. The location privacy discussed in these drafts primarily concerns modifications to the Mobile IPv6 protocol to eliminate places where an eavesdropper could track the mobile node's movement by correlating home address and care of address. In order to reduce the risk from location privacy compromises as a result of IP address changes, the goal for NETLMM is to remove the need to change IP address as mobile node moves across links. Keeping the IP address fixed removes any possibility for the correspondent node to deduce the precise geographic location of the mobile node without the user's authorization. Note that keeping the address constant doesn't completely remove the possibility of deducing the geographical location, since a local address still is required. However, it does allow the network to be deployed such that the mapping between the geographic and topological location is considerably less precise. If the mapping is not precise, an attacker can only deduce in real time that the mobile node is Kempf, editor Expires December 2006 [Page 5] Internet Draft NETLMM Goals June, 2006 somewhere in a large geographic area, like, for example, a metropolitan region or even a small country, reducing reducing the granularity of the location information. 2.4 Efficient Use of Wireless Resources (Goal #4) Advances in wireless physical layer and medium access control layer technology continue to increase the bandwidth available from limited wireless spectrum, but even with technology increases, wireless spectrum remains a limited resource. Unlike wired network links, wireless links are constrained in the number of bits/Hertz by their coding technology and use of physical spectrum, which is fixed by the physical layer. It is not possible to lay an extra cable if the link becomes increasingly congested as is the case with wired links. While header compression technology can remove header overhead, it does not come without cost. Requiring header compression on the wireless access points increases the cost and complexity of the access points, and increases the amount of processing required for traffic across the wireless link. Header compression also requires special software on the host, which may or may not be present. Since the access points tend to be a critical bottleneck in wireless access networks for real time traffic (especially on the downlink), reducing the amount of per-packet processing is important. While header compression probably cannot be completely eliminated, especially for real time media traffic, simplifying compression to reduce processing cost is an important goal. The goal is that the localized mobility management protocol should not introduce any new signaling or increase existing signaling over the air. 2.5 Limit the Signaling Overhead in the Network (Goal #5) While bandwidth and router processing resources are typically not as constrained in the wired network, access networks tend to have somewhat stronger bandwidth and router processing constraints than the backbone. These constraints are a function of the cost of laying fiber or wiring to the wireless access points in a widely dispersed geographic area. Therefore, any solutions for localized mobility management should minimize signaling within the wired network as well. 2.6 No Extra Security Between Mobile Node and Network (Goal #6) Localized mobility management protocols that have signaling between the mobile node and network require a security association between the mobile node and the network entity that is the target of the signaling. Establishing a security association specifically for localized mobility service in a roaming situation may prove difficult, because provisioning a mobile node with security Kempf, editor Expires December 2006 [Page 6] Internet Draft NETLMM Goals June, 2006 credentials for authenticating and authorizing localized mobility service in each roaming partner's network may be unrealistic from a deployment perspective. Reducing the complexity of mobile node to network security for localized mobility management can therefore reduce barriers to deployment. If the access router deduces mobile node movement based on active IP-level movement detection by the mobile node, then authentication is required for the IP-level movement detection messages from the mobile node to ensure that the mobile node is authorized to possess the address used for the movement detection. The authorization may be at the IP level or it may be tied to the original network access authentication and wireless link layer authorization for handover. Some wireless link layers, especially cellular protocols, feature full support and strong security for handover at the link level, and require no IP support for handover. If such wireless link security is not available, however, then it must be provided at the IP level. Security threats to the NETLMM protocol are discussed in [20]. In summary, ruling out mobile node involvement in local mobility management simplifies security by removing the need for service- specific credentials to authenticate and authorize the mobile node for localized mobility management in the network. This puts localized mobility management on the same level as basic IP routing. Hosts obtain this service as part of their network access. The goal is that support for localized mobility management should not require security between the mobile node and the network other than that required for network access or local link security (such as SEND [1]). 2.7 Wireless Link Technology Agnostic (Goal #7) The number of wireless link technologies available is growing, and the growth seems unlikely to slow down. Since the standardization of a wireless link physical and medium access control layers is a time consuming process, reducing the amount of work necessary to interface a particular wireless link technology to an IP network is necessary. A localized mobility management solution should ideally require minimal work to interface with a new wireless link technology. In addition, an edge mobility solution should provide support for multiple wireless link technologies. It is not required that the localized mobility management solution support handover from one wireless link technology to another without change in IP address, but this possibility should not be precluded. The goal is that the localized mobility management protocol should not use any wireless link specific information for basic routing Kempf, editor Expires December 2006 [Page 7] Internet Draft NETLMM Goals June, 2006 management, though it may be used for other purposes, such as identifying a mobile node. 2.8 Support for Unmodified Mobile Nodes (Goal #8) In the wireless LAN switching market, no modification of the software on the mobile node is required to achieve localized mobility management. Being able to accommodate unmodified mobile nodes enables a service provider to offer service to as many customers as possible, the only constraint being that the customer is authorized for network access. Another advantage of minimizing mobile node software for localized mobility management is that multiple global mobility management protocols can be supported. There are a variety of global mobility management protocols that might also need support, including proprietary or wireless link technology-specific protocols needing support for backward compatibility reasons. Within the Internet, both HIP [14] and Mobike [5] are likely to need support in addition to Mobile IPv6, and Mobile IPv4 support may also be necessary. Note that this goal does NOT mean that the mobile node has no software at all associated with mobility or wireless. The mobile node must have some kind of global mobility protocol if it is to move from one domain of edge mobility support to another and maintain session continuity, although no global mobility protocol is required if the mobile node only moves within the coverage area of the localized mobility management protocol or no session continuity is required during global movement. Also, every wireless link protocol requires handover support on the mobile node in the physical and medium access control layers, typically in the wireless interface driver. Information passed from the medium access control layer to the IP layer on the mobile node may be necessary to trigger IP signaling for IP handover. Such movement detection support at the IP level may be required in order to determine whether the mobile node's default router is still reachable after the move to a new access point has occurred at the medium access control layer. Whether or not such support is required depends on whether the medium access control layer can completely hide link movement from the IP layer. For a wireless link protocol such as the 3G protocols, the mobile node and network undergo an extensive negotiation at the medium access control layer prior to handover, so it may be possible to trigger routing update without any IP protocol involvement. However, for a wireless link protocol such as IEEE 802.11 in which the decision for handover is entirely in the hands of the mobile node, IP layer movement detection signaling from the mobile node may be required to trigger a routing update. The goal is that the localized mobility management solution should be able to support any mobile node that joins the link and that has Kempf, editor Expires December 2006 [Page 8] Internet Draft NETLMM Goals June, 2006 a wireless interface that can communicate with the network, without requiring localized mobility management software on the mobile node. 2.9 Support for IPv4 and IPv6 (Goal #9) While most of this document is written with IPv6 in mind, localized mobility management is a problem in IPv4 networks as well. A solution for localized mobility that works for both versions of IP is desirable, though the actual protocol may be slightly different due to the technical details of how each IP version works. From Goal #8 (Section 2.8), minimizing mobile node support for localized mobility means that ideally no IP version-specific changes would be required on the mobile node for localized mobility, and that global mobility protocols for both IPv4 and IPv6 should be supported. Any IP version-specific features would be confined to the network protocol. 2.10 Re-use of Existing Protocols Where Sensible (Goal #10) Many existing protocols are available as Internet Standards upon which the NETLMM protocol can be built. The design of the protocol should have a goal to re-use existing protocols where it makes architectural and engineering sense to do so. The design should not, however, attempt to re-use existing protocols where there is no real architectural or engineering reason. For example, the suite of Internet Standards contains several good candidate protocols for the transport layer, so there is no real need to develop a new transport protocol specifically for NETLMM. Re-use is clearly a good engineering decision in this case, since backward compatibility with existing protocol stacks is important. On the other hand, the network-based, localized mobility management functionality being introduced by NETLMM is a new piece of functionality, and therefore any decision about whether to re-use an existing global mobility management protocol should carefully consider whether re-using such a protocol really meets the needs of the functional architecture for network-based localized mobility management. The case for re-use is not so clear in this case, since there is no compelling backward compatibility argument. 2.11 Localized Mobility Management Independent of Global Mobility Management Localized mobility management should be implementable and deployable independently of any global mobility management protocol. This enables the choice of local and global mobility management to be made independently of particular protocols that are implemented and deployed to solve the two different sorts of mobility management problems. The operator can choose a particular localized mobility management protocol according to the specific features of their access network. It can subsequently upgrade the localized mobility management protocol on its own, without even Kempf, editor Expires December 2006 [Page 9] Internet Draft NETLMM Goals June, 2006 informing the mobile nodes. Similarly, the mobile nodes can use a global mobility management protocol that best suits their requirements, or even not use one at all. Also, a mobile node can move into a new access network without having to check that it understands the localized mobility management protocol being used there. The goal is that the implementation and deployment of the localized mobility management protocol should not restrict, or be restricted by, the choice of global mobility management protocol. 2.12 Configurable Data Plane Forwarding between Mobility Anchor and Access Router Different network operators may require different types of forwarding options between the mobility anchor and the access routers for mobile node data plane traffic. An obvious forwarding option that has been used in past IETF localized mobility management protocols is IP-IP encapsulation for bidirectional tunneling. The tunnel endpoints could be the mobility anchor and the access routers. But other options are possible. Some network deployments may prefer routing-based solutions. Others may require security tunnels using IPsec ESP encapsulation if part of the localized mobility management domain runs over a public access network and the network operator wants to protect the traffic. A goal of the NETLMM protocol is to allow the forwarding between the mobility anchor and access routers to be configurable depending on the particulars of the network deployment. Configurability is not expected to be dynamic as in controlled by the arrival of a mobile node; but rather, configuration is expected to be similar in time scale to configuration for routing. The NETLMM protocol may designate a default forwarding mechanism. It is also possible that additional work may be required to specify the interaction between a particular forwarding mechanism and the NETLMM protocol, but this work is not in scope of the NETLMM base protocol. 3.0 IANA Considerations There are no IANA considerations for this document. 4.0 Security Considerations There are two kinds of security issues involved in network-based localized mobility management: security between the mobile node and the network, and security between network elements that participate in the network-based localized mobility management protocol Security between the mobile node and the network itself consists of two parts: threats involved in localized mobility management in Kempf, editor Expires December 2006 [Page 10] Internet Draft NETLMM Goals June, 2006 general, and threats to the network-based localized mobility management from the host. The first is discussed above in Sections 2.3 and 2.6. The second is discussed in the threat analysis document [20]. For threats to network-based localized mobility management, the basic threat is an attempt by an unauthorized party to signal a bogus mobility event. Such an event must be detectable. This requires proper mutual authentication and authorization of network elements that participate in the network-based localized mobility management protocol, and data origin authentication on the signaling traffic between network elements. 5.0 Acknowledgements The authors would like to acknowledge the following for particularly diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin. 6.0 Author's Addresses James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 Email: kempf@docomolabs-usa.com Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com Phil Roberts Motorola Labs Schaumberg, IL USA Email: phil.roberts@motorola.com Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 Email: nishidak@nttdocomo.co.jp Kempf, editor Expires December 2006 [Page 11] Internet Draft NETLMM Goals June, 2006 Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 Email: gerardo.giaretta@tilab.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 Email: marco.liebsch@ccrle.nec.de 7.0 Informative References [1] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Neighbor Discovery (SEND)", RFC 3971, March, 2005. [2] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., "Design, Implementation and Evaluation of Cellular IP", IEEE Personal Communications, June/July 2000. [3] Carpenter, B., "Architectural Principles of the Internet," RFC 1958, June, 1996. [4] Choi, J, and Daley, G., "Goals of Detecting Network Attachment in IPv6", Internet Draft, Work in Progress. [5] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) specifications", IEEE Std. 802.11, 1999. [7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June, 2001. [8] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6", RFC 3775. [9] Kempf, J., editor, "Problem Statement for IP Local Mobility," Internet Draft, Work in Progress. [10] Kempf, J., and Koodli, R., "Distributing a Symmetric FMIPv6 Handover Key using SEND", Internet Draft, Work in Progress. [11] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 4068, July, 2005. [12] Koodli, R., " IP Address Location Privacy and Mobile IPv6: Problem Statement", Internet Draft, Work in Progress. [13] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753, June, 2004. [14] Moskowitz, R., and Nikander, P., "Host Identity Protocol (HIP) Architecture", RFC 4423, May, 2006. [15] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta, G., and Bournelle, J., "Handover Keys Using AAA", Internet Draft, Work in Progress. Kempf, editor Expires December 2006 [Page 12] Internet Draft NETLMM Goals June, 2006 [16] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., "HAWAII: A domain-based approach for supporting mobility in wide-area wireless networks", in Proceedings of the International Conference on Networking Protocols (ICNP), 1999. [17] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., Levkowetz, H., Thubert, P, and Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) for Hosts and Routers", Internet Draft, Work in Progress. [18] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L., "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August, 2005. [19] Vida, R., and Costa, L., " Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [20] Vogt, C., and Kempf, J., "Security Threats to Network-based Localized Mobillity Management", Internet Draft, Work in Progress. 8.0 Appendix: Gap Analysis This section discusses a gap analysis between existing proposals for solving localized mobility management and the goals in Section. 2.0. 8.1 Mobile IPv6 with Local Home Agent One option is to deploy Mobile IPv6 with a locally assigned home agent in the local network. This solution requires the mobile node to somehow be assigned a home agent in the local network when it boots up. This home agent is used instead of the home agent in the home network. The advantage of this option is that no special solution is required for edge mobility - the mobile node reuses the global mobility management protocol for that purpose - if the mobile node is using Mobile IPv6. The analysis of this approach against the goals above is the following. Goal #1 Handover Performance Improvement: If the mobile node does not perform route optimization, this solution reduces, but does not eliminate, IP handover related performance problems. Goal #2 Reduction in Handover-related Signaling Volume: Similarly to Goal #1, signaling volume is reduced if no route optimization signaling is done on handover. Goal #3 Location privacy: Location privacy is preserved for external correspondents as long as all of the mobile node's traffic is routed through the local HA. Goal #4 Efficient Use of Wireless Resources: If traffic is not route optimized, the mobile node still pays for an over-the-air Kempf, editor Expires December 2006 [Page 13] Internet Draft NETLMM Goals June, 2006 tunnel to the locally assigned home agent. The overhead here is exactly the same as if the mobile node's home agent in the home network is used and route optimization is not done. Goal #5 Limit the Signaling Overhead in the Network: If the localized mobility management domain is large, the mobile node may suffer from unoptimzed routes. RFC 3775 [8] provides no support for notifying a mobile node that another localized home agent is available for a more optimized route, or for handing over between home agents. A mobile node would have to perform the full home agent bootstrap procedure, including establishing a new IPsec SA with the new home agent. Goal #6 No Extra Security Between Mobile Node and Network: A local home agent in a roaming situation requires the guest mobile node to have the proper credentials to authenticate with the local home agent in the serving network. The credentials used for network access authentication could also be used for mobile service authentication and authorization if the local home agent uses EAP over IKEv2 to authenticate the mobile node with its home AAA server. This may require additional authorization between the home and visited networks to use the same credentials for a different service, however. In addition, as in Goal #3, if binding updates are done in cleartext over the access network or the mobile node has become infected with malware, the local home agent's address could be revealed to attackers and the local home agent could become the target of a DoS attack. So a local home agent would provide no benefit for this goal. Goal #7 Support for Heterogeneous Wireless Link Technologies: This solution supports multiple wireless technologies with separate IP subnets for different links. No special work is required to interface a local home agent to different wireless technologies. Goal #8 Support for Unmodified Mobile Nodes: The mobile node must support Mobile IPv6 in order for this option to work. So mobile node changes are required and other IP mobility protocols are not supported. Goal #9 Support for IPv4 and IPv6: The Mobile IPv6 working group is working on modifying the protocol to allow registration of IPv4 care of addresses in an IPv6 home agent, and also to allow a mobile node to have an IPv4 care of address [17]. Goal #10 Re-use of Existing Protocols Where Sensible: This solution re-uses an existing protocol, Mobile IPv6. Goal #11 Localized Mobility Management Independent of Global Mobility Management: This solution merges localized mobility management and global mobility management, so it does not support the goal. Kempf, editor Expires December 2006 [Page 14] Internet Draft NETLMM Goals June, 2006 8.2 Hierarchical Mobile IPv6 (HMIPv6) HMIPv6 [18] provides the most complete localized mobility management solution available today. In HMIPv6, a localized mobility anchor called a MAP serves as a routing anchor for a regional care of address. When a mobile node moves from one access router to another, the mobile node changes the binding between its regional care of address and local care of address at the MAP. No global mobility management signaling is required, since the care of address seen by correspondents does not change. This part of HMIPv6 is similar to the solution outlined in Section 8.1; however, HMIPv6 also allows a mobile node to hand over between MAPs. Handover between MAPs and MAP discovery requires configuration on the routers. MAP addresses are advertised by access routers. Handover happens by overlapping MAP coverage areas so that, for some number of access routers, more than one MAP may be advertised. Mobile nodes need to switch MAPs in the transition area, and then must perform global mobility management update and route optimization to the new regional care of address, if appropriate. The analysis of this approach against the goals above is the following. Goal #1 Handover Performance Improvement: This solution shortens, but does not eliminate, the latency associated with IP handover, since it reduces the amount of signaling and the length of the signaling paths. Goal #2 Reduction in Handover-related Signaling Volume: Signaling volume is reduced simply because no route optimization signaling is done on handover within the coverage area of the MAP. Goal #3 Location privacy: Location privacy is preserved for external correspondents. Goal #4 Use of Wireless Resources: The mobile node always pays for an over-the-air tunnel to the MAP. If the mobile node is tunneling through a global home agent or VPN gateway, the wired link experiences double tunneling. Over-the-air tunnel overhead can be removed by header compression, however. Goal #5 Limit the Signaling Overhead in the Network: From Goal #1 and Goal #4, the signaling overhead is no more or less than for mobile nodes whose global mobility management anchor is local. However, because MAP handover is possible, forwarding across large localized mobility management domains can be improved thereby improving wired network resource utilization by using multiple MAPs and handing over, at the expense of the configuration and management overhead involved in maintaining multiple MAP coverage areas. Kempf, editor Expires December 2006 [Page 15] Internet Draft NETLMM Goals June, 2006 Goal #6 Extra Security Between Mobile Node and Network: In a roaming situation, the guest mobile node must have the proper credentials to authenticate with the MAP in the serving network. In addition, since the mobile node is required to have a unicast address for the MAP that is either globally routed or routing restricted to the local administrative domain, the MAP is potentially a target for DoS attacks across a wide swath of network topology. Goal #7 Support for Heterogeneous Wireless Link Technologies: This solution supports multiple wireless technologies with separate IP subnets for different links. Goal #8 Support for Unmodified Mobile Nodes: This solution requires modification to the mobile nodes. In addition, the HMIPv6 design has been optimized for Mobile IPv6 mobile nodes, and is not a good match for other global mobility management protocols. Goal #9 Currently, there is no IPv4 version of this protocol; although there is an expired Internet draft with a design for a regional registration protocol for Mobile IPv4 that has similar functionality. It is possible that the same IPv4 transition solution as used for Mobile IPv6 could be used [17] above. Goal #10 Re-use of Existing Protocols Where Sensible: This solution re-uses an existing protocol, HMIPv6. Goal #11 Localized Mobility Management Independent of Global Mobility Management: While HIMPv6 is technically a separate protocol from MIPv6 and could in principle be implemented and deployed without MIPv6, the design is very similar and implementation and deployment would be easier if the mobile nodes supported MIPv6. 8.3 Combinations of Mobile IPv6 with Optimizations One approach to local mobility that has received much attention in the past and has been thought to provide a solution is combinations of protocols. The general approach is to try to cover gaps in the solution provided by MIPv6 by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6 and HMIPv6 + FMIPv6 are discussed. 8.3.1 MIPv6 with local home agent + FMIPv6 As discussed in Section 8.1, the use of MIPv6 with a dynamically assigned, local home agent cannot fulfill the goals. A fundamental limitation is that Mobile IPv6 cannot provide seamless handover (i.e. Goal #1). FMIPv6 [11] above has been defined with the intent to improve the handover performance of MIPv6. For this reason, the Kempf, editor Expires December 2006 [Page 16] Internet Draft NETLMM Goals June, 2006 combined usage of FMIPv6 and MIPv6 with a dynamically assigned local home agent has been proposed to handle local mobility. Note that this gap analysis only applies to localized mobility management, and it is possible that MIPv6 and FMIPv6 might still be acceptable for global mobility management. The analysis of this combined approach against the goals follows. Goal #1 Handover Performance Improvement: FMIPv6 provides a solution for handover performance improvement that should fulfill the goals raised by real-time applications in terms of jitter, delay and packet loss. The location of the home agent (in local or home domain) does not affect the handover latency. Goal #2 Reduction in Handover-related Signaling Volume: FMIPv6 requires the mobile node to perform extra signaling with the access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as in standard MIPv6, whenever the mobile node moves to another link, it must send a Binding Update to the home agent. If route optimization is used, the mobile node also performs return routability and sends a Binding Update to each correspondent node. Nonetheless, it is worth noting that FMIPv6 should result in a reduction of the amount of IPv6 Neighbor Discovery signaling on the new link. Goal #3 Location privacy: The mobile node maintains a local care of address. If route optimization is not used, location privacy can be achieved using bi-directional tunneling. Goal #4 Use of Wireless Resources: As stated for Goal #2, the combination of MIPv6 and FMIPv6 generates extra signaling overhead. For data packets, in addition to the Mobile IPv6 over-the-air tunnel, there is a further level of tunneling between the mobile node and the previous access router during handover. This tunnel is needed to forward incoming packets to the mobile node addressed to the previous care of address. Another reason is that, even if the mobile node has a valid new care of address, the mobile node cannot use the new care of address directly with its correspondents without performing route optimization to the new care of address. This implies that the transient tunnel overhead is in place even for route optimized traffic. Goal #5 Limit the Signaling Overhead in the Network: FMIPv6 generates extra signaling overhead between the previous access router and the new access router for the HI/HAck exchange. Concerning data packets, the use of FMIPv6 for handover performance improvement implies a tunnel between the previous access router and the mobile node that adds some overhead in the wired network. This overhead has more impact on star topology deployments, since packets are routed down to the old access router, then back up to the aggregation router and then back down to the new access router. Kempf, editor Expires December 2006 [Page 17] Internet Draft NETLMM Goals June, 2006 Goal #6 Extra Security Between Mobile Node and Network: In addition to the analysis for Mobile IPv6 with local home agent in Section 8.1, FMIPv6 requires the mobile node and the previous access router to share a security association in order to secure FBU/FBA exchange. Two solutions have been proposed: a SEND-based solution [10] above and an AAA-based solution [15]. Both solutions require additional support on the mobile node and in the network beyond what is required for network access authentication. Goal #7 Support for Heterogeneous Wireless Link Technologies: MIPv6 and FMIPv6 support multiple wireless technologies, so this goal is fulfilled. Goal #8 Support for Unmodified Mobile Nodes: The mobile node must support both MIPv6 and FMIPv6, so it is not possible to satisfy this goal. Goal #9 Support for IPv4 and IPv6: Work is underway to extend MIPv6 with the capability to run over both IPv6-enabled and IPv4-only networks [17] above. FMIPv6 only supports IPv6. Even though an IPv4 version of FMIP has been recently proposed, it is not clear how it could be used together with FMIPv6 in order to handle fast handovers across any wired network. Goal #10 Re-use of Existing Protocols Where Sensible: This solution re-uses existing protocols, Mobile IPv6 and FMIPv6. Goal #11 Localized Mobility Management Independent of Global Mobility Management: This solution merges localized mobility management and global mobility management, so it does not support the goal. 8.3.2 HMIPv6 + FMIPv6 HMIPv6 provides several advantages in terms of local mobility management. However, as seen in Section 8.2, it does not fulfill all the goals identified in Section 2.0. In particular, HMIPv6 does not completely eliminate the IP handover latency. For this reason, FMIPv6 could be used together with HMIPv6 in order to cover the gap. Note that even if this solution is used, the mobile node is likely to need MIPv6 for global mobility management, in contrast with the MIPv6 with dynamically assigned local home agent + FMIPv6 solution. Thus, this solution should really be considered MIPv6 + HMIPv6 + FMIPv6. The analysis of this combined approach against the goals follows. Goal #1 Handover Performance Improvement: HMIPv6 and FMIPv6 both shorten the latency associated with IP handovers. In particular, Kempf, editor Expires December 2006 [Page 18] Internet Draft NETLMM Goals June, 2006 FMIPv6 is expected to fulfill the goals on jitter, delay and packet loss raised by real-time applications. Goal #2 Reduction in Handover-related Signaling Volume: Both FMIPv6 and HMIPv6 require extra signaling compared with Mobile IPv6. As a whole the mobile node performs signaling message exchanges at each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. However, as mentioned in Section 8.2, the use of HMIPv6 reduces the signaling overhead since no route optimization signaling is done for intra-MAP handovers. In addition, naive combinations of FMIPv6 and HMIPv6 often result in redundant signaling. There is much work in the academic literature and the IETF on more refined ways of combining signaling from the two protocols to avoid redundant signaling. Goal #3 Location privacy: HMIPv6 may preserve location privacy, depending on the dimension of the geographic area covered by the MAP. Goal #4 Use of Wireless Resources: As mentioned for Goal #2, the combination of HMIPv6 and FMIPv6 generates a lot of signaling overhead in the network. Concerning payload data, in addition to the over-the-air MIPv6 tunnel, a further level of tunneling is established between mobile node and MAP. Notice that this tunnel is in place even for route optimized traffic. Moreover, if FMIPv6 is directly applied to HMIPv6 networks, there is a third temporary handover-related tunnel between the mobile node and previous access router. Again, there is much work in the academic literature and IETF on ways to reduce the extra tunnel overhead on handover by combining HMIP and FMIP tunneling. Goal #5 Limit the Signaling Overhead in the Network: The signaling overhead in the network is not reduced by HMIPv6, as mentioned in Section 8.2. Instead, FMIPv6 generates extra signaling overhead between the previous access router and new access router for HI/HAck exchange. For payload data, the same considerations as for Goal #4 are applicable. Goal #6 Security Between Mobile Node and Network: FMIPv6 requires the mobile node and the previous access router to share a security association in order to secure the FBU/FBA exchange. In addition, HMIPv6 requires that the mobile node and MAP share an IPsec security association in order to secure LBU/LBA exchange. The only well understood approach to set up an IPsec security association is the use of certificates, but this may raise deployment issues. Thus, the combination of FMIPv6 and HMIPv6 doubles the amount of mobile node to network security protocol required, since security for both FMIP and HMIP must be deployed. Goal #7 Support for Heterogeneous Wireless Link Technologies: HMIPv6 and FMIPv6 support multiple wireless technologies, so this goal is fufilled. Kempf, editor Expires December 2006 [Page 19] Internet Draft NETLMM Goals June, 2006 Goal #8 Support for Unmodified Mobile Nodes: The mobile node must support both HMIPv6 and FMIPv6 protocols, so this goal is not fulfilled. Goal #9 Support for IPv4 and IPv6: Currently there is no IPv4 version of HMIPv6. There is an IPv4 version of FMIP but it is not clear how it could be used together with FMIPv6 in order to handle fast handovers across any wired network. Goal #10 Re-use of Existing Protocols Where Sensible: This solution re-uses existing protocols, HMIPv6 and FMIPv6. Goal #11 Localized Mobility Management Independent of Global Mobility Management: While HIMPv6 is technically a separate protocol from MIPv6 and could in principle be implemented and deployed without MIPv6, the design is very similar and implementation and deployment would be easier if the mobile nodes supported MIPv6. 8.4 Micromobility Protocols Researchers have defined some protocols that are often characterized as micromobility protocols. Two typical protocols in this category are Cellular-IP [2] and HAWAII [16]. Researchers defined these protocols before local mobility optimizations for Mobile IP such as FMIP and HMIP were developed, in order to reduce handover latency. Cellular-IP and HAWAII were proposed in the IETF for standardization, but after some study in the IRTF, were dropped. There are many micromobility protocols defined in the academic literature, but in this document, the term is used specifically to refer to Cellular-IP and HAWAII. The micromobility approach to localized mobility management requires host route propagation from the mobile node to a collection of specialized routers in the localized mobility management domain along a path back to a boundary router at the edge of the localized mobility management domain. A boundary router is a kind of localized mobility management domain gateway. Localized mobility management is authorized with the access router, but reauthorization with each new access router is necessary on link movement, in addition to any reauthorization for basic network access. The host routes allow the mobile node to maintain the same IP address when it moves to a new link, and still continue to receive packets on the new link. Cellular IP and HAWAII have a few things in common. Both are compatible with Mobile IP and are intended to provide a higher level of handover performance in local networks than was previously available with Mobile IP without such extensions as HMIP and FMIP. Both use host routes installed in a number of routers within a restricted routing domain. Both define specific messaging to update Kempf, editor Expires December 2006 [Page 20] Internet Draft NETLMM Goals June, 2006 those routes along the forwarding path and specify how the messaging is to be used to update the routing tables and forwarding tables along the path between the mobile and a micromobility domain boundary router at which point Mobile IP is to used to handle global mobility in a scalable way. Unlike the FMIP and HMIP protocols, however, these protocols do not require the mobile node to obtain a new care of address on each access router as it moves; but rather, the mobile node maintains the same care of address across the micromobility domain. From outside the micromobility domain, the care of address is routed using traditional longest prefix matching IP routing to the domain's boundary router, so the care of address is conceptually withain the micromobility domain boundary router's subnet. Within the micromobility domain, the care of address is routed to the correct access router using host routes. Micromobility protocols have some potential drawbacks from a deployment and scalability standpoint. Both protocols involve every routing element between the mobile device and the micromobility domain boundary router in all packet forwarding decisions specific to care of addresses for mobile nodes. Scalability is limited because each care of address corresponding to a mobile node generates a routing table entry, and perhaps multiple forwarding table entries, in every router along the path. Since mobile nodes can have multiple global care of addresses in IPv6, this can result in a large expansion in router state throughout the micromobility routing domain. Although the extent of the scalability for micromobility protocols is still not clearly understood from a research standpoint, it seems certain that they will be less scalable than the Mobile IP optimization enhancements, and will require more specialized gear in the wired network. The following is a gap analysis of the micromobility protocols against the goals in Section 2.0: Goal #1 Handover Performance Improvement: The micromobility protocols reduce handover latency by quickly fixing up routes between the boundary router and the access router. While some additional latency may be expected during host route propagation, it is typically much less than experienced with standard Mobile IP. Goal #2 Reduction in Handover-related Signaling Volume: The micromobility protocols require signaling from the mobile node to the access router to initiate the host route propagation, but that is a considerable reduction over the amount of signaling required to configure to a new link. Goal #3 Location privacy: No care of address changes are exposed to correspondent nodes or the mobile node itself while the mobile node is moving in the micromobility-managed network. Kempf, editor Expires December 2006 [Page 21] Internet Draft NETLMM Goals June, 2006 Goal #4 Use of Wireless Resources: The only additional over-the-air signaling is involved in propagating host routes from the mobile node to the network upon movement. Since this signaling would be required for movement detection in any case, it is expected to be minimal. Mobile node traffic experiences no overhead. Goal #5 Limit the Signaling Overhead in the Network: Host route propagation is required throughout the wired network. The volume of signaling could be more or less depending on the speed of mobile node movement and the size of the wired network. Goal #6 Security Between Mobile Node and Network: The mobile node only requires a security association of some type with the access router. Because the signaling is causing routes to the mobile node's care of address to change, the signaling must prove authorization to hold the address. Goal #7 Support for Heterogeneous Wireless Link Technologies: HMIPv6 The micromobility protocols support multiple wireless technologies, so this goal is satisfied. Goal #8 Support for Unmodified Mobile Nodes: The mobile node must support some way of signaling the access router on link handover, but this is required for movement detection anyway. The nature of the signaling for the micromobility protocols may require mobile node software changes, however. Goal #9 Re-use of Existing Protocols Where Sensible: Support for IPv4 and IPv6: Most of the work on the micromobility protocols was done in IPv4, but little difference could be expected for IPv6. Goal #10 This solution does not reuse an existing protocol because there is currently no Internet Standard protocol for micromobility. Goal #11 Localized Mobility Management Independent of Global Mobility Management: This solution separates global and local mobility management, since the micromobility protocols only support localized mobility management. 8.5 Summary The following table summarizes the discussion in Section 9.1 through 9.5. In the table, a "M" indicates that the protocol completely meets the goal, a "P" indicates that it partially meets the goal, and an "X" indicates that it does not meet the goal. Protocol #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 -------- -- -- -- -- -- -- -- -- -- --- MIPv6 P X X X X X M X M M Kempf, editor Expires December 2006 [Page 22] Internet Draft NETLMM Goals June, 2006 HMIPv6 P X X X P X M X X M MIPv6 + FMIPv6 M X X X P X M X P M HMIPv6 + FMIPv6 M X X X X X M X X M Micro. M M M M P M M M P X 9.0 IPR Statements 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. 10.0 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. 11.0 Copyright Notice Kempf, editor Expires December 2006 [Page 23] Internet Draft NETLMM Goals June, 2006 Copyright (C) The Internet Society (2006). 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. Kempf, editor Expires December 2006 [Page 24]