Hyun-Kook Kahng Internet Draft Jin-Woo Jung Document: draft-kahng-mobileip-moving6to4-00.txt InJun Hwang KeumYoun Kwon Korea University Expires: January 2004 Agust 2003 An interconnection mechanism of Mobile IPv6 using 6to4 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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 This document specifies a new mechanism to solve mobility problems over IPv6 transition networks which IPv6 sites are interconnected over a wide area network which has no native IPv6 support[4]. This draft defines an extended mechanism of 6to4 mechanism[4] and Mobile IPv6[2] to support mobility over 6to4. It also describes scenarios for using the proposed mechanism during the co-existence period. Hyun-Kook Kahng [Page1] INTERNET-DRAFT Mobile 6to4 August 2003 1. Introduction 6to4 is one of the most powerful transition mechanisms. It is designed to allow IPv6 hosts in 6to4 sites to communicate with other IPv6 hosts in other 6to4 sites. While it is believed that a 6to4 mechanism supports the transition to IPv6, it has several limitations over IPv6 mobility environment. This draft defines an extension of 6to4 mechanism[4] and Mobile IPv6[2] to support mobility over 6to4. It also describes scenarios for using the proposed mechanism during the co-existence period. The aim for this document is to allow IPv6 hosts to remain reachable while moving round in the isolated IPv6 sites, attached to a wide area network which has no native IPv6 support. There are 3 cases to consider: 1) The mobile node has IPv6 connectivity with correspondent node in other 6to4 sites and roams a 6to4 network. This case is covered in section 3.1 2) The mobile node has IPv6 connectivity with correspondent node in native IPv6 sites and roams a 6to4 network. This case is covered in section 3.2 3) The mobile node has both IPv6 connectivity in above (1) and (2) and roams a 6to4 network. This case is covered in section 3.2 4) The mobile node has IPv6 connectivity with correspondent node located in a 6to4 sites and roams a new native IPv6 sites. This case is covered in section 3.3 1.1 Requirement Languages In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. 1.2 Assumption We assume that the mobile node implements Mobile IPv6 and that the MIPv6 home agent has a 6to4 address and native IPv6 address. The mobile node may know the native IPv6 prefix and 6to4 prefix through regular mobile IPv6 agent advertisements. Packets destined for IPv6 Anycast address MUST be routed to correct network via 6to4 relay router. Hyun-Kook Kahng [Page2] INTERNET-DRAFT Mobile 6to4 August 2003 1.3 Terminology This section presents a few terms used through the document. This document uses the same terminology as introduced in Mobile IPv6[2], 6to4[4]. 6to4 site: A site running IPv6 internally using 6to4 addresses, therefore containing at least one 6to4 host and at least one 6to4 router[4]. Native IPv6 Wide Area Network: A site which has at least one native IPv6 prefix which is not a 6to4 prefix(2002:: prefix). Correspondent Node: Any node communicating with a mobile node by using native IPv6 address or 6to4 address. 2. Overview of mobile 6to4 2.1 Basic Operation Figure 1 shows the basic architecture of mobile 6to4 mechanism proposed in this document. +--+--+ | CN | +--+--+ +--------------+--------------+ | | | 6to4 domain | | | | +------+ | +-----------+------------+-----------| 6to4 |----------+---------+ | | +------+ | |Native IPv6| | | | Wide Area IPv4 Network | | Wide Area | | | Network | | | | | | # | # | | #------# +------+ | +-----| 6to4 |------------+--------+-----------| 6to4 |----------+ | |Router| | | |Router| | | +------+ | | +------+ | Hyun-Kook Kahng [Page3] INTERNET-DRAFT Mobile 6to4 August 2003 | | | | | | | | | | | | | +-----+ | | | | | HA | Home Site | | Visited 6to4 Site | | +-----+ | | | | | | | | | | | +-------------------------+ +-----------------------------+ Figure 1. Network architecture of mobile 6to4 The 6to4 router which has a global unique IPv4 address is able to advertise 6to4 prefix and another prefixes of default relay router. It is normally the border router between IPv6 site and wide area IPv4 network. The 6to4 router supports a "6to4 Relay anycast prefix" based on [12]. By using this mechanism, the mobile node may know the address of any router on its home link that can serve as a home agent for it. Home Agent(HA) located in a home site MUST advertise 6to4 prefix and its native IPv6 prefix. Also, it must support Mobile IPv6. 2.2 Address Selection in mobile node In our architecture, a mobile node has "home address" and "care-of addresses" like as mobile IPv6. To ensure the correct operation of mobile node in complex topologies, the home address and desired care-of address selection must be appropriately defined. 2.2.1 Home Address Selection The method for home address selection is similar with the address selection[2.1 in ref. 4] in 6to4. However, for a home address the 6to4 address is preferable for default configuration. 2.2.2 Primary Care-of Address Selection While a mobile node is away from home, it uses one or more care-of addresses. If mobile node receives Router Advertisement message from Router after moving into other networks, MN will have autoconfigured address using prefix information in RA message. When sending BU message to HA while away from home, a mobile node MAY choose among these in selecting the address that it will use as the primary CoA of the packet. In our method, the 6to4 address is preferred to native IPv6 address as primary care-of address. The mechanism for care-of address selection is the following principle: Hyun-Kook Kahng [Page4] INTERNET-DRAFT Mobile 6to4 August 2003 If mobile node has only a 6to4 address as home address, and if a visited network supports native IPv6 prefix and 6to4 prefix, then mobile node must generate 6to4 address based on 6to4 prefix and use 6to4 address as a primary CoA. If mobile node has both 6to4 address and native IPv6 address as home address, and if a visited network supports native IPv6 prefix and 6to4 prefix, then it generates both native IPv6 address and 6to4 address and uses only a 6to4 address as a primary CoA. If mobile node fails to generate 6to4 address because of address duplication, it can use native IPv6 address as a primary CoA. The default configuration should be 6to4 address. An alternative method is that mobile node registers two different CoA for both 6to4 address and native IPv6 address with HA. i.e. if mobile node has both 6to4 address and native IPv6 address as home address, and if a visited network supports native IPv6 prefix and 6to4 prefix, then it generates both native IPv6 address and 6to4 address, and uses both a 6to4 address and native IPv6 address as CoAs. It registers 6to4 address as a primary CoA for home 6to4 address and native IPv6 address as a primary CoA for home native IPv6 address with HA. Multiple CoA registration is out of scope in this document. 2.3 Mobile Node Operation The method proposed here conforms with the Mobile IPv6[2] and 6to4 mechanisms[4] to solve mobility problems over 6to4. All message types, data structures, and message procedures specified within this document are used unmodified, unless otherwise noted. The mobile node MUST register its primary CoA with HA after movement detection. The primary CoA selection rule follows section 2.4 in this document. If a mobile node has 6to4 address or native IPv6 address as home address and a correspondent node has native IPv6 address, then mobile node MUST send the packets via reverse tunneling [11.3.1 in ref. [2]]. If a mobile node has 6to4 address or native IPv6 address as home address and a correspondent node has 6to4 address, then it needs to ensure that there exists a Binding Cache entry for its home address so that the correspondent node can process the packet. If the Binding Cache entry exists, it can directly send packets to the correspondent node. 2.4 MTU considerations TBD Hyun-Kook Kahng [Page5] INTERNET-DRAFT Mobile 6to4 August 2003 3 Mobile 6to4 Transition Scenarios 3.1 IPv6 connectivity with correspondent node in other 6to4 sites If the mobile node has the IPv6 connectivity with correspondent node located in other 6to4 sites, and if it roams other 6to4 sites, it MUST be able to retain its existing connectivity. In this section, we specify two scenarios for retaining 6to4 connectivity between the mobile node and the correspondent. For this scenario, they do not need to support external routing protocol. 3.1.1 Route Optimization If the mobile node knows that the correspondent node has a suitable Binding Cache entry specified in [2], it can deliver packets without going through the home network. In this case, the mobile node has an 6to4 based connectivity with correspondent node. Also the mobile node can form 6to4 address as its primary CoA from 6to4 prefix advertised by foreign 6to4 router. All procedures for mobile IPv6 are maintained without modification [2]. 3.1.2 Reverse Tunneling If the correspondent node does not support mobile IPv6, and even if the mobile node has not registered its current binding with the correspondent node, the mobile node and correspondent node MUST always deliver packets through the home network. In this case, its home address is 6to4 address and its primary CoA also is 6to4 address. And, all procedures for mobile IPv6 are same to the procedure of reserve tunneling in [2]. 3.2 IPv6 connectivity with correspondent node in native IPv6 sites In this section, we specifies two scenarios when the mobile node has the IPv6 connectivity based on native IPv6 address with correspondent node located in native IPv6 network. When the mobile node moves a new 6to4 site, it can acquire both a native IPv6 address and 6to4 address as CoAs. For this case, the mobile node MUST register both a native IPv6 address and 6to4 address with Home Agent. Therefore, the separated Binding Update Hyun-Kook Kahng [Page6] INTERNET-DRAFT Mobile 6to4 August 2003 message for each address MUST be delivered to Home Agent, respectively. This procedure for registering multiple home addresses is out of scope. 3.2.1 Route Optimization If the correspondent node can support mobile IPv6, and if the mobile node has a Binding Cache for the correspondent node, the mobile node can directly communicate with the correspondent node. In this scenario, the mobile node MUST select the primary CoA by classifying the Home Address (i.e. if the mobile node has a native IPv6 address, the native IPv6 address is selected as the primary CoA. If the mobile node has both a 6to4 address and native IPv6 address, it MUST register each address with home agent and update binding information in the correspondent node, respectively). 3.2.2 Reverse Tunneling Like as 3.2.1, the mobile node registers both a 6to4 address and native IPv6 address with the Home Agent and correspondent node. However, because the relay router applies source address based filters to accept traffic only from specific 6to4 routers, the messages between Home Agent and the mobile node MUST be delivered by using 6to4 address. NOTE: Sometimes, the new 6to4 site cannot support the routing for the native 6to4 sites because of scaling issue of relay router. If the mobile node has both the 6to4 address and native IPv6 address, the reverse tunneling is recommended. 3.3 A MN roams a new native IPv6 sites when its home network is 6to4 site. When the mobile node's home network is a 6to4 site and a mobile node has an IPv6 connection with a correspondent node in other 6to4 site, it cannot directly communicate with the correspondent node. In this case, if the mobile node moves a new native IPv6 network, it can only generate a native IPv6 addresses as CoAs. Therefore, the mobile node MUST use a native IPv6 address as a primary CoA and register a native IPv6 address with home agent. Because the mobile node can have both a native IPv6 address and 6to4 address, it MUST register its primary CoA with home agent by using the separated BU. Hyun-Kook Kahng [Page7] INTERNET-DRAFT Mobile 6to4 August 2003 NOTE: If the mobile node does not support a 6to4 mechanism, it MUST use the reverse tunneling mechanism specified in [2]. References [1] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. [2] D. Johnson and C. Perkins, J. Arkko, "Mobility Support for IPv6", draft ietf-mobileip-ipv6-24.txt, June 2003. [3] Hyun-Kook Kahng, Jin Woo Jung, Jung Hoon Cheon, "Requirements for 4to6 mobility transition using hierarchical Mobility Agent", dreft-ietf-ngtrans-hdsma-00.txt, October 2001. [4] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [5] Shiao-Li Tsao, Georage Tsirtsis, Wolfgang Boehm, Editor. "Moving in a Dual Stack Internet", draft-ietf-ngtrans-moving- 01.txt, July 2001. [6] P. Engelstad, "Transitional Integration of Mobile IPv4 and Mobile IPv6", draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt, August 2001. [7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993. [9] S. Thomson and T. Narten, "IPv6 Stateless Address Auto- configuration", IETF RFC 2462, Dec. 1998. [10] R. Callon, D. Haskin, "Routing Aspects of IPv6 Transition", RFC 2185, September 1997. [11] B. Carpenter, C. Jung., C. "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529. [12] C. Huitema, "An Anycast prefix for 6to4 Relay Routers", RFC 3068, June 2001. Hyun-Kook Kahng [Page8] INTERNET-DRAFT Mobile 6to4 August 2003 Author's Addresses Hyun Kook Kahng Korea University Electronic Information Engineering Phone: +82-41-860-1424 Seoul, Korea Email: kahng@korea.ac.kr Jin Woo Jung Korea University Electronic Information Engineering Phone: +82-41-860-1424 Seoul, Korea Email: jjw@korea.ac.kr InJun Hwang Korea University Electronic Information Engineering Phone: +82-41-860-1424 Seoul, Korea Email: hwangij@korea.ac.kr KeumYoun Kwon Korea University Electronic Information Engineering Phone: +82-41-860-1424 Seoul, Korea Email: kwonky@korea.ac.kr Hyun-Kook Kahng [Page9]