MobOpts Research Group Rajeev Koodli INTERNET DRAFT Nokia Research Center 11 July 2005 Mobile IPv4 Route Optimization Using Mobile IPv6 Return Routability draft-irtf-mobopts-ipv4ro-00.txt By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This document is a submission of the IRTF MobOpts RG. Comments should be directed to the MobOpts RG mailing list, mobopts@irtf.org. Abstract The motivation for this document comes from considerations in implementing IPv6 Return Routability in an IPv4 network, especially where the Mobile Node and the Correspondent Nodes are capable of performing IPv6-in-IPv4 tunneling. As a result, this document proposes an IPv4 Address extension to Mobile IPv6 Return Routability procedure which can provide route optimization for IPv4 traffic. Koodli Expires 11 January 2005 [Page i] Internet Draft Mobile IPv4 Route Optimization 11 July 2005 Contents Abstract i 1. Introduction and Problem Description 1 2. Reference Model and Assumptions 2 3. Protocol Operation 3 4. Message Formats 4 5. IANA Considerations 5 6. Security Considerations 5 7. Author's Address 6 Intellectual Property Statement 6 Disclaimer of Validity 6 Copyright Statement 7 Acknowledgment 7 1. Introduction and Problem Description The Return Routability (RR) mechanism for Mobile IPv6 [1] specifies a shared secret establishment between a Mobile Node (MN) and an arbitrary Correspondent Node (CN) node on the Internet in order to enable route-optimized communication between them. It does this based on the assumption that the underlying routing infrastructure is able to correctly route packets based on their destination addresses. In other words, if a node can demonstrate that it is able to receive packets at an address by responding to messages sent to that address, assigning ownership of that address to the node cannot make the current Internet less secure. In spite of its documented weaknesses, Return Routability (RR) is generally accepted as the default mechanism for route optimization with Mobile IPv6. When looking into the practical deployment of RR, some interesting considerations arise. First, the routing infrastructure is based predominantly on IPv4. So, the routability of an IPv6 address is determined, at least, in part by the ability to correctly associate Koodli Expires 11 January 2005 [Page 1] Internet Draft Mobile IPv4 Route Optimization 11 July 2005 the IPv6 address with the IPv4 address of the tunnel end-point that actually forwards the IPv6 packet encapsulated in an IPv4 packet. The work in progress in the [v6ops] working group in IETF is presumably addressing this issue. Second, most terminals for which RR is of interest are likely going to be dual-stack. For instance, most Mobile Nodes with Mobile IPv6 are expected to be dual-stack, and those Correspondent Nodes which are not Mobile Nodes themselves but support route-optimized communication are likely going to be dual-stack. In deployments where this is valid, RR can be accomplished by the end-points themselves without the need for additional support for IPv6 tunneling from the infrastructure elements. The use of IPv6 when routable IPv4 addresses are available could be questioned. However, the nodes cannot use route-optimized path even with globally routable IPv4 addresses. Finally, even if the end-points themselves are not able to tunnel RR messages, route optimization for IPv4 traffic deserves consideration given that majority of the routing is based on IPv4. This motivates the need for a solution that allows direct, route-optimized communication using both IPv6 and IPv4 addresses. In this document, we investigate the following problem: How to enable route-optimized communication for IPv4 traffic using IPv6 RR. We provide a reference model and identify the extensions to the existing RR mechanism. 2. Reference Model and Assumptions In our model, a Correspondent Node is assumed to be capable of performing IP-in-IP encapsulation and de-encapsulation. Specifically, a CN is able to perform IPv6-in-IPv4 encapsulation and de-encapsulation. A CN is the end-point for the IPv6-in-IPv4 tunnel. A Home Agent is also an end-point for the IPv6-in-IPv4 tunnel. Note that the CN and the HA need not be general-purpose tunnel end-points. A Mobile Node need not be an IPv6-in-IPv4 tunnel end-point. The Mobile Nodes learn about a CN's IPv4 address and IPv6 address via DNS or by other means. A single node acts as a Home Agent for both IPv4 and IPv6. In other words, a MN's Home Agent has access to both the IPv4 and IPv6 binding and security information. It is not clear if a protocol is necessary to access the IPv4 bindings from an IPv6 Home Agent and vice-versa; in any case, such a protocol is beyond the scope of this specification. Finally, the Home Agent is able to process new Mobility Options this document specifies. Koodli Expires 11 January 2005 [Page 2] Internet Draft Mobile IPv4 Route Optimization 11 July 2005 3. Protocol Operation When a MN sends the Care of Address Test Init (COTI) message, it includes a new IPv4 CoA Mobility Header Option and a new IPv4 CN Address Mobility Header Option. The IPv4 CoA is what the MN uses on the visited network for its IPv4 traffic. The IPv4 CoA acts as the tunnel end-point for the COTI (and the ensuing COT) message. When the address is co-located with the MN's interface, the COTI message is encapsulated and the COT message is de-encapsulated by the MN itself. When the IPv4 address is not co-located with the MN, the node offering the IPv4 address service for the MN MUST be able to perform (de)encapsulation and correctly forward the tunneled IPv4 and IPv6 packets to the MN. When the IPv4 address is not co-located, the node hosting the IPv4 address also needs to know the CN's IPv4 address to tunnel the COTI message to. One way to do this is by having the tunnel end-point inspect the packets for Mobility Header type, and process the new options when present. This operation is not necessary when the MN itself can act as a tunnel end-point. In any case, the COTI message with the new extension is encapsulated and sent to the CN's IPv4 address. The source address of the tunnel is the IPv4 CoA. As might be evident, the purpose of tunneling directly to a CN's IPv4 address is to demonstrate to the CN that the MN is reachable at the source IPv4 address of the tunnel. When the MN sends the Home Addess Test Init (HOTI) message, it includes a new IPv4 Home Address (HoA) option, as well as a new IPv4 CN Address option. There are no specific IPv4 tunneling requirements for the HOTI message. However, if the MN is the IPv4 tunnel end-point, it MAY tunnel the HOTI message directly to the Home Agent's IPv4 address. In such a case, avoiding reverse tunneling of HOTI using IPv6 addresses may be considered; however this has implications on IPSec operations for the HOTI message. Specifically, the IPSec association needs to be based on the MN's IPv4 CoA. For transparent operation, the MN SHOULD encapsulate the IPSec protected HOTI message using its IPv4 CoA. When the Home Agent receives the HOTI message, it MUST process the new extensions. Note that the Home Agent must be able to inspect the Next Header field anyway in order to be able to apply IPSec. The proposal here requires the Home Agent to also look for the new extension when the Next Header type is Mobility Header, and perform the following operations. The Home Agent MUST act as the IPv6-in-IPv4 tunnel end-point by including the MN's HoA as the source IP address and the CN's IPv4 address as the destination address for the tunnel. Both the addresses are present in the new extension to HOTI. The Home Agent MUST ensure that a valid binding exists for the IPv4 HoA before tunneling the packet to the CN. When the CN processes the new extension in COTI, it first compares whether the IPv4 CoA in the extension is the same as the source Koodli Expires 11 January 2005 [Page 3] Internet Draft Mobile IPv4 Route Optimization 11 July 2005 address in the IPv4 tunnel. It then compares if the IPv4 CN address in the extension is the same as its own IPv4 address present in the destination address of the IPv4 tunnel. If both verifications are true, it concatenates the IPv4 CoA to the other parameters in generating the care-of keygen token. The CN then tunnels the Care of Test (COT) message to the MN's IPv4 CoA. When the CN processes the new extension in HOTI, it first compares whether the IPv4 HoA in the extension is the same as the source address in the IPv4 tunnel. It then compares if the IPv4 CN address in the extension is the same as its own IPv4 address present in the destination address of the IPv4 tunnel. If both verifications are true, it concatenates the IPv4 HoA to the other parameters in generating the home keygen token. The CN then tunnels the Home Test (HOT) message to the MN's IPv4 HoA. When the Home Agent receives the tunneled HOT message, it does the following. Since the destination address in the outer packet is IPv4 HoA, the IPv4 portion of the Home Agent operation requires verification of presence of a tunnel, according to RFC 3344 (Section 4.2.3). In this case, the destination addresses are the ``same'' in the tunneled and encapsulating packets. They belong to different IP versions however. When the inner packet is of type IPv6, the inner packet MUST be forwarded to Mobile IPv6 processing code, which in turn applies IPSec and returns the HOT packet back to the Mobile IPv4 processing code. The Home Agent then changes the destination address of the outer IPv4 packet to the IPv4 CoA corresponding to the IPv4 HoA. The MN receives both the COT and HOT messages. The MN constructs the Binding Update message. The MAC calculation MUST include the IPv4 CoA and the CN's IPv4 addresses. The MN MUST include the IPv4 HoA and the IPv4 CoA as new Mobility Header Options. The Binding Update MUST be sent using an IPv4 tunnel with IPv4 CoA as the source address and the CN's IPv4 address as the destination address just as in the COTI message transmission. The CN binds the IPv4 CoA to the IPv4 HoA in addition to binding IPv6 CoA to the IPv6 HoA. The CN also binds the IPv6 CoA to IPv4 CoA for IPv6-in-IPv4 tunneling. This allows direct, route-optimized communication for IPv4 traffic, and allows tunneling route-optimized IPv6 traffic using IPv4. 4. Message Formats A new IPv4 address option is defined as a Mobility Header option. This option is used to carry the MN's IPv4 CoA and CN's IPv4 addresses in the RR messages and the Binding Update message. Koodli Expires 11 January 2005 [Page 4] Internet Draft Mobile IPv4 Route Optimization 11 July 2005 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Mobility Header IPv4 Address Option Type New Type denoting an IPv4 Address Length Length of the option in octets not including the Type and Length fields. MUST be set to 4. IPv4 Address This field can include the MN's IPv4 HoA and CoA (in that order when both are present) and the CN's IPv4 address. 5. IANA Considerations The IPv4 Address Option needs a new type assignment from the Mobile IPv6 Mobility Header Options registry. 6. Security Considerations With IPv6-in-IPv4 tunneling, a node could potentially include any IPv6 address inside an IPv4 packet. This document does not propose a solution to this general problem. It does however require that the tunnel end-points are the correspondents and mobile nodes themselves. This consideration applies to tunneling of COTI in an IPv4 packet. With HOTI, the Home Agent can ensure that the IPv6 HoA and the IPv4 HoA actually belong to the same MN. A correspondent node MUST ensure that the address present in the IPv4 Mobility Header option is the same as the source IP address of the encapsulating IPv4 packet. References [1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. Request for Comments 3775, Internet Engineering Task Force, June 2004. Koodli Expires 11 January 2005 [Page 5] Internet Draft Mobile IPv4 Route Optimization 11 July 2005 7. Author's Address Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 650 625 2359 Fax: +1 650 625 2502 E-Mail: Rajeev.Koodli@nokia.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. 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 implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Koodli Expires 11 January 2005 [Page 6] Internet Draft Mobile IPv4 Route Optimization 11 July 2005 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koodli Expires 11 January 2005 [Page 7]