Hyun-Kook Kahng Internet Draft Jin Woo Jung Document: draft-kahng-ngtrans-hdsma-00.txt Jung Hoon Cheon Korea University Expires: 2002 October 2001 Requirements for 4to6 mobility transition using Hierarchical Mobility Agent. 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 the requirements for MIPv4/MIPv6 transition. Researches on the IPv4 to IPv6, or IPv6 to IPv4, transition mechanisms are actively being conducted. These transition mechanisms assume that hosts are attached to the network statically. Currently, developments of communication mechanisms are developed individually and differently. This means that the effects of considering mobile node (MN) roaming in IPv4/IPv6 transition networks have not been investigated. Therefore, this document proposes the requirements and analysis of different routing architecture of MIPv4/MIPv6 transition network. 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 KOREA University [Page1] INTERNET-DRAFT Korea University October 2001 3. Requirements for Internetworking................................5 3.1 Requirements for home domain...................................5 3.2 Requirements for visited domain................................5 3.3 Requirements for DSHA..........................................5 3.4 Requirements for DSFA..........................................5 3.4.1 Requirements for IDSFA.......................................6 3.4.2 Requirements for BDSFA.......................................7 4. Example of scenario.............................................8 4.1 Problem associated with current mobile IP infrastructure.......8 4.2 Proposed routing infrastructure................................8 References.........................................................9 Author's Addresses................................................11 Korea University [Page2] INTERNET-DRAFT Korea University October 2001 1. Introduction Currently, IPv4 forms the basis for the Internet infrastructure, and to apply IPv6 to IPv4 environment, development of transition mechanisms are actively being conducted. Most of the transition mechanisms of IPv6 are to transmit IPv6 packets in IPv4 routing environment. This document describes the requirements for MIPv4/MIPv6 node internetworking based on the communication network structure that enables the mutual transmission between IPv4 and IPv6 node, and also to enable flexible internetworking structure, this document devised and defined more efficient MIPv4/MIPv6 transition network. This document defined and derived a more efficient infrastructure from existing MIPv4 and MIPv6 to achieve a flexible internetworking infrastructure. Therefore, with this internetworking structure and added network configuration, it is assumed that the MIPv4 and MIPv6's best feature of flexible communication structure can be maintained. IPv4/IPv6 node transition mechanism that is developed now will become more stable and adaptable mechanism with times to come. 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 following acronyms are used in this draft: MN Mobile Node CN Correspondent Node MIPv4 Mobile IPv4 Protocol MIPv6 Mobile IPv6 Protocol DSMA Dual Stack Mobility Agent DSHA Dual Stack Home Agent DSFA Dual Stack Foreign Agent BDSMA Boundary Dual Stack Mobility Agent BDSFA Boundary Dual Stack Foreign Agent BDSHA Boundary Dual Stack Home Agent IDSMA Interior Dual Stack Mobility Agent IDSFA Interior Dual Stack Foreign Agent IDSHA Interior Dual Stack Home Agent 2. Terminology This document uses the same terminology as introduced in Mobile IPv4 [1], Mobile IPv6[2] and [3], and [4]. In addition modified terms in [4] and newly terms are defined: Korea University [Page3] INTERNET-DRAFT Korea University October 2001 Domain: A set of networks that only shares same IP version routing. All the routers in same domain should only be configured of either IPv4 or IPv6. Home Domain: A domain that includes the home network and a Dual Stack Home Agent(DSHA). Local Care-of Address: An address that is assigned to foreign agent that provides the connection to the MN. Registration message received from MNs is transmitted via local care-of-address, if it exists, to Boarder Dual Stack Mobile Agent (BDSMA) or other Internal Dual Stack Foreign Agent (IDSFA). If the MN does not have local COA, then MN does not directly transmit to BDSFA. Dual stack mobile agent (DSMA): An agent that supports both MIPv4 protocol and MIPv6 protocol and maps IPv4 address to IPv6 address, or vice versa. DSMA includes all the meanings such as DSHA, Dual Stack Foreign Agent (DSFA), Boarder Dual Stack Foreign Agent (BDSFA), Boarder Dual Stack Home Agent (BDSHA), Internal Dual Stack Foreign Agent (IDSFA) and Internal Dual Stack Home Agent (IDSFA). Dual stack home agent (DSHA): An agent that acts as a home agent to the MN. This agent understands and processes the MIPv4 messages and MIPv6 messages. DSHA has dual stack structures, which enables to communicate with DSMA that has different version of IP, for example NAT-PT, SIIT, and etc. Dual stack foreign agent (DSFA): An agent that act as both foreign agent for MIPv4's MN and default router for MIPv6. This agent also enables the mapping of IPv4 address to Ipv6 address or vice versa. DSFA has transition mechanism that enables to communicate with DSMA by utilizing different IP version and also has tunneling methods to IPv4 and IPv6, for example NAT-PT, SIIT, and etc. Correspondent node (CN): A peer node that communicates with MN. CN may be either mobile or stationary. CN is IPv4-only, IPv6-only, or dual stack node. Border Dual Stack Mobile Agent (BDSMA): An agent is located on the border of domain and has public routable IPv4 and IPv6 address. BDSMA has to support the same transition mechanism that is used in the fixed network. Internal Dual Stack Mobile Agent (IDSMA): An agent that is located within domain and has either public or private routable IPv4 and IPv6 address, but it could have global unique IP address. IDSMA acts as a tunneling point between BDSMA and IDSMA. Korea University [Page4] INTERNET-DRAFT Korea University October 2001 3. Requirements for Internetworking Each Ipv4 and IPv6 has different routing infrastructure, therefore in order to facilitate MIPv4/MIPv6 communication in transition networks the following requirements are needed. 3.1 Requirements for home domain In wired network, translation mechanisms for transition are divided into host-based translation and intermediate node based translation (located in the path between source and destination). In the mobile IP case, the intermediate node based translation may cause a connection between mobile node and correspondent node to break. Therefore the intermediate node MUST be located in the home domain. 3.2 Requirements for visited domain This document assumed that in visited domain, foreign agents have two layers. Thus in visited domain, there has to exist a foreign agent that has at least one added feature such as BDSMA. BDSMA has to have public routable IPv4 and IPv6 address and in the low hierarchy of BDSMA, there exists more than one IDSMA. Furthermore, we assumed that there exists an established security agreement between BDSMA and IDSMA. DSMA's multiple hierarchy level is beyond scope of this paper. When we design a domain that supports such mechanisms, IDSMA and BDSMA has to be compatible. That is, above agents has to support the same encapsulation type, compress mechanism and transition mechanism. 3.3 Requirements for DSHA In order to support the mobility, regardless of IP version, DSHA has to have home agent function of both MIPv4 and MIPv6. But in the proposed infrastructure of transition network, DSHA being BDSHA or IDSHA is irrelevant. DSHA has to have the following functions. - Has to be able to recognize and access MN's registered IP address regardless of IP version. - Has to have global unique IPv4 address and IPv6 address (or IPv4- compatible IPv6 address). - Has to enable mapping from IPv4 address to IPv6 address, or vice versa. - Has to support typical transition mechanisms. - Has to have information on the location of border router. 3.4 Requirements for DSFA In MIPv6 protocol, there is no foreign agent, but in order to provide MIP handoff regional entity is needed within the foreign network. Korea University [Page5] INTERNET-DRAFT Korea University October 2001 Therefore, like MIPv4's foreign agent, DSFA is required in each subnet. DSFA has to implement MIPv4's foreign agent and MIPv6 router's action, and has to be able to recognize IPv4 and IPv6 packets and process them. And also due to the problem occurs during transition of routing from one version to another, this document separately describes DSFA as BDSFA and IDSFA. 3.4.1 Requirements for IDSFA IDSFA has the following requirements: - Has to have global unique IPv4 address and IPv6 address (or IPv4- compatible IPv6 address). - Has to enable mapping from IPv4 address to IPv6 address, or vice versa. - Has to have the tunneling function between BDSFA and itself - Has to support the reverse tunneling - Has to support typical transition mechanism. - Has to have information on the location of border router. For other IP version datagram, DSFA's Tunnel End Point (TEP) has to be configured as domain's border router. - Has to implement MIPv4's foreign agent and MIPv6's border router action. - Has to notify the visited network's IP version (IPv4-only, IPv6- only, or Dual stack network) to MN. - Has to save data that is relevant to MN(eg. MN's home IP address, CN's IP address and etc). Depending on the MN's IP version and visited network's IP version, DSFA operates in four different operation modes. - IDSFA in IPv4-only network: If MN is IPv4-only system, IDSFA operates like mobile agent in MIPv4. IDSFA only receives IPv4-in-IPv4 packet that is tunneled from DSHA, IDSFA decapsulates the received packet and forwards IPv4 packet to MN. Operating procedure of IDSFA on MIPv4MN is similar to that of existing MIPv4, but if MN receives packet from CN, then correspondent's IP version has to take into account. This document assumes that the mechanism implemented in here is as same as stable transition mechanism applied in fixed network. Therefore, IPv4to6 transition is beyond scope of this document. If MN is IPv6-only system, IDSFA operates like IPv6 router. Therefore, IDSFA, like that of IPv6 router, transmits router advertisement to the subnet periodically. When MN receives this advertisement, it sets this IDSFA as its default router. IDSFA receives IPv6-in-IPv4 packet that is tunneled from BDSFA, then checks on MIPv6's visitor list and directly forwards the interior IPv6 packet to the matching MN. When MN transmits packet to CN, MN has to transmit packet to CN through IDSFA. When IDSFA receives IPv6 packet destined for CN, then it checks the Diff-visitor list (MN that uses IP version which is Korea University [Page6] INTERNET-DRAFT Korea University October 2001 different from foreign network's IP version.) and tunnels the received packet to BDSMA using IPv4 tunneling method. - IDSFA in IPv6-only network: If MN is IPv4-only system, IDSFA operates as mobile agent in MIPv4. An IDSFA receives IPv4-in-IPv6 packet that are tunneled from BDSFA or that are translated from Home Translator. Then, IDSFA decapsulates (or translates) the received packet and forwards the internal IPv4 packet to MN. While MN transmits registration message to DSHA, IDSFA tunnels that message to BDSFA. TEP of IDSFA has to be configured with domain's internal BDSFA interface. If MN is IPv6-only system, IDSFA operates like IPv6 router. Since MN is located on IPv6 foreign network, MN receives router advertisement from many IPv6 routers including IDSFA. In this paper, MN is able to select arbitrary router as a default router for IPv6-only foreign network. Therefore, mobility mechanism supporting IPv6 is as same as the one in existing MIPv6 protocol. - IDSFA in dual stack network Foreign network is a dual stack network that utilizes both IPv4 routing protocol and IPv6 routing protocol. Thus, both IPv4 packet and IPv6 packet can be routable to MN. In IPv4 point of view, IDSFA operates like a mobile agent in MIPv4. If IDSFA acts as a mobile agent in MIPv4, IDSFA receives IPv4-in-IPv4 packets whose destination address is a IPv4's COA, which is tunneled from DSHA. Therefore, IDSFA decapsulates the packet and forwards the internal IPv4 packet to MN. In IPv6 point of view, DSFA operates like IPv6 router. But, because the foreign network is dual network, a number of routers transmit router advertisement periodically. Therefore, MN is able to select arbitrary router as a default router in dual stack network. 3.4.2 Requirements for BDSFA In order to connect MIPv4-only or MIPv-6-only network to different IP version network, network has to have domain's border router that acts as BDSMA. BDSMA has to implement tunneling/reverse tunneling mechanism at both IPv4 and IPv6, and has to have a function of transition mechanism in the fixed network. Thus, BDSHA (or IDSHA) should receive the entire packet of MN, encapsulate it and forward it to current address of MN. The transition mechanism between IDSHA in home network and BDSFA in visited domain, should be operational with the existing and future mechanism. Thus, BDSMA in IPv4-only network should be implemented on MIPv6 over MIPv4 [9]. When confronted to foreign network, MN recognizes global unique address of BDSFA regardless of MN's IP version. Korea University [Page7] INTERNET-DRAFT Korea University October 2001 In visited network, the allocation of COA could be either static or non-static. Generation of IPv6 address and IPv4/IPv6 address mapping is beyond scope of this paper. The related information can be found on reference [7]. New BDSMA option in router advertisement message notifies MN the presence of BDSFA. 4. Example of scenario This document points out the current problems associated with MIP, and showed following routing infrastructure for MIPv4/MIPv6 transition network. 4.1 Problem associated with current mobile IP infrastructure. In the case of existing MIP, when MN move to other network, it alerts the home agent its movement and at the same time registers with its new COA. If MN continuously moves around the limited routing space, MN registration procedure becomes continuous, therefore home agent gets an overhead on MN registration. To provide a solution to such problem, IETF mobile-IP WG is working on the local registration. (draft-ietf-mobileip-reg-tunnel-05.txt) When MIPv4 and MIPv6 routes, more serious problems may arise from the existing MIP. If MN moves while communicating with CN, and if visited domain and CN has a different IP version, address is converted by address converter before transmitting. If MN moves to other domain, converter recognizes another converting point and causes the loss of previous converting point. Therefore, this paper designed and proposed hierarchical MIPv4 and MIPv6 routing infrastructure that is similar to the local registration. 4.2 Proposed routing infrastructure. We proposed the following routing infrastructure. [figure 1] Through this routing infrastructure, registration of MN takes place with the following procedure. +----+ | CN | +--+-+ | +-----------------------------------------+----------------------+ | | | IPv4 routing Infrastructure | | +-------------------------------------------+ | | | (4) Forwarding or Tunneling or Transition | | | | Registration Request | | Korea University [Page8] INTERNET-DRAFT Korea University October 2001 | | +-----------------------------------+ | | | | | (6) Registration Confirm | | | | V | V | | | +-----+ +-----+ | +-----|BDSHA|-------------+-------------------|BDSHA|------------+ | +-----+ | +-----+ | | | ^ (5)Forwarding| | ^(3)Forwarding | | V | or Tunneling | V | or Tunneling | | +-----+ | +-----+ | | |IDSHA| Home Domain | Visited Domain |IDSFA| | | +-----+ | +-----+ | | | | | ^ (2) | | |(7)Registr. Confirm | | |Registration | +-------------------------+--------------------|-|-|-------------+ (1)Advertisement V V | +----+ +----+ | MN |-----------------------> | MN | +----+ Moving +----+ Figure 1. Example of hierarchical MIPv4/MIPv6 routing infrastructure (1) IDSFA periodically advertises both an Agent Advertisement Message in mobile IPv4 and a Router Advertisement Message in IPv6. (2) MN sends a Registration Request Message (i.e, registration request message for mobile IPv4 or Binding Updates for mobile IPv6) to the IDSFA according to the IP version of mobile node. (3) IDSFA forwards (or tunnels) a Registration Request Message to the Boundary DSFA(BDSFA). (4) BDSFA received Registration Request message on the visited domain updates registration information of the visitor list (or diff-visitor list) forwards (or tunnels) the Message to the IDSHA(if BDSHA, via BDSHA). (5) BDSHA received valid Registration Request message updates registration information for the mobile node and forwards the message to IDSHA. IDSHA updates own home list, then tunnels (or forwards) Registration Confirm message to BDSHA. (6) IDSHA reply with Registration Confirm Message to the BDSFA on the visited domain. (7) IDSFA sends Registration Confirm Message to the MN. 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. Korea University [Page9] INTERNET-DRAFT Korea University October 2001 [3] Shiao-Li Tsao, Georage Tsirtsis, Wolfgang Boehm, Editor. "Moving in a Dual Stack Internet", draft-ietf-ngtrans-moving-00.txt, July 2001. [4] P. Engelstad, "Transitional Integration of Mobile IPv4 and Mobile IPv6", draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt, August 2001. [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993. [7] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", IETF RFC 2462, Dec. 1998. [8] R. Callon, D. Haskin, "Routing Aspects of IPv6 Transition", RFC 2185, September 1997. [9] B. Carpenter, C. Jung., C. "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529. [10] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1998. Korea University [Page10] INTERNET-DRAFT Korea University October 2001 Author's Addresses Jin Woo Jung Korea University Dept. of Electronic Information Engineering Phone: +82-41-860-1424 Seoul, Korea Email: grjjw@tiger.korea.ac.kr Hyun Kook Kahng Korea University Dept. of Electronic Information Engineering Phone: +82-41-860-1424 Seoul, Korea Email: kahng@tiger.korea.ac.kr Jung Hoon Cheon Korea University Dept. of Electronic Information Engineering Phone: +82-41-860-1424 Seoul, Korea Email: grcurly@tiger.korea.ac.kr Korea University [Page11]