Network Working Group I. Van Beijnum Internet-Draft May 8, 2003 Expires: November 6, 2003 Multihoming in IPv6 by Rewriting Addresses draft-van-beijnum-multi-rewrite-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 Internet-Draft will expire on November 6, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This is an effort to take the core ideas from 8+8 and/or GSE and create a multihoming solution for IPv6 by expanding on those ideas. The central principle is that there is a difference between the addresses both endpoints in a communication session see (the identifiers) and the addresses used for forwarding (the locators). This allows end-to-end sessions to survive a change in topology characteristics and by extension the reachability status of the addresses associated with this topology. This approach is based on extensive discussions in the multihoming in IPv6 (multi6) working group. As such, any credit should be bestowed on the multi6 wg, but the author takes full responsibility for all Van Beijnum Expires November 6, 2003 [Page 1] Internet-Draft Multihoming in IPv6 by Rewriting Addresses May 2003 possible blame. Van Beijnum Expires November 6, 2003 [Page 2] Internet-Draft Multihoming in IPv6 by Rewriting Addresses May 2003 1. Introduction Historically, the IP address has always primarily been an identifier of an interface for a host. Since early IP didn't provide any other identifiers, the IP address has been doing double duty as an a higher-layer identifier. This isn't much of a problem when a host has a single, stable address, which has typically been the case with IPv4. However, in IPv6 it is expected that hosts routinely have more than a single address with a larger than link-local scope. One of the main reasons for this is that having multiple provider-aggregatable addresses is the only way for hosts or sites to connect to more than one service provider (multihome) that doesn't have inherent scaling limitations. In the presence of multiple addresses for both the source and destination hosts, even a mundane task like creating a transport session becomes rather complex as each combination of source and destination addresses has different properties. Just choosing a combination that works is difficult enough, but choosing the optimum combination is nearly impossible. To add insult to injury, these properties may change over the lifetime of a session. Moving from one source/destination address pair to another is something common transport protocols such as TCP can't do. In the past it has been suggested to separate the identifyer function that applications and transport protocols need from the locator function that the routing system can provide. It is the purpose of this memo to outline a way to do this in enough detail to uncover the potential problems with this approach in order to facilitate discussions within the IETF. As such, it is an explicit goal to include all reasonable permutations and synthesize those into more general mechanisms where possible. This inevitably means more complexity, but the author is of the opinion that a complex design that leads to a simple solution is better than a simple design that leads to a complex solution. If the IETF chooses to pursue this approach, there should be ample opportunity to remove options that are deemed undesirable later. Van Beijnum Expires November 6, 2003 [Page 3] Internet-Draft Multihoming in IPv6 by Rewriting Addresses May 2003 2. Addressing Overview The basic idea behind this approach is to give the transport layer and applications a stable identifier while in transit packets use one of several provider aggregatable addresses. This can implemented in hosts, in which case there are no specific limits on the shape of the identifier. It can also be implemented in a proxy multihoming agent, in which case the identifier must be a valid IPv6 unicast address. The original GSE and 8+8 drafts split the IPv6 address in two 64-bit parts. The lower part is used within the site or subnet. Routers add the higher 64 bits as packets leave the site. Since hosts don't know the higher 64 bits their correspondent will see, they must disregard these bits, which has the relatively minor consequence that the TCP and UDP pseudo header used in checksum calculations must be changed. A more severe consequence is that the lower 64 bits must now be globally unique. This in turn makes it very easy to perform spoofing attacks, as an attacker can simply present arbitrary lower bits, thereby assuming any desired identity, while setting the higher bits such that the packets are routed back to the attacker and not to the host identified by the lower 64 bits. This vulnerability, breaking autoconfiguration and, to a lesser degree, the transport layer checksums, make adopting GSE or 8+8 unfeasible and undesirable. Rather than go from one extreme, where one and the same value is both the locator and the identifier, to the other, where the locator and identifier are completely unrelated, it makes sense to separate these functions only to the degree that is absolutely required. This is done by creating a mapping mechanism that allows an identifier value to be mapped to a small number of locators, and a locator only to a single identifier. In essence, the locators retain the identifier function, the identifier value is only necessary to avoid the complications that would arise in applications and transport protocols if those had to handle multiple addresses themselves. This "weak" identifier/locator separation has two advantages: 1. Assuming the mapping function is set up properly, return routability still works, so there is no need for extensive additional per-packet security measures to retain the level of security offered by regular TCP/IP. 2. IPv6-capable hosts that are unaware of the multihoming mechanisms outlined in this document can enjoy the full benefits of multihoming in the presence of proxy multihoming agents. Unmodified hosts simply operate as before and can enjoy the full benefits of autoconfiguration and the simplicity of having to deal only with a single address for each interface. Van Beijnum Expires November 6, 2003 [Page 4] Internet-Draft Multihoming in IPv6 by Rewriting Addresses May 2003 A multihomed site must be assigned a range of IPv6 addresses by each of its ISPs. These addresses are used as locators. One range may also be used concurrently as identifiers. However, it is expected that multihomed networks will want to use provider-independent (PI) address space for the locator function. Author's Address Iljitsch van Beijnum Karel Roosstraat 95 2571 BG The Hague NL EMail: iljitsch@muada.com Van Beijnum Expires November 6, 2003 [Page 5] Internet-Draft Multihoming in IPv6 by Rewriting Addresses May 2003 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 implementors 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 which 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 (2003). 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 assignees. 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 Van Beijnum Expires November 6, 2003 [Page 6] Internet-Draft Multihoming in IPv6 by Rewriting Addresses May 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Van Beijnum Expires November 6, 2003 [Page 7]