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

bind-3.2.

   choose the outgoing interface that will allow it to use the source 
   address that shares a longer common prefix with the destination. 
  
Draves          Standards Track - Expires January 2002              10 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
   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 
   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 
  
Draves          Standards Track - Expires January 2002              11 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
   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) 
   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) 
  
Draves          Standards Track - Expires January 2002              12 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
   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) 
   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 
  
Draves          Standards Track - Expires January 2002              13 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
   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 
   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: 
  
Draves          Standards Track - Expires January 2002              14 
draft-ietf-ipngwg-default-addr-select-05                  June 4, 2001 
 
 
          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 
   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