

IPng Working Group                                          Richard Draves 
Internet Draft                                          Microsoft Research 
Document: draft-ietf-ipngwg-default-addr-select-04.txt        May 14, 2001 
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. 

   All IPv6 nodes, including both hosts and routers, must implement 
   default address selection as defined in this specification. 

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" 
  
Draves         Standards Track - Expires December 2001              1 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   and "temporary 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 
   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 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 [6], 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 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. 



  
Draves         Standards Track - Expires December 2001              2 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
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 [7]. 

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 [8] like 
   getaddrinfo() 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() 
   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. 

   Well-behaved applications should iterate through the list of 
   addresses returned from getaddrinfo() until they find a working 
   addresses. 

   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, public addresses [4] are preferred over temporary 
   addresses. In mobile situations [5], 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 
  
Draves         Standards Track - Expires December 2001              3 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   over addresses that are solely a home address or solely a care-of 
   address. 

   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 specifies 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. 

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

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

2.2. 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 [2]. For example, to lookup the 
   precedence or other attributes of an IPv4 address in the policy 
   table, lookup the corresponding IPv4-mapped IPv6 address. 

   IPv4 addresses are assigned scopes as follows. IPv4 auto-
   configuration addresses [6], which have the prefix 169.254/16, are 
   assigned link-local scope. IPv4 private addresses [10], which have 
   the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-
   local scope. IPv4 loopback addresses [11, section 4.2.2.11], which 
   have the prefix 127/8, are assigned link-local scope (analogously to 
   the treatment of the IPv6 loopback address [9, section 4]). Other 
   IPv4 addresses are assigned global scope. 

  
Draves         Standards Track - Expires December 2001              4 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   IPv4 addresses should be treated as having "preferred" configuration 
   status. 

2.3. IPv6 Addresses with Embedded IPv4 Addresses 

   IPv4-compatible addresses [2] and 6to4 addresses [12] contain an 
   embedded IPv4 address. For the purposes of this document, these 
   addresses should be treated as having global scope. 

   IPv4-compatible addresses should be treated as having "preferred" 
   configuration status. 

2.4. Loopback Address and Other Format Prefixes 

   The loopback address should be treated as having link-local 
   scope [9, section 4] and "preferred" configuration status. 

   NSAP addresses and other addresses with as-yet-undefined format 
   prefixes should be treated as having global scope and "preferred" 
   configuration status. Later standards may supercede this treatment. 

2.5. 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 Precedence(A) and a 
   classification or label 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. 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 
          ::1/128               50     0 
          ::/0                  40     1 
          2002::/16             30     2 
          ::/96                 20     3 
          ::ffff:0:0/96         10     4 

  
Draves         Standards Track - Expires December 2001              5 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
 
   One effect of the default policy table is to prefer using native 
   source addresses with native destination addresses, 6to4 [12] source 
   addresses with 6to4 destination addresses, and v4-compatible [2] 
   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.6. 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. 

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. 

   If an 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 is an error. If the application or upper-layer 
   specifies a source address that is in the candidate set for the 
  
Draves         Standards Track - Expires December 2001              6 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   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. 

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). 

   This source address selection algorithm only applies to IPv6 
   destination addresses, not IPv4 addresses. 

   The pair-wise comparison consists of eight rules, which should be 
   applied in order. If a rule chooses an address, then the remaining 
   rules are not relevant and should be ignored. Subsequent rules act 
   as tie-breakers for earlier rules. If the eight rules fail to choose 
   an address, some unspecified tie-breaker should be used. 

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

   Rule 2: Prefer appropriate scope. 
   If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then choose SB 
   and otherwise choose SA. 
   Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then 
   choose SA and otherwise choose SB. 

   Rule 3: 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", choose 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. 
   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 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. 
  
Draves         Standards Track - Expires December 2001              7 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   Rule 6: Prefer matching label. 
   If Label(SA) = Label(D) and Label(SB) <> Label(D), then choose SA. 
   Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 
   choose SB. 

   Rule 7: Prefer public addresses. 
   If SA is a public address and SB is a temporary address, then prefer 
   SA. Similarly, if SB is a public address and SA is a temporary 
   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 temporary addresses over public 
   addresses. 

   This rule avoids 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 
   privacy considerations outweigh these application compatibility 
   concerns MAY reverse the sense of this rule and by default prefer 
   temporary addresses over public 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. 

   Rule 2 (prefer appropriate scope) MUST be implemented and given high 
   priority because it can affect interoperability. 

