J. Kempf Internet Draft DoCoMo USA Labs Document: draft-kempf-mobileip-arch-00.txt P. Nikander Expires: August 2003 Ericsson Research Nomadic Lab February, 2003 Organizing Mobile IP Along Natural Architectural Boundaries Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an individual submission to the Mobile IP Working Group. 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. Abstract A natural architectural split exists in Mobile IP between the mechanisms involved in global routing change and the mechanisms involved in local link routing change. The global mechanisms modify the mapping between a Mobile Node's routing identifier (care of address) and its global node identifier (home address). The local mechanisms allow the Mobile Node to obtain IP connectivity on the subnet and provide measures to locally mitigate routing failure while the global routing change is occurring. This draft makes a case for keeping the mechanisms involved in these two architectural components distinct and separate in Mobile IPv6, and suggests that the Mobile IP group might want to think about a separate working group specifically focused on local link routing changes for mobility in Mobile IPv6. Table of Contents Kempf Expires August 2003 [Page 1] Internet Draft Think Globally, Act Locally February, 2003 1.0 Introduction.................................................2 2.0 Global Architectural Elements in Mobile IP...................2 3.0 The Local Routing Problem....................................3 4.0 Local Architectural Elements in Mobile IP....................3 5.0 Security Considerations......................................6 6.0 Focusing on Local Link Mobility..............................8 7.0 Recommendation...............................................9 8.0 References...................................................9 9.0 Author Information..........................................10 10.0 Full Copyright Statement...................................10 1.0 Introduction Mobile IP [1][2] was developed as a way to support node mobility for IP nodes that are undergoing continuous and unpredictable changes in their point of attachment to the Internet. Movement involves two basic elements: - A change in the global routability of packets due to movement betweens subnets, - A change in local link IP connectivity that requires actions on the local subnets. In this document, the natural architectural boundaries separating these two elements are discussed, and some suggestions are made for organizing the local link routing change protocol design around this architecture. 2.0 Global Architectural Elements in Mobile IP Since the initial standardization of Mobile IPv4, the architectural basis of Mobile IP [1][2] has been dictated by the global Internet routing architecture. The Internet routing architecture uses an IP address for two purposes: - To provide a globally unique node identifier for use by the transport layer, which is the node identifier, - To direct the routing of packets between one end node and another while packets are in flight, which is the routing identifier. This conflation of function leads to the need for a global routing proxy, the Home Agent, to maintain a changeable mapping between the node identifier, or home address, and the routing identifier, or care of address. When a Mobile Node moves, the mapping is updated to reflect the new route to the Mobile Node. In this document, the update of the mapping at the Home Agent is called a global routing change. Packets are routed initially to the home address, and then tunneled by the Home Agent to the Mobile Node. In addition, packets from the Mobile Node are typically also reverse tunneled through the Home Agent, if ingress filtering in the access network is operating. Kempf Expires August 2003 [Page 2] Internet Draft Think Globally, Act Locally February, 2003 An immediate consequence of using a routing proxy is the existence of suboptimal routes between some Correspondent Nodes and the Mobile Node. The routing forms a triangle, with the Home Agent (the routing proxy), Correspondent Node, and Mobile Node at the edges. In normal IP routing, packets take the shortest route directly between the end nodes, in this case, the Correspondent Node and Mobile Node. Early work in Mobile IPv4 (now expired) led, in Mobile IPv6, to route optimization being included in the base Mobile IPv6 protocol [2] with proper security protections. Route optimization allows a Mobile Node to propagate the global change in routing identifier directly to all Correspondent Nodes, thereby eliminating the suboptimal routes. An important point to note is that, since the Internet routing architecture has not changed in IPv6, the global architectural elements of Mobile IP have remained substantially the same between Mobile IPv4 and Mobile IPv6. The few architectural changes between Mobile IPv4 and Mobile IPv6 have been primarily related to Home Agent discovery and, as mentioned, to route optimization. 3.0 The Local Routing Problem Unlike the global routing problem, the local routing problem in Mobile IP has received much less attention, until very recently. The local routing problem consists of two parts: 1) The need for a mechanism by which the Mobile Node obtains a new care of address on a new link, 2) The need for a mechanism to temporarily repair the local routing failure due to a switch in link prior to the change in global routing at the Home Agent (and, in route optimized, Mobile IPv6 Correspondent Nodes) taking place. The extent to which local routing disruption in 2) is a problem for the Mobile Node depends, to a large extent, on its particular traffic pattern. The typical bursty Web browsing traffic that characterizes most Internet traffic today will be largely unaffected by temporary disruptions during handover, especially if the latency in the access network is high. However, for streaming media or real- time traffic, routing disruptions during handover can introduce unacceptable artifacts into the transmission. 4.0 Local Architectural Elements in Mobile IP While the global architectural elements in Mobile IP are dictated by the Internet routing architecture, the local architectural elements addressing 1) above have undergone a quite radical change between Mobile IPv4 and Mobile IPv6. In Mobile IPv4, a specialized last hop router, called a Foreign Agent, is responsible for maintaining the endpoint of the bidirectional tunnel with the Home Agent. The Foreign Agent performs decapsulation of tunnelled packets from the Home Agent, and encapsulation of reverse tunneled packets to the Home Agent. In many Kempf Expires August 2003 [Page 3] Internet Draft Think Globally, Act Locally February, 2003 respects, the Foreign Agent looks like an on-link Home Agent. It maintains a binding between the care of address (typically the global address of the Foreign Agent itself) and the link layer address of the Mobile Node, similar to the binding cache maintained by the Home Agent. The expired route optimization draft for Mobile IPv4 even specified that a Foreign Agent could act as an on-link Home Agent for the previous care of address, to allow a Mobile Node to continue utilizing its old care of address when it moves to the new link. The old Foreign Agent tunnels packets to the new Foreign Agent until the global routing change is effected. Re-enforcing this design, the local signaling for establishing a new care of address at the Foreign Agent or requesting that forwarding be performed to an old one is very similar to the global signaling used to change the mapping between the home address and care of address at the Home Agent, or, respectively, to inform Correspondent Nodes about a change in home address to care of address binding. In Mobile IPv6, the utilization of the global architectural elements on the local link for solving the first local routing problem was eliminated. Instead, standard IPv6 mechanisms for establishing local link routability and address configuration (both stateless [5][6] and stateful [7]) were specified to replace the Foreign Agent. An initial draft of the Mobile IPv6 specification did contain a design for an on-link Home Agent that used global Mobile IPv6 signaling to allow forwarding from previous care of address, but this was removed due to security considerations. In the current/final version, the Mobile Node itself handles the bidirectional tunnel to the Home Agent, and route optimization with Correspondent Nodes. The replacement of the Foreign Agent with specific local link mechanisms is one of the primary innovations in the Mobile IPv6 design. Neither Mobile IPv4 nor Mobile IPv6 addressed 2) above, namely how to repair the local routing failure until the global routing change is complete. There have been three proposed solutions: 1) "Localized" mobility management to reduce the time required for changing global routing [8][9][10], 2) Preconfiguration on the new subnet to reduce the time required for changing local routing [3][13], 3) Fixing the routing failure when the Mobile Node switches links so that routing to and from the Mobile Node is continued until the global routing change is complete [3][13]. We discuss these in the following subsections. 4.1 "Localized" Mobility Management "Localized" mobility management involves introducing a regional routing proxy, called a Regional Registration agent or Mobility Anchor Point somewhere in the access network topologically close to the Mobile Node. When the Mobile Node moves from one subnet to another, it changes its care of address at the regional routing proxy rather than at the Home Agent. Because the regional routing proxy is topologically closer, the delay between the Mobile Node Kempf Expires August 2003 [Page 4] Internet Draft Think Globally, Act Locally February, 2003 obtaining a new care of address and the global routing change is reduced (but not eliminated). The basic mechanism used by the regional routing proxy is the same as that used by the Home Agent, namely a binding between a more global address, in this case the regional care of address, and a more local one, the local care of address. When the Mobile Node ultimately does change from one regional routing proxy to another, the Home Agent must be notified to change the home address to regional care of address mapping, but this occurs much less frequently. Localized mobility management does not address reducing the amount of time required for the Mobile Node to detect that is has moved or to obtain a new care of address, nor does it provide a solution for fixing up the routing failure after the link is switched. Because the regional routing proxy is at some distance from the actual link, multiple proxies may be required to tune the performance, and complete elimination of the delay in the routing change may not be possible. At the extreme, a regional routing proxy may be required for every subnet, like a Foreign Agent, or for every aggregation router serving a collection of subnets through a low capacity edge link, like a T1 line. Because both the mechanism and expected deployment pattern of the regional routing proxy involve mechanisms more similar to the global Mobile IP architectural elements, "localized" mobility management should more properly be called "regionalized" mobility management, and therefore regional routing proxies are more properly considered part of the global, not local, Mobile IP architecture. 4.2 Preconfiguration Preconfiguration involves two components: 1) Obtaining information on wireless connectivity between geographically adjacent subnets, 2) Using this information to preconfigure various components of the local link configuration on the new link, by either contacting a router on the other subnet directly or indirectly through the current default router. Step 1) is often called "Candidate Access Router Discovery" [11] because the discovered last hop (or access) routers are candidates for handover. In step 2), the kinds of information that can be preconfigured include: - Security and authentication information, such as IPsec security associations or AAA contexts, - First hop router in the new subnet, and other router information, - Subnet prefix on the new subnet, - New care of address, - Global routing change (i.e. change in home address to care of address mapping). Kempf Expires August 2003 [Page 5] Internet Draft Think Globally, Act Locally February, 2003 Preconfiguration tightly coupled to link handover and without any local routing repair, i.e. performing the global routing change prior to the actual link switch, tends to perform poorly [17] because the timing of the link switch is probabilistic and the Mobile Node can lose routing while still on the old link if the switch happens too late. Preconfiguration with local route repair performs better, but when the preconfiguration signaling is also tightly coupled with handover, the signaling can occasionally be disrupted by the handover causing the handover to fail over to standard Mobile IP on-link configuration after the Mobile Node has performed the link switch [18]. Removing the tight coupling of preconfiguration signaling with handover can potentially eliminate these difficult timing problems. However, any preconfiguration that requires reserving resources on a new router (such as security associations or new care of addresses) generates a resource management problem if the Mobile Node ultimately chooses not to move to that router. Preconfiguring the Mobile Node with router IP addresses of some type or link layer addresses on the new link has no problem because no state is created on the new router and there is no tight timing with handover. 4.3 Local Route Repair Local route repair involves having the old access router forward packets to the new access router during the period in which the Mobile Node is undergoing the link switch and is waiting for the change in global home address to care of address mapping [13][3] to complete. Typically, this process is accomplished by using an IP in IP tunnel or Routing Header between the two routers, but it could also be done using MPLS. The old and new access routers maintain a set of host routes pointing to a bidirectional tunnel between them, allowing the Mobile Node to send and receive packets as if it were on the old subnet. The tunnel is meant to be a temporary measure until the new care of address has been established, but it can be maintained until the Mobile Node requests that it be dropped, if the Mobile Node is moving so quickly that the global routing change fails to complete before another movement. The current proposal for Mobile IPv6 [13] requires the Mobile Node to signal the old access router after undergoing a handover to start the tunnel. The use of global Mobile IPv6 signaling to perform this is questionable on architectural grounds, as will be discussed below. In addition, the signaling assumes that the new access router's ingress filter is willing to pass packets with the Mobile Node's previous care of address. From the design, it is entirely unclear why the old access router is privileged with respect to starting the tunnel. The new access router could equally well perform the tunnel initiation, after being prompted to do so by the Mobile Node. 5.0 Security Considerations Kempf Expires August 2003 [Page 6] Internet Draft Think Globally, Act Locally February, 2003 As with other aspects of Mobile IP, security has a component involving local routing change and a component involving global routing change. The mechanisms to implement these components differ in Mobile IPv4 and Mobile IPv6. 5.1 Mobile IPv4 In the base Mobile IPv4 protocol [1], the same mechanism is used for authenticating both local routing change and global routing change, but only the global authentication mechanism is required. These are: - For changing the node identifier to routing identifier mapping, an extension to the Mobile IPv4 Registration Request message to the Home Agent is required to contain a message authentication code calculated with keyed MD5. Additionally, the same mechanism may be used to authenticate a pass-through node identifier to routing identifier change from the Foreign Agent to Home Agent. - For changing the routing identifier locally, the same mechanism provides for local change authentication between the Mobile Node and Foreign Agent. - For local repair of routing during handover, the same mechanism provides for authentication between two Foreign Agents to assure that the Foreign Agents are authorized to initiate routing changes [3]. In each case, the security relationship is different (Mobile-Home Agent, Mobile-Foreign Agent, Foreign Agent-Home Agent, or Foreign Agent-Foreign Agent), although the basic mechanism - a message extension with a keyed MD5 MAC - is the same. 5.2 Mobile IPv6 As is the case for the general Mobile IPv6 design, the security for the local and global aspects of routing change has been separated. Security for global routing changes consists of the following two mechanisms: - A specialized IPsec security association for protecting signaling traffic between the Home Agent and Mobile Node [4], - A specialized security algorithm called Return Routability that uses an extension on the Binding Update message to secure route optimization routing changes with the Correspondent Node [1]. The security for the local routing repair is not yet completely specified. Aspects of security that involve utilizing RFC 2461 and RFC 2462 [5][6][12] to obtain router information and local care of address if stateless autoconfiguration is used, or DHCP security [7] (currently unspecified), if stateful address autoconfiguration is used, utilize the appropriate security mechanisms for the relevant protocol. However, proposals for repairing local routing failures based on global Mobile IP signaling specify that IPsec should be Kempf Expires August 2003 [Page 7] Internet Draft Think Globally, Act Locally February, 2003 used without describing in detail how the security association is constructed [13]. Unlike Mobile IPv4, Mobile IPv6 contains no Mobile IP-specific mechanisms for establishing credentials with the local network. It is assumed that these credentials are established in a manner consistent with that used by any host wishing gain access to the local network. This design is architecturally cleaner, since it separates the authentication mechanism from the mobility protocol and so avoids the need for different authentication mechanisms depending on whether the host is mobile or not. Many link protocols have their own authentication mechanisms, but an IP based alternative for those that don't (PANA [14]) is currently under development in the IETF, and it is a candidate AAA protocol between a Mobile Node and the network. 6.0 Focusing on Local Link Mobility As discussed above, one of the most important innovations of Mobile IPv6 is the elimination of global mechanisms used to solve local routing problems. The reason this innovation is important is because it introduces modularity into the Mobile IP design. On the local side, Mobile IPv6 nodes can utilize standard IPv6 local link route discovery, address configuration, and security mechanisms during initial deployments while the local mechanisms are improved. Correspondingly on the global side, although a change in the Internet routing architecture to better accommodate mobility might seem unlikely now, a modular design would allow such a change to occur without impacting the local link protocol. The local and global mechanisms also exhibit a difference in scalability. The global routing proxies scale like servers, in the sense that reliability depends on multiple expensive, very reliable nodes with highly replicated state so that the unlikely failure of one node requires a hot standby to quickly take over. The local routing scales like routers, in the sense that reliability depends on multiple, cheap nodes with replicated functionality and minimal replicated state so that routing fails over automatically with minimal to no host involvement. This suggests that the signaling for mitigating local routing failure should be derivative of the local link signaling in RFC 2461 rather than the global signaling used with the Home Agent and Correspondent Node. The function of this signaling includes providing the Mobile Node with prehandover information about wireless connectivity to other subnets for preconfiguration, allowing the Mobile Node to perform preconfiguration, and initiating and terminating the routing tunnel between the old subnet and the new. Changes in RFC 2461 and 2462 to optimize posthandover local link configuration for mobility should also be considered. Some existing proposals along these lines (examples are [15][16]) address reducing latency in duplicate address detection and router discovery. Kempf Expires August 2003 [Page 8] Internet Draft Think Globally, Act Locally February, 2003 7.0 Recommendation The interdependence between the various functions performed by the protocols involved in local link mobility suggests that a well- integrated design might benefit from having a tightly coupled design effort to minimze duplication. For example, the relative merit of prehandover configuration depends heavily on how long posthandover configuration requires and how long the local routing repair can reasonably be maintained. If local link configuration is fast enough and acceptable routing repair algorithms are in place, preconfiguration becomes a less attractive choice, for the reasons cited above. As another example, prehandover wireless connectivity information need only be provided by one protocol. The local link mobility protocols should be well designed to provide orthogonal functionality, such as is already the case for RFC 2461 and 2462. In order to properly co-ordinate the design effort, the Mobile IP Working Group might want to consider setting up a separate working group specifically to address local link mobility. This group would encompass the fast handover work currently in the Mobile IP working group, the candidate access router discovery work in the Seamoby working group, and the optimized link configuration work in IPv6 working group. Such a working group could focus specifically on designing local routing enhancements for mobility that fit well with RFC 2461 and 2462, and leverage the existing design effort made in local link routing changes for Mobile IPv6, where applicable. 8.0 References [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, August, 2002. [2] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-20.txt, a work in progress. [3] El Malki, K., editor, "Low Latency Handoffs in Mobile IPv4," draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt, a work in progress. [4] Arkko, J., Devarapalli, V., and Dupont, F., "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-02.txt, a work in progress. [5] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. [6] Thomson, S., and Narten, T., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December, 1998. [7] Droms, R., editor, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-28.txt, a work in progress. [8] Williams, C., "Localized Mobility Management Requirements", draft-ietf-mobileip-lmm-requirements-02.txt, a work in progress. [9] Gustafsson, E., et. al., "Mobile IPv4 Regional Registration", draft-ietf-mobileip-reg-tunnel-07.txt, a work in progress. [10] Soliman, H., et. al., " Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-07.txt, a work in progress. Kempf Expires August 2003 [Page 9] Internet Draft Think Globally, Act Locally February, 2003 [11] Liebsch, M., and Singh, A., "Candidate Access Router Discovery", draft-ietf-seamoby-card-protocol-00.txt, a work in progress. [12] http://www.ietf.org/html.charters/send-charter.html [13] Koodli, R., editor, "Fast Handovers for Mobile IPv6," draft- ietf-mobileip-fast-mipv6-05.txt, a work in progress. [14] http://www.ietf.org/html.charters/pana-charter.html [15] Moore, N., "Optimistic Duplicate Address Detection", draft- moore-ipv6-optimistic-dad-02.txt, a work in progress. [16] Khalil, M., et. al., "IPv6 Fast Router Advertisement", draft- mkhalil-ipv6-fastra-03.txt, a work in progress. [17] Kempf, J., et. al., "Link Synchronous Mobile IPv4 Handover Algorithms," submitted to JSAC special issue on All-IP Wireless Networks. [18] Kempf, J., et. al., "Fast Mobile IPv6 Handover Packet Loss Performance," Proceedings of WCNC 2003, March, 2003. 9.0 Author Information James Kempf Email: kempf@docomolabs-usa.com DoCoMo USA Labs Telephone: +1 408 451 4711 181 Metro Drive Suite 300 San Jose, CA 95110 USA Pekka Nikander EMail: pekka.nikander@nomadiclab.com Ericsson Research Nomadic Lab Phone: +358 9 299 1 Jorvas FIN-02420 FINLAND 10.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Kempf Expires August 2003 [Page 10] Internet Draft Think Globally, Act Locally February, 2003 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kempf Expires August 2003 [Page 11]