Mobile IP Pat R. Calhoun INTERNET DRAFT Black Storm Networks draft-mccann-mobileip-ipv6mipv4-02.txt Paal E. Engelstad Telenor R&D Tom Hiller Peter J. McCann Lucent Technologies December, 2001 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 [Bradner96]. 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 Mobile IPv4 extension that may be used by dual stack mobile nodes to obtain IPv6 service with the use of a Mobile IPv4 registration. This extension allows for immediate deployment of IPv6 on dual stack mobile devices, without the need for a full IPv6 infrastructure. It is believed that providing IPv6 services to mobile devices in the short term will spur the growth of IPv6 networks. This extension makes use of the existing Mobile IPv4 security model, including the interface to the AAA infrastructure, but does not provide the route optimization capabilities included in the Mobile IPv6 protocol. Further, this specification requires that the mobile node and Home Agent have dual IPv4 and IPv6 stacks. There are no changes to the FA nor does it need to be dual stack. McCann et al. Expires 06/2002 [Page 1] IPv6 over MobileIPv4 December, 2001 2. Introduction This specification defines a Mobile IPv4 extension that may be used by mobile nodes to request IPv6 service from Mobile IPv4 Home Agents. When a mobile node requests IPv6 service, and the Home Agent is capable of providing such service, IPv6 packets destined for the mobile are encapsulated within an IPv4 header between the mobile node and Home Agent. IPv6 packets are then decapsulated within the mobile node. Similarly, the mobile node encapsulates IPv6 packets within an IPv4 header that is destined for the Home Agent. AAAF ----------- AAAH / \ / IPv6 over \ MN - IPv4 - FA ----- IPv4 ------- HA ---- IPv6 link Internet Island Figure 1. A deployment scenario for IPv6 over MobileIPv4. Figure 1 depicts an example deployment scenario for IPv6-over- MobileIPv4. We assume that the MN and FA are separated by exactly one link-layer hop. Here the MN registers with the FA using a Mobile IPv4 Registration Request including a skippable IPv6 Address Extension (defined below), an NAI, and a Challenge-Response. The registration is validated through the use of a AAA infrastructure and sent to the HA. While the extension defined here does not strictly depend upon the use of AAA, we expect this to be a useful deployment case. We assume the HA is located on a link where the MN's home IPv4 address resides, and that it owns a range of IPv6 addresses for use by MNs. Upon processing the IPv6 Address Extension, the HA assigns an IPv6 address to the MN and begins to serve as an IPv6 router for the MN. When the HA receives an IPv6 packet addressed to the MN, it first encapsulates the packet in an IPv4 packet, using the MN home address as the destination address and the HA address as the source address. The HA then forwards the encapsulated packet to the MN using its Mobile IPv4 mobility binding; for FA-located COA, the packet is sent to the FA over an IPv4 tunnel, where it is decapsulated. The FA then delivers the packet to the MN, and the MN itself performs the last stage of decapsulation, delivering the IPv6 packet to upper layers. For co-located COA, the MN itself performs both decapsulations. When the MN sends an IPv6 packet using this mechanism, it encapsulates the IPv6 packet in an IPv4 header destined to the Home Agent. When using FA-located COA and reverse tunneling, the packet is delivered to the FA which encapsulates it again and routes it towards the HA. When using co-located COA and reverse tunneling, the McCann et al. Expires 06/2002 [Page 2] IPv6 over MobileIPv4 December, 2001 MN performs the second layer of encapsulation itself and routes the resulting packet towards the HA. Finally, when reverse tunneling is not in use, the MN may send the singly-encapsulated packet directly to the HA. Note that the IPv4 address assigned to the MN may be private to the Home Agent [Montenegro01], which reduces the demand for public IPv4 addresses. The advantages of this proposal include: - It allows mobile devices to support IPv6 in the near term. - It allows mobiles that belong to an IPv6 network to receive service on an IPv4 network, which is believed to be critical since only some geographical areas will be deploying IPv6 networks. - It does not affect the FA nor require any link-layer support for IPv6 on the visited link. - It allows dual stack mobile devices to benefit from existing Mobile IPv4 deployments. - It supports dynamic IPv6 home address allocation. - It can alleviate the demand for public IPv4 addresses while supporting globally routable IPv6 addresses. This specification is intended to allow dual stack mobile nodes to receive IPv6 services while mobile, and does require that the Home Agent in the network also be dual stack. This specification is not intended to replace the Mobile IPv6 protocol, which does not have such restrictions and at the same time provides route optimization capabilities. 3. Mobile Node Considerations A mobile node may request IPv6 service using a Mobile IPv4 Registration Request. The mobile node MUST include the IPv6 Address Extension, and it MUST appear prior to any authentication extensions in the registration request. If the Mobile Node has a static IPv6 home address it MAY be encoded in the IPv6 Address Extension. Alternatively, the mobile node MAY request that an IPv6 home address be dynamically assigned to it by setting the high order 64 bits to zero, and the low order 64 bits to a unique interface identifier. The MN MAY request that both the prefix and interface identifier be dynamically assigned to it by setting the entire 128-bit IPv6 Address to zero. If the low-order 64 bits are derived from an EUI-48 or EUI-64 number, the 'u' bit (Internet bit 6) MUST be set to 1. Otherwise this bit MUST be set to 0. McCann et al. Expires 06/2002 [Page 3] IPv6 over MobileIPv4 December, 2001 A successful registration reply that does not include an IPv6 Address extension implies that the Home Agent was not willing or capable of providing IPv6 service. In this case the mobile node has the option of either using the IPv4 service, or initiating a registration request with a lifetime of zero (0) to inform the Home Agent that it does not wish to make use of the registered mobility binding. Upon receipt of a successful registration reply that does include the IPv6 Address Extension, the MN configures a local IPv6 interface for IPv6-over-MobileIPv4 operation with the negotiated IPv6 address. When sending IPv6 packets on this interface, the MN MUST encapsulate them in an IPv4 header using the HA address as the destination and the MN address as the source. Depending on the type of Mobile IPv4 registration, the MN either delivers that packet to the FA (FA- located COA), encapsulates the packet a second time and routes it to the HA (co-located COA with reverse tunneling), or routes the packet directly to the HA (co-located COA with no reverse tunneling). When receiving packets from the HA, the MN decapsulates packet once for FA-located COA or twice for co-located COA. If the result is an IPv6 packet with the negotiated destination address, it is delivered to the upper layers from the IPv6-over-MobileIPv4 interface. 4. Home Agent Considerations Home Agents that support the IPv6 Address Extension MUST be configured with at least one unique IPv6 subnet prefix. Upon receipt of a registration request with the IPv6 Address Extension, the Home Agent uses the following algorithm in the formation of the IPv6 home address: 1. If the most significant 64 bits of the address matches one of the prefixes configured on the Home Agent, the requested prefix is used. Otherwise, the HA chooses one of its configured prefixes. 2. If the least significant 64 bits of the address are set to a non-zero value, and the value forms an interface identifier that is unique to the prefix chosen in step 1, the value requested is used. Otherwise (the least 64 bits were set to zero or were not unique to the prefix), the Home Agent allocates an interface identifier unique to the prefix. The interface identifier is concatenated with the prefix chosen in step 1 to form the complete IPv6 home address. If the Registration Request was successfully processed, the IPv6 home address constructed using the above algorithm is inserted in the Registration Reply's IPv6 Address extension. If the requested Mobile IP lifetime is greater than the remaining lifetime of the McCann et al. Expires 06/2002 [Page 4] IPv6 over MobileIPv4 December, 2001 address prefix given in the response, the HA MUST reduce the lifetime to the remaining prefix lifetime. The HA behaves as a first-hop IPv6 router for the mobile node, NOT as a Mobile IPv6 Home Agent. In particular, when a packet for the MN's IPv6 address arrives on the home network, it will be delivered to the HA by the next upstream router due to IPv6 routing mechanisms. The HA MUST encapsulate it in a packet addressed to the MN's home address. The result will be encapsulated again, according to the negotiated Mobile IPv4 encapsulation format. The HA performs usual IPv4 layer 3 forwarding procedures on that packet. In the opposite direction, the HA MUST decapsulate packets arriving from the MN. Such packets will be singly- or doubly-encapsulated, depending on the placement of the care-of address (co-located or FA- located) and the use of reverse tunneling. The HA then performs usual layer 3 forwarding on the resulting IPv6 packet. Identical encapsulation rules apply for broadcast or multicast packets. The HA should only forward broadcast traffic if the 'B' bit was set in the registration request, and it should only forward multicast traffic if the MN explicitly requested to join a group via IGMP messages. Link-local and site-local addresses also are subject to the same handling. Here the scope of the IPv6 link is the IPv4 tunnel between the HA and MN. 5. Neighbor Discovery The MN and HA MAY exchange Neighbor Discovery [Narten98a] messages if desired, but they must observe the above rules when sending IPv6 all-nodes or all-routers multicast packets. The use of Neighbor Discovery is optional because the IPv6 Address Extension provides a mechanism for establishing a unique MN interface identifier and network prefix in the same round-trip as Mobile IPv4 registration. 6. IPv6 Address Extension The IPv6 Address extension is used by a mobile node to communicate its desire to receive IPv6 packets from the Home Agent. The mobile node MAY request that a home address be dynamically assigned, using the procedures described in section 3. The format of the extension is as follows: McCann et al. Expires 06/2002 [Page 5] IPv6 over MobileIPv4 December, 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Binding Type | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The IPv6 Address Extension Type TBD (skippable) Length The length field MUST contain 18. Binding Type The Binding Type field is provided for future compatibility with other v4/v6 inter-working mechanisms that may also use the IPv6 Address Extension. This document uses the value zero: 0 - IPv6 over MobileIPv4 MNs and HAs that comply with this specification MUST set the Binding Type field to zero. Future specifications may define additional values. IPv6 Address When the Binding Type field is set to zero, the IPv6 Address field contains the mobile node's IPv6 home address. The mobile node MAY set the most significant 64 bits to zero to request that a prefix be dynamically assigned. The mobile node MAY also set the least 64 bits to zero to request that an interface identifier be dynamically assigned. 7. Security Considerations The IPv6 Address Extension outlined in this document is a Mobile IP extension and should be protected by appropriate Mobile IP Authentication Extensions, as outlined in the base Mobile IP specification [Perkins01]. McCann et al. Expires 06/2002 [Page 6] IPv6 over MobileIPv4 December, 2001 8. IANA Considerations The IPv6 Address extension defined in Section 8 is a Mobile IP registration extension as defined in the base Mobile IP specification [Perkins01]. The IANA should assign a value from the skippable (128-255) range. The Binding Type field of the IPv6 Address Extension is a new name space that must be managed by IANA. This document reserves the value zero. Following the policies outlined in RFC 2434 [Narten98b], future assignments should be made after consultation with a Designated Expert. 9. Acknowledgements Thanks to Paul Francis for pointing out the double encapsulation idea to avoid impact on the FA, and to Mark Lipford of SprintPCS and Bryan Cook of Verizon Wireless for valuable feedback and encouragement. 10. References [Braden89] Braden, R. (ed.), "Requirements for Internet Hosts -- Communication Layers," RFC 1122, October 1989. [Bradner96] Bradner, S., "The Internet Standards Process, Revision 3," RFC 2026, October 1996. [Montenegro01] Montenegro, G., editor, "Reverse Tunneling for Mobile IP, revised," RFC 3024, January 2001. [Narten98a] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. [Narten98b] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. [Perkins01] Perkins, C., "IP Mobility Support for IPv4, revised," draft-ietf-mobileip-rfc2002bis-08.txt, September 2001. Work In Progress. McCann et al. Expires 06/2002 [Page 7] IPv6 over MobileIPv4 December, 2001 11. Authors' Addresses Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 713 9359 FAX: +1 630 713 4982 E-mail: mccap@lucent.com Pat R. Calhoun Black Storm Networks 250 Cambridge Ave, Suite 200 Palo Alto, CA 94306-1549 USA Phone: +1 650 617 2932 Fax: +1 720 293 7501 E-mail: pcalhoun@bstormnetworks.com Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 979 7673 FAX: +1 630 979 7673 E-mail: tom.hiller@lucent.com Paal E. Engelstad Telenor R&D, Palo Alto 399 Sherman Ave, Suite 12 Palo Alto, CA 94306-1863 USA Phone: +1 650 714 7538 E-mail: paal@telenorisv.com McCann et al. Expires 06/2002 [Page 8] IPv6 over MobileIPv4 December, 2001 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. 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 practice this standard. Please address the information to the IETF Executive Director. 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. McCann et al. Expires 06/2002 [Page 9]