Network Working Group S. Jeong Internet-Draft ETRI Expires: December 21, 2006 Y-H. Han KUT M-K. Shin H-J. Kim ETRI June 19, 2006 Network-based Mobility Support for Dual Stack Nodes draft-jeong-netlmm-dual-stack-moving-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes the network-based mobility support for dual stack mobile nodes moving into an IPv4-only or an IPv6-only subnetwork within a NETLMM domain. This memo also presents a network-based global mobility management protocol with support of IPv4-IPv6 Jeong, et al. Expires December 21, 2006 [Page 1] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 traversal. By utilizing this document, mobile nodes can move from an IPv4/IPv6 dual stack localized domain to an IPv6-only (or IPv4-only) localized domain without any IP session disruption. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7 5. Scenarios for Dual Stack Mobile Nodes . . . . . . . . . . . . 8 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 12 6.1. Scenario 1: Moving into an IPv4-only or IPv6-only subnetwork within a NETLMM Domain . . . . . . . . . . . . 12 6.1.1. MN moves into IPv6-only subnetwork in a NETLMM domain . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.2. MN moves into IPv4-only subnetwork in a NETLMM domain . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Scenario 2: Foreign NETLMM domain only supports IPv6 . . . 14 6.2.1. Binding Management . . . . . . . . . . . . . . . . . . 14 6.2.2. Protocol Operation . . . . . . . . . . . . . . . . . . 15 6.3. Scenario 3: Foreign Netlmm domain only supports IPv4 . . . 15 6.3.1. Binding Management . . . . . . . . . . . . . . . . . . 15 6.3.2. Protocol Operation . . . . . . . . . . . . . . . . . . 16 6.4. Dual Stack Mobile Node Specification . . . . . . . . . . . 17 6.5. AR Specification . . . . . . . . . . . . . . . . . . . . . 17 6.6. GMAP Specification . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Jeong, et al. Expires December 21, 2006 [Page 2] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 1. Introduction The Internet is now evolving towards a commercial carrier-grade IP network with appropriate QoS and security. Mobility management is one of the important factors in realizing such a mature IP network. Many proposals on IP mobility management for the Internet have considered the use of end-to-end principles. However, it is well known that mobility management has been based on network intelligence in existing and conventional telecommunication networks. That is, mobility management has been handled through collaboration between the network nodes. Recently, the IETF NETLMM WG has launched standardization of network- based IP mobility management in a localized domain network. According to [I-D.ietf-netlmm-nohost-ps], some problems of the existing IP-level protocols for localized mobility management are summarized as follow: 1) change of host stack software, 2) complex security associations between network nodes and hosts, and 3) lack of supporting IPv4 and IPv6. Thus, the standardization result of IETF NETLMM WG is expected to be the interoperable and scalable localized mobility management protocol with no requirement of host stack change. It will have a more modular architecture which is independent of any other existing global mobility management protocols. It should be noted, however, that while one of NETLMM's goals is not to require updates on the host software, some update is still required for global mobility management. When a host moves across localized domains, the host's software should execute its mobility management protocol to handle global mobility. So, relying on adding such software to a host will still limit the lack of widespread deployment of new features. The size of a global mobility management protocol stack is expected to be no less than a localized mobility management protocol stack. During the transition period from IPv4 to IPv6, it is likely that there are heterogeneous localized domains deploying different IP stacks on their network equipments. That is, in a localized domain, we can find different subnetworks only supporting IPv4 or IPv6. Also, it is expected that one localized domain deploys only IPv4, while other domain deploys only IPv6. Even though the results of NETLMM will support both IPv4 and IPv6, a host is expected to use different protocols, e.g. MIPv4 and MIPv6, to maintain connectivity while moving between such localized network domains deploying different IP stacks. As mentioned in [I-D.ietf-mip6-dsmip-problem], the burdens of implementation and operation, the inefficiency of mobility management, and the impossibility of IP connection will occur if different mobility protocols would be used simultaneously Jeong, et al. Expires December 21, 2006 [Page 3] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 for global mobility management. Moreover, if a software upgrade to each host is required to accommodate such mobility protocols, it will further hinder the broad deployment of those protocols. This document is aimed to address and solve the similar problems as the ones proposed by both [I-D.ietf-netlmm-nohost-ps] and [I-D.ietf- mip6-dsmip-problem]. It will describes the efficient support for mobile nodes moving into an IPv4-only or IPv6-only subnetwork within a NETLMM domain. It will also describes a network-based global mobility management protocol with support of IPv4-IPv6 traversal. By utilizing this document, mobile nodes can move from an IPv4/IPv6 dual stack localized domain to an IPv6-only (or IPv4-only) localized domain without any IP session disruption. Jeong, et al. Expires December 21, 2006 [Page 4] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 2. Terminology Terminology in this document follows that in [RFC3753] and [I-D.ietf- netlmm-nohost-ps], with the addition of some new and and revised terminology given here: o Global Mobility Management Protocol : Unlike Mobile IP, HIP, and MOBIKE, the Global Mobility Management Protocol of this Document is a mobility protocol used by network nodes to change the global, end-to-end routing of packets for a mobile nodes. The purposes of global mobility management protocol is to maintain session continuity when movement causes a topology change of a NETLMM domain. o MNID : A mobile node's unique identifier. E.g., MAC address of the mobile node's interface o GMAP : A node in the network where a mapping between mobile node's permanent address and the subnet-local temporary address is stored and managed. GMAP may be used for purposes of rendezvous and possibly traffic forwarding. It also handles the NETLMM domain movment events of a mobile node. It registers the association of a mobile node's permanent address with its domain-local temporary address into Home GMAP. On behalf of a mobile node, that is, GMAP itself manages its global mobility. o Home GMAP : A node in the network where a mapping between a mobile node's permanent address and the domain-local temporary address is stored and managed. Home GMAP may be also used for purposes of rendezvous and possibly traffic forwarding. o AR (Access Router) : A router in a NETLMM Domain, which handles the movement events of a mobile node, registers the association of a mobile node with its point of attachment to a GMAP and provides routing services to mobile nodes. Jeong, et al. Expires December 21, 2006 [Page 5] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 3. Problem Statement The problem statements used to motivate this document are similar to both [I-D.ietf-netlmm-nohost-ps] and [I-D.ietf-mip6-dsmip-problem]. Among the all problems mentioned in the two documents, however, some problems do not pertain to this document, while others are closely connected to this document. The following lists such relevant problems. The first problem is that current global mobility management requires updates to the host software, which hinders the broad deployment of those protocols. Even though the end-to-end intelligence is the design philosophy used in IETF, many mobile network operators have pointed out that several problems caused by the end-to-end approach are not suitable to realize the commercial carrier-grade All-IP mobile network. NETLMM WG tries to eliminate such a software update to a host by shifting the mobility management function from host to access router. However, a software upgrade to a NETLMM-compliant host is still required since it should support a global mobility management protocol. The second problem is that complex security associations between network nodes and hosts are still required for the existing global mobility management solutions, even though NETLMM solution is utilized. In addition to the additional signaling required to set up the security associations, provisioning a host with credentials for roaming to all the localized domains will hinder the broad deployment of the future All-IP mobile network. The third problem is that existing mobility management protocols do not simultaneously support both IPv4 and IPv6. So, the network operator would need to have two separate GMAPs implementing different protocols, each supporting IPv4 or IPv6, or make a GMAP support both protocols. Network signaling messages, configuration information, operational and implementation burdens would be doubled. In addition to them, since the IPv4-IPv6 traversal is not supported by existing mobility management protocols, a node moving to a new IPv4-only (or IPv6-only) localized domain would not be able to maintain connectivity of its IPv6 (or IPv4) applications. Recently, the MIP6 WG has adopted [I-D.ietf-mip6-nemo-v4traversal] for this purpose and MIPv4 WG is considering a similar solution [I-D.tsirtsis-v4v6-mipv4]. However, it still requires an amount of updates to a host protocol stack. Jeong, et al. Expires December 21, 2006 [Page 6] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 4. Design Principles The goal of this document is to provide a network-based global mobility management protocol which supports v4-v6 traversal. The protocol has following design principles. o A host has an IPv4/IPv6 dual stack. o A host does not have any mobility management protocol stack. o A host does not have any protocol stack for v4-v6 traversal. o An AR has IPv4/IPv6 dual stack. o A GMAP has an IPv4/IPv6 dual stack. o A localized domain (including home domain) deploys its networks by using only IPv4 stack (or only an IPv6 stack). o The expected solution of the NETLMM WG is used in a localized domain. Jeong, et al. Expires December 21, 2006 [Page 7] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 5. Scenarios for Dual Stack Mobile Nodes If IPv6 is more widely deployed, dual stack nodes will move to dual, IPv6-only or IPv4-only networks. It is reasonable to assume that mobile nodes will move to networks that might not support IPv6 and would therefore need the capability to support an IPv4 address. It is unlikely that the mobile nodes will use IPv6 addresses only for their connections. It is reasonable to assume that mobile nodes will, for a long time, need an IPv4 address that can be used by applications. In [I-D.ietf-mip6-nemo-v4traversal], four scenarios were proposed for dual stack moving nodes. At this phase, this draft considers a subset of the scenarios in [I-D.ietf-mip6-nemo-v4traversal]. NAT- traversal scenarios will be discussed later. Additionally, we consider an intra-Netlmm domain moving scenario for dual stack nodes. The scenarios considered in this draft are as follow. All of the following scenarios assume that both the mobile node and the Home GMAP are IPv4 and IPv6-enabled and that Network-based Localized Mobility Management protocol is used within NETLMM domains. We also assume that the Home GMAP is always reachable through a globally unique IPv4 or IPv6 address. Jeong, et al. Expires December 21, 2006 [Page 8] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 Scenario 1: Moving into an IPv4-only or IPv6-only subnetwork within a NETLMM Domain In this scenario, a mobile dual stack node moves to an IPv4-only or IPv6-only subnetwork within a NETLMM domain. /-----------\ / Internet \ \ / \-----+-----/ | +-------+ | GMAP | +---+---+ | /------------+------------\ / NETLMM \ \ domain / / \-------------------------/ \ | | | +--+--+ +--+--+ +--+--+ | AR1 |v4/6 | AR2 |v4 | AR3 |v6 +-----+ +-----+ +-----+ / \ / \ / \ / \ / \ / \ +----+ +----+ +----+ | MN | --> | MN | --> | MN | +----+ +----+ +----+ movement Figure 1: Moving into an IPv4-only or IPv6-only subnetwork within a NETLMM Domain We also consider the following two cases of applications for CN. o case 1 : CN (Use of IPv4-only applications) o case 2 : CN (Use of IPv6 applications) Jeong, et al. Expires December 21, 2006 [Page 9] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 Scenario 2: Foreign NETLMM domain supports IPv6-only In this scenario, a mobile dual stack node moves to an IPv6-only foreign NETLMM domain. /-----------\ / Internet \ \ / \-----+-----/ | +-------------+-------------+ | | +-------+ +-------+ | GMAP | | GMAP | +---+---+ +-------+ | | /------+------\ /------+------\ / NETLMM \ / NETLMM \ \ domain (v4/6)/ \ domain(v6) / \-------------/ \-------------/ | | | | +--+--+ +--+--+ +--+--+ +--+--+ | AR1 | | AR2 | | AR3 | | AR4 | +-----+ +-----+ +-----+ +-----+ / \ / \ / \ / \ / \ / \ / \ / \ +----+ +----+ | MN | --> | MN | +----+ +----+ movement Figure 2: Foreign Netlmm domain only supports IPv6 In this scenario, the mobile node moves to an IPv6 Netlmm domain, but, the mobile node might be communicating with an IPv4-only application as well as an IPv6 application. So, we consider the following two cases of applications for CN. o case 1 : CN (Use of IPv4-only applications) o case 2 : CN (Use of IPv6 applications) Jeong, et al. Expires December 21, 2006 [Page 10] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 Scenario 3: Foreign NETLMM domain supports IPv4-only In this scenario, a mobile dual stack node moves to an IPv4-only foreign NETLMM domain. /-----------\ / Internet \ \ / \-----+-----/ | +-------------+-------------+ | | +-------+ +-------+ | GMAP | | GMAP | +---+---+ +-------+ | | /------+------\ /------+------\ / NETLMM \ / NETLMM \ \ domain (v4/6)/ \ domain(v4) / \-------------/ \-------------/ | | | | +--+--+ +--+--+ +--+--+ +--+--+ | AR1 | | AR2 | | AR3 | | AR4 | +-----+ +-----+ +-----+ +-----+ / \ / \ / \ / \ / \ / \ / \ / \ +----+ +----+ | MN | --> | MN | +----+ +----+ movement Figure 3: Foreign Netlmm domain only supports IPv4 In this scenario, the mobile node moves to an IPv4 Netlmm domain, but, the mobile node might be communicating with an IPv6-only application as well as an IPv4-only application. So, we consider the following two cases of applications for CN. o case 1 : CN (Use of IPv4-only applications) o case 2 : CN (Use of IPv6 applications) Jeong, et al. Expires December 21, 2006 [Page 11] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 6. Protocol Specification This section presents a specification of the network-based mobility and IPv4-IPv6 traversal support protocol for each dual stack host moving scenario which is shown in the previous section. 6.1. Scenario 1: Moving into an IPv4-only or IPv6-only subnetwork within a NETLMM Domain 6.1.1. MN moves into IPv6-only subnetwork in a NETLMM domain When a MN moves into a IPv6-only subnetwork within a NETLMM domain, the MN will initiate a reachability test for the MN's IPv6 address by transmission of a RS message. Since the AR2 has no state information about the MN, it queries a GMAP in the NETLMM domain for information about the MN. The GMAP in the NETLMM domain sends the AR2 in the IPv6-only subnetwork the MN's state information (e.g., IPv6 address, IPv4 address, and so on), so the AR2 can configure its routing table such that traffic to the MN's IPv4 or IPv6 address will reach the MN through AR2. The GMAP also informs the old AR so that it can clean up the state about the MN. The operation between MN and AR should follow the interface defined in [I-D.ietf-netlmm-mn-ar-if]. The AR2 updates its forwarding state and sends a RA message in order to confirm MN's IPv6 address. Figure 4 describes the binding update procedures when a MN moves from AR1 to AR2 which supports IPv6 only. MN AR2 GMAP AR1 | | | | | |QUERY(MNID,MN's | | | RS | IPv6 addr)| | |------------>|--------------->| | | | | | | |REPLY(MNID,MN's |UPDATE(MNID,MN's| | | IPv4 addr,| IPv4 addr, MN's| | RA | MN's IPv6 addr)| IPv6 addr)| |<------------|<---------------|--------------->| | | | | | | | | Figure 4: MN moves into IPv6-only subnetwork in a NETLMM domain When a GMAP in a NETLMM domain receives a packet destined to the MN's IPv4 or IPv6 address, the GMAP knows that the MN has moved to AR2 by looking up its forwarding state. The GMAP delivers the received Jeong, et al. Expires December 21, 2006 [Page 12] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 packet to AR2 by using the NETLMM protocol which will be defined by the NETLMM WG. After receiving the packet sent from GMAP, AR2 recovers the original packet which was sent from the CN. If the original packet is an IPv4 packet, AR2 looks up its IPv4 forwarding table and examines whether the destination address of the IPv4 packet is in the IPv4 routing table. If the original packet is an IPv6 packet, AR2 looks up its IPv6 routing table. When the destination address of the original packet is found in the IPv4 or IPv6 routing table, AR2 builds an L2 frame by using MNID and transmits it to the MN. The packet transmission between the AR and MN will follow the solution of the NETLMM WG. 6.1.2. MN moves into IPv4-only subnetwork in a NETLMM domain When a MN moves into a IPv4-only subnetwork within a NETLMM domain, the MN will initiate a reachability test for the MN's IPv4 address according to [RFC4436] by transmission of a DHCP message. Since the AR2 has no state information about the MN, it queries a GMAP in the NETLMM domain for information about the MN. The rest of the binding update procedures is similar to the 'MN moves into IPv6-only subnetwork case' except that the AR2 replies to the MN trough a DHCP reply message. Figure 5 depicts the binding update procedures when a MN moves from AR1 to AR2 which supports IPv4 only. MN AR2 GMAP AR1 | | | | | |QUERY(MNID,MN's | | | DHCPREQUEST | IPv4 addr)| | |------------>|--------------->| | | | | | | |REPLY(MNID,MN's |UPDATE(MNID,MN's| | | IPv4 addr,| IPv4 addr, MN's| | DHCPACK | MN's IPv6 addr)| IPv6 addr)| |<------------|<---------------|--------------->| | | | | | | | | Figure 5: MN moves into IPv4-only subnetwork in a NETLMM domain Protocol operation for data transport is similar to the MN moves into IPv6-only subnetwork in a NETLMM domain case. Jeong, et al. Expires December 21, 2006 [Page 13] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 6.2. Scenario 2: Foreign NETLMM domain only supports IPv6 6.2.1. Binding Management When a MN moves into a foreign NETLMM domain which supports IPv6 only, the MN will initiate a reachability test for the MN's IPv6 home address by transmission of a RS message. Since the AR2 has no state information about the MN, it queries a GMAP2 in the NETLMM domain for information about the MN. The GMAP2 examines the MN's home address and finds out that the address does not belongs to GMAP2's local NETLMM domain. Thus, the GMAP2 queries the GMAP1 in the MN's home NETLMM domain for information about the MN. We assume that the address of the GMAP1 in the home NETLMM domain is given to the AR2 by using link layer technology (out of scope of this document). The GMAP1 in the home NETLMM domain sends the GMAP2 in foreign NETLMM domain the MN's state information (e.g., IPv6 home link prefix information, IPv6 home address, IPv4 home address, and so on), so the GMAP2 can configure its routing table such that traffic to the MN's IPv4 or IPv6 home address will reach the MN through AR2. The GMAP1 also informs the old AR so that it can clean up the state about the MN. The GMAP2 sends the AR2 the MN's state information. Then, the AR2 updates its forwarding state and sends a RA message to the MN with the MN's IPv6 home link prefix included. Figure 6 shows the binding management procedures when a MN moves from home NETLMM domain (GMAP1) to foreign NETLMM domain (GMAP2) which supports IPv6 only. MN AR2 GMAP2 GMAP1 (Home GMAP) AR1 | | | | | | |QUERY(MNID,IPv6 |QUERY(MNID,IPv6 | | | RS | home addr)| home addr)| | |------------>|--------------->|---- ---------->| | | | | | | | |REPLY(MNID,v6 HL|REPLY(MNID,v6 HL|UPDATE(MNID,IPv4| | | prefix,v4 home,| prefix,v4 home,| home addr,IPv6| | RA | v6 home addr)| v6 home addr)| home addr)| |<------------|<---------------|<---------------|--------------->| | | | | | | | | | | Figure 6: MN in foreign netlmm domain supports IPv6 Jeong, et al. Expires December 21, 2006 [Page 14] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 6.2.2. Protocol Operation If the binding update is done according to the procedures in the previous subsection, we can consider two protocol operation cases, communicating with the CN via IPv4 and IPv6, respectively. When a GMAP1 in the MN's home NETLMM domain receives a packet destined to the MN's IPv4 or IPv6 home address, the GMAP1 knows that the MN has moved to another NETLMM domain by looking up its forwarding state. The GMAP1 encapsulates the received packet in an IPv6 packet and delivers it to a GMAP2 in the MN's foreign NETLMM domain. The source and destination address in the outer IPv6 header are the addresses of GMAP1 and GMAP2, respectively. The GMAP2 in MN's foreign NETLMM domain removes the outer IPv6 header of the received packet and encapsulates the original packet in an IPv6 packet again. The GMAP2 looks up its state information and sets the source address in the outer IPv6 header to GMAP2's address and the destination to the address of AR2 which the MN is connected to. After that, GMAP2 sends the encapsulated packet to the AR2. After receiving the packet sent from GMAP2, AR2 recovers the original packet which was sent from the CN. We assume that AR2 has an IPv4/ IPv6 dual stack. If the original packet is an IPv4 packet, AR2 looks up its IPv4 forwarding table and examines whether the destination address of the IPv4 packet is in the IPv4 routing table. If the original packet is an IPv6 packet, AR2 looks up its IPv6 routing table. When the destination address of the original packet is found in the IPv4 or IPv6 routing table, AR2 builds an L2 frame by using MNID and transmits it to the MN. The packet transmission between AR and MN will follow the solution of the NETLMM WG. 6.3. Scenario 3: Foreign Netlmm domain only supports IPv4 6.3.1. Binding Management When a MN moves into a foreign NETLMM domain supports IPv4 only, the MN will initiate a reachability test for MN's IPv4 home address according to [RFC4436] by transmission of a DHCP message. Since the AR2 has no state information about the MN, it queries a GMAP2 in the NETLMM domain for information about the MN. The rest of the binding update procedures are similar to Scenario 1 except that the AR2 replies to the MN trough DHCP reply message. Jeong, et al. Expires December 21, 2006 [Page 15] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 Figure 7 describes the binding management procedures when a MN moves from home NETLMM domain (GMAP1) to foreign NETLMM domain (GMAP2) which supports IPv4 only. MN AR2 GMAP2 GMAP1 (Home GMAP) AR1 | | | | | | |QUERY(MNID,IPv4 |QUERY(MNID,IPv4 | | | DHCPREQUEST | home addr)| home addr)| | |------------>|--------------->|---- ---------->| | | | | | | | |REPLY(MNID,v4 HL|REPLY(MNID,v4 HL|UPDATE(MNID,IPv4| | | prefix,v4 home,| prefix,v4 home,| home addr,IPv6| | DHCPACK | v6 home addr)| v6 home addr)| home addr)| |<------------|<---------------|<---------------|--------------->| | | | | | | | | | | Figure 7: MN in foreign netlmm domain supports IPv4 6.3.2. Protocol Operation If the binding update is done according to the procedures in the previous subsection, we can consider two operation cases, communicating with a CN via IPv4 and IPv6, respectively. When the GMAP1 in the MN's home NETLMM domain receives a packet destined to the MN's IPv4 or IPv6 home address, the GMAP1 finds out that the MN is no longer in its NETLMM domain by looking up its forwarding state. Hence, the GMAP1 encapsulates the received IPv4 or IPv6 packet in an IPv4 header which includes the GMAP1's IPv4 address in the source address field and the GMAP2's address in the destination address field. Then, GMAP1 delivers the encapsulated packet to a GMAP2 in the MN's foreign NETLMM domain. The GMAP2 in the MN's foreign NETLMM domain decapsulates the received packet and encapsulates the original packet in an IPv4 packet again. The GMAP2 looks up its state information and sets the source address in the outer IPv4 header to GMAP2's address and the destination to the address of the AR2 which the MN is connected to. After that, GMAP2 sends the encapsulated packet to the AR2. An AR2 receives the packet and recovers the original packet which was sent from the CN. Then, the AR2 transmits the original packet to the MN according to the lookup result of the appropriate routing table depending on the protocol version of the original packet. The packet transmission between the AR and MN will follow the same solution of the NETLMM WG. Jeong, et al. Expires December 21, 2006 [Page 16] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 6.4. Dual Stack Mobile Node Specification Mobile hosts are equipped with both an IPv4 and IPv6 stack. MN utilizes link layer technology (out of scope of this document) in order to give MN's MNID and home GMAP information to the AR when the MN moves to a new NETLMM domain. Also, it should support the MN specification in the protocol for NETLMM which will be specified by the NETLMM working group. 6.5. AR Specification When an AR receives a RS (or DHCP) message from a MN, the AR does not discard the received message which includes an unknown address(i.e., MN's home address). The AR sends a QUERY message containing the MNID, the MN's home address (IPv4 or IPv6), and the address of MN's home GMAP to a GMAP in the local NETLMM domain. The AR has an IPv4/IPv6 dual stack. When the AR receives a packet encapsulating the original packet sent from the CN, it looks up the appropriate forwarding table depending on the protocol version of the original packet. For example, if the original packet is an IPv4 packet, the AR searches the IPv4 forwarding table in order to find forwarding table entry for the MN. The AR also should support the AR specification in the protocol for the NETLMM which will be specified by the NETLMM working group. 6.6. GMAP Specification If a foreign GMAP receives a QUERY message from an AR containing MNID, the MN's home address, and the address of MN's home GMAP, it sends a QUERY message to the MN's home GMAP. If the MN's home GMAP receives a QUERY message from another GMAP, it replies with its state information about the MN. The home GMAP also informs the old AR so that it can clean up the state about the MN. When the foreign GMAP receives a REPLY from the home GMAP, it configures its routing table such that traffic to the MN's home address will reach the MN through the AR2. The foreign GMAP also sends the AR2 its state information about the MN. Both the home GMAP and the foreign GMAP should support the MAP specification in the protocol for NETLMM which will be specified by the NETLMM working group. Jeong, et al. Expires December 21, 2006 [Page 17] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 7. Security Considerations Although NETLMM provides mobility support without any extra signaling between a MN and network, it still requires mobility signaling for the global mobility management. So, it is required to have extra security association between each GMAP (and Home GMAP) and MNs. However, this document describes an efficient protocol without any such extra security association between a MN and a network entity. Also removing MN involvement in localized and global mobility management limits the possibility of DoS attacks on network infrastructural elements [I-D.ietf-netlmm-nohost-req]. IPSec can be applied to guarantee the signaling messages exchanged by network entities. The security associations between network entities can be built by static configuration or from other technologies, which will be analyzed in the future version of this draft. 8. References [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work in progress), June 2006. [I-D.ietf-mip6-dsmip-problem] Soliman, H. and G. Tsirtsis, "Mobility management for Dual stack mobile nodes A Problem Statement", draft-ietf-mip6-dsmip-problem-01 (work in progress), October 2005. [I-D.ietf-mip6-nemo-v4traversal] Soliman, H., "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-01 (work in progress), March 2006. [I-D.tsirtsis-v4v6-mipv4] Tsirtsis, G., "Dual Stack Mobile IPv4", draft-tsirtsis-v4v6-mipv4-01 (work in progress), April 2006. [I-D.ietf-netlmm-mn-ar-if] Laganier, J. and S. Narayanan, "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", draft-ietf-netlmm-mn-ar-if-00 (work in progress), April 2006. [I-D.ietf-netlmm-nohost-req] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", draft-ietf-netlmm-nohost-req-01 Jeong, et al. Expires December 21, 2006 [Page 18] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 (work in progress), April 2006. [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. Jeong, et al. Expires December 21, 2006 [Page 19] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 Authors' Addresses Sangjin Jeong ETRI 161 Gajeong-dong, Yusung-gu Daejeon, 305-350 Korea Phone: +82 42 860 1877 Email: sjjeong@gmail.com Youn-Hee Han KUT Gajeon-Ri 307 Byeongcheon-Myeon Cheonan-Si Chungnam Province, 330-708 Korea Email: yhhan@kut.ac.kr Myung-Ki Shin ETRI 161 Gajeong-dong, Yusung-gu Daejeon, 305-350 Korea Phone: +82 42 860 4847 Email: myungki.shin@gmail.com Hyoung-Jun Kim ETRI 161 Gajeong-dong, Yusung-gu Daejeon, 305-350 Korea Phone: +82 42 860 6576 Email: khj@etri.re.kr Jeong, et al. Expires December 21, 2006 [Page 20] Internet-Draft Mobility Support for Dual Stack Nodes June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jeong, et al. Expires December 21, 2006 [Page 21]