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

bind-3.2.

          ::/0                  40     1 
          2002::/16             30     2 
          ::/96                 20     3 
          ::ffff:0:0/96         10     4 
  
Draves          Standards Track - Expires January 2002               5 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 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 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.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 forwards packets, subject to the restrictions 
   described below. 
     Discussion: The Neighbor Discovery Redirect mechanism [13] 
     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. Implementations that wish to support the use 
     of global source addresses assigned to a loopback interface should 
     behave as if the loopback interface originates and forwards the 
     packet. 
   In some cases the destination address may be qualified with a zone 
   index 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. 
  
Draves          Standards Track - Expires January 2002               6 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
     Discussion: The restriction for multicast destination addresses is 
     necessary because currently-deployed multicast forwarding 
     algorithms use Reverse Path Forwarding (RPF) checks. 
   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. The specified source address may 
   influence the candidate set, by affecting the choice of outgoing 
   interface. 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. 
   Discussion: 
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. 
  
Draves          Standards Track - Expires January 2002               7 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
   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. 
   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 superseded if the implementation has other means of 
   choosing among source addresses. For example, if the implementation 
  
Draves          Standards Track - Expires January 2002               8 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
   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. 
   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 the current next-hop neighbor for DB 
   is known to be unreachable or if Source(DB) is undefined, then sort 
   DA before DB. Similarly, if there is no route to DA or the current 
   next-hop neighbor for DA is known to be unreachable or if Source(DA) 
   is undefined, then sort DB before DA. 
   For IPv6 destination addresses, the  
   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. 
  
Draves          Standards Track - Expires January 2002               9 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
   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. 
   Rule 9: Otherwise, leave the order unchanged. 
   Sort DA before DB. 
   Rules 8 and 9 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. 
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