Multi6 Working Group I. van Beijnum Internet-Draft June 23, 2003 Expires: December 22, 2003 Two Prefixes in One Address draft-van-beijnum-multi6-2pi1a-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 December 22, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo presents a possible solution to the multihoming in IPv6 problem. It borrows from earlier 8+8 and GSE proposals but it diverts from these approaches in order to be more readily deployable. A source host that wants to initiate communications looks up the IPv6 addresses that will function as the transport-layer identifier and the IP-level locators for the remote end in the DNS and collapses both of its own addresses into a single one. This makes it possible to communicate without prior negotiation, but without opening the door to trivial identity theft that must be repaired by cryptographic means. Van Beijnum Expires December 22, 2003 [Page 1] Internet-Draft Two Prefixes in One Address June 2003 1. Clients and servers Note that the use of the words "client" and "server" indicate the role a host fulfills at a particular time communication with a particular correspondent. A single host can operate as both a client and a server (for different sessions) concurrently. Van Beijnum Expires December 22, 2003 [Page 2] Internet-Draft Two Prefixes in One Address June 2003 2. Client to multihomed server When a client connects to a multihomed server, it looks up all the addresses for the server in the DNS. The DNS returns one address that will be used as an identifier (i.e., this address will be presented to upper layers, even if the actual address used for transmitting and receiving packets changes over the course of a session) and two or more addresses that will be used to locate the server. The identifier address may or may not do double duty as a locator address. The wisdom of using one address both as a multihomed identifier and a generic IPv6 is under debate, so this shouldn't be the default. The different locator addresses may be bound to the same physical interface, or to different interfaces or a combination. For instance, a host with two network interfaces could have a single locator address for each interface, while a host with one network interface would have two locator addresses tied to this one interface. A host with two interfaces could also have two addresses for each interface, for a total of four, if there are compelling reasons for this. The client sets up mapping state that allows incoming packets from one of the locator addresses to be mapped back to the identifier address, and for outgoing packets the identifier address to be mapped to one of the locators. Note that despite the fact that this happens at session setup time, this mechanism works at the IP level. So if the mapping has been set up it is re-used on subsequent sessions that are directed to the same identifier address. The mapping state is flushed when there haven't been any active higher layer sessions for some time. Since removing the mapping state will break all higher layer sessions that are still active, and hinder applications that may want to set up new sessions to systems they have communicated with earlier, the system must not be too aggressive in this regard. The client may implement several heuristics to determine wich locator address should be used when transmitting packets. If one of the heuristics is the use of ICMP packets to check reachability, the number of those may not exceed one per minute unless the client has positive knowledge the server is prepared to handle a larger number. In the absense of better knowledge, the client is expected to return packets to the locator address last used by the server. However, since this locator may become unreachable for the client at some point, the client must be prepared to make its own judgement of the reachability of this locator and switch to an alternative locator if Van Beijnum Expires December 22, 2003 [Page 3] Internet-Draft Two Prefixes in One Address June 2003 this is warranted. Van Beijnum Expires December 22, 2003 [Page 4] Internet-Draft Two Prefixes in One Address June 2003 3. Multihomed server to client When a multihomed server receives a packet on one of its locator addresses, it maps this packet to its identifier address and continues to process the packet as if it had been addressed to the identifier address. In order for the multihomed server to recognize whether a packet was sent to a locator address by a multihoming-aware client, or to a generic address by a non-multihoming-aware client, locator address may not be the same as regular addresses that are published using AAAA records. The identifier address may be the same as one of those addresses, however. Note that in this case, the server must keep per-peer-address state in order to know whether the correspondent host is multihoming-capable. When a multihomed server transmits a packet back to a multihoming-capable client it maps the identifier address to one of the locator addresses. The server may implement several heuristics to determine wich locator address should be used when transmitting packets. If one of the heuristics is the use of ICMP packets to check reachability, the number of those may not exceed one per minute unless the server has positive knowledge the client is prepared to handle a larger number. A multihomed server is not required to keep per-correspondent state about which of its locators is best used as a source address to reach a certain correspondent. A server may make this determination based on the contents of the routing table, or it may select a single locator to be used for all multihoming-aware correspondents. The latter isn't advised as it provides only partial multihoming benefits. Van Beijnum Expires December 22, 2003 [Page 5] Internet-Draft Two Prefixes in One Address June 2003 4. Multihomed client In order to avoid the use of discovery or negotiation mechanisms when setting up sessions to multihomed servers, multihomed clients encode two prefixes (and host- and subnet identifiers) into two equivalent 128 bit IPv6 addresses that are to be used as locators. These addresses are structured as follows: Locator 1: +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Prefix from ISP A | Subnt | Prefix from ISP B | Host | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Locator 2: +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Prefix from ISP B | Subnt | Prefix from ISP A | Host | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Locator 2 is an alternate form of locator 1 and vice versa. One of the locators is also used as the identifier. In order to determine which, two 48-bit values are derived from a locator. The first value (V1) has the bits 32 - 47 as the first 16 bits, bits 16 - 31 as the second 16 bits and bits 0 - 15 as the last 16 bits. The second value (V2) has bits 96 - 111 as the first 16 bits, bits 80 - 95 as the second 16 bits and bits 64 - 79 as the last 16 bits. V1 and V2 are now compared, as are the 16 bit subnet and host values. There are now four possibilities: 1. subnet >= host and V1 >= V2: the current form of the address is the identifier 2. subnet >= host and V1 < V2: the alternate form of the address is the identifier 3. subnet < host and V1 >= V2: the alternate form of the address is the identifier 4. subnet < host and V1 < V2: the current form of the address is the identifier When setting up a session, both the multihomed client and the server set up the necessary mapping state to map the identifier to the alternate locator and from the alternate locator back to the identifier, when required. The subsequent handling of transmitting and receiving packets is equivalent to the multihomed server case. Van Beijnum Expires December 22, 2003 [Page 6] Internet-Draft Two Prefixes in One Address June 2003 5. Single homed, but multihoming-aware client to multihomed server When a multihoming-aware, but not multihomed client wants to communicate with a multihomed server, it must avoid being classified as an actual multihomed client. This is accomplished by using a value in bits 64 - 111 of its address that is easily recognizable as not being a valid 48 bit prefix of a routable IPv6 unicast address. At present, setting bits 64 - 66 to any other binary value than 001 will accomplish this, but single homed, multihoming-aware clients are advised to use the value 0 in bits 64 - 71 in order to avoid being mistaken for a multihomed client when the global unicast address space is increased. Alternatively, the client may create an address for itself the same way a multihomed client would, but with the same prefix in both bits 0 - 47 and bits 64 - 111. An implementation must support setting the entire address by user-configurable means such as manual configuration or DHCP. Van Beijnum Expires December 22, 2003 [Page 7] Internet-Draft Two Prefixes in One Address June 2003 6. Address discovery through the DNS In order for multihoming-aware clients to set up sessions to multihomed servers, they must connect to the right locator addresses and create mappings using the identifier address, but these addresses must remain invisible to legacy IPv6 hosts; those should connect to different addresses for which no multihoming processing is done. This is accomplished by publishing identifiers and locators in the DNS using a new resource record type. The name "A8" seems appropriate for this purpose. The exact structure of the A8 RR will be determined at a later date. The A8 record, or the full set of A8 records, for a host should provide the following information about the set of addresses the host wants to use in multihoming: 1. Whether the address is an identifier only, and identifier and locator, or a locator only. 2. Whether a locator may always be used or it is just a backup. 3. A value that indicates the degree of preference given to a locator. All else being equal, a locator with a twice as high preference value should receive twice the number of connection attempts and/or packets during established sessions as another locator with half that preference value. Note that this document doesn't provide for multihomed communication without involvement from the DNS. Alternative mechanisms to discover the locators based on an identifier so the identifier can be used by applications to set up sessions the same way a literal IP address can be used may be developed later. Van Beijnum Expires December 22, 2003 [Page 8] Internet-Draft Two Prefixes in One Address June 2003 7. Source address handling It is very important to select the right source address for every outgoing packet. Not only will return traffic often be directed at this address, using an unfortunate source address may also cause the packet to be lost due to egress or ingress filtering. It is strongly encouraged that hosts implement heuristics to determine that a source address doesn't work and that a different one should be used. An obvious example of such an heuristic is listening for ICMP administratively prohibited messages that are generated by the site's edge routers upon egress filtering. There are some security issues with this, but the unnecessary triggering of source address switching isn't fatal, while not switching source addresses when the wrong one is used often is (in the presence of ingress filtering by an ISP). Additionaly, routers may route packets based on the source address. So when a packet contains a source address with a prefix from ISP A, the packet is forwarded to ISP A, even though the routing table may point to a different ISP as the best or working route for this destination. This feature works well with smart hosts that know how to manipulate the source address for optimum connectivity. An alternative approach is to rewrite the address to conform with the ISP's ingress filtering when the packet leaves the site. Hosts may signal their desire to have addresses rewritten by setting one of two special source prefixes. When a router encounters the first special prefix in a source address, it rewrites the upper 48 bits of the source address with the prefix received from the ISP the packet is fowarded to. This special prefix is to be used by multihomed servers that have identical lower 80 bits in all their locator addresses. The second special prefix signals the router to perform the action indicated by the first special prefix, but also to rewrite bits 64 - 111 with the prefix received from the secondary ISP. Use of this special prefix is appropriate for multihomed clients. Both servers and clients must support manual disabling of the rewriting feature and should automatically recover from a situation where rewriting is requested but not honored. Van Beijnum Expires December 22, 2003 [Page 9] Internet-Draft Two Prefixes in One Address June 2003 8. Stateless autoconfiguration The requirements for bits 64 - 111 set forth in this document don't necessarily break stateless autoconfiguration, but they do limit the part of the IPv6 address that identifies a host to only 16 bits. Such a small value can't be realistically be expected to be chosen by the host without the strong possibility of address conflicts. This means autoconfiguration can't be depended upon to select the same address for a host repeatedly, which probably means servers must be manually configured with their addresses. For clients this shouldn't be much of an issue. Both multihomed clients and servers may obtain additional addresses that are not used in multihoming using traditional stateless autoconfiguration or DHCP. Van Beijnum Expires December 22, 2003 [Page 10] Internet-Draft Two Prefixes in One Address June 2003 9. IANA considerations The IANA is requested to assign a new resource record type code for A8 information in the DNS and two 48 bit values that can be used as a prefix in source addresses to signal routers that the source address should be rewritten upon egress. Van Beijnum Expires December 22, 2003 [Page 11] Internet-Draft Two Prefixes in One Address June 2003 10. Security considerations This multihoming mechanism doesn't provide any more security than regular IPv6 or IPv4. As such, the use of additional security measures such as TLS, IPsec and/or DNSSEC is highly recommended for even slightly sensitive applications. In order to be compatible with IPsec AH, both ends must either always first do IPsec processing and then multihoming processing, or first multihoming processing and then IPsec processing. A situation where one host does the former and the other host does the latter can't work. The implications of choosing the processing order are unknown at this time and should be subject of further study. In the mean time, implementations should by default perform all IPsec processing (not limited to AH) first and the required multihoming processing after that, but it should be configurable to do this the other way around. This mechanism enables communication over different addresses than the addresses applications see. This breaks most security mechanisms that operate on addresses. It is recommended that services that depend on address-based access restrictions not be multihoming-enabled by not binding the services to a multihomed identifier address and/or filtering the service on both the identifier and locator addresses. In order to be able to enable multihoming on clients, the client must not run any applications that restrict access to certain server addresses. However, it shouldn't be a problem to have these same restrictions enforced by mechanisms working at the IP layer (i.e., a firewall), as long as these mechanisms take all possible addresses into account. Hosts acting as multihomed clients can trick servers into sending traffic to third party networks by constructing a double prefix address with the target network's prefix in bits 64 - 111 and then ignore incoming packets from the server. However, if the original sender's ISP employs ingress filtering, this should be easy to track down as bits 64 - 111 in the packet that ends up at the target network points back to the original source network. Still, transport protocols and applications are encouraged to scale back their bandwidth use when there is a switch to a new destination locator. In TCP this event could trigger slow start. Van Beijnum Expires December 22, 2003 [Page 12] Internet-Draft Two Prefixes in One Address June 2003 Author's Address Iljitsch van Beijnum Karel Roosstraat 95 2571 BG The Hague NL email: iljitsch@muada.com Van Beijnum Expires December 22, 2003 [Page 13] Internet-Draft Two Prefixes in One Address June 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 December 22, 2003 [Page 14] Internet-Draft Two Prefixes in One Address June 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 December 22, 2003 [Page 15]