Dual stack host default address selection

As many organizations ponder IPv6 deployment, the most popular approach will be dual-stack deployment according to a recent survey. This approach entails activating IPv4 and IPv6 address types and assigning corresponding addresses by defined means such as manual, DHCP or auto-configuration for a given device's interface(s). All major host operating systems (OSs) support IPv4 and IPv6 and in some cases auto-configure IPv6 addresses by default.

When an application seeks to communicate with a remote host given its hostname, the application calls the getaddrinfo() sockets API call. This API call triggers one or more DNS lookups (though other forms of name resolution could be used) with the query name set to the hostname passed in the getaddrinfo() call, the query class set to Internet and the query type set to A and AAAA on successive DNS queries. So given a host with both IPv4 and IPv6 interface addresses and destination host name resolution yielding both IPv4 and IPv6 addresses, which addresses are used? Microsoft, Linux, Unix and Mac operating systems all prefer IPv6 source addresses over IPv4 by default. when an appropriate IPv6 destination address is available.

RFC 3484 defines an algorithm for source address selection in the form of a policy table which prioritizes precedence values and preferred source address prefixes for returned destination addresses. This table enables the host to select the most appropriate source address given the possible destination addresses returned with the DNS queries. The original default policy table published in RFC 3484 appeared as:


PrefixPrecedenceLabelMeaning
::1/128500localhost
::/0401Default (matching unicast) IPv6 address
2002::/163026to4
::/96203IPv4-compatible IPv6 address
::ffff:0:0/96104IPv4-mapped IPv6 address

While RFC 3484 defines independent rules for selecting source and destination addresses based on the policy table, the logic is generally the same and consists of selection in the following priority order:

  1. Prefer the same address type
  2. Prefer the same address scope (link-local, site/ULA, etc.)
  3. Prefer non-deprecated addresses (avoid both globally deprecated addresses like site-local and addresses in deprecated state)
  4. Prefer home addresses over care-of addresses (Mobile IPv6)
  5. Prefer source addresses on the selected outbound interface assigned by the designated next hop (e.g., if the outbound interface connects to multiple ISPs, each of which assigned an IP address to the interface, select the one assigned by the corresponding ISP (next-hop)
  6. Prefer matching labels (source and destination prefix mapping)
  7. Prefer public address space
  8. Prefer the address with the longest matching prefix up to the subnet prefix length (this "up to" qualifier added to enable proper DNS round robin operation where multiple round robin destinations on the same subnet resulted in always the same one being selected, that having the longest total bit-wise matching prefix

RFC 3484 is currently undergoing revision and is currently in Internet draft status to add Unique Local Addresses (ULA) as well as Teredo addresses. Though unofficial as yet, the revised policy table currently looks like:

PrefixPrecedenceLabelMeaning
::1/128600localhost
fc00::/7501ULA
::/0402Default (matching) IPv6 address
::ffff:0:0/96303IPv4-mapped IPv6 address
2002::/162046to4
2001::/32105Teredo
::/96110Avoid IPv4-compatible IPv6 address
fec0::/10111Avoid site local IPv6 address

A given host's policy table may be modified if needed in one of the following ways depending on the OS:

  • On Linux you can explicitly denote a prefix as non-preferred setting the preferred_lft parameter to 0. For example, ip -6 addr change 2001:db8:4e/128 dev eth0 preferred_lft 0 disables selection of 2001:db8::4e address as an outbound source address.
  • On Unix/Solaris you can edit the /usr/sbin/ipaddrsel.conf file which is formatted just like the policy tables above. This allows insertion or demoting of address prefixes as desired. Run the /usr/sbin/ipaddrsel command to load the new configuration.
  • On Windows XP, use the ipv6.exe command to update the policy table for a given prefix in the form of:
    ipv6 ppu prefix precedence precedence_value srclabel label_value_source [dstlable label_value_dest ].
  • On Windows 7, Server 2003 and 2008R2, you can update the policy table for a given prefix in the form of:
    netsh interface IPv6 add prefixpolicy [prefix =] prefix/length [precedence=] precedence_value [label=]label_value[[[store=] {active | persistent}]].

Of course creation of and sending of an IP packet with the best match IP source and destination addresses does not guarantee delivery as intermediate transit nodes may or may not support the chosen protocol. As with most things, having a second or third choice improves the probability of a successful connection.

Comments

Post a Comment

Popular posts from this blog

Handy AAAA filter in BIND 9.8

The ISC introduced a pair of new configuration file options in BIND 9.8 to enable administrators to easily filter who may receive AAAA record type responses even if valid responses exist. For example, clients on subnets that do not have IPv6 network access can be excluded from receiving affirmative answers for AAAA queries. This feature provides simpler administration than the alternative mechanism using views. The first option, filter-aaaa-on-v4,defines whether the server will return AAAA records to certain clients. Such clients are defined by the address match list parameter of the second option, filter-aaaa. Note that BIND must be compiled with the --enable-filter-aaaa option on the configure command line to enable AAAA filtering. The syntax of these options is as follows: filter-aaaa-on-v4 (yes | no | break-dnssec) ; filter-aaaa {addr_match_list;} ; The filter-aaaa option identifies the address match list for which the filter-aaaa-on-v4 option is to be applied as described ...
Read more

Inglorious DDI

We all know how critical DHCP/DNS/IPAM (DDI) services are. Your network cannot function without them. But like most foundational elements of anything, they are certainly not glamorous...like good luck finding a home designer who specializes in home foundations. I would not be shocked should HGTV pass on my brilliant concept for a foundation building show. I suppose most people would find a show detailing footing depths and concrete pouring techniques rather boring.  Nevertheless, there are countless shows for redesigning and remodeling homes. On most episodes the foundation is out of sight, out of mind. If it's stable, no one wants to pay it attention, they just expect it to keep doing its job, supporting the structure. Once in a while a foundational issue is brought up that unexpectedly threatens to raise the budget to heighten the drama. All work stops until the issue is addressed. And you'll notice that the owner never denies paying the extra amount to fix the issue. ...
Read more

BIND 9.8.0 Adds DNS64 Support - Part 2 - How is it configured?

BIND 9.8.0 introduced a new dns64 option statement that can be configured within the server named.conf options block or within a view options block. Recall from a prior post that DNS64 configures a recursive DNS server to issue A record queries on behalf of a client requesting AAAA records, then appends the returned IPv4 address to a defined IPv6 prefix. This manufactured IPv6 address enables the querying host to connect to a NAT64 gateway which will terminate the IPv6 connection from the client and map it to an outbound IPv4 connection to the appended IPv4 address, completing the connection! Whew! BIND offers a number of useful parameters within the dns64 statement to control this process. The statement syntax is: dns64 IPv6_prefix { [clients {address_match_list };] [mapped {address_match_list };] [exclude {address_match_list };] [suffix IPv6_addr;] [recursive-only (yes|no);] [break-dnssec (yes|no);] }; The IPv6_prefix parameter is the prefix to which returned...
Read more