Mobile IP Changwen Liu INTERNET DRAFT Intel draft-liu-mobileip-mipv6overmipv4-00.txt Feb. 2002 Mobile IPv6 over 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 a 6to4 site [4] to continue utilizing Mobile IPv6 [5] services when they roam into IPv4 domains. The mechanism is based on Mobile IPv6 and Mobile IPv4 [7] glued together naturally by the 6to4 protocol [4] 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. The 6to4 border router(s) at the 6to4 site MUST also be capable to act as Mobile IPv4 home agent(s). Liu Expires 08/2002 [Page i] Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 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 4 2.3 Mobile Node Roams From IPv4 Domain Into IPv6 Domain 6 2.4 Benefits 6 3. Mobile IPv4 Home Agent Considerations 6 4. Mobile Node Considerations 7 4.1 Configurations 7 4.2 Mobile IPv4 Registration and Mobile IPv6 Binding Update 8 4.3 Route Optimization 8 4.4 Detection of Movement to IPv4 Domain 8 4.5 Establishing Forwarding from Previous CoA at Home 6to4 Site 9 4.6 IPv4 NAT and Firewall Traversal 9 5. Mobile IPv6 Home Agent Considerations 9 6. Mobile IPv4 Foreign Agent Considerations 9 7. Security Considerations 10 8. Intellectual property rights 10 9. Acknowledgements 10 Liu Expires 08/2002 - 1 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 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 mobile 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 a 6to4 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. 2. Protocol Overview This section specifies the behavior and the benefits of the proposed mechanism. 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 6to4 border router that acts as the MN's Mobile IPv4 Liu Expires 08/2002 - 2 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 Mobile IPv6 MN \ \ 6to4 Site IPv4 link / \ \ / \ \_______ / \ \ / \ \ / \ Mobile IPv6 --- IPv4 - FA ----- IPv4 ----6to4 ----Mobile IPv6 MN link Internet Border Router HA Figure 2.1 Mobile IPv6 Nodes Roam into IPv4 domains 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 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 router with mechanisms such as NAI 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, and creates and binds a 6to4 pseudo-interface to the address locally. For example, if the MN has an IPv4 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 the 6to4 address of its Mobile IPv6 home agent HA. The binding update messages are transferred as 6to4 and Mobile IPv4 tunneled data packets as elaborated in the following two cases Liu Expires 08/2002 - 3 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 1. Mobile IPv6 Binding Update packet: Since the IPv6 packet destination address is a 6to4 address, the 6to4 encapsulation, 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 6to4 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's 6to4 address. The pre-configured 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 according to the 6to4 protocol [4]. 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. 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 6to4 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 a 6to4 address of the home agent and the newly derived 6to4 address as the CoA of MN. Similarly, the binding update messages are transferred as 6to4 and Mobile IPv4 tunneled data packets. With the 6to4 protocol as the glue, Mobile IPv6 is layered on top of Mobile IPv6 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's 6to4 address. The pre-configured border Liu Expires 08/2002 - 4 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 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 according to the 6to4 protocol [4]. 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 MUST 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 6to4 site into IPv4 domains. The 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's 6to4 address. The reverse tunneled packet is again encapsulated in an IPv4 header according to the 6to4 protocol. 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 6to4 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 6to4 border router directly. Finally, when Mobile Liu Expires 08/2002 - 5 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 IPv4 reverse tunneling is not in use, the MN may send the twice- encapsulated packet directly to the 6t4 border router. The 6to4 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 6to4 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 at a 6to4 site having multiple prefixes and multiple subnets 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 to initiate IPv6 communication sessions either with 6to4 addresses or with native IPv6 addresses. 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 6to4 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 Liu Expires 08/2002 - 6 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 The pre-configured 6to4 border router acts as the Mobile IPv4 home agent for Mobile IPv6 MNs. 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. For the incoming IPv4 packets from IPv4 domains, the 6to4 border router can demultiplex 6to4-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 6to4 tunneled packets. If the 6to4 site is single homed on IPv4, then its only 6to4 border router is the Mobile IPv4 home agent. All tunneled packets from the MN's Mobile IPv6 agent to MN will be routed to the border router automatically. If the 6to4 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 6to4 border router. 2. Each border router manages a distinct pool of IPv4 addresses. Either way, a 6to4 border router that is also a Mobile IPv4 home agent has to 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 6to4 border router manages the IPv4 address pool 10.14.x.x/16, the border router has to advertise 2002:0A0E::/32 prefix within the 6to4 site so that all IPv6 packets destined to an address whose first 32 bits are 2002:0A0E are routed to this router. However, the more specific 6to4 prefix than 2002::/16 MUST not be advertised on native IPv6 interface(s) within the site to be compliant with the 6to4 protocol [4]. 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- Liu Expires 08/2002 - 7 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 configured 6to4 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 6to4 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 6to4 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 6to4 border router via other mechanisms such as using the Mobile IP NAI extension [3]. The MN SHOULD NOT use its IPv4 home address to initiate any communication sessions other than to encapsulate Mobile IPv6 packets, in particular if the IPv4 home address is globally non-routable. The MN MUST know its Mobile IPv6 HA's 6to4 address corresponding to its Mobile IPv4 home agent's IPv4 address. There are at least 2 possible solutions: by pre-configuration or by the Home Agent Address Discovery procedure specified in the next section on Mobile IPv6 Home Agent Considerations. 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 6to4 border router as its Mobile IPv4 home address, the MN has to get such an address from the 6to4 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. 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. Liu Expires 08/2002 - 8 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 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 6to4 sites cannot be routed across the global IPv4 infrastructure toward the MNs. 4.5 Establishing Forwarding from a Previous CoA at Home 6to4 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 6to4 site, the MN MUST be able to determine that its previous point of attachment is within its home 6to4 site. There are a few ways to do that. For example, if it sees in router advertisement on the previous link a 6to4 address that is derived from the same IPv4 address as its pre-configured Mobile IPv4 home agent, then it knows that its previous link is on its home 6to4 site. When the MN roams into IPv4 domain from a place other than its home 6to4 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 NAT Traversal If the MN roams into an IPv4 NAT domain, the MN needs the Nat traversal support. The mechanisms specified in [8,9] may be applied. 5. Mobile IPv6 Home Agent Considerations Each potential Mobile IPv6 home agent in a 6to4 site must 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. The agent advertisement may still have other (native) IPv6 addresses (if the agent has such addresses). Similarly when replying to Home Agent Address Discovery requests, a home agent must 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 MUST support delivering packets to MNs with private addresses as in [6]. Liu Expires 08/2002 - 9 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 2002 7. Security Considerations The author is not aware of any new security vulnerabilities outside of those introduced by the use of 6to4 protocol, Mobile IPv4, and Mobile IPv6. Mobile IPv4 registration SA management on the 6to4 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 this draft. 10. 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, and Charles E. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-15.txt, Sept 2001, 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] Farid Adrangi, and Prakash Iyer, Mobile IPv4 Traversal Across Firewalls, draft-adrangi-mobileip-natvpn-traversal-00, November 13 2001 [9] O. H. Levkowetz, J. Forslow, and H. Sjostrand, NAT Traversal for Mobile IP using UDP Tunnelling, July 4, 2001 Liu Expires 08/2002 - 10 - Internet Draft Mobile IPv6 over Mobile IPv4 Feb. 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 08/2002 - 11 -