Mobile IP Pat R. Calhoun INTERNET DRAFT Black Storm Networks draft-mccann-mobileip-ipv6mipv4-03.txt Paal E. Engelstad Telenor R&D Tom Hiller Peter J. McCann Lucent Technologies October, 2002 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 04/2003 [Page 1] IPv6 over MobileIPv4 October, 2002 2. Introduction To allow for the incremental deployment of IPv6, it will be necessary to support mobile IPv6 nodes that connect to IPv4-only networks. This document defines a Mobile IPv4 extension that may be used by mobile nodes to request IPv6 service from Mobile IPv4 Home Agents, even when visiting Foreign Agents (or access routers) that implement only IPv4. 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. McCann et al. Expires 06/2002 [Page 2] IPv6 over MobileIPv4 October, 2002 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 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. McCann et al. Expires 06/2002 [Page 3] IPv6 over MobileIPv4 October, 2002 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. 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. McCann et al. Expires 06/2002 [Page 4] IPv6 over MobileIPv4 October, 2002 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 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. Foreign Agent Considerations The operation of the Foreign Agent is not affected by this specification. The IPv6 Address Extension is skippable, which means that it need not be parsed or understood by the FA. Of course, if there is a security association in place between the FA and any other mobility entities, the FA's authentication extensions must cover the IPv6 Address Extension as it would any other extension that appeared in the same place in the Registration Request or Reply. 6. 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 McCann et al. Expires 06/2002 [Page 5] IPv6 over MobileIPv4 October, 2002 interface identifier and network prefix in the same round-trip as Mobile IPv4 registration. 7. 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: 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 McCann et al. Expires 06/2002 [Page 6] IPv6 over MobileIPv4 October, 2002 node MAY also set the least 64 bits to zero to request that an interface identifier be dynamically assigned. 8. 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]. This specification couples IPv6 address assignment, including prefix discovery and interface identifier selection, to the Mobile IPv4 registration process. While this creates a dependency that might be avoided if generic IPv6 neighbor discovery procedures were used through a tunnel established by other means, there is a benefit from covering the address assignment process with the same security associations used for Mobile IPv4. The HA can create a secure binding between the MN's IPv4 address, its NAI (if present in the Registration Request), and its IPv6 address. Because the HA will be redirecting IPv6 packets to the given IPv4 address, it is important for this binding to be secure. Note that this document does not address other security threats to the IPv6 over IPv4 tunnel, and in particular such traffic may be vulnerable to eavesdropping or packet injection attacks. However, these attacks are no more severe than those that are possible with ordinary reverse tunneling for Mobile IPv4 traffic [Montenegro01], and can be remedied with the same techniques. For example, it may be necessary to use IP Security between the HA and the v4 tunnel endpoint. However, not all deployment environments will require such a level of security. The use of Neighbor Discovery procedures, given as optional in Section 6, may introduce additional security considerations if they result in new packets being redirected to mobile nodes. These messages are ordinarily not protected by security associations. 9. 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. McCann et al. Expires 06/2002 [Page 7] IPv6 over MobileIPv4 October, 2002 10. 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. 11. 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 8] IPv6 over MobileIPv4 October, 2002 12. 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 1921 E-mail: mccap@lucent.com Pat R. Calhoun Black Storm Networks 110 Nortech Parkway San Jose, CA 95134 USA Phone: +1 408 941 0500 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 9] IPv6 over MobileIPv4 October, 2002 Intellectual Property Statement At the time of submission the authors are not aware of any intellectual property rights that pertain to the implementation or use of the technology described in this document. However, this does not preclude the possibility that Lucent Technologies, Inc. or other entities may have such rights. The patent licensing policy of Lucent Technologies, Inc. is on file with the IETF Secretariat. 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. McCann et al. Expires 06/2002 [Page 10] IPv6 over MobileIPv4 October, 2002 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 11]