ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

add

Browse Source
This commit is contained in:
Bob Halley
1999-10-29 15:52:16 +00:00
parent 9e5bf8aab6
commit 9df6eb8719
1 changed files with 587 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

587
doc/draft/draft-ietf-ipngwg-default-addr-select-00.txt Normal file
View File

@@ -0,0 +1,587 @@
IPng Working Group R. Draves
Internet Draft Microsoft Research
Document: draft-ietf-ipngwg-default-addr-select-00.txt October 22, 1999
Category: Standards Track
Default Address Selection for IPv6
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [1].
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.
Abstract
This document describes two algorithms, for destination address
ordering and for source address selection. The algorithms specify
default behavior for all IPv6 implementations. They do not override
choices made by applications or upper-layer protocols, nor do they
preclude the development of more advanced mechanisms for address
selection. The two algorithms share a common framework, including an
optional mechanism for allowing administrators to provide policy
that can override the default behavior.
1. Introduction
The IPv6 addressing architecture [2] allows multiple unicast
addresses to be assigned to interfaces. These addresses may have
different reachability scopes (link-local, site-local, or global).
These addresses may be "preferred" or "deprecated" [3]. In addition,
multi-homing situations will result in more addresses per node. For
example, a node may have multiple interfaces, some of them tunnels
or virtual interfaces, or a site may have multiple ISP attachments.
The end result is that IPv6 implementations will very often be faced
with multiple possible source and destination addresses when
initiating communication. It is desirable to have simple default
algorithms, common across all implementations, for selecting source
Draves Standards Track - Expires May 2000 1
Default Address Selection for IPv6 October 22, 1999
and destination addresses so that developers and administrators can
reason about and predict the behavior of their systems.
This document specifies source address selection and destination
address selection separately, but using a common framework so that
together the two algorithms yield useful results. The algorithms
attempt to choose source and destination addresses of appropriate
scope and configuration status (preferred or deprecated).
Furthermore, this document suggests a preferred method, longest
matching prefix, for choosing among otherwise equivalent addresses
in the absence of better information.
The framework also has policy hooks to allow administrative override
of the default behavior. For example, using these hooks an
administrator can specify a preferred source prefix for use with a
destination prefix, or prefer destination addresses with one prefix
over addresses with another prefix. These hooks give an
administrator flexibility in dealing with some multi-homing and
transition scenarios, but they are certainly not a panacea.
The rules specified in this document MUST NOT be construed to
override an application or upper-layer's explicit choice of
destination or source address.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [4].
2. Framework
Our framework for address selection derives from the most common
implementation architecture, which separates the choice of
destination address from the choice of source address. Consequently,
the framework specifies two separate algorithms for these tasks. The
algorithms are designed to work well together and they share a
mechanism for administrative policy override.
In this implementation architecture, applications use APIs [5] like
getipnodebyname() and getaddrinfo() that return a list of addresses
to the application. The application then passes a destination
address to the IPv6 layer with connect() or sendto(). The
application might just use the first address in the list, or it
might loop over the list of addresses to find a working address. In
any case, the IPv6 network layer is never in a position where it
needs to choose a destination address from several alternatives. The
application might also specify a source address with bind(), but
often the source address is left unspecified. Therefore the IPv6
layer does often choose a source address from several alternatives.
As a consequence, we intend that implementations of
getipnodebyname() and getaddrinfo() will use the destination address
Draves Standards Track - Expires May 2000 2
Default Address Selection for IPv6 October 22, 1999
ordering algorithm specified here to sort the list of addresses that
they return. Separately, the IPv6 network layer will use the source
address selection algorithm when an application or upper-layer has
not specified a source address.
The algorithms use several criteria in making their decisions. The
combined effect is to prefer destination/source address pairs for
which the two addresses are of equal scope or type, prefer smaller
scopes over larger scopes for the destination address, prefer non-
deprecated source addresses of sufficient scope to reach the
destination, avoid the use of transitional addresses when native
addresses are available, and all else being equal prefer address
pairs having the longest possible common prefix.
The framework optionally allows for the possibility of
administrative configuration of policy that can override the default
behavior of the algorithms. The policy override takes the form of a
configurable table that provides precedence values and preferred
source prefixes for destination prefixes. If an implementation is
not configurable, or if an implementation has not been configured,
then the default policy table specified in this document MUST be
used.
2.1. Scope Comparisons
Multicast destination addresses have a 4-bit scope field that
controls the propagation of the multicast packet. The IPv6
addressing architecture defines scope field values for node-local
(0x1), link-local (0x2), site-local (0x5), organization-local (0x8),
and global (0xE) scopes.
Application of the address selection algorithms in the presence of
multicast destination addresses requires the comparison of a unicast
address scope with a multicast address scope. We map unicast link-
local to multicast link-local, unicast site-local to multicast site-
local, and unicast global scope to multicast global scope. For
example, unicast site-local is equal to multicast site-local, which
is smaller than multicast organization-local, which is smaller than
unicast global, which is equal to multicast global.
We write Scope(A) to mean the scope of address A. For example, if A
is a link-local unicast address and B is a site-local multicast
address, then Scope(A) < Scope(B).
This mapping implicitly conflates unicast site boundaries and
multicast site boundaries.
2.2. IPv4-Compatible Addresses and Other Format Prefixes
For the purposes of this document, IPv4-compatible addresses have
global scope and "preferred" configuration status.
Draves Standards Track - Expires May 2000 3
Default Address Selection for IPv6 October 22, 1999
Similarly, NSAP addresses, IPX addresses, or addresses with as-yet-
undefined format prefixes should be treated as having global scope
and "preferred" configuration status. Later standards may supercede
this treatment.
The loopback address should be treated as having link-local scope
and "preferred" configuration status.
2.3. Policy Table
The policy table is a longest-matching-prefix lookup table, like a
routing table. Given an address A, a lookup in the policy table
produces three values: a precedence value Precedence(A), a
classification or label Label(A), and a second label
MatchSrcLabel(A).
The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A
has higher precedence than address B, meaning that our algorithm
will prefer to sort destination address A before destination address
B.
The labels Label(A) and MatchSrcLabel(A) allow for policies that
prefer a particular source address prefix for use with a destination
address prefix. The algorithms prefer to use a source address S with
a destination address D if Label(S) = MatchSrcLabel(D).
IPv6 implementations SHOULD support configurable address selection
via a mechanism at least as powerful as the policy tables defined
here. If an implementation is not configurable or has not been
configured, then it MUST operate according to the algorithms
specified here in conjunction with the following default policy
table:
Prefix Precedence Label MatchSrcLabel
fe80::/10 40 1 1
fec0::/10 30 2 2
::/0 20 3 3
2002::/16 10 4 4
::/96 10 5 5
One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 source
addresses with 6to4 destination addresses, and v4-compatible source
addresses with v4-compatible destination addresses. Another effect
of the default policy table is to prefer communication using native
addresses to communication using either 6to4 or v4-compatible
addresses, but not to express a preference for 6to4 addresses over
v4-compatible addresses or vice-versa.
Draves Standards Track - Expires May 2000 4
Default Address Selection for IPv6 October 22, 1999
2.4. Candidate Source Addresses
Both the destination address ordering algorithm and the source
address selection algorithm use the concept of a "candidate set" of
potential source addresses for a given destination address.
We write CandidateSrc(A) to denote the candidate set for the address
A. In some cases the destination address A may be qualified with a
scope-id or other information that will constrain the candidate set.
We write PreferSrc(A) to denote the subset of preferred (non-
deprecated) addresses in CandidateSrc(A) We write MatchSrc(A) to
denote the subset of addresses S in PreferSrc(A) for which Label(S)
= MatchSrcLabel(A).
The destination address ordering algorithm and the source address
selection algorithm specify somewhat different definitions for
CandidateSrc(A). This is because the two algorithms operate in
different environments. The source address selection algorithm
assumes that an outgoing interface for a packet has already been
selected, while the destination address ordering algorithm does not
assume that knowledge. Therefore the destination address ordering
algorithm uses a broader or more-inclusive definition of
CandidateSrc(A).
In any case, anycast addresses, multicast addresses, and the
unspecified address MUST NOT be included in a candidate set.
2.5. Common Prefix Length
We define the common prefix length CommonPrefixLen(A, B) of two
addresses A and B as the length of the longest prefix that the two
addresses have in common. It ranges from 0 to 128.
We define the maximum common prefix length MaxCommonPrefixLen(A, X)
of an address A and a non-empty set of addresses X as the maximum of
CommonPrefixLen(A, B) for addresses B in the set X.
3. Destination Address Ordering
The destination address ordering algorithm takes a list of
destination addresses and sorts the addresses to produce a new list.
It is specified here in terms of the pair-wise comparison of
addresses DA and DB, where DA appears before DB in the original
list.
The pair-wise comparison consists of four rules, which MUST be
applied in order. If a rule determines a result, then the remaining
rules are not relevant and MUST be ignored. Subsequent rules act as
tie-breakers for earlier rules.
Rule 1: If MatchSrc(DA) is non-empty and MatchSrc(DB) is empty, then
sort DA before DB. Similarly, if MatchSrc(DA) is empty and
MatchSrc(DB) is non-empty, then sort DB before DA.
Draves Standards Track - Expires May 2000 5
Default Address Selection for IPv6 October 22, 1999
Rule 2: If Precedence(A) > Precedence(B), then sort DA before DB.
Similarly, if Precedence(B) > Precedence(A), then sort DB before DA.
Rule 3: If MatchSrc(DA) and MatchSrc(DB) are both non-empty. If
MaxCommonPrefixLen(DA, MatchSrc(DA)) > MaxCommonPrefixLen(DB,
MatchSrc(DB)), then sort DA before DB. Similarly, if
MaxCommonPrefixLen(DB, MatchSrc(DB)) > MaxCommonPrefixLen(DA,
MatchSrc(DA)), then sort DB before DA.
Rule 4: Sort DA before DB.
The third and fourth rules MAY be superceded if the implementation
has other means of sorting destination addresses. For example, if
the implementation somehow knows which destination addresses will
result in the "best" communications performance.
3.1. Candidate Source Addresses
For the purposes of destination address ordering, the candidate set
of source addresses CandidateSrc(D) for a destination address D
SHOULD contain all and only the unicast addresses assigned to
interfaces that might be used to send to the destination D.
For example, if the address D is a link-local unicast address that
is qualified with a scope-id value specifying a particular
interface, then CandidateSrc(D) SHOULD contain all and only the
unicast addresses assigned to that interface.
For example, if the address D is a global scope unicast address,
then CandidateSrc(D) MAY contain every unicast address assigned to
all interfaces. However if the implementation wishes to consult a
routing table and determine a likely outgoing interface, then
CandidateSrc(D) MAY contain only unicast addresses assigned to that
outgoing interface.
4. Source Address Selection
The source address selection algorithm chooses a source address for
use with a destination address D. It is specified here in terms of
the pair-wise comparison of addresses SA and SB. The pair-wise
comparison can be used to select an address from the set
CandidateSrc(D).
The pair-wise comparison consists of six rules, which MUST be
applied in order. If a rule chooses an address, then the remaining
rules are not relevant and MUST be ignored. Subsequent rules act as
tie-breakers for earlier rules. If the six rules fail to choose an
address, some unspecified tie-breaker MUST be used.
Rule 1: If SA is in MatchSrc(D) and SB is not, then choose SA.
Similarly, if SB is in MatchSrc(D) and SA is not, then choose SB.
Draves Standards Track - Expires May 2000 6
Default Address Selection for IPv6 October 22, 1999
Rule 2: If SA is equal to D, then choose SA. Similarly, if SB is
equal to D, then choose SB.
Rule 3a: If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then
choose SB. Otherwise, if one of the source addresses is "preferred"
and one of them is "deprecated", then choose the "preferred"
address. Otherwise, choose SA.
Rule 3b: Similarly, if Scope(SB) < Scope(SA). If Scope(SB) <
Scope(D), then choose SA. Otherwise, if one of the source addresses
is "preferred" and one of them is "deprecated", then choose the
"preferred" address. Otherwise, choose SB.
Rule 4: The addresses SA and SB have the same scope. If one of the
source addresses is "preferred" and one of them is "deprecated", an
implementation MUST choose the one that is preferred.
Rule 5: If Label(SA) = MatchSrcLabel(D) and Label(SB) <>
MatchSrcLabel(D), then choose SA. Similarly, if Label(SA) <>
MatchSrcLabel(D) and Label(SB) = MatchSrcLabel(D), then choose SB.
(Note that this rule will apply only when both SA and SB are
deprecated.)
Rule 6: If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then
choose SA. Similarly, if CommonPrefixLen(SB, D) >
CommonPrefixLen(SA, D), then choose SB.
The sixth rule MAY be superceded if the implementation has other
means of choosing among source addresses. For example, if the
implementation somehow knows which source address will result in the
"best" communications performance.
4.1. Candidate Source Addresses
For the purposes of source address selection, the candidate set of
source addresses CandidateSrc(D) for a destination address D MUST
contain all and only the unicast addresses assigned to the interface
that will be used to send to the destination D.
5. Interactions with Routing
All IPv6 nodes, including both hosts and routers, MUST conform to
this specification.
This specification of source address selection implies that routing
(more precisely, selecting an outgoing interface on a node with
multiple interfaces) is done before source address selection.
However, implementations MAY use source address considerations as a
tiebreaker when choosing among otherwise equivalent routes.
For example, suppose a node has interfaces on two different links,
with both links having a working default router. One of the
interfaces has a preferred global address and the other interface
Draves Standards Track - Expires May 2000 7
Default Address Selection for IPv6 October 22, 1999
only has a deprecated global address. When sending to a global
destination address, if there's no routing reason to prefer one
interface over the other, then an implementation MAY preferentially
choose the outgoing interface that will allow it to use the
preferred global source address.
6. Interactions with Mobility
TBD
7. Implementation Considerations
The destination address ordering algorithm needs information about
potential source addresses. One possible implementation strategy is
for getipnodebyname() and getaddrinfo() to call down to the IPv6
network layer with a list of destination addresses, sort the list in
the network layer with full current knowledge of available source
addresses, and return the sorted list to getipnodebyname() or
getaddrinfo(). This is simple but it introduces overhead.
Another implementation strategy is to call down to the network layer
to retrieve source address information and then sort the list of
addresses directly in the context of getipnodebyname() or
getaddrinfo(). To reduce overhead in this approach, the source
address information SHOULD be cached, amortizing the overhead of
retrieving it across multiple calls to getipnodebyname() and
getaddrinfo(). If an implementation uses cached and possibly stale
source address information in its implementation of destination
address ordering, then it MUST ensure that the source address
information is no more than one second out of date.
8. Security Considerations
This document has no direct impact on Internet infrastructure
security.
References
1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
3 S. Thompson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462 , December 1998.
4 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
5 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket
Interface Extensions for IPv6", RFC 2553, March 1999.
Draves Standards Track - Expires May 2000 8
Acknowledgments
The author would like to acknowledge the contributions of the IPng
Working Group.
Author's Address
Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA 98052
Email: richdr@microsoft.com
Revision History
Changes from draft-draves-ipngw-simple-srcaddr-01
Added framework discussion.
Added algorithm for destination address ordering.
Added mechanism to allow the specification of administrative policy
that can override the default behavior.
Added section on routing interactions and TBD section on mobility
interactions.
Changed the candidate set definition for source address selection,
so that only addresses assigned to the outgoing interface are
allowed.
Changed the loopback address treatment to link-local scope.
Changes from draft-draves-ipngw-simple-srcaddr-00
Minor wording changes because DHCPv6 also supports "preferred" and
"deprecated" addresses.
Specified treatment of other format prefixes; now they are
considered global scope, "preferred" addresses.
Reiterated that anycast and multicast addresses are not allowed as
source addresses.
Recommended that source addresses be taken from the outgoing
interface. Required this for multicast destinations. Added analogous
requirements for link-local and site-local destinations.
Specified treatment of the loopback address.
Changed the second selection rule so that if both candidate source
addresses have scope greater or equal than the destination address
and only of them is preferred, the preferred address is chosen.
Draves Standards Track - Expires May 2000 9
Default Address Selection for IPv6 October 22, 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 assigns.
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Draves Standards Track - Expires May 2000 10