[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

IPng Working Group                                          Richard Draves
Internet Draft                                          Microsoft Research
Document: draft-ietf-ipngwg-default-addr-select-01.txt       July 14, 2000
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 source address selection
   and for destination 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. In dual stack
   implementations, the framework allows the destination address
   selection algorithm to consider both IPv4 and IPv6 addresses -
   depending on the available source addresses, the algorithm might
   prefer IPv6 addresses over IPv4 addresses, or vice-versa.

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 also be "preferred" or "deprecated" [3]. Privacy
   considerations have introduced the concepts of "public addresses"
   and "anonymous addresses" [4]. The mobility architecture introduces
   "home addresses" and "care-of addresses" [5]. In addition, multi-
   homing situations will result in more addresses per node. For

Draves          Standards Track - Expires January 2001               1
Default Address Selection for IPv6                       July 14, 2000


   example, a node may have multiple interfaces, some of them tunnels
   or virtual interfaces, or a site may have multiple ISP attachments
   with a global prefix per ISP.

   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
   and destination addresses so that developers and administrators can
   reason about and predict the behavior of their systems.

   Furthermore, dual or hybrid stack implementations, which support
   both IPv6 and IPv4, will very often need to choose between IPv6 and
   IPv4 when initiating communication. For example, when DNS name
   resolution yields both IPv6 and IPv4 addresses and the network
   protocol stack has available both IPv6 and IPv4 source addresses. In
   such cases, a simple policy to always prefer IPv6 or always prefer
   IPv4 can produce poor behavior. As one example, suppose a DNS name
   resolves to a global IPv6 address and a global IPv4 address. If the
   node has assigned a global IPv6 address and a 169.254/16 "autonet"
   IPv4 address, then IPv6 is the best choice for communication. But if
   the node has assigned only a link-local IPv6 address and a global
   IPv4 address, then IPv4 is the best choice for communication. The
   destination address selection algorithm solves this with a unified
   procedure for choosing among both IPv6 and IPv4 addresses.

   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 [6].


Draves            Standards Track - Expires May 2000                 2
Default Address Selection for IPv6                       July 14, 2000


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 [7] like
   getaddrinfo() and getipnodebyname() that return a list of addresses
   to the application. This list might contain both IPv6 and IPv4
   addresses (sometimes represented as IPv4-mapped addresses). The
   application then passes a destination address to the network stack
   with connect() or sendto(). The application might use only the first
   address in the list, or it might loop over the list of addresses to
   find a working address. In any case, the network layer is never in a
   situation 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 network layer does often choose a source
   address from several alternatives.

   As a consequence, we intend that implementations of getaddrinfo()
   and getipnodebyname() will use the destination address selection
   algorithm specified here to sort the list of IPv6 and IPv4 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. Application of this
   framework to source address selection in an IPv4 network layer may
   be possible but this is not explored further here.

   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. For source address
   selection, an anonymous address [4] is preferred over its
   corresponding public address. In mobile situations [5], home
   addresses are preferred over care-of addresses.

   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 SHOULD be
   used.


Draves            Standards Track - Expires May 2000                 3
Default Address Selection for IPv6                       July 14, 2000


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.

   Use of the source address selection algorithm 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.

   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. IPv4 Addresses and IPv4-Mapped Addresses

   The destination address selection algorithm operates on both IPv6
   and IPv4 addresses. For this purpose, IPv4 addresses should be
   represented as IPv4-mapped addresses. For example, to lookup the
   precedence or other attributes of an IPv4 address in the policy
   table, lookup the corresponding IPv4-mapped IPv6 address.

2.4. Policy Table

   The policy table is a longest-matching-prefix lookup table, much
   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).


