Skip to main content

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

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:

  • Policy Table (Section 2.1): a table that specifies precedence values and preferred source prefixes for destination prefixes.

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

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

Last updated on