doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc6724.txt b/doc/rfc/rfc6724.txt
new file mode 100644
index 0000000..4325b3d
--- /dev/null
+++ b/doc/rfc/rfc6724.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    D. Thaler, Ed.
+Request for Comments: 6724                                     Microsoft
+Obsoletes: 3484                                                R. Draves
+Category: Standards Track                             Microsoft Research
+ISSN: 2070-1721                                             A. Matsumoto
+                                                                     NTT
+                                                                T. Chown
+                                               University of Southampton
+                                                          September 2012
+
+
+    Default Address Selection for Internet Protocol Version 6 (IPv6)
+
+Abstract
+
+   This document describes two algorithms, one for source address
+   selection and one for destination address selection.  The algorithms
+   specify default behavior for all Internet Protocol version 6 (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 context, including an optional mechanism for allowing
+   administrators to provide policy that can override the default
+   behavior.  In dual-stack implementations, the destination address
+   selection algorithm can consider both IPv4 and IPv6 addresses --
+   depending on the available source addresses, the algorithm might
+   prefer IPv6 addresses over IPv4 addresses, or vice versa.
+
+   Default address selection as defined in this specification applies to
+   all IPv6 nodes, including both hosts and routers.  This document
+   obsoletes RFC 3484.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6724.
+
+
+
+
+
+
+Thaler, et al.               Standards Track                    [Page 1]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................4
+   2. Context in Which the Algorithms Operate .........................4
+      2.1. Policy Table ...............................................6
+      2.2. Common Prefix Length .......................................7
+   3. Address Properties ..............................................7
+      3.1. Scope Comparisons ..........................................8
+      3.2. IPv4 Addresses and IPv4-Mapped Addresses ...................8
+      3.3. Other IPv6 Addresses with Embedded IPv4 Addresses ..........9
+      3.4. IPv6 Loopback Address and Other Format Prefixes ............9
+      3.5. Mobility Addresses .........................................9
+   4. Candidate Source Addresses .....................................10
+   5. Source Address Selection .......................................11
+   6. Destination Address Selection ..................................14
+   7. Interactions with Routing ......................................16
+   8. Implementation Considerations ..................................16
+   9. Security Considerations ........................................17
+   10. Examples ......................................................18
+      10.1. Default Source Address Selection .........................18
+      10.2. Default Destination Address Selection ....................19
+      10.3. Configuring Preference for IPv6 or IPv4 ..................20
+           10.3.1. Handling Broken IPv6 ..............................21
+      10.4. Configuring Preference for Link-Local Addresses ..........21
+      10.5. Configuring a Multi-Homed Site ...........................22
+      10.6. Configuring ULA Preference ...............................24
+      10.7. Configuring 6to4 Preference ..............................25
+   11. References ....................................................26
+      11.1. Normative References .....................................26
+      11.2. Informative References ...................................27
+   Appendix A.  Acknowledgements .....................................29
+   Appendix B.  Changes since RFC 3484 ...............................29
+
+
+
+Thaler, et al.               Standards Track                    [Page 2]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+1.  Introduction
+
+   The IPv6 addressing architecture [RFC4291] allows multiple unicast
+   addresses to be assigned to interfaces.  These addresses might have
+   different reachability scopes (link-local, site-local, or global).
+   These addresses might also be "preferred" or "deprecated" [RFC4862].
+   Privacy considerations have introduced the concepts of "public
+   addresses" and "temporary addresses" [RFC4941].  The mobility
+   architecture introduces "home addresses" and "care-of addresses"
+   [RFC6275].  In addition, multi-homing situations will result in more
+   addresses per node.  For example, a node might have multiple
+   interfaces, some of them tunnels or virtual interfaces, or a site
+   might 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 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 auto-
+   configured IPv4 address [RFC3927], 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.
+
+   The algorithms in this document are specified as a set of rules that
+   define a partial ordering on the set of addresses that are available
+   for use.  In the case of source address selection, a node typically
+   has multiple addresses assigned to its interfaces, and the source
+   address ordering rules in Section 5 define which address is the
+   "best" one to use.  In the case of destination address selection, the
+   DNS might return a set of addresses for a given name, and an
+   application needs to decide which one to use first and in what order
+   to try others if the first one is not reachable.  The destination
+   address ordering rules in Section 6, when applied to the set of
+   addresses returned by the DNS, provide such a recommended ordering.
+
+
+
+Thaler, et al.               Standards Track                    [Page 3]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   This document specifies source address selection and destination
+   address selection separately but uses a common context 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" in the
+   RFC 4862 sense).  Furthermore, this document suggests a preferred
+   method, longest matching prefix, for choosing among otherwise
+   equivalent addresses in the absence of better information.
+
+   This document also specifies 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 selection rules specified in this document MUST NOT be construed
+   to override an application or upper layer's explicit choice of a
+   legal 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 BCP 14, RFC 2119
+   [RFC2119].
+
+2.  Context in Which the Algorithms Operate
+
+   Our context for address selection derives from the most common
+   implementation architecture, which separates the choice of
+   destination address from the choice of source address.  Consequently,
+   we have 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 such as
+   getaddrinfo() [RFC3493] 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 would then typically try the first
+   address in the list, looping over the list of addresses until it
+   finds 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
+
+
+
+
+Thaler, et al.               Standards Track                    [Page 4]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   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 APIs such as
+   getaddrinfo() 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 specification to
+   source address selection in an IPv4 network layer might be possible,
+   but this is not explored further here.
+
+   Well-behaved applications SHOULD NOT simply use the first address
+   returned from an API such as getaddrinfo() and then give up if it
+   fails.  For many applications, it is appropriate to iterate through
+   the list of addresses returned from getaddrinfo() until a working
+   address is found.  For other applications, it might be appropriate to
+   try multiple addresses in parallel (e.g., with some small delay in
+   between) and use the first one to succeed.
+
+   Although source and destination address selection is most typically
+   done when initiating communication, a responder also must deal with
+   address selection.  In many cases, this is trivially dealt with by an
+   application using the source address of a received packet as the
+   response destination and the destination address of the received
+   packet as the response source.  Other cases, however, are handled
+   like an initiator, such as when the request is multicast and hence
+   source address selection must still occur when generating a response
+   or when the request includes a list of the initiator's addresses from
+   which to choose a destination.  Finally, a third application scenario
+   is that of a listening application choosing on what local addresses
+   to listen.  This third scenario is out of the scope of this document.
+
+   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, 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, temporary addresses [RFC4941] are preferred over
+   public addresses.  In mobile situations [RFC6275], home addresses are
+   preferred over care-of addresses.  If an address is simultaneously a
+   home address and a care-of address (indicating the mobile node is "at
+   home" for that address), then the home/care-of address is preferred
+   over addresses that are solely a home address or solely a care-of
+   address.
+
+
+
+Thaler, et al.               Standards Track                    [Page 5]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   This specification optionally allows for the possibility of
+   administrative configuration of policy (e.g., via manual
+   configuration or a DHCP option such as that proposed in
+   [ADDR-SEL-OPT]) that can override the default behavior of the
+   algorithms.  The policy override consists of the following set of
+   state, which SHOULD be configurable:
+
+   o  Policy Table (Section 2.1): a table that specifies precedence
+      values and preferred source prefixes for destination prefixes.
+
+   o  Automatic Row Additions flag (Section 2.1): a flag that specifies
+      whether the implementation is permitted to automatically add site-
+      specific rows for certain types of addresses.
+
+   o  Privacy Preference flag (Section 5): a flag that specifies whether
+      temporary source addresses or stable source addresses are
+      preferred by default when both types exist.
+
+2.1.  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 two values: a precedence value denoted Precedence(A) and a
+   classification or label denoted Label(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 label value Label(A) allows 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) = Label(D).
+
+   IPv6 implementations SHOULD support configurable address selection
+   via a mechanism at least as powerful as the policy tables defined
+   here.  It is important that implementations provide a way to change
+   the default policies as more experience is gained.  Sections 10.3
+   through 10.7 provide examples of the kind of changes that might be
+   needed.
+
+   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:
+
+
+
+
+
+
+Thaler, et al.               Standards Track                    [Page 6]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+      Prefix        Precedence Label
+      ::1/128               50     0
+      ::/0                  40     1
+      ::ffff:0:0/96         35     4
+      2002::/16             30     2
+      2001::/32              5     5
+      fc00::/7               3    13
+      ::/96                  1     3
+      fec0::/10              1    11
+      3ffe::/16              1    12
+
+   An implementation MAY automatically add additional site-specific rows
+   to the default table based on its configured addresses, such as for
+   Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
+   for instance (see Sections 10.6 and 10.7 for examples).  Any such
+   rows automatically added by the implementation as a result of address
+   acquisition MUST NOT override a row for the same prefix configured
+   via other means.  That is, rows can be added but never updated
+   automatically.  An implementation SHOULD provide a means (the
+   Automatic Row Additions flag) for an administrator to disable
+   automatic row additions.
+
+   As will become apparent later, 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,
+   etc.  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 address prefixes that are not of global
+   scope MAY be qualified with an optional zone index.  If so, a prefix
+   table entry only matches against an address during a lookup if the
+   zone index also matches the address's zone index.
+
+2.2.  Common Prefix Length
+
+   We define the common prefix length CommonPrefixLen(S, D) of a source
+   address S and a destination address D as the length of the longest
+   prefix (looking at the most significant, or leftmost, bits) that the
+   two addresses have in common, up to the length of S's prefix (i.e.,
+   the portion of the address not including the interface ID).  For
+   example, CommonPrefixLen(fe80::1, fe80::2) is 64.
+
+3.  Address Properties
+
+   In the rules given in later sections, addresses of different types
+   (e.g., IPv4, IPv6, multicast, and unicast) are compared against each
+   other.  Some of these address types have properties that aren't
+
+
+
+Thaler, et al.               Standards Track                    [Page 7]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   directly comparable to each other.  For example, IPv6 unicast
+   addresses can be "preferred" or "deprecated" [RFC4862], while IPv4
+   addresses have no such notion.  To compare such addresses using the
+   ordering rules (e.g., to use "preferred" addresses in preference to
+   "deprecated" addresses), the following mappings are defined.
+
+3.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 interface-
+   local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5),
+   organization-local (0x8), and global (0xE) scopes (Section 2.7 of
+   [RFC4291]).
+
+   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.  (Note that IPv6
+   site-local unicast addresses are deprecated [RFC4291].  However, some
+   existing implementations and deployments may still use these
+   addresses; they are therefore included in the procedures in this
+   specification.  Also, note that ULAs are considered as global, not
+   site-local, scope but are handled via the prefix policy table as
+   discussed in Section 10.6.)
+
+   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 [RFC4007].
+
+3.2.  IPv4 Addresses and IPv4-Mapped Addresses
+
+   The destination address selection algorithm operates on both IPv6 and
+   IPv4 addresses.  For this purpose, IPv4 addresses MUST be represented
+   as IPv4-mapped addresses [RFC4291].  For example, to look up the
+   precedence or other attributes of an IPv4 address in the policy
+   table, look up the corresponding IPv4-mapped IPv6 address.
+
+   IPv4 addresses are assigned scopes as follows.  IPv4 auto-
+   configuration addresses [RFC3927], which have the prefix 169.254/16,
+   are assigned link-local scope.  IPv4 loopback addresses (Section
+
+
+
+Thaler, et al.               Standards Track                    [Page 8]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   4.2.2.11 of [RFC1812]), which have the prefix 127/8, are assigned
+   link-local scope (analogously to the treatment of the IPv6 loopback
+   address (Section 4 of [RFC4007])).  Other IPv4 addresses (including
+   IPv4 private addresses [RFC1918] and Shared Address Space addresses
+   [RFC6598]) are assigned global scope.
+
+   IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862
+   sense) configuration status.
+
+3.3.  Other IPv6 Addresses with Embedded IPv4 Addresses
+
+   IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4-
+   converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses
+   [RFC3056] contain an embedded IPv4 address.  For the purposes of this
+   document, these addresses MUST be treated as having global scope.
+
+   IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be
+   treated as having "preferred" (in the RFC 4862 sense) configuration
+   status.
+
+3.4.  IPv6 Loopback Address and Other Format Prefixes
+
+   The loopback address MUST be treated as having link-local scope
+   (Section 4 of [RFC4007]) and "preferred" (in the RFC 4862 sense)
+   configuration status.
+
+   NSAP addresses and other addresses with as-yet-undefined format
+   prefixes MUST be treated as having global scope and "preferred" (in
+   the RFC 4862) configuration status.  Later standards might supersede
+   this treatment.
+
+3.5.  Mobility Addresses
+
+   Some nodes might support mobility using the concepts of home address
+   and care-of address (for example, see [RFC6275]).  Conceptually, a
+   home address is an IP address assigned to a mobile node and used as
+   the permanent address of the mobile node.  A care-of address is an IP
+   address associated with a mobile node while visiting a foreign link.
+   When a mobile node is on its home link, it might have an address that
+   is simultaneously a home address and a care-of address.
+
+   For the purposes of this document, it is sufficient to know whether
+   one's own addresses are designated as home addresses or care-of
+   addresses.  Whether an address ought to be designated a home address
+   or care-of address is outside the scope of this document.
+
+
+
+
+
+
+Thaler, et al.               Standards Track                    [Page 9]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+4.  Candidate Source Addresses
+
+   The source address selection algorithm uses the concept of a
+   "candidate set" of potential source addresses for a given destination
+   address.  The candidate set is the set of all addresses that could be
+   used as a source address; the source address selection algorithm will
+   pick an address out of that set.  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 forwards packets, subject to the restrictions described below.
+   Implementations that wish to support the use of global source
+   addresses assigned to a loopback interface MUST behave as if the
+   loopback interface originates and forwards the packet.
+
+      Discussion: The Neighbor Discovery Redirect mechanism [RFC4861]
+      requires that routers verify that the source address of a packet
+      identifies a neighbor before generating a Redirect, so it is
+      advantageous for hosts to choose source addresses assigned to the
+      outgoing interface.
+
+   In some cases, the destination address might be qualified with a zone
+   index or other information that will constrain the candidate set.
+
+   For all 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.
+
+      Discussion: The restriction for multicast destination addresses is
+      necessary because currently deployed multicast forwarding
+      algorithms use Reverse Path Forwarding (RPF) checks.
+
+   For site-local unicast 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, multicast addresses and the unspecified address MUST NOT
+   be included in a candidate set.
+
+   On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT)
+   [RFC6145], if the destination address is an IPv4-converted address,
+   then the candidate set MUST contain only IPv4-translatable addresses.
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 10]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   If an application or upper layer specifies a source address, it may
+   affect the choice of outgoing interface.  Regardless, if the
+   application or upper layer specifies a source address that is not in
+   the candidate set for the destination, then the network layer MUST
+   treat this as an error.  If the application or upper layer specifies
+   a source address that is in the candidate set for the destination,
+   then the network layer MUST respect that choice.  If the application
+   or upper layer does not specify a source address, then the network
+   layer uses the source address selection algorithm specified in the
+   next section.
+
+5.  Source Address Selection
+
+   The source address selection algorithm produces as output a single
+   source address for use with a given destination address.  This
+   algorithm only applies to IPv6 destination addresses, not IPv4
+   addresses.
+
+   The algorithm is specified here in terms of a list of pair-wise
+   comparison rules that (for a given destination address D) imposes a
+   "greater than" ordering on the addresses in the candidate set
+   CandidateSource(D).  The address at the front of the list after the
+   algorithm completes is the one the algorithm selects.
+
+   Note that conceptually, a sort of the candidate set is being
+   performed, where a set of rules define the ordering among addresses.
+   But because the output of the algorithm is a single source address,
+   an implementation need not actually sort the set; it need only
+   identify the "maximum" value that ends up at the front of the sorted
+   list.
+
+   The ordering of the addresses in the candidate set is defined by a
+   list of eight pair-wise comparison rules, with each rule placing a
+   "greater than", "less than", or "equal to" ordering on two source
+   addresses with respect to each other (and that rule).  In the case
+   that a given rule produces a tie, i.e., provides an "equal to" result
+   for the two addresses, the remaining rules MUST be applied (in order)
+   to just those addresses that are tied to break the tie.  Note that if
+   a rule produces a single clear "winner" (or set of "winners" in the
+   case of ties), those addresses not in the winning set can be
+   discarded from further consideration, with subsequent rules applied
+   only to the remaining addresses.  If the eight rules fail to choose a
+   single address, the tiebreaker is implementation-specific.
+
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 11]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   When comparing two addresses SA and SB from the candidate set, we say
+   "prefer SA" to mean that SA is "greater than" SB, and similarly, we
+   say "prefer SB" to mean that SA is "less than" SB.  If neither is
+   stated to be preferred, this means that SA is "equal to" SB, and the
+   remaining rules apply as noted above.
+
+   Rule 1: Prefer same address.
+   If SA = D, then prefer SA.  Similarly, if SB = D, then prefer SB.
+
+   Rule 2: Prefer appropriate scope.
+   If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
+   otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
+   Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
+
+      Discussion: This rule must be given high priority because it can
+      affect interoperability.
+
+   Rule 3: Avoid deprecated addresses.
+   If one of the two source addresses is "preferred" and one of them is
+   "deprecated" (in the RFC 4862 sense), then prefer the one that is
+   "preferred".
+
+   Rule 4: Prefer home addresses.
+   If SA is simultaneously a home address and care-of address and SB is
+   not, then prefer SA.  Similarly, if SB is simultaneously a home
+   address and care-of address and SA is not, then prefer SB.  If SA is
+   just a home address and SB is just a care-of address, then prefer SA.
+   Similarly, if SB is just a home address and SA is just a care-of
+   address, then prefer SB.
+
+   Implementations supporting home addresses MUST provide a mechanism
+   allowing an application to reverse the sense of this preference and
+   prefer care-of addresses over home addresses (e.g., via appropriate
+   API extensions such as [RFC5014]).  Use of the mechanism MUST only
+   affect the selection rules for the invoking application.
+
+   Rule 5: 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 5.5: Prefer addresses in a prefix advertised by the next-hop.
+   If SA or SA's prefix is assigned by the selected next-hop that will
+   be used to send to D and SB or SB's prefix is assigned by a different
+   next-hop, then prefer SA.  Similarly, if SB or SB's prefix is
+   assigned by the next-hop that will be used to send to D and SA or
+   SA's prefix is assigned by a different next-hop, then prefer SB.
+
+
+
+Thaler, et al.               Standards Track                   [Page 12]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+      Discussion: An IPv6 implementation is not required to remember
+      which next-hops advertised which prefixes.  The conceptual models
+      of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
+      have no such requirement.  Hence, Rule 5.5 is only applicable to
+      implementations that track this information.
+
+   Rule 6: Prefer matching label.
+   If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA.
+   Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then
+   prefer SB.
+
+   Rule 7: Prefer temporary addresses.
+   If SA is a temporary address and SB is a public address, then prefer
+   SA.  Similarly, if SB is a temporary address and SA is a public
+   address, then prefer SB.
+
+   Implementations MUST provide a mechanism allowing an application to
+   reverse the sense of this preference and prefer public addresses over
+   temporary addresses (e.g., via appropriate API extensions such as
+   [RFC5014]).  Use of the mechanism MUST only affect the selection
+   rules for the invoking application.  This default is intended to
+   address privacy concerns as discussed in [RFC4941] but introduces a
+   risk of applications potentially failing due to the relatively short
+   lifetime of temporary addresses or due to the possibility of the
+   reverse lookup of a temporary address either failing or returning a
+   randomized name.  Implementations for which application compatibility
+   considerations outweigh these privacy concerns MAY reverse the sense
+   of this rule and by default prefer public addresses over temporary
+   addresses.  There SHOULD be an administrative option (the Privacy
+   Preference flag) to change this preference, if the implementation
+   supports temporary addresses.  If there is no such option, there MUST
+   be an administrative option to disable temporary addresses.
+
+   Rule 8: Use longest matching prefix.
+   If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.
+   Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
+   prefer SB.
+
+   Rule 8 MAY be superseded 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.
+
+
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 13]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+6.  Destination Address Selection
+
+   The destination address selection 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 algorithm sorts together both IPv6 and IPv4 addresses.  To find
+   the attributes of an IPv4 address in the policy table, the IPv4
+   address MUST be represented as an IPv4-mapped address.
+
+   We write Source(D) to indicate the selected source address for a
+   destination D.  For IPv6 addresses, the previous section specifies
+   the source address selection algorithm.  Source address selection for
+   IPv4 addresses is not specified in this document.
+
+   We say that Source(D) is undefined if there is no source address
+   available for destination D.  For IPv6 addresses, this is only the
+   case if CandidateSource(D) is the empty set.
+
+   The pair-wise comparison of destination addresses consists of ten
+   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 tiebreakers for earlier rules.  See
+   the previous section for a lengthier description of how pair-wise
+   comparison tiebreaker rules can be used to sort a list.
+
+   Rule 1: Avoid unusable destinations.
+   If DB is known to be unreachable or if Source(DB) is undefined, then
+   prefer DA.  Similarly, if DA is known to be unreachable or if
+   Source(DA) is undefined, then prefer DB.
+
+      Discussion: An implementation might know that a particular
+      destination is unreachable in several ways.  For example, the
+      destination might be reached through a network interface that is
+      currently unplugged.  For example, the implementation might retain
+      information from Neighbor Unreachability Detection [RFC4861] for
+      some period of time.  In any case, the determination of
+      unreachability for the purposes of this rule is implementation-
+      dependent.
+
+   Rule 2: Prefer matching scope.
+   If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)),
+   then prefer DA.  Similarly, if Scope(DA) <> Scope(Source(DA)) and
+   Scope(DB) = Scope(Source(DB)), then prefer DB.
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 14]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Rule 3: Avoid deprecated addresses.
+   If Source(DA) is deprecated and Source(DB) is not, then prefer DB.
+   Similarly, if Source(DA) is not deprecated and Source(DB) is
+   deprecated, then prefer DA.
+
+   Rule 4: Prefer home addresses.
+   If Source(DA) is simultaneously a home address and care-of address
+   and Source(DB) is not, then prefer DA.  Similarly, if Source(DB) is
+   simultaneously a home address and care-of address and Source(DA) is
+   not, then prefer DB.
+
+   If Source(DA) is just a home address and Source(DB) is just a care-of
+   address, then prefer DA.  Similarly, if Source(DA) is just a care-of
+   address and Source(DB) is just a home address, then prefer DB.
+
+   Rule 5: Prefer matching label.
+   If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB),
+   then prefer DA.  Similarly, if Label(Source(DA)) <> Label(DA) and
+   Label(Source(DB)) = Label(DB), then prefer DB.
+
+   Rule 6: Prefer higher precedence.
+   If Precedence(DA) > Precedence(DB), then prefer DA.  Similarly, if
+   Precedence(DA) < Precedence(DB), then prefer DB.
+
+   Rule 7: Prefer native transport.
+   If DA is reached via an encapsulating transition mechanism (e.g.,
+   IPv6 in IPv4) and DB is not, then prefer DB.  Similarly, if DB is
+   reached via encapsulation and DA is not, then prefer DA.
+
+      Discussion: The IPv6 Rapid Deployment on IPv4 Infrastructures
+      (6rd) Protocol [RFC5969], the Intra-Site Automatic Tunnel
+      Addressing Protocol (ISATAP) [RFC5214], and configured tunnels
+      [RFC4213] are examples of encapsulating transition mechanisms for
+      which the destination address does not have a specific prefix and
+      hence can not be assigned a lower precedence in the policy table.
+      An implementation MAY generalize this rule by using a concept of
+      interface preference and giving virtual interfaces (like the IPv6-
+      in-IPv4 encapsulating interfaces) a lower preference than native
+      interfaces (like ethernet interfaces).
+
+   Rule 8: Prefer smaller scope.
+   If Scope(DA) < Scope(DB), then prefer DA.  Similarly, if Scope(DA) >
+   Scope(DB), then prefer DB.
+
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 15]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Rule 9: Use longest matching prefix.
+   When DA and DB belong to the same address family (both are IPv6 or
+   both are IPv4): If CommonPrefixLen(Source(DA), DA) >
+   CommonPrefixLen(Source(DB), DB), then prefer DA.  Similarly, if
+   CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB),
+   then prefer DB.
+
+   Rule 10: Otherwise, leave the order unchanged.
+   If DA preceded DB in the original list, prefer DA.  Otherwise, prefer
+   DB.
+
+   Rules 9 and 10 MAY be superseded 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.
+
+7.  Interactions with Routing
+
+   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
+   interfaces have preferred (in the RFC 4862 sense) 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.
+
+   Implementations that support Rule 5.5 of source address selection
+   (Section 5) also use the choice of router to influence the choice of
+   source address.  For example, suppose a host is on a link with two
+   routers.  One router is advertising a global prefix A and the other
+   router is advertising global prefix B.  Then, when sending via the
+   first router, the host might prefer source addresses with prefix A
+   and when sending via the second router, prefer source addresses with
+   prefix B.
+
+8.  Implementation Considerations
+
+   The destination address selection algorithm needs information about
+   potential source addresses.  One possible implementation strategy is
+   for getaddrinfo() to call down to the network layer with a list of
+   destination addresses, sort the list in the network layer with full
+
+
+
+Thaler, et al.               Standards Track                   [Page 16]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   current knowledge of available source addresses, and return the
+   sorted list to 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 re-sort 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 getaddrinfo().  To reduce
+   overhead in this approach, the source address information can be
+   cached, amortizing the overhead of retrieving it across multiple
+   calls to getaddrinfo().  In this approach, the implementation might
+   not have knowledge of the outgoing interface for each destination, so
+   it MAY use a looser definition of the candidate set during
+   destination address ordering.
+
+   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, source address assignments, or prefix
+   policy table entries that might affect these algorithms have changed.
+   Another strategy is to use an invalidation counter that is
+   incremented whenever any underlying state is changed.  By caching the
+   current invalidation counter value with derived state and then later
+   comparing against the current value, the implementation could detect
+   if the derived state is potentially stale.
+
+9.  Security Considerations
+
+   This document has no direct impact on Internet infrastructure
+   security.
+
+   Note that most source address selection algorithms, including the one
+   specified in this document, expose a potential privacy concern.  An
+   unfriendly node can infer correlations among a target node's
+   addresses by probing the target node with request packets that force
+   the target host to choose its source address for the reply packets
+   (perhaps because the request packets are sent to an anycast or
+   multicast address or perhaps because the upper-layer protocol chosen
+   for the attack does not specify a particular source address for its
+   reply packets).  By using different addresses for itself, the
+   unfriendly node can cause the target node to expose the target's own
+   addresses.  The source address selection default preference for
+   temporary addresses helps mitigate this concern.
+
+
+
+Thaler, et al.               Standards Track                   [Page 17]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Similarly, most source and destination address selection algorithms,
+   including the one specified in this document, influence the choice of
+   network path taken (as do routing algorithms that are orthogonal to,
+   but used together with, such algorithms) and hence whether data might
+   be sent over a path or network that might be more or less trusted
+   than other paths or networks.  Administrators should consider the
+   security impact of the rows they configure in the prefix policy
+   table, just as they should consider the security impact of the
+   interface metrics used in the routing algorithms.
+
+   In addition, some address selection rules might be administratively
+   configurable.  Care must be taken to make sure that all
+   administrative options are secured against illicit modification, or
+   else an attacker could redirect and/or block traffic.
+
+10.  Examples
+
+   This section contains a number of examples, first showing default
+   behavior and then demonstrating the utility of policy table
+   configuration.  These examples are provided for illustrative
+   purposes; they are not to be construed as normative.
+
+10.1.  Default Source Address Selection
+
+   The source address selection rules, in conjunction with the default
+   policy table, produce the following behavior:
+
+   Destination: 2001:db8:1::1
+   Candidate Source Addresses: 2001:db8:3::1 or fe80::1
+   Result: 2001:db8::1 (prefer appropriate scope)
+
+   Destination: ff05::1
+   Candidate Source Addresses: 2001:db8:3::1 or fe80::1
+   Result: 2001:db8:3::1 (prefer appropriate scope)
+
+   Destination: 2001:db8:1::1
+   Candidate Source Addresses: 2001:db8:1::1 (deprecated) or
+   2001:db8:2::1
+   Result: 2001:db8:1::1 (prefer same address)
+
+   Destination: fe80::1
+   Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1
+   Result: fe80::2 (prefer appropriate scope)
+
+   Destination: 2001:db8:1::1
+   Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2
+   Result: 2001:db8:1:::2 (longest matching prefix)
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 18]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Destination: 2001:db8:1::1
+   Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001:
+   db8:3::2 (home address)
+   Result: 2001:db8:3::2 (prefer home address)
+
+   Destination: 2002:c633:6401::1
+   Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8
+   (temporary) or 2001:db8:1::2
+   Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label)
+
+   Destination: 2001:db8:1::d5e3:0:0:1
+   Candidate Source Addresses: 2001:db8:1::2 (public) or
+   2001:db8:1::d5e3:7953:13eb:22e8 (temporary)
+   Result: 2001:db8:1::d5e3:7953:13eb:22e8 (prefer temporary address)
+
+10.2.  Default Destination Address Selection
+
+   The destination address selection rules, in conjunction with the
+   default policy table and the source address selection rules, produce
+   the following behavior:
+
+   Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78
+   Destination Address List: 2001:db8:1::1 or 198.51.100.121
+   Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src
+   169.254.13.78) (prefer matching scope)
+
+   Candidate Source Addresses: fe80::1 or 198.51.100.117
+   Destination Address List: 2001:db8:1::1 or 198.51.100.121
+   Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src
+   fe80::1) (prefer matching scope)
+
+   Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4
+   Destination Address List: 2001:db8:1::1 or 10.1.2.3
+   Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src
+   10.1.2.4) (prefer higher precedence)
+
+   Candidate Source Addresses: 2001:db8:1::2 or fe80::2
+   Destination Address List: 2001:db8:1::1 or fe80::1
+   Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2)
+   (prefer smaller scope)
+
+   Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001:
+   db8:3::1 (home address) or fe80::2 (care-of address)
+   Destination Address List: 2001:db8:1::1 or fe80::1
+   Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2)
+   (prefer home address)
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 19]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated)
+   Destination Address List: 2001:db8:1::1 or fe80::1
+   Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2)
+   (avoid deprecated addresses)
+
+   Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or
+   fe80::2
+   Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1
+   Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src
+   2001:db8:3f44::2) (longest matching prefix)
+
+   Candidate Source Addresses: 2002:c633:6401::2 or fe80::2
+   Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1
+   Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1
+   (src 2002:c633:6401::2) (prefer matching label)
+
+   Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or
+   fe80::2
+   Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1
+   Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src
+   2002:c633:6401::2) (prefer higher precedence)
+
+10.3.  Configuring Preference for IPv6 or IPv4
+
+   The default policy table gives IPv6 addresses higher precedence than
+   IPv4 addresses.  This means that applications will use IPv6 in
+   preference to IPv4 when the two are equally suitable.  An
+   administrator can change the policy table to prefer IPv4 addresses by
+   giving the ::ffff:0.0.0.0/96 prefix a higher precedence:
+
+      Prefix        Precedence Label
+      ::1/128               50     0
+      ::/0                  40     1
+      ::ffff:0:0/96        100     4
+      2002::/16             30     2
+      2001::/32              5     5
+      fc00::/7               3    13
+      ::/96                  1     3
+      fec0::/10              1    11
+      3ffe::/16              1    12
+
+   This change to the default policy table produces the following
+   behavior:
+
+   Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78
+   Destination Address List: 2001:db8::1 or 198.51.100.121
+   Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121
+   (src 169.254.13.78) (prefer matching scope)
+
+
+
+Thaler, et al.               Standards Track                   [Page 20]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Candidate Source Addresses: fe80::1 or 198.51.100.117
+   Destination Address List: 2001:db8::1 or 198.51.100.121
+   Unchanged Result: 198.51.100.121 (src 198.51.100.117) then
+   2001:db8::1 (src fe80::1) (prefer matching scope)
+
+   Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4
+   Destination Address List: 2001:db8::1 or 10.1.2.3
+   New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src
+   2001:db8::2) (prefer higher precedence)
+
+10.3.1.  Handling Broken IPv6
+
+   One problem in practice that has been recently observed occurs when a
+   host has IPv4 connectivity to the Internet but has "broken" IPv6
+   connectivity to the Internet in that it has a global IPv6 address but
+   is disconnected from the IPv6 Internet.  Since the default policy
+   table prefers IPv6, this can result in unwanted timeouts.
+
+   This can be solved by configuring the table to prefer IPv4 as shown
+   above.  An implementation that has some means to detect that it is
+   not connected to the IPv6 Internet MAY do this automatically.  An
+   implementation could instead treat it as part of its implementation
+   of Rule 1 (avoid unusable destinations).
+
+10.4.  Configuring Preference for Link-Local Addresses
+
+   The destination address selection rules give preference to
+   destinations of smaller scope.  For example, a link-local destination
+   will be sorted before a global scope destination when the two are
+   otherwise equally suitable.  An administrator can change the policy
+   table to reverse this preference and sort global destinations before
+   link-local destinations:
+
+      Prefix        Precedence Label
+      ::1/128               50     0
+      ::/0                  40     1
+      ::ffff:0:0/96         35     4
+      fe80::/10             33     1
+      2002::/16             30     2
+      2001::/32              5     5
+      fc00::/7               3    13
+      ::/96                  1     3
+      fec0::/10              1    11
+      3ffe::/16              1    12
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 21]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   This change to the default policy table produces the following
+   behavior:
+
+   Candidate Source Addresses: 2001:db8::2 or fe80::2
+   Destination Address List: 2001:db8::1 or fe80::1
+   New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2)
+   (prefer higher precedence)
+
+   Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2
+   Destination Address List: 2001:db8::1 or fe80::1
+   Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001:
+   db8::2) (avoid deprecated addresses)
+
+10.5.  Configuring a Multi-Homed Site
+
+   Consider a site A that has a business-critical relationship with
+   another site B.  To support their business needs, the two sites have
+   contracted for service with a special high-performance ISP.  This is
+   in addition to the normal Internet connection that both sites have
+   with different ISPs.  The high-performance ISP is expensive, and the
+   two sites wish to use it only for their business-critical traffic
+   with each other.
+
+   Each site has two global prefixes, one from the high-performance ISP
+   and one from their normal ISP.  Site A has prefix 2001:db8:1aaa::/48
+   from the high-performance ISP and prefix 2001:db8:70aa::/48 from its
+   normal ISP.  Site B has prefix 2001:db8:1bbb::/48 from the high-
+   performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP.
+   All hosts in both sites register two addresses in the DNS.
+
+   The routing within both sites directs most traffic to the egress to
+   the normal ISP, but the routing directs traffic sent to the other
+   site's 2001 prefix to the egress to the high-performance ISP.  To
+   prevent unintended use of their high-performance ISP connection, the
+   two sites implement ingress filtering to discard traffic entering
+   from the high-performance ISP that is not from the other site.
+
+   The default policy table and address selection rules produce the
+   following behavior:
+
+   Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
+   fe80::a
+   Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
+   Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b
+   (src 2001:db8:1aaa::a) (longest matching prefix)
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 22]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   In other words, when a host in site A initiates a connection to a
+   host in site B, the traffic does not take advantage of their
+   connections to the high-performance ISP.  This is not their desired
+   behavior.
+
+   Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
+   fe80::a
+   Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
+   Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c
+   (src 2001:db8:70aa::a) (longest matching prefix)
+
+   In other words, when a host in site A initiates a connection to a
+   host in some other site C, the reverse traffic might come back
+   through the high-performance ISP.  Again, this is not their desired
+   behavior.
+
+   This predicament demonstrates the limitations of the longest-
+   matching-prefix heuristic in multi-homed situations.
+
+   However, the administrators of sites A and B can achieve their
+   desired behavior via policy table configuration.  For example, they
+   can use the following policy table:
+
+      Prefix        Precedence Label
+      ::1/128               50     0
+      2001:db8:1aaa::/48    43     6
+      2001:db8:1bbb::/48    43     6
+      ::/0                  40     1
+      ::ffff:0:0/96         35     4
+      2002::/16             30     2
+      2001::/32              5     5
+      fc00::/7               3    13
+      ::/96                  1     3
+      fec0::/10              1    11
+      3ffe::/16              1    12
+
+   This policy table produces the following behavior:
+
+   Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
+   fe80::a
+   Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b
+   New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8:
+   70bb::b (src 2001:db8:70aa::a) (prefer higher precedence)
+
+   In other words, when a host in site A initiates a connection to a
+   host in site B, the traffic uses the high-performance ISP as desired.
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 23]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or
+   fe80::a
+   Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c
+   New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8:
+   1ccc::c (src 2001:db8:70aa::a) (longest matching prefix)
+
+   In other words, when a host in site A initiates a connection to a
+   host in some other site C, the traffic uses the normal ISP as
+   desired.
+
+10.6.  Configuring ULA Preference
+
+   Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe
+   address selection problems related to Unique Local Addresses (ULAs)
+   [RFC4193].  By default, global IPv6 destinations are preferred over
+   ULA destinations, since an arbitrary ULA is not necessarily
+   reachable:
+
+   Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
+   Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
+   Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2
+   (src fd11:1111:1111:1::1) (prefer higher precedence)
+
+   However, a site-specific policy entry can be used to cause ULAs
+   within a site to be preferred over global addresses as follows.
+
+      Prefix        Precedence Label
+      ::1/128               50     0
+      fd11:1111:1111::/48   45    14
+      ::/0                  40     1
+      ::ffff:0:0/96         35     4
+      2002::/16             30     2
+      2001::/32              5     5
+      fc00::/7               3    13
+      ::/96                  1     3
+      fec0::/10              1    11
+      3ffe::/16              1    12
+
+   Such a configuration would have the following effect:
+
+   Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
+   Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2
+   Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:
+   2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence)
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 24]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
+   Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2
+   New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001:
+   db8:2::2 (src 2001:db8:1::1) (prefer higher precedence)
+
+   Since ULAs are defined to have a /48 site prefix, an implementation
+   might choose to add such a row automatically on a machine with a ULA.
+
+   It is also worth noting that ULAs are assigned global scope.  As
+   such, the existence of one or more rows in the prefix policy table is
+   important so that source address selection does not choose a ULA
+   purely based on longest match:
+
+   Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
+   Destination Address List: ff00:1
+   Result: 2001:db8:1::1 (prefer matching label)
+
+10.7.  Configuring 6to4 Preference
+
+   By default, NATed IPv4 is preferred over 6to4-relayed connectivity:
+
+   Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3
+   Destination Address List: 2001:db8:1::1 or 203.0.113.1
+   Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633:
+   6401::2) (prefer matching label)
+
+   However, NATed IPv4 is now also preferred over 6to4-to-6to4
+   connectivity by default.  Since a 6to4 prefix might be used natively
+   within an organization, a site-specific policy entry can be used to
+   cause native IPv6 communication (using a 6to4 prefix) to be preferred
+   over NATed IPv4 as follows.
+
+      Prefix        Precedence Label
+      ::1/128               50     0
+      2002:c633:6401::/48   45    14
+      ::/0                  40     1
+      ::ffff:0:0/96         35     4
+      2002::/16             30     2
+      2001::/32              5     5
+      fc00::/7               3    13
+      ::/96                  1     3
+      fec0::/10              1    11
+      3ffe::/16              1    12
+
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 25]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Such a configuration would have the following effect:
+
+   Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3
+   Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1
+   New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then
+   203.0.113.1 (sec 10.1.2.3) (prefer higher precedence)
+
+   Since 6to4 addresses are defined to have a /48 site prefix, an
+   implementation might choose to add such a row automatically on a
+   machine with a native IPv6 address with a 6to4 prefix.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3056]       Carpenter, B. and K. Moore, "Connection of IPv6
+                   Domains via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3879]       Huitema, C. and B. Carpenter, "Deprecating Site Local
+                   Addresses", RFC 3879, September 2004.
+
+   [RFC4193]       Hinden, R. and B. Haberman, "Unique Local IPv6
+                   Unicast Addresses", RFC 4193, October 2005.
+
+   [RFC4291]       Hinden, R. and S. Deering, "IP Version 6 Addressing
+                   Architecture", RFC 4291, February 2006.
+
+   [RFC4380]       Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+                   Network Address Translations (NATs)", RFC 4380,
+                   February 2006.
+
+   [RFC4862]       Thomson, S., Narten, T., and T. Jinmei, "IPv6
+                   Stateless Address Autoconfiguration", RFC 4862,
+                   September 2007.
+
+   [RFC4941]       Narten, T., Draves, R., and S. Krishnan, "Privacy
+                   Extensions for Stateless Address Autoconfiguration in
+                   IPv6", RFC 4941, September 2007.
+
+   [RFC6145]       Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+                   Algorithm", RFC 6145, April 2011.
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 26]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+11.2.  Informative References
+
+   [ADDR-SEL-OPT]  Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
+                   "Distributing Address Selection Policy using DHCPv6",
+                   Work in Progress, August 2012.
+
+   [RFC1794]       Brisco, T., "DNS Support for Load Balancing",
+                   RFC 1794, April 1995.
+
+   [RFC1812]       Baker, F., "Requirements for IP Version 4 Routers",
+                   RFC 1812, June 1995.
+
+   [RFC1918]       Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
+                   G., and E. Lear, "Address Allocation for Private
+                   Internets", BCP 5, RFC 1918, February 1996.
+
+   [RFC2827]       Ferguson, P. and D. Senie, "Network Ingress
+                   Filtering: Defeating Denial of Service Attacks which
+                   employ IP Source Address Spoofing", BCP 38, RFC 2827,
+                   May 2000.
+
+   [RFC3484]       Draves, R., "Default Address Selection for Internet
+                   Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC3493]       Gilligan, R., Thomson, S., Bound, J., McCann, J., and
+                   W. Stevens, "Basic Socket Interface Extensions for
+                   IPv6", RFC 3493, February 2003.
+
+   [RFC3701]       Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
+                   Allocation) Phaseout", RFC 3701, March 2004.
+
+   [RFC3927]       Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+                   Configuration of IPv4 Link-Local Addresses",
+                   RFC 3927, May 2005.
+
+   [RFC4007]       Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
+                   and B. Zill, "IPv6 Scoped Address Architecture",
+                   RFC 4007, March 2005.
+
+   [RFC4191]       Draves, R. and D. Thaler, "Default Router Preferences
+                   and More-Specific Routes", RFC 4191, November 2005.
+
+   [RFC4213]       Nordmark, E. and R. Gilligan, "Basic Transition
+                   Mechanisms for IPv6 Hosts and Routers", RFC 4213,
+                   October 2005.
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 27]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   [RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
+                   Soliman, "Neighbor Discovery for IP version 6
+                   (IPv6)", RFC 4861, September 2007.
+
+   [RFC5014]       Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
+                   Socket API for Source Address Selection", RFC 5014,
+                   September 2007.
+
+   [RFC5214]       Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+                   Automatic Tunnel Addressing Protocol (ISATAP)",
+                   RFC 5214, March 2008.
+
+   [RFC5220]       Matsumoto, A., Fujisaki, T., Hiromi, R., and K.
+                   Kanayama, "Problem Statement for Default Address
+                   Selection in Multi-Prefix Environments: Operational
+                   Issues of RFC 3484 Default Rules", RFC 5220,
+                   July 2008.
+
+   [RFC5969]       Townsley, W. and O. Troan, "IPv6 Rapid Deployment on
+                   IPv4 Infrastructures (6rd) -- Protocol
+                   Specification", RFC 5969, August 2010.
+
+   [RFC6275]       Perkins, C., Johnson, D., and J. Arkko, "Mobility
+                   Support in IPv6", RFC 6275, July 2011.
+
+   [RFC6598]       Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe,
+                   C., and M. Azinger, "IANA-Reserved IPv4 Prefix for
+                   Shared Address Space", BCP 153, RFC 6598, April 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 28]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+Appendix A.  Acknowledgements
+
+   RFC 3484 [RFC3484] acknowledged the contributions of the IPng Working
+   Group, particularly Marc Blanchet, Brian Carpenter, Matt Crawford,
+   Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino,
+   Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik
+   Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman,
+   Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas.  In
+   addition, the anonymous IESG reviewers had many great comments and
+   suggestions for clarification.
+
+   This revision was heavily influenced by the work by Arifumi
+   Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working document
+   that made proposals for this revision to adopt, with input from Pekka
+   Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man
+   Working Group.  Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes
+   George also provided valuable feedback on this revision.
+
+Appendix B.  Changes since RFC 3484
+
+   Some changes were made to the default policy table that were deemed
+   to be universally useful and cause no harm in every reasonable
+   network environment.  In doing so, care was taken to use the same
+   preference and label values as in RFC 3484 whenever possible and for
+   new rows to use label values less likely to collide with values that
+   might already be in use in additional rows on some hosts.  These
+   changes are:
+
+   1.  Added the Teredo [RFC4380] prefix (2001::/32), with the
+       preference and label values already widely used in popular
+       implementations.
+
+   2.  Added a row for ULAs (fc00::/7) below native IPv6 since they are
+       not globally reachable, as discussed in Section 10.6.
+
+   3.  Added a row for site-local addresses (fec0::/10) in order to
+       depreference them, for consistency with the example in
+       Section 10.3, since they are deprecated [RFC3879].
+
+   4.  Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4
+       connectivity is less reliable today (and is expected to be phased
+       out over time, rather than becoming more reliable).  It remains
+       above Teredo since 6to4 is more efficient in terms of connection
+       establishment time, bandwidth, and server load.
+
+   5.  Depreferenced IPv4-Compatible addresses (::/96) since they are
+       now deprecated [RFC4291] and not in common use.
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 29]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   6.  Added a row for 6bone testing addresses (3ffe::/16) in order to
+       depreference them as they have also been phased out [RFC3701].
+
+   7.  Added optional ability for an implementation to add automatic
+       rows to the table for site-specific ULA prefixes and site-
+       specific native 6to4 prefixes.
+
+   Similarly, some changes were made to the rules, as follows:
+
+   1.  Changed the definition of CommonPrefixLen() to only compare bits
+       up to the source address's prefix length.  The previous
+       definition used the entire source address, rather than only its
+       prefix.  As a result, when a source and destination addresses had
+       the same prefix, common bits in the interface ID would previously
+       result in overriding DNS load balancing [RFC1794] by forcing the
+       destination address with the most bits in common to be always
+       chosen.  The updated definition allows DNS load balancing to
+       continue to be used as a tie breaker.
+
+   2.  Added Rule 5.5 to allow choosing a source address from a prefix
+       advertised by the chosen next-hop for a given destination.  This
+       allows better connectivity in the presence of BCP 38 [RFC2827]
+       ingress filtering and egress filtering.  Previously, RFC 3484 had
+       issues with multiple egress networks reached via the same
+       interface, as discussed in [RFC5220].
+
+   3.  Removed restriction against anycast addresses in the candidate
+       set of source addresses, since the restriction against using IPv6
+       anycast addresses as source addresses was removed in Section 2.6
+       of RFC 4291 [RFC4291].
+
+   4.  Changed mapping of RFC 1918 [RFC1918] addresses to global scope
+       in Section 3.2.  Previously, they were mapped to site-local
+       scope.  However, experience has resulted in current
+       implementations already using global scope instead.  When they
+       were mapped to site-local, Destination Address Selection Rule 2
+       (Prefer matching scope) would cause IPv6 to be preferred in
+       scenarios such as that described in Section 10.7.  The change to
+       global scope allows configurability via the prefix policy table.
+
+   5.  Changed the default recommendation for Source Address Selection
+       Rule 7 to prefer temporary addresses rather than public
+       addresses, while providing an administrative override (in
+       addition to the application-specific override that was already
+       specified).  This change was made because of the increasing
+       importance of privacy considerations, as well as the fact that
+       widely deployed implementations have preferred temporary
+       addresses for many years without major application issues.
+
+
+
+Thaler, et al.               Standards Track                   [Page 30]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+   Finally, some editorial changes were made, including:
+
+   1.  Changed global IP addresses in examples to use ranges reserved
+       for documentation.
+
+   2.  Added additional examples in Sections 10.6 and 10.7.
+
+   3.  Added Section 10.3.1 on "broken" IPv6.
+
+   4.  Updated references.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 31]
+
+RFC 6724           Default Address Selection for IPv6     September 2012
+
+
+Authors' Addresses
+
+   Dave Thaler (editor)
+   Microsoft
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+
+   Phone: +1 425 703 8835
+   EMail: dthaler@microsoft.com
+
+
+   Richard Draves
+   Microsoft Research
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+
+   Phone: +1 425 706 2268
+   EMail: richdr@microsoft.com
+
+
+   Arifumi Matsumoto
+   NTT SI Lab
+   Midori-Cho 3-9-11
+   Musashino-shi, Tokyo  180-8585
+   Japan
+
+   Phone: +81 422 59 3334
+   EMail: arifumi@nttv6.net
+
+
+   Tim Chown
+   University of Southampt on
+   Southampton, Hampshire  SO17 1BJ
+   United Kingdom
+
+   EMail: tjc@ecs.soton.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thaler, et al.               Standards Track                   [Page 32]
+