Network Working Group C. Wan Internet-Draft X. Qin Expires: December 16, 2006 C. Ye Huawei Technologies June 14, 2006 Route management of mobile entity with an ipv6 home address roaming into the ipv4 network draft-wan-mip6-nemo-routing-00.txt 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 16, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The current Mobile IPv6 and NEMO specification supports only IPv6. As an extension, the DSMip6 protocol [v4traversal]defines how the dual-stack mobile node roams in the ipv4 network. The dsmip6 protocol assumes that both home agent and mobile node supports mipv4 and mipv6 protocol. It also assumes that both the home agent and mobile node have a configured ipv4 address. These assumptions do Wan, et al. Expires December 16, 2006 [Page 1] Internet-Draft v4traversal June 2006 work during many scenarios. However, as the ipv4 address is a scarce resource in many counrties, some mobile nodes may not be able to get configured ipv4 home addresses from their home agents. In this scenario, a temporary ipv4 home address is more useful. This document will focuse on this scenario. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of the solution . . . . . . . . . . . . . . . . . . . 5 4. FHA discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Binding update . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Route management . . . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 10 7.1. Mobile entity consideration . . . . . . . . . . . . . . . 10 7.2. Home agent consideration . . . . . . . . . . . . . . . . . 10 7.3. Correspondent node consideration . . . . . . . . . . . . . 10 7.4. Foreign home agent consideration . . . . . . . . . . . . . 10 7.5. Foreign agent consideration . . . . . . . . . . . . . . . 10 8. Security considerations . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Wan, et al. Expires December 16, 2006 [Page 2] Internet-Draft v4traversal June 2006 1. Introduction MIP6 and NEMO allow mobile entities to move away from its home network while maintaining reachability and ongoing sessions, using an IPv6 home address or prefix. However, since IPv6 is not widely deployed, it is reasonable to assume that mobile nodes will move to networks that might not support IPv6. To solve this problem,dsmip6 protocol is designed, The dsmip6 protocol assumes that HA and mobile entity support both mip4 and mip6 protocol. The mobile node may have no ipv4 home address. If the mobile node has no ipv4 home address, the home agent will act as a DHCP server, and assign the mobile node an ipv4 home address. This requires that the HA must have an ipv4 address pool. As the ipv4 address is a scarce resource, some home agents may have no ipv4 address pool. So some home agents may not be able to assign an ipv4 home address to the mobile entity. At the same time, only part of the global network will support both ipv4 and ipv6 protocols. There are surely some networks that support only ipv6 protocol. HA in these networks will not be able to support mip4 protocol. In addition,if we assume that all mip6 home agents must support mip4 protocol, it means that the ipv6 network must support ipv4 protocol. This is not reasonable. So there are three categories of scenarios in the global network: [DS-PB] In the first category, the home network is an ipv4/ipv6 mixed network. The dual-stack mobile entity with at least an ipv6 address roams into the ipv4 or ipv6 network. In the second category, the dual-stack mobile entity with an ipv6 home address roams into the ipv4 network. The home network is an ipv6 only network. In the third category, the dual-stack mobile entity with an ipv4 home address roams into the ipv6 network. The home network is an ipv4 only network. The dsmip6 protocol is focusing on the first category of scenarios. This document will focus on the second category of scenarios. The second category of scenarios assmues that the mobile entity can not get an stable ipv4 home address from its home agent. The mobile entity supports both mip4 and mip6 protocols, thus it supports both ipv4 and ipv6 protocols. The home agent does not support ipv4 protocol, and mip4 protocol. Wan, et al. Expires December 16, 2006 [Page 3] Internet-Draft v4traversal June 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [STANDARDS]. This Document uses terminology defined in [TERMS]. In addition or in replacement of these, the following terms are defined or redefined: FHA FHA is the alias of foreign home agent, a function entity that can provide temporary ipv4 address for the mobile entity. THOAv4 THOAv4 is the temporary ipv4 home address that mobile entity gets from FHA. ME ME is the alias of mobile entity. ME may be a mobile node or a mobile router defined in the mip4 and mip6 protocol. Wan, et al. Expires December 16, 2006 [Page 4] Internet-Draft v4traversal June 2006 3. Overview of the solution In the scenarios of the second category, when the mobile entity roams into an ipv4 network, it can get an ipv4 COA from foreign agent[RFC3344]. To use mip4 protocol, the mobile entity must get an ipv4 home address too. It is a problem that the mobile entity can not get ipv4 home address from the home agent. To solve this problem, a new facility is added in the network, called foreign home agent (FHA), which is located in the ipv4/ipv6 mixed network. The foreign home agent supports both mip4 and mip6 protocol [RFC3775] . The foreign home agent has both ipv4 and ipv6 address pools. When the mobile entity with an ipv6 only home network roams into an ipv4 only network, the foreign home agent temporarily assigns an ipv4 home address to the mobile entity. The ipv4 home address is called THOAv4. In the ipv4 network, the mobile entity registers the ipv4 COA got from FA to the FHA. The foreign home agent acts as a mip4 home agent of the mobile entity.FA considers FHA as mobile entity's HA. An ipv4 tunnel is built between mobile entity and FHA,and the ipv6 packets are transmitted over the tunnel. when mobile entity sends/receives ipv6 packets to/from its home agent or correspondent nodes, the ipv6 packet is encapsulated in the ipv4 tunnel. The home agent and correspondent node do not know that the mobile entity is in the ipv4 network. They will send ipv6 packets to the mobile entity. when the ipv6 packets is routed to the FHA, the FHA will encapsulate it into ipv4 packet, and send it to the mobile entity. the mobile entity must send mip6 binding update to the home agent or correspondent nodes. So it must get a ipv6 COA. As the ipv6 packet from HA or correspondent node must be routed to FHA, the ipv6 COA must be acquired from the FHA. The ipv6 COA may be mapped from the THOAv4, or by other method. There are 3 main problems in this framework to be solved, including FHA discovery, registering, and routing. Wan, et al. Expires December 16, 2006 [Page 5] Internet-Draft v4traversal June 2006 4. FHA discovery Mip6 protocol defines a dynamic home agent address discovery mechanism. It allows the mobile entity to discover their home agent by the anycast interface identifier to their home link's prefix. When the mobile entity is in the ipv6 network, it can use this mechanism to discover FHA. When the mobile entity is in the ipv4 only network, it can discover the foreign home agent's ipv4 address through the domain name system. The mobile entity must be configured with the name of the home agent. There may be some other FHA discovery mechanisms. This document will not discuss on the detail of FHA discovery mechanisms. The FHA discovery mechanism is similar to the HA discovery mechanism which is defined in the mip4 and mip6 protocols. Though the FHA discovery mechanism is similar to the HA discovery mechanism, There are some differences between them. The reply message from the FHA includes not only the FHA's ipv4 and ipv6 address but also the THOAv4 address. As the mobile entity must register ipv6 COA to the home agent or correspondent node, it must get the ipv6 COA from the FHA. The ipv6 COA can be an ipv4-mapped ipv6 address. It is mapped from the THOAv4 address. If the FHA supports DHCPv6 protocol, it can assign an ipv6 COA to the mobile entity. In the mip6 protocol, there are two bootstrapping solutions called integrated bootstrapping and split bootstrapping. There may be some differences between mip6 bootstrapping solution and v4traversal bootstrapping solution.This document will not focuse on this topic. Wan, et al. Expires December 16, 2006 [Page 6] Internet-Draft v4traversal June 2006 5. Binding update There are two kinds of register procedures. One is the mip4 register procedure, and the other is the mip6 binding update procedure. In the mip4 register procedure, the mobile entity will register its ipv4 care-of address to FHA. The mobile entity gets its ipv4 care-of address from the foreign agent, and registers the ipv4 COA to FHA according to mip4 protocol. The mobile entity may send the register packets straightly, or the foreign agent will send the register packets instead. The home address in the mip4 register packet is THOAv4. After getting THOAv4 address from foreign home agent, the mobile entity may roam back to ipv6 network. Then it will return its THOAv4 address to the foreign home agent and the mip4 register will expire. In the mip6 binding update procedure, the mobile entity will send binding update message to its ipv6 home agent or correspondent node. There are two kinds of mechanisms. One is normal mip6 binding updates procedure. The mobile entity sends the binding updates to the home agent or correspondent node. The only difference is that the binding update messages are encapsulated over the IPv4 network. The other is proxy register. When using the proxy register mechanism, the mobile entity will not send register packet to the home agent. The foreign home agent will send it instead. To use the proxy register mechanism, a security alliance will need to be built between FHA and HA. In the mip4 register procedure, both mobile node and mobile router[RFC3963] will send mip4 register. In the mip6 binding update procedure, the mobile node will send mip6 binding update and the mobile router will send NEMO binding update. Wan, et al. Expires December 16, 2006 [Page 7] Internet-Draft v4traversal June 2006 6. Route management From the HA and CN perspective, the packet sent to/by the mobile entity are ipv6 packets. The ipv6 packets may include mip6 signaling information. But in the ipv4 network, the ipv6 packet is encapsulated in the ipv4 packet. There is a tunnel between FHA and mobile entity. In the sending data procedure, the mobile entity will send ipv6 packets to the correspondent nodes or home agent over ipv4 network. The ipv6 packets are encapsulated into ipv4 packets on the mobile entity. The source address of the ipv4 packets is the THOAv4 address, and the destination address of the ipv4 packets is the ipv4 address of FHA. After encapsulating, the mobile entity will send the packets according to the mip4 protocol. The foreign agent will route it to FHA. If there is source address filtering problem, the foreign agent should support Reverse Tunneling[RFC2344] for mobile ip. When the FHA received the ipv4 packets from the mobile entity, it will route the ipv6 packets which is decapsulated from the ipv4 packets to the correspondent nodes or the home agent. In the receiving data procedure, the ipv6 packets from the correspondent nodes or home agent are routed to FHA. This is because the ipv6 COA included in the binding update packets sent to the home agent or correspondent nodes is assigned by FHA which is defined in the FHA discovery section. FHA will encapsulate the ipv6 packets into ipv4 packets. The source address of the ipv4 packets is the ipv4 address of FHA, and the destination address of the ipv4 packets is the THOAv4 of the mobile entity. After encapsulating,FHA will send the ipv4 packets over the tunnel between HA and FA/MN according to the mip4 protocol. Here FHA operation is similar to mip4 HA, it will tunnel packets to foreign agent or mobile entity. When mobile entity receives the ipv4 packets, it will decapsulate the ipv4 packets. Thus the mobile entity gets the ipv6 packets from correspondent nodes or home agent which are encapsulated in the ipv4 packets. Figure 1 is the route method when mobile entity uses bi-directional tunneling mode. Figure 2 is the route method when mobile entity uses route optimization mode. Wan, et al. Expires December 16, 2006 [Page 8] Internet-Draft v4traversal June 2006 ipv6 network | ipv4/ipv6 mixed network | ipv4 network | | CN HA | FHA | FA MN | | | | | | | |----->|------|---------->|---------------|--------->|------->| | | | | | | | |<-----|<-----|-----------|<--------------|----------|--------| | | | | | | | | | | | | | | Figure 1: v4 traversal of bi-directional tunneling ipv6 network | ipv4/ipv6 mixed network | ipv4 network | | CN | FHA | FA MN | | | | | | | |------|------|---------->|---------------|--------->|------->| | | | | | | | |<-----|------|-----------|<--------------|----------|--------| | | | | | | | | | | | | | | Figure 2: v4 traversal of route optimization If the mobile entity is a mobile router, it acts as an ipv6 mobile router and an ipv4 mobile node. The ipv6 packets sent to/by the mobile router will be encapsulated in the ipv4 tunnel defined as the said. Wan, et al. Expires December 16, 2006 [Page 9] Internet-Draft v4traversal June 2006 7. Protocol Operations 7.1. Mobile entity consideration In the FHA discovery procedure, mobile entity may get FHA information and THOAv4 by the anycast method or DNS method. After mobile entity gets its THOAv4 address, it must register to FHA termly. In the ipv4 network, mobile entity will encapsulate ipv6 packets sent to HA or CN into ipv4 packets. 7.2. Home agent consideration The home agent needs to support only mip6 protocol. It does not know that the mobile entity has roamed into an ipv4 network. 7.3. Correspondent node consideration The correspondent node needs to support only mip6 protocol. It does not know mobile entity has roamed into an ipv4 network. 7.4. Foreign home agent consideration The foreign home agent must be able to accept registers from mobile entity, and it must be able to allocate tHOAv4 for mobile entity. In the ipv4 network, the foreign home agent acts as a mip4 home agent. In the ipv6 network, the foreign home agent acts as a mip6 access router. The foreign home agent will encapsulate the ipv6 packet sent to mobile entity into ipv4 packet and route the ipv4 packet to the mobile entity. The foreign home agent will decapsulate the ipv4 packet from mobile entity into ipv6 packet and route the ipv6 packet to the correspondent node. In the proxy register procedure,the foreign home agent may also send register message to the home agent of mobile entity instead of the mobile entity.The foreign home agent may be a extension function of the dual-stack home agent defined in [v4traversal], or a independent facility. The foreign home agent is a logic entity. 7.5. Foreign agent consideration The foreign agent needs to support only mip4 protocol. It acts as a conventional mip4 foreign home agent. Wan, et al. Expires December 16, 2006 [Page 10] Internet-Draft v4traversal June 2006 8. Security considerations Security is an end to end solution. When the mobile entity communicates with the correspondent node or home agent, it uses the security mechanism defined in the mip6 protocol[RFC3776]. When the mobile entity communicates with the foreign home agent or foreign agent, it uses the security mechanism defined in the mip4 protocol. When the mobile entity uses the proxy register mechanism, there must be a security association between FHA and HA. 9. Normative References [DS-PB] "Scenario analysis and problem statement of the dual-stack mobile entity roaming in the ipv4 and ipv6 network", June 2006. [RFC2344] "Reverse Tunneling for Mobile IP", May 1998. [RFC3344] "IP Mobility Support for IPv4", August 2002. [RFC3775] "Mobility Support in IPv6", June 2004. [RFC3776] "Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks", June 2004. [RFC3963] "Network Mobility (NEMO) Basic Support protocol", January 2005. [STANDARDS] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997, . [TERMS] "Mobility Related Terminology", June 2004, . [v4traversal] "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", ???. Wan, et al. Expires December 16, 2006 [Page 11] Internet-Draft v4traversal June 2006 Authors' Addresses Changsheng Wan Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, China 210001 Phone: +86-25-84565415 Email: wanchangsheng@huawei.com Xia Qin Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, China 210001 Phone: +86-25-84565414 Email: alice.Q@huawei.com Chengping Ye Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, China 210001 Phone: +86-25-84565414 Email: yechengping@huawei.com Wan, et al. Expires December 16, 2006 [Page 12] Internet-Draft v4traversal 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. Wan, et al. Expires December 16, 2006 [Page 13]