Internet DRAFT - draft-moore-ipv6-prefix-substitution
draft-moore-ipv6-prefix-substitution
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]