Draves            Standards Track - Expires May 2000                 4
Default Address Selection for IPv6                       July 14, 2000


   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 SHOULD operate according to the algorithms
   specified here in conjunction with the following default policy
   table:

          Prefix                 Precedence Label MatchSrcLabel
          ::1/128                       100     1             1
          fe80::/10                      90     2             2
          fec0::/10                      80     3             3
          ::/0                           70     4             4
          2002::/16                      60     5             5
          ::/96                          50     6             6
          ::ffff:169.254.0.0/112         30     7             7
          ::ffff:10.0.0.0/104            20     8             8
          ::ffff:172.16.0.0/108          20     9             9
          ::ffff:192.168.0.0/112         20    10            10
          ::ffff:0:0/96                  10    11            11

   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 IPv6
   addresses to communication using IPv4 addresses, if matching source
   addresses are available.

   Policy table entries for scoped address prefixes MAY be qualified
   with an optional scope-id. If so, a prefix table entry only matches
   against an address during a lookup if the scope-id also matches the
   address's scope-id.

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 (looking at
   the most significant, or leftmost, bits) that the two addresses have
   in common. It ranges from 0 to 128.




Draves            Standards Track - Expires May 2000                 5
Default Address Selection for IPv6                       July 14, 2000


3. Candidate Source Addresses

   The source address selection algorithm uses the concept of a
   "candidate set" of potential source addresses for a given
   destination address. We write CandidateSource(A) to denote the
   candidate set for the address A.

   It is RECOMMENDED that the candidate source addresses be the set of
   unicast addresses assigned to the interface that will be used to
   send to the destination. (The "outgoing" interface.) On routers, the
   candidate set MAY include unicast addresses assigned to any
   interface that could forward the destination address to the outgoing
   interface.

   In some cases the destination address may be qualified with a scope-
   id or other information that will constrain the candidate set.

   For multicast and link-local destination addresses, the set of
   candidate source addresses MUST only include addresses assigned to
   interfaces belonging to the same link as the outgoing interface.

   For site-local destination addresses, the set of candidate source
   addresses MUST only include addresses assigned to interfaces
   belonging to the same site as the outgoing interface.

   In any case, anycast addresses, multicast addresses, and the
   unspecified address MUST NOT be included in a candidate set.

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
   CandidateSource(D).

   The pair-wise comparison consists of eight 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 eight rules fail to choose an
   address, some unspecified tie-breaker must be used.

   Rule 1: Prefer same address.
   If SA = D, then choose SA. Similarly, if SB = D, then choose SB.

   Rule 2: Prefer matching label.
   If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D),
   then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and
   Label(SA) <> MatchSrcLabel(D), then choose SB.





Draves            Standards Track - Expires May 2000                 6
Default Address Selection for IPv6                       July 14, 2000


   Rule 3: Prefer appropriate scope.
   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.
   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: Avoid deprecated addresses.
   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: Prefer home addresses.
   If SA is a home address and SB is a care-of address, then prefer SA.
   Similarly, if SB is a home address and SA is a care-of address, then
   prefer SB.
   An implementation MAY support a per-connection configuration
   mechanism (for example, a socket option) to reverse the sense of
   this preference and prefer care-of addresses over home addresses.

   Rule 6: Prefer outgoing interface.
   If SA is assigned to the interface that will be used to send to D
   and SB is assigned to a different interface, then prefer SA.
   Similarly, if SB is assigned to the interface that will be used to
   send to D and SA is assigned to a different interface, then prefer
   SB.

   Rule 7: Prefer anonymous addresses.
   If SA is an anonymous address and SB is its corresponding public
   address, then prefer SA. Similarly, if SB is an anonymous address
   and SA is its corresponding public address, then prefer SB.
   An implementation MAY support a per-connection configuration
   mechanism (for example, a socket option) to reverse the sense of
   this preference and prefer public addresses over anonymous
   addresses.

   Rule 8: Use longest matching prefix.
   If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA.
   Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
   choose SB.

   Rule 8 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.

5. Destination Address Selection

   The destination address selection algorithm takes a list of
   destination addresses and sorts the addresses to produce a new list.