5. 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 should 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. 


  
Draves         Standards Track - Expires December 2001              8 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   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 nine 
   rules, which should be applied in order. If a rule determines a 
   result, then the remaining rules are not relevant and should be 
   ignored. Subsequent rules act as tie-breakers for earlier rules. 

   Rule 1: Avoid unusable destinations. 
   If there is no route to DB or if Source(DB) is undefined, then sort 
   DA before DB. Similarly, if there is no route to DA or if Source(DA) 
   is undefined, then sort DB before DA. 

   Rule 2: Prefer matching scope. 
   If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), 
   then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA)) 
   and Scope(DB) = Scope(Source(DB)), then sort DB before DA. 

   Rule 3: Avoid deprecated addresses. 
   If Source(DA) is deprecated and Source(DB) is not, then sort DB 
   before DA. Similarly, if Source(DA) is not deprecated and Source(DB) 
   is deprecated, then sort DA before DB. 

   Rule 4: Prefer home addresses. 
   If Source(DA) is simultaneously a home address and care-of address 
   and Source(DB) is not, then sort DA before DB. Similarly, if 
   Source(DB) is simultaneously a home address and care-of address and 
   Source(DA) is not, then sort DB before DA. 
   If Source(DA) is just a home address and Source(DB) is just a care-
   of address, then sort DA before DB. Similarly, if Source(DA) is just 
   a care-of address and Source(DB) is just a home address, then sort 
   DB before DA. 

   Rule 5: Prefer matching label. 
   If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), 
   then sort DA before DB. Similarly, if Label(Source(DA)) <> Label(DA) 
   and Label(Source(DB)) = Label(DB), then sort DB before DA. 

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

   Rule 7: Prefer smaller scope. 
   If Scope(DA) < Scope(DB), then sort DA before DB. Similarly, if 
   Scope(DA) > Scope(DB), then sort DB before DA. 

   Rule 8: Use longest matching prefix. 
   If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, 
   Source(DB)), then sort DA before DB. Similarly, if 
   CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), 
   then sort DB before DA. 
  
Draves         Standards Track - Expires December 2001              9 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   Rule 9: Otherwise, leave the order unchanged. 
   Sort DA before DB. 

   Rules 8 and 9 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 

   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 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 may 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 route is advertising global prefix B. Then when sending 
   via the first router, the host may prefer source addresses with 
   prefix A and when sending via the second router, prefer source 
   addresses with prefix B. 

7. 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 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 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 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 may not 
   have knowledge of the outgoing interface for each destination, so it 

  
Draves         Standards Track - Expires December 2001             10 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   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 should 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. 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 can detect if the derived 
   state is potentially stale. 

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

9. Examples 

   This section contains a number of examples, first of default 
   behavior and then demonstrating the utility of policy table 
   configuration. These examples are provided for illustrative 
   purposes; they should not be construed as normative. 

9.1. Default Source Address Selection 

   The source address selection rules, in conjunction with the default 
   policy table, produce the following behavior: 

   Destination: 2001::1 
   Sources: 3ffe::1 vs fe80::1 
   Result: 3ffe::1 (prefer appropriate scope) 

   Destination: 2001::1 
   Sources: fe80::1 vs fec0::1 
   Result: fec0::1 (prefer appropriate scope) 
  
Draves         Standards Track - Expires December 2001             11 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   Destination: fec0::1 
   Sources: fe80::1 vs 2001::1 
   Result: 2001::1 (prefer appropriate scope) 

   Destination: ff05::1 
   Sources: fe80::1 vs fec0::1 vs 2001::1 
   Result: fec0::1 (prefer appropriate scope) 

   Destination: 2001::1 
   Sources: 2001::1 (deprecated) vs 2002::1 
   Result: 2001::1 (prefer same address) 

   Destination: fec0::1 
   Sources: fec0::2 (deprecated) vs 2001::1 
   Result: fec0::2 (prefer appropriate scope) 

   Destination: 2001::1 
   Sources: 2001::2 vs 3ffe::2 
   Result: 2001::2 (longest-matching-prefix) 

   Destination: 2001::1 
   Sources: 2001::2 (care-of address) vs 3ffe::2 (home address) 
   Result: 3ffe::2 (prefer home address) 

   Destination: 2002:836b:2179::1 
   Sources: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) vs 2001::2 
   Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label) 

   Destination: 2001::d5e3:0:0:1 
   Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) 
   Result: 2001::2 (prefer public address) 

