Mobile IP Pat R. Calhoun INTERNET DRAFT Black Storm Networks draft-mccann-mobileip-ipv6mipv4-00.txt Tom Hiller Peter J. McCann Lucent Technologies August, 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 mobility agents have dual IPv4 and IPv6 stacks. McCann, Calhoun, Hiller Expires 02/2002 [Page 1] IPv6 over MobileIPv4 August, 2001 2. Introduction This specification defines a Mobile IPv4 extension that may be used by mobile nodes to request IPv6 service from mobility agents. When a mobile node requests IPv6 services, and the agents are capable of providing such service, IPv6 packets destined for the mobile are encapsulated within an IPv4 header between the foreign and home agents. IPv6 packets are then delivered directly to the mobile via the foreign agent. AAAF ----------- AAAH / \ / IPv6 over \ MN -IPv6- FA ----- IPv4 ------- HA ---- IPv6 Internet Island Figure 1. A deployment scenario for IPv6 over MobileIPv4. Figure 1 depicts an example deployment scenario for IPv6-over- MobileIPv4. Here the MN registers with the FA using a Mobile IPv4 Registration Request including an NAI and 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. Upon processing the IPv6 Home Address Extension, the HA assigns an IPv6 address to the MN and begins to serve as an IPv6 router for the MN. IPv6 packets addressed to the MN are forwarded to the FA over an IPv4 tunnel, where they are decapsulated and delivered to the MN. Note that the IPv4 address assigned to the MN may be private to the HA [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 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, but does require that the mobility agents in the network also be dual stack. This specification is not intended to replace the Mobile IPv6 protocol, which does not have such restrictions. McCann, Hiller, Calhoun Expires 02/2002 [Page 2] IPv6 over MobileIPv4 August, 2001 3. Mobile Node Considerations A mobile node may request IPv6 service using a Mobile IPv4 Registration Request if the Foreign Agent advertises such service in the agent advertisements (see section 6). In order to request IPv6 service, the mobile node MUST include the IPv6 Home Address extension, which MUST appear prior to any authentication extensions in the registration request. A registration request that includes the IPv6 Home Address extension MUST set the 'T' bit (reverse tunnel [Montenegro01]) to one. Also, the MN MUST NOT request Minimal Encapsulation as its tunneling format. If the Mobile Node has a static IPv6 home address it MAY be encoded in the IPv6 Home 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 Home 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. A successful registration reply that does not include an IPv6 Home 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 Home Address Extension, the MN configures a local IPv6 interface for IPv6-over-MobileIPv4 operation with the given IPv6 address. When using a co-located care-of address for its Mobile IPv4 registration, all IPv6 packets sent on this interface are reverse tunneled to the HA, and the MN MUST be prepared to receive IPv4-encapsulated IPv6 packets from the HA. When using an FA- located care-of address, all IPv6 packets sent from the MN on this interface MUST be link-layer unicasted to the FA. Also, the MN MUST be prepared to receive IPv6 packets that are link-layer unicasted to it from the FA. Packets received by the MN that were not link-layer unicasted MUST be ignored for purposes of the IPv6-over-MobileIPv4 interface. McCann, Hiller, Calhoun Expires 02/2002 [Page 3] IPv6 over MobileIPv4 August, 2001 4. Foreign Agent Considerations A Foreign Agent that is willing to provide IPv6 service to dual stack Mobile IPv4 nodes MUST set the IPv6-Enabled bit in the agent advertisement (see section 6). Upon receipt of a registration request with the IPv6 Home Address extension present, the foreign agent MUST insert the associated information in the mobile node's visitor entry. Upon receipt of a successful registration reply from the Home Agent, the foreign agent MUST perform the necessary procedures to ensure that the MN's IPv6 packets are properly delivered. Any IPv6 packet received from the MN's link layer source address whose source IPv6 address matches the IPv6 Home Address extension MUST be encapsulated and reverse tunneled to the proper HA. For each encapsulated IPv6 packet received from the HA, the FA MUST decapsulate and deliver the packet to the proper MN via link-layer unicast. The proper MN is determined by indexing on both the HA's IPv4 address, taken from the outer tunnel header, and the destination IPv6 address. The decapsulation and/or delivery of other packets from the HA, such as encapsulated IPv4 packets, is unaffected by this specification. 5. Home Agent Considerations Home Agents that support the IPv6 Home Address extension MUST be configured with at least one unique IPv6 subnet prefix. Upon receipt of a registration request with the IPv6 Home 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 address constructed using the above algorithm is inserted in the Registration Reply's IPv6 Home Address extension. If the requested Mobile IP lifetime is greater than the remaining lifetime of the McCann, Hiller, Calhoun Expires 02/2002 [Page 4] IPv6 over MobileIPv4 August, 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. When such a packet arrives, the HA MUST encapsulate it in an IPv4 outer header, according to the Mobile IPv4 encapsulation format that was negotiated, and forward it to the MN's care-of address. If a MN requested Minimal Encapsulation with the IPv6 Home Address extension, the HA MUST NOT include an IPv6 Home Address extension in the response and MUST NOT tunnel IPv6 packets to the MN. 6. Multicast, Broadcast, and Addresses Acquired Differently When using IPv6-over-MobileIPv4 with an FA-located care-of address, the FA must route packets based on the IPv6 home address of the MN, which includes a prefix from the home network. Note that multicast or broadcast packets from the home network do not include the MN's IPv6 home address in the IPv6 header. Also, if the MN acquires an IPv6 prefix by some mechanism other than the one outlined in this document, the FA may not be aware of it and will be unable to properly route packets that contain it. For these reasons, the HA must observe special rules when forwarding multicast packets, broadcast packets, or packets with addresses other than the one assigned during Mobile IPv4 registration. The rules are identical to those given for multicast and broadcast packets in Mobile IPv4 [Perkins01]. Any packet destined to a broadcast, multicast, or differently acquired address that the HA wishes to send to the MN must be doubly encapsulated, unless the MN is using a co-located care-of address ('D' bit was set in the Registration Request). Also, 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 reverse-tunneled IGMP messages. In the opposite direction, when using an FA-located care-of address, the MN MUST encapsulate IPv6 packets destined to the home network if they contain a source address other than the one negotiated in the Mobile IPv4 registration. Note that multicast or broadcast packets from the MN that do contain the negotiated MN source address need not be doubly encapsulated, but may simply be link-layer unicasted to the FA. The FA MUST reverse tunnel any link-layer unicast packet containing the negotiated source address to the HA. McCann, Hiller, Calhoun Expires 02/2002 [Page 5] IPv6 over MobileIPv4 August, 2001 When performing double encapsulation, the tunnel endpoints MUST be the IPv4 home address of the MN and the IPv4 address of the HA. The MN and HA MAY exchange Neighbor Discovery [Narten98] messages if desired, but they must observe the above rules when sending IPv6 all-nodes or all-routers multicast packets. Note that link-local and site-local addresses are also examples of differently acquired addresses that may require special handling. The use of Neighbor Discovery is optional because the IPv6 Home Address extension provides a mechanism for establishing a unique MN interface identifier and network prefix in the same round-trip as Mobile IPv4 registration. Neighbor Discovery is an example of a mechanism by which the MN may acquire addresses outside the scope of Mobile IPv4 registration. 7. Mobility Agent Advertisement Extension 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|D|r|T|C| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | The only change to the Mobility Agent Advertisement Extension [Perkins01] is the additional 'C' bit: C IPv6-Enabled. The IPv6-Enabled bit is enabled by Foreign Agents to communicate their support of this extension, and its willingness to provide IPv6 service via Mobile IPv4 registrations. Using this information, a mobile node is able to choose a foreign agent that supports IPv6 over Mobile IPv4. Notice that if a mobile node does not understand this bit, it simply ignores it as per Mobile IPv4 [Perkins01]. 8. IPv6 Home Address Extension The IPv6 Home Agent 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, Hiller, Calhoun Expires 02/2002 [Page 6] IPv6 over MobileIPv4 August, 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 | IPv6 Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The IPv6 Home Address Extension Type TBD (skippable) Length The length field MUST contain 16. IPv6 Address 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. 9. IANA Considerations The IPv6 Home Address extension defined in Section 8 is a Mobile IP registration extension as defined in [Perkins01]. The IANA should assign a value from the skippable (128-255) range. The 'C' bit uses one of the existing, reserved bits from the Mobility Agent Advertisement extension. 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. [Narten98] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. [Perkins01] Perkins, C., "IP Mobility Support for IPv4, revised," draft-ietf-mobileip-rfc2001bis-06.txt, June 2001. Work In Progress. McCann, Hiller, Calhoun Expires 02/2002 [Page 7] IPv6 over MobileIPv4 August, 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 EMail: mccap@lucent.com Pat R. Calhoun Black Storm Networks 250 Cambridge Ave, Suite 200 Palo Alto USA Phone: +1 650 617-2932 Fax: +1 720 293 7501 Email: 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 EMail: tom.hiller@lucent.com McCann, Hiller, Calhoun Expires 02/2002 [Page 8] IPv6 over MobileIPv4 August, 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, Hiller, Calhoun Expires 02/2002 [Page 9]