Draves            Standards Track - Expires May 2000                 7
Default Address Selection for IPv6                       July 14, 2000


   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 destination address selection algorithm uses the source address
   selection algorithm as a subroutine. We write Source(D) to indicate
   the selected source address for a destination D.

   The pair-wise comparison of destination addresses 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: Prefer destinations with a matching source.
   If Label(Source(DA)) = MatchSrcLabel(DA) and Label(Source(DB)) <>
   MatchSrcLabel(DB), then sort DA before DB. Similarly, if
   Label(Source(DB)) = MatchSrcLabel(DB) and Label(Source(DA)) <>
   MatchSrcLabel(DA), then sort DB before DA.

   Rule 2: Prefer higher precedence.
   If Precedence(DA) > Precedence(DB), then sort DA before DB.
   Similarly, if Precedence(DB) > Precedence(DA), then sort DB before
   DA.

   Rule 3: Use longest matching prefix.
   Applies only if Label(Source(DA)) = MatchSrcLabel(DA) and
   Label(Source(DB)) = MatchSrcLabel(DB).
   If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB,
   Source(DB)), then sort DA before DB. Similarly, if
   CommonPrefixLen(DB, Source(DB)) > CommonPrefixLen(DA, Source(DA)),
   then sort DB before DA.

   Rule 4: Otherwise, leave the order unchanged.
   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.

6. Interactions with Routing

   All IPv6 nodes, including both hosts and routers, SHOULD conform to
   this specification.

   This specification of source address selection assumes 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. Both of the

Draves            Standards Track - Expires May 2000                 8
Default Address Selection for IPv6                       July 14, 2000


   interfaces have preferred global addresses. 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 source
   address that shares a longer common prefix with the destination.

7. Implementation Considerations

   The destination address selection 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 and gives the best results but it
   introduces the overhead of another system call. One way to reduce
   this overhead is to cache the sorted address list in the resolver,
   so that subsequent calls for the same name do not need to resort the
   list.

   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 can be cached, amortizing the overhead of
   retrieving it across multiple calls to getipnodebyname() and
   getaddrinfo().

   In any case, if the implementation uses cached and possibly stale
   information in its implementation of destination address selection,
   or if the ordering of a cached list of destination addresses is
   possibly stale, then it MUST ensure that the destination address
   ordering returned to the application is no more than one second out
   of date. For example, an implementation might make a system call to
   check if any routing table entries or source address assignments
   that might affect these algorithms have changed.

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.


Draves            Standards Track - Expires May 2000                 9
Default Address Selection for IPv6                       July 14, 2000



   4  T. Narten, R. Draves, "Privacy Extensions for Stateless Address
      Autoconfiguration in IPv6", draft-ietf-ipngwg-addrconf-privacy-
      01.txt, July 2000.

   5  D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-
      mobileip-ipv6-12.txt, April 2000.

   6  S. Bradner, "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   7  R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket
      Interface Extensions for IPv6", RFC 2553, March 1999.

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
   Phone: 1-425-936-2268
   Email: richdr@microsoft.com

Revision History

Changes from draft-ietf-ipngwg-default-addr-select-00

   Changed the candidate set definition so that the strong host model
   is recommended but not required. Added a rule to source address
   selection to prefer addresses assigned to the outgoing interface.

   Simplified the destination address selection algorithm, by having it
   use source address selection as a subroutine.

   Added a rule to source address selection to handle anonymous/public
   addresses.

   Added a rule to source address selection to handle home/care-of
   addresses.

   Changed to allow destination address selection to sort both IPv6 and
   IPv4 addresses. Added entries in the default policy table for IPv4-
   mapped addresses.

   Changed default precedences, so v4-compatible addresses have lower
   precedence than 6to4 addresses.



Draves            Standards Track - Expires May 2000                10
Default Address Selection for IPv6                       July 14, 2000


Changes from draft-draves-ipngwg-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-ipngwg-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                11
Default Address Selection for IPv6                       July 14, 2000


   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                12


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/