draft-ietf-ipngwg-default-addr-select-05.txt

bind-3.2.

IPng Working Group                                          Richard Draves 
Internet Draft                                          Microsoft Research 
Document: draft-ietf-ipngwg-default-addr-select-05.txt        June 4, 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 January 2002               1 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 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 January 2002               2 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 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 January 2002               3 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 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 interface-
   local (0x1), link-local (0x2), subnet-local (0x3), admin-local 
   (0x4), 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 January 2002               4 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 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 supersede 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