mipv6 S. Yamamoto Internet-Draft KDDI Labs USA Expires: August 9, 2004 H. Yokota KDDI R&D Labs C. Williams KDDI Labs USA M. Parthasarathy Consultant KDDI Labs USA February 9, 2004 Mobile IPv6 Node traversal of IPv4 subnets using automatic tunnels draft-yamamoto-mipv6node-v4trav-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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 August 9, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft presents Mobile IPv6 [1] operation in IPv4 networks by using existing automatic tunneling method. A mobile IPv6 node uses Mobile IPv6 to maintain connectivity while moving between IPv6 subnets. Not all access networks will transition to IPv6 at once. Therefore, seamless Mobile IPv6 connectivity is not guarantied since a mobile IPv6 node may roam into an IPv4 only network. We describe a scheme, named GLOB6, to allow mobile IPv6 nodes to traverse IPv4 Yamamoto, et al. Expires August 9, 2004 [Page 1] Internet-Draft MIPv6 node traversal of IPv4 February 2004 subnets by using automatic tunneling. ISATAP [2] is an example automatic tunneling mechanism described in this document to enable Mobile IPv6 connectivity over IPv4 networks. The draft concludes with a brief description of how the scheme can be applied to certain 3G networks as well as WLAN deployments as part of an overall strategy for the realization of global mobility - a main feature of IPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Glob6 Operation Scheme . . . . . . . . . . . . . . . . . . . . 4 3.1 ISATAP Example . . . . . . . . . . . . . . . . . . . . . . . . 4 4. 3GGP2 deployment scenario . . . . . . . . . . . . . . . . . . 5 5. WLAN Hotspot deployment scenario . . . . . . . . . . . . . . . 6 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 Normative references . . . . . . . . . . . . . . . . . . . . . 8 Informative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Yamamoto, et al. Expires August 9, 2004 [Page 2] Internet-Draft MIPv6 node traversal of IPv4 February 2004 1. Introduction One of the obstacles to universal deployment of IPv6 is an easy transition. Every router, every PC, and every server owned by Internet-service-providers (ISPs), Mobile Network Operators (MNOs), corporations, universities, governments, and individuals would have to be replaced or upgraded. Individuals and businesses upgrade or replace network equipment and hosts one at a time. In addition, all the applications and current services need to work using IPv6. As a result, the thousands of organizations that control little pieces of the Internet including networks controlled by mobile network operators are trying to determine does IPv6 bring enough value to those to warrant the expense and time the transition would entail. By having a carefully planned transition strategy that sought to build IPv6 requirements into all new developments and upgrades could significantly reduce these costs and spread them over a number of years. To provide the functionality of Mobile IPv6 in a wireless system, IPv6 support is required in the architecture of the wireless access networks. The IPv6 access router (AR) is the 1st hop routing entity that connects with several radio access networks (RANs) to form a wireless data serving area. When a mobile IPv6 node moves to a visited IPv6 network, it obtains an IPv6 prefix sent by the AR in router advertisement messages as defined in [6]. The IPv6 prefix is then used to auto-configure a global routable IPv6 care-of address (CoA). A mobile node now uses its care-of address as the Source Address in the IP header of packets it sends. If the mobile node handoff to a network that is IPv4 only, the mobile node is unable to continue IPv6 connectivity. This draft presents a Mobile IPv6 operational approach in which the communication of an IPv6 node can continue uninterrupted as it moves within IPv4 networks. The operational approach, named GLOB6, uses existing IPv6 transition schemes based on automatic tunneling. The Mobile IPv6 protocol is not IP layer independent and thus only enables IPv6 nodes to roam within IPv6 networks. Enabling IPv6 nodes to roam within IPv4 networks is important as not all access networks will be upgraded to IPv6 all at once. For an initial period of time, IPv6 deployments will be small islands amidst a sea of IPv4 networks. Thus, Mobile IPv6 connectivity is restricted to roaming within these newly formed IPv6 networks. For supporting a global seamless roaming service using Mobile IPv6, it is necessary to deploy a scheme for Mobile IPv6 nodes to continue IPv6 connectivity when independent of the IP version of the visited network. The proposed approach is based on the concept of using dynamic tunneling to provide IPv6 routing over an IPv4 network. Automatic Yamamoto, et al. Expires August 9, 2004 [Page 3] Internet-Draft MIPv6 node traversal of IPv4 February 2004 based tunneling schemes have desirable architectural properties to facilitate mobile IPv6 client handover in IPv4 subnets. First, the tunneling agent can act as a 1st hop IPv6 router on behalf of the mobile IPv6 nodes visiting the IPv4 domain it services. When the mobile node (using MIPv6) moves between IPv4 access routers, the tunneling node can continue to serve as the first hop IPv6 router. One of the purposes of this document is to define and describe how automatic tunneling methods can facilitate the operation for mobile IPv6 node traversal within IPv4 subnets. ISATAP is used as an example transition method in this document. 2. Terminology See [3] for mobility terminology used in this document. 3. Glob6 Operation Scheme Automatic based tunneling schemes have desirable architectural properties to facilitate mobile IPv6 client handover in IPv4 subnets. The tunneling agent can act as a 1st hop IPv6 router on behalf of the mobile IPv6 nodes visiting the IPv4 domain it services. Automatic tunneling allows for a mobile IPv6 node to create a virtual IPv6 link over the IPv4 access network. IPv6 packets are encapsulated in IPv4 packets and then decapsulated at the other end of the tunnel. For example, upon entering an IPv4 access network, a mobile IPv6 node can tunnel its Mobile IPv6 traffic over the IPv4 access network to an IPv6 transition agent that in turn routes the IPv6 packets to an IPv6 backbone on to the IPv6 correspondence node. 3.1 ISATAP Example ISATAP [2] is an IPv6 transition mechanism that allows IPv6-in-IPv4 tunnels to be created automatically within a site. ISATAP clients usually perform stateless IPv6 address autoconfiguration via ISATAP router discovery. IPv6 packets destined to other hosts are sent and received via the ISATAP router by tunneling the IPv6 packets in IPv4. Mobile IPv6 nodes sends a router solicitation to the ISATAP router for configuring the ISATAP care-of address. It uses the prefix information in the router advertisement to configure the care-of address which it later uses to send binding updates to its correspondent nodes. Although the Mobile IPv6-ISATAP method does not require Mobile IPv4, the Mobile IPv6 node must be dual stack. This is because the virtual IPv6 links provided by automatic tunneling methods are implemented by virtual IPv6 interfaces that are configured over one or more physical Yamamoto, et al. Expires August 9, 2004 [Page 4] Internet-Draft MIPv6 node traversal of IPv4 February 2004 IPv4 interfaces. Every time the dual stack node moves to another IPv4 access router, it will obtain and configure a new IPv4 address. The tunnel endpoints will be updated to use the new IPv4 address as the source address and the ISATAP router's address as the destination address. As the Mobile IPv6 CoA is an ISATAP address, any change in the mobile node's IPv4 address results in a change of the IPv6 CoA as well. At this point a mobile IPv6 handover occurs even if the mobile IPv6 prefix remains the same. This consists of configuring a new Mobile IPv6 CoA and sending binding updates (BUs) to the respective corresponding peers. The above scheme requires additional implementation support for movement detection. The mobile client would be a dual stack node with Mobile IPv6 and ISATAP support. The mobile IPv6 movement detection needs to be extended to detect IPv4 access networks as well. When the mobile node moves from an IPv6 network to an IPv4 network, it will lose connection with its current IPv6 access router and will cease to hear IPv6 router advertisements. This triggers the mobile node to autoconfigure an IPv4 address (i.e., using DHCP). If it succeeds, then it autoconfigures a mobile IPv6 ISATAP care-of address and sends a binding update via the ISATAP router to its correspondent nodes. When the mobile node moves from IPv4 network to the IPv6 network, it will lose connection with the current IPv4 default router and start hearing new IPv6 router advertisements. When it receives an RA, it unconfigures the ISATAP interface and starts using native IPv6. It autoconfigures a mobile IPv6 care-of address and sends binding updates to its correspondent nodes. Mobile IPv6 node learns the address of the ISATAP router using DHCP based discovery method. Other ISATAP agent discovery methods that have been discussed are based on DNS queries as well as one that uses the well-known IPv4 ANYCAST address. The usage of tunneling in this mobility deployment scheme serves the purpose of enabling IPv6 communication between the mobile IPv6 client node and some gateway that will forward the IPv6 packets on to an IPv6 backbone. There is not requirement about what the operator’s backbone looks like. For example, the ISATAP agent may reside on the boarder of the IPv4 access network and the operator’s IPv6 backbone. In another scenario, the ISATAP agent may also connect to the operator’s IPv6 backbone through a 6to4 tunnel or an IGP/EGP routing protocol based tunneling mechanism. 4. 3GGP2 deployment scenario 3GPP2 based standards assume IP layer mobility when roaming within the cdma2000 network. Many operators who have invested and deployed cdma2000 do so with Yamamoto, et al. Expires August 9, 2004 [Page 5] Internet-Draft MIPv6 node traversal of IPv4 February 2004 PDSN access networks that are IPv4 (i.e., RAN-PDSN is IPv4) and upgrading these PDSN’s may not be a viable option as the operator is trying to recuperate the costs of the IPv4 PDSN network deployment. Gradually IPv6 transition in the RAN-PDSN can be done by while introducing IPv6 PDSN access islands – say in major metropolitan areas. It is also worth noting that PDSN vendors are only now looking at IPv6 but have yet to release commercial products. Carriers will want to trail the service but still launch a Mobile IPv6 service that works in the IPv4 PDSN network as well. In summary, while dual stack deployment would be recommended, trails and gradual integration are valid options of an operator’s transition plan. The incorporation of GLOB6 within 3GPP2 PDSN networks is easy and requires little cost. The automatic tunneling agents can be placed behind the PDSNs in the core network or on the boarder of the IPv4 and IPv6 backbones. In the former case the core network can be dual stack or a tunnel (i.e., 6to4, IGP/EGP) to the IPv6 backbone can be configured. No changes to the RAN-PDSN access network are required. All clients would support a dual stack running ISATAP and Mobile IPv6 with the implementation caveats described above. No protocol modifications or changes are required. 3GPP2 uses PPP as a method for detecting movement of a node and for allocation of the IPv4 address. The Mobile IPv6 node in GLOB6 will also use PPP for these functions when deployed in 3GGP2 networks. As PDSN vendors upgrade their commercial offerings to IPv6, initial IPv6 deployment can happen in the metropolitan areas. However, GLOB6 will allow for a global Mobile IPv6 connectivity even when moving from the metropolitan areas to the rural areas where IPv4 access networks still reside. 5. WLAN Hotspot deployment scenario Most hotspots today use WLAN. IP layer mobility enables roaming between WLAN and other types of access networks types (i.e., 3G). Most hotspots deployed today use private address space. As such there is little motivation for such deployments to upgrade to IPv6. However, if the hotspot provider were able to offer some service that depended on IPv6, this would serve as an incentive for transition. Full scale deployment with Mobile IPv4 is unrealistic for many reasons. However, with the available IPv6 address space combined with the Mobile IPv6 feature being part and parcel of the core protocol, a global roaming service would be possible. The major roadblock that prevents a global roaming service based on Mobile IPv6 is that the WLAN hotspots may not provide IPv6 capability. While tunnel broker services can be used to gain simple IPv6 connectivity; such a service itself doesn’t address the requirements for seamless and automatic connectivity to happen in conjunction with the Mobile Yamamoto, et al. Expires August 9, 2004 [Page 6] Internet-Draft MIPv6 node traversal of IPv4 February 2004 IPv6 handover. The Glob6 scheme enables hotspot deployments as well as other WLAN networks to be part of a global federation whereby global roaming is possible. The hot-spots are not only providing an inexpensive and high performance spectrum alternative to 3G networks but they can also offer their hotspot as one of many points of roaming in a universal mobile network. The deployment of an automatic tunneling method (i.e., ISATAP) within an ISP's network could allow for roaming to take place between the 3G network that may support IPv6 and the WLAN hotspot that may be operated using IPv4 private addresses. The WLAN hotspot network can setup a default route to the ISP's ISATAP router for IPv6 tunneling service for the mobile IPv6 node. No other special deployment infrastructure would be required on the part of the Hotspot operator. The same problems posed by stationary nodes using automatic tunneling methods remain for mobility nodes. It is not the intent of this document to address those short-comings. 6. Conclusions GLOB6 is temporary deployment scheme to enable mobile IPv6 client nodes to seamlessly roam within IPv4 subnets while maintaining IPv6 connectivity. GLOB6 scheme reuses existing IPv6 automatic tunneling method and requires no protocol changes. GLOB6 is supposed to provide a temporary migration solution to allow for the gradual transition of IPv6 within the operator’s access networks. One of the design goals behind GLOB6 was not to come up with a model whereby it became a requirement to over engineer or specify transition solutions in order to solve the problem at hand - that being to enable Mobile IPv6 movement within IPv4 subnets. GLOB6 can be realized today with minimal implementation changes to the mobile IPv6 client and using off the shelve ISATAP routers. The performance of GLOB6 is equivalent to that of base Mobile IPv6. The purpose of this scheme is to only provide backward compatibility of Mobile IPv6, for example, IPv6 mobility within IPv4 subnets. ISATAP is used here as an example; however, other automatic tunneling methods - such as Tunnel Broker - can be used. The authors are currently exploring the tunnel broker model in this respect as well. Related work in this problem space can be found in [4] and [5]. Yamamoto, et al. Expires August 9, 2004 [Page 7] Internet-Draft MIPv6 node traversal of IPv4 February 2004 7. Security Considerations TBD. Normative references [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt, Work In Progress, June 2003. [2] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-16.txt, Work In Progress, October 2003. Informative References [3] Manner, J. and M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-05.txt, Work In Progress, November 2003. [4] Tsirtsis, G. and H. Soliman, "Mobility Management for Dual Stack Mobile Nodes", draft-tsirtsis-dsmip-problem-01.txt, Work In Progress, August 2003. [5] Soliman, H. and G. Tsirtsis, "Dual Stack Mobile IPv6", draft-soliman-v4v6-mipv4-00.txt, Work In Progress, August 2003. [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461 , December 1998. [7] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC3056 , Feb. 2001. [8] Wiljakka, J., "Analysis of IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-08.txt, Work In Progress, January 2004. Authors' Addresses Shu Yamamoto KDDI Labs USA Palo Alto 94301 United States Phone: +650.566.8165 EMail: shu@kddilabs.com Yamamoto, et al. Expires August 9, 2004 [Page 8] Internet-Draft MIPv6 node traversal of IPv4 February 2004 Hidetoshi Yokota KDDI R&D Labs Kamifukuoka-Shi Saitama 356-8502 Japan Phone: 81 (49) 278-7894 EMail: yokota@kddlabs.co.jp Carl Williams KDDI Labs USA Palo Alto, CA 94301 USA Phone: +1.650.279.5903 EMail: carlw@kddilabs.com Mohan Parthasarathy Consultant, KDDI Labs USA Palo Alto 94301 United States EMail: mohanp@sbcglobal.net Yamamoto, et al. Expires August 9, 2004 [Page 9] Internet-Draft MIPv6 node traversal of IPv4 February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. 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 THE INFORMATION Yamamoto, et al. Expires August 9, 2004 [Page 10] Internet-Draft MIPv6 node traversal of IPv4 February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yamamoto, et al. Expires August 9, 2004 [Page 11]