HyunKook Kahng Internet Draft JinWoo Jung Document: draft-kahng-ngtrans-moving6to4-00.txt JaeEun Kim Korea University Expires: December 2002 June 2002 An interconnection mechanism of Mobile IPv4 and 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. 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 using 6to4 to solve mobility problems in IPv4 and IPv6 interconnected networks. This draft is based on the Architecture of Hierarchical Dual Stack Mobility Agent(HDSMA) that supports the IP version-independent mobility of mobile node and improves the registration efficiency and the performance[3]. The aim is to support 6to4 mechanism for IPv6 transition while mobile node only uses mobile IPv6 capability for mobility services. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 1.1 Requirement Languages.........................................3 1.2 Abbreviations..................................................3 2. Terminology.....................................................3 3. Architecture of HDSMA...........................................4 3.1 Function of Dual Stack Mobile Agent(DSMA)......................4 KOREA University [Page1] INTERNET-DRAFT Korea University June 2002 3.2 Function of IDSMA..............................................5 3.3 Function of BDSMA..............................................5 4. HDSMA using 6to4 transition mechanism...........................5 References.........................................................6 Author's Addresses.................................................8 Korea University [Page2] INTERNET-DRAFT Korea University June 2002 1. Introduction Though it is believed that a transition mechanism must support the mobility regardless of the MN's IP version, when a mobile node moves from IPv4 network to IPv6 network, or vice versa, the existing mobile IP mechanism has difficulties in supporting the version- independent mobility. While routers as mobile agents should provide routing services and tunnels datagrams for delivery, those routers as relay routers also should support transit routing between 6to4 addresses and native IPv6 addresses. Since mobile nodes(MN) have limited capabilities, it should not be assumed that MN is of dual stack. i.e. the routers should be of dual stacks. This document describes a new mechanism using 6to4 to solve mobility problems in IPv4 and IPv6 interconnected networks. MIPv6-only mobile node can communicate between isolated IPv6 domain, attached to an IPv4 network which has no native IPv6 support, and other such IPv6 domain. This architecture achieves 6-to-4 transition by implementing 6to4 mechanism at domain boundary dual stack mobile agents(BDSMA), and mobility by implementing dual stack of MIPv6 and MIPv4 at interior dual stack mobile agents(IDSMA) and BDSMA. Due to this hierarchical operations, we refer this architecture to Hierarchical DSMA(HDSMA). Using this interconnecting mechanism and added network configuration, it is believed that the MIPv4 and MIPv6Æs best feature of flexible communication structure can be maintained. 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 Abbreviations The acronyms are to be interpreted as described in HDSMA[3]. 2. Terminology This document uses the same terminology as introduced in Mobile IPv4 [1], Mobile IPv6[2] and HDSMA[3], and 6to4 transition mechanism[4]. In addition modified terms in HDSMA[3] and newly terms are defined: 6to4 Domain: A set of networks that shares IPv6 routing. All the routers in same domain should have a 6to4 pseudo-interface[4]. 6to4 Care-of Address : A care-of address constructed using a 6to4 prefix. Korea University [Page3] INTERNET-DRAFT Korea University June 2002 3. Architecture of HDSMA Figure 1 shows routing infrastructure for MIPv4/MIPv6 transition network. The simplest deployment scenario for the proposed solution is to use it between a number of sites, each of which has at least one connection to a shared IPv4 Internet. Our proposed mechanism is based on the architecture of HDSMA that enables the mutual transmission between isolated IPv6 domain, attached to an IPv4 network which has no native IPv6 support, and other such IPv6 domain. Each IPv4 and IPv6 domain has different routing infrastructure, and a domain MUST have a BDSMA and one more IDSHA. +----+ | CN | +--+-+ | +-----------------------------------------+----------------------+ | | | Wide Are IPv4 Network | | +-------------------------------------------+ | | | | | | | | | | | +-----------------------------------+ | | | | | | | | | V | V | | | +-----+ +-----+ | +-----|BDSHA|-------------+-------------------|BDSFA|------------+ | +-----+ | +-----+ | | | ^ | | ^ | | V | | V | | | +-----+ | +-----+ | | |IDSHA| Home Domain | Visited Domain |IDSFA| | | +-----+ | (6to4 domain) +-----+ | | | | | ^ | | | | | | | +-------------------------+--------------------|-|-|-------------+ V V | +----+ +----+ | MN |-----------------------> | MN | +----+ +----+ Figure 1. Architecture of Hierarchical Dual Stack Mobility Agent 3.1 Function of Dual Stack Mobile Agent(DSMA) Agents such as DSHA, DSFA, IDSFA, IDSHA, BDSHA, and BDSFA are DSMA[3]. DSMA MUST support MIPv6 services. In the proposed infrastructure of transition network, DSMA MUST have the following functions. - MUST be able to recognize and process a 6to4 CoA of MN. - MUST have a global unique IPv4 address. Korea University [Page4] INTERNET-DRAFT Korea University June 2002 - MUST support a 6to4 transition mechanism. It is normally the border router between IPv6 site and IPv4 network. 3.2 Function of IDSMA IDAMA located within a domain has either public or private routable IPv6 address. In order to provide MIPv6 operation, IDSHA operates MIPv6 Home Agent and IDSFA acts as IPv6 router. - MUST be able to advertise 6to4 prefix of default Relay router. - MUST support mobile IPv6 service. 3.3 Function of BDSMA BDSMA is located on the border of domain and has public routable IPv4 address and 6to4 address. It acts as a tunneling point between two BDSMAs. - MUST be able to operating 6to4 relay router. - MUST support tunneling mechanism. 4. HDSMA using 6to4 transition mechanism Figure2 is MIPv6 registration procedure of Mobile IPv6 using 6to4 transition mechanism. +----------------+ | CN | +----------------+ | ^ +----------------------------------------|---------|--------------+ | +-------------------8------------+ | | | | IPv4 Network | 10 | | |+------------------4---------------------+| | | || || | | ||+-----------------6-------------------+ || | | |||+-----------------------------------+| || | | |||| || || | | VV|| VV || | | +-----+ +-----+ | +-----|BDSHA|-------------+-------------------|BDSFA|-------------+ | +-----+ | +-----+ | | ||^^ | || ^| | | |5|9 | |7 3| | | VV|| | VV || | | +-----+ | +-----+ | | |IDSHA| Home Domain | Visited Domain |IDSFA| | | +-----+ | +-----+ | | | || ^| | | | 1| || | | | || 2| | | | VV || | | +------+ | +------+ | Korea University [Page5] INTERNET-DRAFT Korea University June 2002 | | MN |----------------------->| MN | | | +------+ | Moving +------+ | | | | | | | +-------------------------+---------------------------------------+ Figure 2. Registration procedures of MIPv4/MIPv6 using 6to4 (1) IDSFA periodically advertises Router Advertisement with 6to4 prefix of default relay router. (2) When a MN using mobile IPv6 roams into visited domain, it receives Router Advertisement. Then it constructs a 6to4 CoA by using the Address Autoconfiguration and sends a Binding Update Message to the IDSHA. (3) On receiving a Binding Update Message, IDSFA sends to a default Relay Router(BDSFA)[4] directly. (4) BDSFA encapsulates Binding Update Message from MN with V4ADDR[4] that described into the RFC 3056[4]. Then, BDSFA forwards the encapsulated Binding Update Message to BDSHA. (5) On receiving valid encapsulated packet, the BDSHA decapsulates the received packet to retrieve the original packet and forwards the Binding Update Message to IDSHA. The IDSHA updates own binding list, then sends Binding Acknowledgement Message to MN. (6) On receiving a Binding Acknowledgement Message, BDSHA encapsulates it and sends to BDSFA on the visited domain by tunneling. (7) BDSFA decapsulates a tunneled packet and forwards decapsulated packet to IDSFA. IDSFA only forwards the Binding Acknowledgement Message to the MN. (8) After completed Binding Update procedures between IDSHA and MN, if IDSHA receives a packet that configures home address from CN, it encapsulates that packet by using MN's 6to4 CoA. (9) IDSHA sends encapsulated packet via BDSHA which encapsulates the received packet in 6to4 tunnel. (10) On receiving a twice- twice-encapsulated packet, a mobile node updates binding to CN. This binding update message is transmitted via BDSFA using 6to4 transition mechanism. References [1] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. [2] D. Johnson and C. Perkins, "Mobility Support for IPv6", draft- ietf-mobileip-ipv6-14.txt, July 2000, Work in Progress. [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. Korea University [Page6] INTERNET-DRAFT Korea University June 2002 [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 Autoconfiguration", 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] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1998. Korea University [Page7] INTERNET-DRAFT Korea University June 2002 Author's Addresses Hyun Kook Kahng Dept. of Electronics and Information Engineering Korea University Seoul, Korea Email: kahng@korea.ac.kr Phone: +82-2-3290-3989 Jin Woo Jung Dept. of Electronics and Information Engineering Korea University Seoul, Korea Email: jjw@korea.ac.kr Phone: +82-2-3290-3989 Jae Eun Kim Dept. of Electronics and Information Engineering Korea University Seoul, Korea Email: jindia@korea.ac.kr Phone: +82-2-3290-3989 Korea University [Page8]