Individual Submission K. Moore Internet-Draft University of Tennessee Expires: 14 February 2004 14 August 2003 Substitution of IPv6 Prefixes for Improved Address Stability draft-moore-ipv6-prefix-substitution-aa Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Comments on this proposal should be sent to the IPv6 working group mailing list ipng@sunroof.eng.sun.com, or to the author. Abstract This document proposes a method known as "prefix substitution" to allow IPv6 applications whose endpoints share a common address prefix to substitute a stable prefix in source and destination addresses for a less stable one. This allows stable addresses to be used by applications where appropriate, without having to advertise such addresses in DNS or in other kinds of referrals. This in turn should minimize leakage of such addresses outside of the portion of the network in which they are usable. 1. Introduction For various reasons it will sometimes be necessary for Internet sites to change the routable prefixes associated with their networks, and Moore IPv6 Prefix Substitution [Page 1] Internet-Draft 14 August 2003 therefore, the IP addresses used by hosts at that site will also need to change. This can cause disruption to IP-based applications even when those applications communicate only over local links. Various proposals exist for addresses which are bound to a organization ("provider- independent") rather than to that organization's ISP ("provider- assigned"), which should allow for more stability, but this comes at a cost - the addresses are either ambiguous or are not generally usable from arbitrary points in the network, and hence are not suitable for referrals via DNS or other applications that are not aware of the boundaries within which such addresses are usable. This document proposes a method known as "prefix substitution" to allow IPv6 applications whose endpoints share a common address prefix to substitute a stable (though perhaps not universally usable) prefix for a less stable one. This allows stable addresses to be used by applications where appropriate, even though those addresses were not obtained via referrals from DNS or another application. Furthermore, since those stable addresses need not be advertised in DNS or other applications in order to be used, this provides an opportunity to minimize leakage of such addresses. In a nutshell, the method is as follows: - In addition to the routable prefixes that are currently assigned to a network, stable prefixes are advertised using the Routing Advertisement (RA) protocol [rfc2461]. - An extension to RA defines a mapping from routable prefixes to stable prefixes known as the "prefix substitution table" (PST). By providing this table the network indicates its willingness to route the stable prefixes equivalently to the routable prefixes, within the portion of the network to which the RA is sent. This PST is then made available to the host's IP stack and applications. - Hosts or applications desiring maximum stability for their endpoint addresses may consult the PST for possible substitutions. If there is a common prefix available to each of the endpoints, and an equivalent prefix for that common prefix is listed in the PST, the host or application may (under some circumstances) substitute the equivalent prefix for the prefixes in the source and destination addresses, instead of addresses which were obtained by DNS or other means. (However a host is not permitted to substitute a prefix in an address which was explicitly specified by the application.) The format and allocation mechanisms for stable prefixes is outside the scope of this version of the proposal, but may be specified later. There have been multiple proposals for Globally-Unique Provider- Independent addresses (GUPIs) or Probabilistically-Unique Provider- Moore IPv6 Prefix Substitution [Page 2] Internet-Draft 14 August 2003 Independent addresses (PUPIs) which might be suitable. 2. Protocol The PST is transmitted to hosts via a new option to the Routing Advertisement (RA) protocol. The PST maintained by a host is a list of the RA Substitutable Prefix options it has received which are still within their Substitution Lifetimes. The Substitutable Prefix option 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 | Prefix Length | Criteria | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Substitution Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + reserved + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Original Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Substitute Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type To be defined by IANA. Length 6 (indicating a total length of 6*8 octets). Moore IPv6 Prefix Substitution [Page 3] Internet-Draft 14 August 2003 Prefix Length 8-bit unsigned integer, indicating the number of leading bits in the Original Prefix that should be used for comparison with a source or destination address, and the number of bits of the Substitute Prefix that may be substituted in a source or destination address that matches the Original Prefix. Criteria The Criteria field is an 8-bit unsigned integer. Each value of the Criteria field indicates a set of conditions under which the substitution is considered appropriate. A value of zero is defined for substitutions which increase the stability of address-to-host bindings, but which may result in addresses that are unroutable, or less efficient, outside the scope of the RA. Other values, indicating different substitution criteria, may be defined in future revisions of this specification. Substitution Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that it is valid to substitute the Substitute Prefix for the Original Prefix. A value of all one bits (0xffffffff) represents infinity. In general this should be no longer than the Valid Lifetime field of the Prefix Information option in which the Original Prefix is advertised. Note that Substitution Lifetime limits the length of time that a host maintains this Substitutable Prefix mapping in its PST, NOT the length of time during which substituted addresses are valid. Once a substitution has been made based on information in the PST, the resulting addresses are assumed to be routable within the local network and stably bound to the same hosts, even if the Substitution Lifetime subsequently expires. Original Prefix, Substitute Prefix Each of these is an IPv6 address or a prefix of an IPv6 address. The Prefix Length field contains the number of valid leading bits in both the Original Prefix and the Substitute Prefix. The remaining bits in each of those prefixes MUST be set to zero by the sender and ignored by the receiver. reserved Fields marked as "reserved" MUST be filled with zero bits when transmitted, and MUST be ignored by recipients. 3. Rules for use of the Substitutable Prefix Option Moore IPv6 Prefix Substitution [Page 4] Internet-Draft 14 August 2003 3.1. Rules for use by applications An application which prefers stable addresses over globally routable addresses MAY consult the PST after it has obtained a set of potential addresses for an intended destination, and use the PST to determine if there are additional source and destination address pairs by which the destination can be reached, in addition to those disclosed to the application through DNS or other means. For each address A of the destination in the original list, if an entry P exists in the PST for which - P.Criteria == 0, - The leading P.Prefix_Length bits of P.Original_Prefix are equal to the same number of leading bits in address A, and - The originating host has a source address assigned to it for which the leading P.Prefix_Length bits of P.Original_Prefix are equal to the same number of leading bits of the source address, then the application MAY substitute the Substitute Prefix in both the source and destination addresses and communicate using those addresses. (An application that substitutes a prefix in either the source or destination address SHOULD substitute the same prefix in the other address.) An application MUST NOT substitute an address which was explicitly specified to the application (say by a user or system administrator) using an address literal. Applications that perform address referrals (i.e. those that transmit addresses to processes on other hosts) SHOULD NOT expose addresses obtained via Prefix Substitution to other processes, since those addresses might not be usable by peers. For the same reason, applications that obtain referral addresses from the IP source address (e.g. getpeername()) SHOULD NOT use Prefix Substitution. Global addresses SHOULD be used in referrals whenever possible. 3.2. Rules for use by host IP stacks On receipt of a Routing Advertisement message containing a valid and applicable (see below) Substitutable Prefix option, a host adds an entry to its Prefix Substitution Table (PST) to contain the new substitution; or if an entry already exists, the host replaces its current entry with the new one. Each Criterion field produces a separate entry in the table. Moore IPv6 Prefix Substitution [Page 5] Internet-Draft 14 August 2003 A host MUST ignore any Substitutable Prefix option which is not valid. Examples of invalid Substitutable Prefix options include those with the Original Prefix set to a multicast prefix, link-local prefix, or site- local prefix. (See section 3.3.) A host MUST ignore any Substitutable Prefix option which is not applicable to that host. A Substitutable Prefix option is applicable if and only if the host has a pair of addresses (A, B) assigned to it (via Stateless Address configuration or other means) where A is contained in the Source Prefix of the Substitutable Prefix option, B is contained in the Destination Prefix of that option, and the last (128 - Prefix Length) bits of A and B are equal. Host stacks MUST provide an API by which applications can access the Prefix Substitution Table (or equivalent information arranged differently) if they permit applications to specify the IPv6 source address or destination address literally (e.g. by bind(), connect(), or sendto() calls). A host IP stack MAY substitute source and destination addresses (according to the rules in section 3.1) if the application specified the destination to the stack using a "host name" (e.g. DNS or other identifier that could potentially map to multiple addresses) through its API. A host IP stack MUST NOT substitute a source or destination address if either has been explicitly specified by the application, unless the API provides a means by which applications may explicitly permit this substitution. For example, in the current "sockets API" [RFC3493] an application explicitly specifies a destination address, so a host using this API MUST NOT perform the substitution - the substitution must be done by the application. However it would be possible to define a new socket option (off by default) that allowed the host stack to perform that substitution when the option was enabled by the application. 3.3. Rules for use by routers A router MUST NOT advertise Substitutable Prefixes unless explicitly configured to do so, either via direct configuration or indirectly via an interior routing protocol or other interior router configuration protocol. A router MUST NOT send a Substitutable Prefix option with the Original Prefix field set to a multicast prefix (any prefix beginning with FF00::/8), a link-local prefix (any prefix beginning with FE80::/10) or a site-local prefix (any prefix beginning with FEC0::/10). Hosts MUST ignore Substitutable Prefix options which provide substitutions for any of these prefix types. Moore IPv6 Prefix Substitution [Page 6] Internet-Draft 14 August 2003 An network administrator MAY configure a router to advertise one or more Substitutable Prefix mappings, if and only if the following conditions apply: - Packets sent to addresses with the Substitute Prefix are routed identically to packets sent to addresses with the Original Prefix, within the portion of the network defined by the Original Prefix and the Prefix Length. - If packet filtering is employed, packets using the Substitute Prefix in a source and/or destination address are filtered identically to packets using the Original Prefix, within the portion of the network defined by the Original Prefix and the Prefix Length. A router that transmits Substitutable Prefix options MUST transmit in the same RA, Prefix options which will cause hosts to configure addresses and routing for both the Source Prefix and Destination Prefix in the Substitutable Prefix option. This ensures that the Source Prefix and Destination Prefix will be valid for all hosts which receive that Substitutable Prefix advertisement. In other words, changing a packet's source and destination addresses from the Original Prefix to the Substitute Prefix MUST NOT result in the network's failure to route a packet to its destination, if the same packet would have been routed without those changes. 4. API Issues The getaddrinfo() interface MUST NOT be changed to include addresses derived from the PST. However it may be desirable to define a new API similar to the following: int substitute_addrs (struct addrinfo **ai, int criteria); where "*ai" is a pointer to the head of a linked-list of addrinfo struc- tures such as might have been provided by getaddrinfo(), and "criteria" indicates the desired Criteria value to be used in substitutions. On return, "*ai" would then point to a modified list of addrinfo struc- tures, with additional destination addresses available if substitutions were found to be possible. 5. Compatibility Issues It is assumed that "old" hosts that do not implement this specification will ignore Substitute Prefix options in Router Advertisements but continue to process the remainder of such Router Advertisements. "Old" hosts will still configure the Prefixes in those options, so they will Moore IPv6 Prefix Substitution [Page 7] Internet-Draft 14 August 2003 be able to accept traffic using the "stable" prefixes as well as at the "portable" prefixes, and exchange traffic with "new" hosts that have employed prefix substitution. However "old" hosts, and applications running on "old" hosts, will not realize that they can treat those prefixes as equivalent when originating traffic. Applications running on "old" hosts may fail if they are using a portable address even though a stable address is available, and the portable address becomes invalid for some reason (say, due to renumbering or disconnection from the network). There is some chance that applications running on "old" hosts will accidentally use the stable prefixes (for instance, in referrals) when the portable prefixes would have been a better choice. On occasion the choice of a stable prefix over a portable one could lead to application failures. However without this extension no means exists which allows portable and non-portable-but-stable prefixes to coexist in a network without advertising both sets of addresses via DNS and expecting applications to choose between them. This extension attempts to minimize the exposure of non-portable addresses to applications that are not able to use them, and thus, to minimize the potential for failures that result from using non-portable addresses outside of the range in which they are routable. 6. Security Considerations Analysis of security considerations is incomplete at this writing. As a first approximation, the security risks of Router Advertisements with Substitutable Prefix options are assumed to be similar to the risks of Router Advertisements without such options, since either kind of advertisement, if forged, could be used to redirect traffic or to disrupt communications. However the risk may be different for the Substitutable Prefix option since that option not only redirects traffic but also can cause source and destination addresses to be changed. This could potentially make detection of attacks by network monitoring devices more difficult. 7. IANA Considerations IANA is requested to create a registry of Neighbor Discovery Option Type codes, starting with the list in RFC 2461, section 4.6; and to allocate an additional code for use by the Substitutable Prefix option as defined in this document. Moore IPv6 Prefix Substitution [Page 8] Internet-Draft 14 August 2003 8. Author's address Keith Moore Computer Science Department University of Tennessee 1122 Volunteer Blvd. Ste. 203 Knoxville TN 37996-3450 moore@cs.utk.edu 9. Normative References [rfc2461] Narten, T. Nordmark, E. Simpson, W. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998. [rfc3513] Hinden, R., Deering, S. Internet Protocol Version 6 (IPv6) Addressing Architecture. RFC 3513, April 2003. 10. Informative References [rfc3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., Stevens, W. Basic Socket Interface Extensions for IPv6. RFC 3493, February 2003. Moore IPv6 Prefix Substitution [Page 9]