Mobile IP Changwen Liu INTERNET DRAFT Intel draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 Connecting Mobile IPv6 Nodes Across IPv4 Clouds Back To IPv6 Domains With Mobile IPv4 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document specifies a mechanism for Mobile IPv6 nodes of IPv6 Site to continue utilizing Mobile IPv6 services when they roam into IPv4 domains. The mechanism is based on Mobile IPv6 and Mobile IPv4 glued together by IPv4 encapsulation for delivering IPv6 packets between the Mobile IPv6 nodes and their Mobile IPv6 home agents. To support the mechanism specified in this draft, the Mobile IPv6 nodes MUST be Mobile IPv4 capable and MUST NOT utilize Mobile IPv6 route optimization when in IPv4 domain, and some of the border routers of the site MUST be capable to act as Mobile IPv4 home agent(s). The IPv6 site does not need to run 6to4 protocol, however. Liu Expires 11/2002 [Page i] Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 Contents Status of This Memo i Abstract i 1. Introduction 2 1.1 Terminology 2 2. Protocol Overview 2 2.1 Mobile Node Roams From IPv6 Domain Into IPv4 Domain 2 2.2 Packet Routing For MN Roaming into An IPv4 Domain 5 2.3 Mobile Node Roams From IPv4 Domain Into IPv6 Domain 6 2.4 Benefits 6 3. Mobile IPv4 Home Agent Considerations 7 4. Mobile Node Considerations 8 4.1 Configurations 8 4.2 Mobile IPv4 Registration and Mobile IPv6 Binding Update 9 4.3 Route Optimization 9 4.4 Detection of Movement to IPv4 Domain 9 4.5 Establishing Forwarding from Previous CoA at Home Site 9 4.6 IPv4 Encapsulation and Decapsulation Requirement 10 4.7 IPv4 NAT and Firewall Traversal 10 5. Mobile IPv6 Home Agent Considerations 10 6. Mobile IPv4 Foreign Agent Considerations 10 7. Security Considerations 10 8. Intellectual property rights 11 9. Acknowledgements 11 Liu Expires 11/2002 - 1 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 1. Introduction Mobile IPv6 [5], based on Mobile IPv4 [7] and developed as an integrated part of IPv6 protocol suite, enables IPv6 nodes to connect to networks and access and be accessible to their home networks (the link on which their home IPv6 subnet prefixes are in use) while the nodes are away from home. Like Mobile IPv4, Mobile IPv6 is transparent to all IPv6 applications running on these devices. Mobile IPv6 enabled devices, however, require a full IPv6 infrastructure deployment and work only within IPv6 networks. To really spur the growth of IPv6 networks, it is necessary for the Mobile IPv6 nodes to continue functioning even when they roam into non-IPv6 domains, in particular IPv4 domains. This document specifies a mechanism for Mobile IPv6 nodes of IPv6 site to continue utilizing Mobile IPv6 services when they roam into IPv4 domains. 1.1. 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 RFC 2119 [2]. In addition, this document frequently uses the following terms: CoA Care-of Address in both Mobile IPv4 and Mobile IPv6. MN Mobile Node in both Mobile IPv4 and Mobile IPv6. IPv6 site A site that runs IPv6. Usually it consists of multiple IPv6 links or subnets, e.g. an IPv6 site that runs global unicast address family [11] has fixed TLA ID and NLA ID and each subnet of the site is identified by the SLA ID. 2. Protocol Overview This section specifies the proposed mechanism and its benefits. 2.1 Mobile Node Roams From IPv6 Domain Into IPv4 Domain When a Mobile IPv6 node MN roams into IPv4 domains, as illustrated in Figure 2.1 below, the MN first performs Mobile IPv4 agent discovery and obtains either an IPv4 co-located or foreign agent CoA. Note that the Mobile IPv6 MN MUST also support Mobile IPv4 MN functionality for this to occur. The MN then performs a Mobile IPv4 registration with a pre-configured border router that acts as Liu Expires 11/2002 - 2 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 Mobile IPv6 MN \ \ IPv6 Site IPv4 link / \ \ / \ \_______ / \ \ / \ \ / \ Mobile IPv6 --- IPv4 - FA ----- IPv4 ---- Border ----Mobile IPv6 MN link Internet Router HA Figure 2.1 Mobile IPv6 Nodes Roam into IPv4 domains the MN's Mobile IPv4 Home agent as showed in Figure 2.2. If the MN does not already have an IPv4 home address, it needs to get the address from the border router with mechanisms such as NAI MN Border Router Mobile IPv6 HA | Mobile IPv4 Reg. Request | | |----------------------------->| | | Mobile IPv4 Reg. Reply | | |<-----------------------------| | | | | | Mobile IPv6 Binding Update | |------------------------------|------------------------>| | Mobile IPv6 Binding Acknowledgement | |<-----------------------------|-------------------------| Figure 2.2 Registration and Binding Update of MN Extension specified in [3, 7] during the Mobile IPv4 registration process. The MN then constructs a 6to4 address based on its Mobile IPv4 home address, creates and binds a 6to4 pseudo-interface to the address locally. For example, if the MN has an IPv4 home address 10.14.10.12, it can use the 6to4 address 2002:0A0E:0A0C::1/48 or 2002:0A0E:0A0C::1/64 as its Mobile IPv6 CoA. Essentially, a degenerated 6to4 site that consists of the MN itself acting as both a host and a router is created. As showed in Figure 2.2, upon successful completion of Mobile IPv4 registration, the MN performs the normal Mobile IPv6 binding update with its Mobile IPv6 home agent. The binding update specifies the MN's 6to4 address derived from its Mobile IPv4 home address as its Mobile IPv6 primary CoA and is sent to its Mobile IPv6 home agent HA via the 6to4 pseudo-interface. The binding update messages are transferred as IPv4 encapsulated [8] and Mobile IPv4 tunneled data packets as elaborated in the following two cases Liu Expires 11/2002 - 3 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 1. Mobile IPv6 Binding Update packet: IPv4 encapsulation with source address as MN IPv4 home address and destination address as the border router address, which results in an IPv4 packet, is applied first, followed by the Mobile IPv4 encapsulation by the MN or a foreign agent. The packet is sent to the border router which decapsulates the two outermost IPv4 encapsulations and forwards the resulting packet to Mobile IPv6 home agent. 2. Mobile IPv6 Binding Acknowledgement packet: The Mobile IPv6 home agent replies to the binding update with the binding acknowledgement destined to the MN's 6to4 address in the binding update and sourced at the Mobile IPv6 home agent address. The preconfigured border router that acts as the Mobile IPv4 home agent of the MN will get the Binding Acknowledgement packet via the sites internal routing mechanisms (see Section 3) and encapsulate it with an IPv4 header with source address as the border router exterior IPv4 address and destination address as MN IPv4 home address. The IPv4 encapsulated packet will then be forwarded to the MN using the border router's Mobile IPv4 mobility binding over the IPv4 tunnel between the MN's Mobile IPv4 CoA and the border router's exterior IPv4 address. The MN will decapsulate the encapsulated packet and retrieve the original Mobile IPv6 binding acknowledgement. Notice that in case 1, MN has to encapsulate all packets out of its 6to4 pseudo-interface with an IPv4 header no matter whether the destination is a 6to4 address or not, and the border router has to decapsulate IPv4 packets with type 41 and route the IPv6 packets inside; in case 2, the border router has to encapsulate all packets destined to 6to4 addresses with an IPv4 header no matter whether the source address is a 6to4 address or not, and MN has to decapsulate IPv4 packets with type 41 to retrieve IPv6 packets inside. If the IPv6 site runs 6to4 protocol and the MN’s home agent address in case 1 and 2 is 6to4 address, then the aforementioned encapsulations and decapsulations at MN and the border router are naturally provided by the 6to4 protocol. Otherwise, behavior changes at MN and the border router are required. In the above process, except for the initial Mobile IPv4 registration that is used to set up a Mobile IPv4 tunnel, the Mobile IPv4 registration and Mobile IPv6 binding update are independent of each other. For example, if a Mobile IPv6 binding update is still valid when the MN moves to another IPv4 domain, the MN only needs to perform a Mobile IPv4 registration. If the MN roams into an IPv4 domain from its home site where its home IPv6 address is located, then in parallel to the MN's binding update with its Mobile IPv6 home agent, MN MAY also send a binding update to any home agent on the link on which the previous CoA is located with the destination address as an IPv6 address of the home agent and the newly derived 6to4 address as the CoA of MN. Similarly, Liu Expires 11/2002 - 4 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 the binding update messages are transferred as IPv4 and Mobile IPv4 tunneled data packets. With the IPv4 encapsulation [8] as the glue, Mobile IPv6 is layered on top of Mobile IPv4 to deliver IPv6 packets between the MN and its Mobile IPv6 home agent HA as described next. The mechanism requires that the Mobile IPv6 route optimization feature with MN be disabled entirely. 2.2 Packet Routing For MN Roaming into An IPv4 Domain When the MN's Mobile IPv6 home agent HA receives an IPv6 packet addressed to the MN, the HA forwards the packet to the MN using MN's Mobile IPv6 binding cache entry over the IPv6 tunnel between MN's Mobile IPv6 CoA and the HA address. The pre-configured border router that acts as the Mobile IPv4 home agent of the MN will get the tunneled IPv6 packet via the site's internal routing mechanisms (see Section 3) and encapsulate it with an IPv4 header with destination address as MN IPv4 home address and source address as the border router IPv4 address according to [8]. The IPv4 encapsulated packet will then be forwarded to the MN using the border router's Mobile IPv4 mobility binding over the IPv4 tunnel between MN's Mobile IPv4 CoA and the border routers’ exterior IPv4 address. For FA-located CoA, the FA performs one decapsulation and delivers the decapsulated packet to the MN. The MN performs two consecutive decapsulations to retrieve the original IPv6 packet and forwards the packet to upper layers of its protocol stack. If the MN's IPv4 home address is private (i.e. not globally routable), the FA SHOULD support the delivery of packets to the MN as specified in [6]. For co-located CoA, the MN performs the three decapsulations by itself. Figure 2.3 shows the packet traffic flow in this forward direction for the co-located CoA case. MN Border Router Mobile IPv6 HA | | | | | IPv6/IPv6 Traffic | | |< -------------------------| | IP/IP/IPv6/IPv6 Traffic | | |< ----------------------- | | Figure 2.3 Packet Flow in Forward Direction Mobile IPv6 [5] allows a mobile node to send a Binding Update to a router on the link on which its previous care-of address is located, for purposes of establishing forwarding from this previous care-of address to its new care-of address. This feature is still supported by the mechanism of the draft for the situation when MN roams from its home IPv6 site into IPv4 domains. The Liu Expires 11/2002 - 5 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 mechanism works similarly for such forwarding as that from MN's Mobile IPv6 home agent HA to MN. When the MN sends an IPv6 packet using this mechanism, it must reverse tunnel the packet to the MN's Mobile IPv6 HA using the Mobile IPv6 binding between its Mobile IPv6 CoA (a 6to4 address) and its Mobile IPv6 HA address. The reverse tunneled packet is again encapsulated in an IPv4 header sourced from MN IPv4 home address and destined to the border router IPv4 address according to the IPv4 encapsulation [8]. When using FA-located CoA and Mobile IPv4 reverse tunneling, the twice-encapsulated packet is delivered to the FA, which encapsulates it again and routes it towards the pre-configured home site border router. When using co- located CoA and Mobile IPv4 reverse tunneling, the MN performs the third layer of encapsulation and routes the resulting packet towards the site border router directly. Finally, when Mobile IPv4 reverse tunneling is not in use, the MN may send the twice- encapsulated packet directly to the site border router. The site border router decapsulates either the two IPv4 outer layers if Mobile IPv4 reverse tunneling is utilized or just the one IPv4 outer layer otherwise. The site border router relays the inner reverse tunneled IPv6 packet to the MN's Mobile IPv6 HA which decapsulates the packet to retrieve the original IPv6 packet and send away the original packet. Figure 2.4 shows the packet traffic in the reverse direction for the Co-located CoA case. MN Border Router Mobile IPv6 HA | IP/IP/IPv6/IPv6 Traffic | | | --------------------------->| | | | IPv6/IPv6 Traffic | | | ------------------------>| Figure 2.4 Packet Flow in Reverse Direction 2.3 Mobile Node Roams From an IPv4 Domain Back Into IPv6 Domain When the Mobile IPv6 node MN roams from IPv4 domain into IPv6 domain, which may or may not be its home site, MN follows Mobile IPv6 to perform normal binding update and packet routing except it MUST NOT send any binding updates to establish forwarding from the 6to4 CoA derived from its IPv4 home address. 2.4 Benefits The mechanism described in this draft enables Mobile IPv6 nodes of an IPv6 site to retain Mobile IPv6 services seamlessly when they move into IPv4 domains. The mechanism enables the Mobile IPv6 nodes whose Mobile IPv6 home agents can be anywhere in the site and do not have any IPv4 addresses to initiate IPv6 communication sessions with its home IPv6 addresses at anywhere (IPv6 domains Liu Expires 11/2002 - 6 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 and IPv4 domains) and roam seamlessly in both IPv4 and IPv6 domains. The authentication in Mobile IPv4 registration also enables the border router to securely redirect the packet traffic to MN IPv4 CoA and hence eliminates significant vulnerability in the traffic redirection to MN. In particular, the mechanism does not affect an IPv4 FA nor require any link-layer support for IPv6 on the (foreign) visited link. It can leverage existing Mobile IPv4 deployments and alleviate the demand for public IPv4 addresses while supporting globally routable IPv6 addresses. The proposed mechanism therefore enables immediate deployment of Mobile IPv6 in IPv6 sites without the needs for an IPv6 infrastructure deployment everywhere and any changes to deployed Mobile IPv4 infrastructure. The only restriction to this mechanism is that Mobile IPv6 reverse tunneling is required when MN roams into IPv4 domains and no Mobile IPv6 route optimization is allowed. 3. Mobile IPv4 Home Agent Considerations The pre-configured site border router acts as the Mobile IPv4 home agent for Mobile IPv6 MNs of the site. The border router manages a pool of IPv4 addresses, which usually are globally non-routable due to global routable IPv4 address space depletion. The address pool forms a virtual network. The border router can allocate addresses from the pool to MNs either statically at MN configuration time or dynamically with registration requests and mechanisms such as the NAI extension. The IPv4 addresses in the pool are for delivering IPv6 packets in IPv4 domains and SHOULD NOT be used for initiating IPv4 communication sessions by MNs. As discussed in Secion 2.1, the border router MUST encapsulate all packets destined to 6to4 addresses with IPv4 headers and decapsulate IPv4 packets with type 41. This encapsulation and decapsulation requirement changes border router normal behavior slightly. However if the IPv6 site runs 6to4 protocol with this border router as its 6to4 router, then the encapsulation and decapsulation at the border router is naturally provided by the 6to4 protocol. For the incoming IPv4 packets from IPv4 domains, the site border router can demultiplex IPv4-encapsulated packets from Mobile IPv4 encapsulated packets by looking at the protocol type field value of outer IP header and hence can apply proper decapsulation process to received packets. For example, the protocol type field value of the outer IP header is 4 for IPIP tunneled Mobile IPv4 packets and 41 for IPv4 tunneled IPv6 packets. If the IPv6 site is single homed on IPv4, then its only border router is the Mobile IPv4 home agent. The Mobile IPv4 home agent MUST advertise the 6to4 prefix 2002::/16 within the site. As a result, all tunneled packets from the MN's Mobile IPv6 agent to MN will be routed to the border router automatically. Notice that the Liu Expires 11/2002 - 7 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 IPv6 site does not need to run the 6to4 protocol even with advertisement of 6to4 prefix 2002::/16 across the site by the border router. If the IPv6 site is multi-homed on IPv4, it may have multiple IPv4 border routers, one for each IPv4 address. Either one border router can be chosen as the Mobile IPv4 home agent for all MNs of the site or different border routers can be chosen as Mobile IPv4 home agents with the following two rules: 1. All MNs in an IPv6 subnet use the same border router. Again the Mobile IPv4 home agent MUST advertise the 6to4 prefix 2002::/16 within the site. 2. Each border router manages a distinct pool of IPv4 addresses. Either way, a site border router that is also a Mobile IPv4 home agent MUST advertise more specific 6to4 prefixes than 2002::/16 within the site so that packets destined to the 6to4 addresses derived from the IPv4 address pool it manages are explicitly routed to this border router. For example, if a site border router manages the IPv4 address pool 10.14.x.x/16, the border router MUST advertise 2002:0A0E::/32 prefix within the IPv6 site so that all IPv6 packets destined to an address whose first 32 bits are 2002:0A0E are routed to this router. An exception is that in the first case, if other border routers do not advertise the 6to4 prefix 2002::/16 within the site, then the chosen Mobile IPv4 home agent only needs to advertise the 6to4 prefix 2002::/16 within the site. Also as in the 6to4 protocol case [4], the more specific 6to4 prefix than 2002::/16 MUST not be advertised onto exterior native IPv6 routing domain. Therefore, if the IPv6 site also has a native IPv6 connection to another IPv6 site, it MUST NOT advertise more specific 6to4 prefixes than 2002::/16, e.g. the aforementioned 2002:0A0E:/32 routing prefix, on that connection. 4. Mobile Node Considerations 4.1 Configurations A Mobile IPv6 node MN that wants to utilize the mechanism mentioned in this document MUST be Mobile IPv4 capable and MUST use a pre-configured site border router as its Mobile IPv4 home agent. All Mobile IPv4 configuration requirements apply. In other words, MN MUST be pre-configured with an IPv4 netmask, and a mobility security association with the site border router. Since the MN's home network usually is a virtual network, the MN has to be configured with the IPv4 address of the site border router. The MN MAY be configured with its IPv4 home address statically, which usually is private. If the mobile node is not configured with an IPv4 home address, it MUST be configured with other parameters such as NAI and be able to obtain an IPv4 address from the site border router via other mechanisms such as using the Mobile IP NAI extension [3]. The MN SHOULD NOT use its IPv4 home address to Liu Expires 11/2002 - 8 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 initiate any communication sessions other than to encapsulate Mobile IPv6 packets, in particular if the IPv4 home address is globally non-routable. 4.2 Mobile IPv4 Registration and Mobile IPv6 Binding Update When the MN first roams into IPv4 domains, the MN performs both Mobile IPv4 registration and Mobile IPv6 binding update. If the MN does not have an IPv4 address from its site border router as its Mobile IPv4 home address, the MN has to get such an address from the site border router first, e.g. using NAI extension, with the Mobile IPv4 registration. No matter whether MN has a Mobile IPv4 home address or not, it MUST perform Mobile IPv6 binding update only after the initial Mobile IPv4 registration is successful since the Mobile IPv6 binding update is carried as data traffic of Mobile IPv4. A successful registration reply and a successful binding acknowledgement are needed to start tunneling IPv6 data packets between the MN and MN's Mobile IPv6 HA. If any of the steps fail, the MN has to notify the proper home agent to revoke its registration or binding update that is successful in a prior step. When MN Mobile IPv6 home agent advertises a list of IPv6 addresses, including a 6to4 address derived from MN Mobile IPv4 home agent, to MN, MN SHOULD pick the 6to4 address for all its communications to its Mobile IPv6 home agent. 4.3 Detection of Movement to An IPv4 Domain The MN MUST be able to detect the fact that it has roamed into an IPv4 only domain. Such detection mechanisms, however, are beyond the scope of this document. 4.4 Route Optimization Mobile IPv6 route optimization MUST NOT be used with this mechanism. The primary reason is due to the fact that IPv4 home addresses of MNs utilizing the mechanism are usually private and hence packets from corresponding nodes that reside at other sites cannot be routed across the global IPv4 infrastructure toward the MNs. 4.5 Establishing Forwarding from a Previous CoA at Home Site If the MN wants to send a binding update to any home agent on the link on which the previous CoA is located when it roams into IPv4 domain from its home IPv6 site, the MN MUST be able to determine that its previous point of attachment is within its home IPv6 site. There are a few ways to do that. For example, if the home IPv6 site runs global unicast address family and MN sees in router advertisement on the previous link the router address is a global unicast address and the first 48 bits of the router address (TLA Liu Expires 11/2002 - 9 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 ID + NLA ID) is the same as that of its Mobile IPv6 home agent, then it knows that its previous link is on its home IPv6 site. When the MN roams into IPv4 domain from a place other than its home IPv6 site, it MUST not send the binding update to any home agent on the link on which the previous CoA is located. Otherwise, the binding acknowledgement may get lost and the packets forwarded by the home agent on the link will not reach MN since the packet may not reach MN's Mobile IPv4 home agent, in particular if MN's IPv4 home address is private. 4.6 IPv4 Encapsulation and Decapsulation Requirement As discussed in Secion 2.1, MN MUST encapsulate all packets out of its 6to4 pseudo-interface with an IPv4 header and decapsulate IPv4 packets with type 41 when in IPv4 domain. The encapsulation and decapsulation requirement changes normal MN behavior slightly. However if MN’s home IPv6 site runs 6to4 protocol and the MN’s home agent utilizes its 6to4 address, then the encapsulation and decapsulation at MN is naturally provided by the 6to4 protocol. 4.7 IPv4 NAT Traversal If the MN roams into an IPv4 NAT domain, the MN needs the NAT traversal support. The mechanisms specified in [9, 10] may be applied. 5. Mobile IPv6 Home Agent Considerations The MIPv6 home agent does not need to have any 6to4 addresses. However if a potential Mobile IPv6 home agent in an IPv6 site has 6to4 address, it SHOULD advertise in its router advertisements either all of its 6to4 addresses and prefixes or just the 6to4 address and prefix derived from the IPv4 address of the 6to4 border router which serves as the Mobile IPv4 home agent for MNs served by that 6To4 router. And when replying to Home Agent Address Discovery requests, the home agent SHOULD include either all 6to4 addresses and prefixes or the aforementioned 6to4 address for each home agent on the link in addition to other (native) IPv6 addresses. 6. Mobile IPv4 Foreign Agent Considerations If the MN's IPv4 home address is globally non-routable, foreign agent SHOULD support delivering packets to MNs with private addresses as in [6]. 7. Security Considerations Liu Expires 11/2002 - 10 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 The author is not aware of any new security vulnerabilities outside of those introduced by the use of IPv4 encapsulation, Mobile IPv4, and Mobile IPv6. Mobile IPv4 registration SA management on the site border router is outside of the scope of the current draft. 8. Intellectual property rights Intel Corporation (hereafter Intel) has one or more patents or patent applications that may be relevant to this internet-draft. If any claims of these are necessary for implementing this standard, any party will be able to obtain a license from Intel to use any such patent claims under openly specified, reasonable, non-discriminatory terms, free of charge, for the purpose of implementing it. 9. Acknowledgements The author would like to thank Prakash Iyer, and Farid Adrangi of Intel Corporation for their review and feedback on an earlier version of this draft. References [1] Bradner, S., "The Internet Standards Process, Revision 3," RFC 2026, October 1996. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [3] Pat R. Calhoun, and Charles E. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000 [4] B. Carpenter, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, Feb. 2001 [5] David B. Johnson, Charles E. Perkins, and Jari Arkko "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-17.txt, May 2002, work in progress. [6] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 3024, Jan. 2001. [7] Charles E. Perkins editor "IP Mobility Support for IPv4", RFC 3220, Jan. 2002. [8] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [9] Farid Adrangi, and Prakash Iyer, Mobile IPv4 Traversal Across Firewalls, draft-adrangi-mobileip-natvpn-traversal-00, November 13 2001, work in progress. [10]O. H. Levkowetz, J. Forslow, and H. Sjostrand, “NAT Traversal for Mobile IP using UDP Tunnelling”, draft-ietf-mobileip-nat- traversal-02.txt, April 5, 2002, work in progress. [11]R. Hinden, M. O'Dell, and S. Deering, “An IPv6 Aggregatable Global Unicast Address Format”, RFC 2374, July 1998. Liu Expires 11/2002 - 11 - Internet Draft draft-liu-mobileip-mipv6tomipv4-00.txt May 2002 11. Author's Addresses Changwen Liu Intel Labs 2111 NE 25th Ave, JF3-206 Hillsboro, OR 97124 USA Phone: +1 503 264 9262 FAX: +1 503 264 3483 E-mail: changwen.liu@intel.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Liu Expires 11/2002 - 12 -