9.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: 

   Sources: 2001::2 or fe80::1 or 169.254.13.78 
   Destinations: 2001::1 vs 131.107.65.121 
   Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 
   169.254.13.78) (prefer matching scope) 

   Sources: fe80::1 or 131.107.65.117 
   Destinations: 2001::1 vs 131.107.65.121 
   Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src 
   fe80::1) (prefer matching scope) 

   Sources: 2001::2 or fe80::1 or 10.1.2.4 
   Destinations: 2001::1 vs 10.1.2.3 
   Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer 
   higher precedence) 

  
Draves         Standards Track - Expires December 2001             12 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   Sources: 2001::2 or fec0::2 or fe80::2 
   Destinations: 2001::1 vs fec0::1 vs fe80::1 
   Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 
   2001::1 (src 2001::2) (prefer smaller scope) 

   Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or 
   fec0::2 (care-of address) or fe80::2 (care-of address) 
   Destinations: 2001::1 vs fec0::1 
   Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home 
   address) 

   Sources: 2001::2 or fec0::2 (deprecated) or fe80::2 
   Destinations: 2001::1 vs fec0::1 
   Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid 
   deprecated addresses) 

   Sources: 2001::2 or 3f44::2 or fe80::2 
   Destinations: 2001::1 vs 3ffe::1 
   Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest 
   matching prefix) 

   Sources: 2002:836b:4179::2 or fe80::2 
   Destinations: 2002:836b:4179::1 vs 2001::1 
   Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src 
   2002:836b:4179::2) (prefer matching label) 

   Sources: 2002:836b:4179::2 or 2001::2 or fe80::2 
   Destinations: 2002:836b:4179::1 vs 2001::1 
   Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 
   2002:836b:4179::2) (prefer higher precedence) 

9.3. Configuring Preference for IPv6 vs 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 
          2002::/16             30     2 
          ::/96                 20     3 
          ::ffff:0:0/96        100     4 
 
   This change to the default policy table produces the following 
   behavior: 

   Sources: 2001::2 or fe80::1 or 169.254.13.78 
   Destinations: 2001::1 vs 131.107.65.121 


  
Draves         Standards Track - Expires December 2001             13 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 
   169.254.13.78) (prefer matching scope) 

   Sources: fe80::1 or 131.107.65.117 
   Destinations: 2001::1 vs 131.107.65.121 
   Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 
   (src fe80::1) (prefer matching scope) 

   Sources: 2001::2 or fe80::1 or 10.1.2.4 
   Destinations: 2001::1 vs 10.1.2.3 
   New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) 
   (prefer higher precedence) 

9.4. Configuring Preference for Scoped Addresses 

   The destination address selection rules give preference to 
   destinations of smaller scope. For example, a site-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 
   site-local destinations, and site-local destinations before link-
   local destinations: 

          Prefix        Precedence Label 
          ::1/128               50     0 
          ::/0                  40     1 
          fec0::/10             37     1 
          fe80::/10             33     1 
          2002::/16             30     2 
          ::/96                 20     3 
          ::ffff:0:0/96         10     4 
 
   This change to the default policy table produces the following 
   behavior: 

   Sources: 2001::2 or fec0::2 or fe80::2 
   Destinations: 2001::1 vs fec0::1 vs fe80::1 
   New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then 
   fe80::1 (src fe80::2) (prefer higher precedence) 

   Sources: 2001::2 (deprecated) or fec0::2 or fe80::2 
   Destinations: 2001::1 vs fec0::1 
   Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) 
   (avoid deprecated addresses) 

9.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 

  
Draves         Standards Track - Expires December 2001             14 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   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:aaaa:aaaa::/48 
   from the high-performance ISP and prefix 2007:0:aaaa::/48 from its 
   normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high-
   performance ISP and prefix 2007:0:bbbb::/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: 

   Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 
   Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b 
   Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b 
   (src 2001:aaaa:aaaa::a) (longest matching prefix) 

   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. 

   Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 
   Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c 
   Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 
   2006:cccc:cccc::c (src 2007:0:aaaa::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 may come back through 
   the high-performance ISP. Again, this is not their desired behavior. 

   This situation 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: 








  
Draves         Standards Track - Expires December 2001             15 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
          Prefix              Precedence Label 
          ::1                         50     0 
          2001:aaaa:aaaa::/48         45     5 
          2001:bbbb:bbbb::/48         45     5 
          ::/0                        40     1 
          2002::/16                   30     2 
          ::/96                       20     3 
          ::ffff:0:0/96               10     4 
 
   This policy table produces the following behavior: 

   Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 
   Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b 
   New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 
   2007:0:bbbb::b (src 2007:0:aaaa::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. 

   Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a 
   Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c 
   New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 
   2001:cccc:cccc::c (src 2007:0:aaaa::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. 

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 Autoconfig-
      uration", RFC 2462 , December 1998. 

   4  T. Narten, R. Draves, "Privacy Extensions for Stateless Address 
      Autoconfiguration in IPv6", RFC 3041, January 2001. 

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

   6  S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local 
      Addresses", draft-ietf-zeroconf-ipv4-linklocal-02.txt, March 
      2001. 

   7  S. Bradner, "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997. 
 
  
Draves         Standards Track - Expires December 2001             16 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
 
   8  R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket 
      Interface Extensions for IPv6", RFC 2553, March 1999. 

   9  S. Deering et. al, "IP Version 6 Scoped Address Architecture", 
      draft-ietf-ipngwg-scoping-arch-02.txt, March 2001. 

   10 Y. Rekhter et. al, "Address Allocation for Private Internets", 
      RFC 1918, February 1996. 

   11 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 
      1812, June 1995. 

   12 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 
      Clouds", RFC 3056, February 2001. 

Acknowledgments 

   The author would like to acknowledge the contributions of the IPng 
   Working Group, particularly Marc Blanchet, Brian Carpenter, Matt 
   Crawford, Steve Deering, Jun-ichiro itojun Hagino, Tony Hain, M.T. 
   Hollinger, Erik Nordmark, Ken Powell, Markku Savela, Dave Thaler, 
   and Mauro Tortonesi. Please let the author know if you contributed 
   to the development of this draft and are not mentioned here. 

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-03 

   Reversed the treatment of temporary addresses, so that unless an 
   application specifies otherwise public addresses are preferred over 
   temporary addresses. 

   Added text clarifying our expectation that applications should 
   iterate through the list of possible destination addresses until 
   finding a working address. 

   Removed references to getipnodebyname(). 

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

   Changed scope treatment of IPv4-compatible and 6to4 addresses, so 
   they are always considered to be global. Removed mention of IPX 
   addresses. 
  
Draves         Standards Track - Expires December 2001             17 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   Changed home address rules to favor addresses that are 
   simultaneously home and care-of addresses, over addresses that are 
   just home addresses or just care-of addresses. 

   Combined SrcLabel & DstLabel in the policy table into a single Label 
   attribute. 

   Added mention of the invalidation counter technique in the 
   implementation section. 

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

   Added Examples section, demonstrating default behavior and some 
   policy table configuration scenarios. 

   Removed many uses of MUST. Remaining uses concern the candidate set 
   of source addresses and the source address selection rule that 
   prefers source addresses of appropriate scope. 

   Simplified the default policy table. Reordered the source address 
   selection rules to reduce the influence of policy labels. Added more 
   destination address selection rules. 

   Added scoping of v4-compatible and 6to4 addresses based on the 
   embedded IPv4 address. 

   Changed references to anonymous addresses to use the new term, 
   temporary addresses. 

   Clarified that a user-level implementation of destination address 
   ordering, which does not have knowledge of the outgoing interface 
   for each destination, may use a looser definition of the candidate 
   set. 

   Clarified that an implementation should prevent an application or 
   upper-layer from choosing a source address that is not in the 
   candidate set and not prevent an application or upper-layer from 
   choosing a source address that is in the candidate set. 

   Miscellaneous editorial changes, including adding some missing 
   references. 

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. 
  
Draves         Standards Track - Expires December 2001             18 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   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. 

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 December 2001             19 
draft-ietf-ipngwg-default-addr-select-04                  May 14, 2001 
 
 
   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 December 2001             20 