Default Address Selection describes the default behaviour for IPv6 clients that have multiple addresses. IPv6 is designed so that multiple addresses must exist on any interface and the application may not necessarily know which IP address is relevant.

Note: The RFC and world uses the term Default Address Selection, Microsoft uses the term Source Address Selection (a Microsoft Standard)

• IPv6 addresses have scope (link-local, site-local and global) and may have all three addreses and multiple global IPv6 addresses.
• IPv6 addresses can also be considered to have ‘state’: EUI-64 (Autoconfigured Stateless) or DHCPv6 (Autoconfigured Stateful).
• Mobile IPv6 addresses can also be permanent (home address) or multiple “care-of addresses.

For example a PC equipped with a single Ethernet network card having a MAC address of 00:2a:0f:33:22:11 sitting in two subnets (2001:1:2:0::/64 and 2002:1:2:1::/64) and participating in the group ff15::1:2:3 must receive data on all these addresses:

• fe80::221:fff:fe33:3311 (link-local)
• 2002:1:2:0:22a:fff:fe33:2211 (configured unicast)
• 2002:1:2:1:22a:fff:fe33:2211 (another configured unicast)
• ::1 (loopback)
• ff01::1 (all nodes on the interface)
• ff02::1 (all nodes on the link)
• ff02::1:ff33:2211 (solicited node multicast)
• ff15::1:2:3 (configured multicast)

And choosing the wrong address means the application may not select the right destination. Therefore we can consider some of these addressing types to be more ‘vital’ than others and to prioritise them over other addresses.

RFC3484 defines algorithms that define the “best” address from the the multiple addresses defined on the IP interface. Additionally, DNS can return multiple addresses for a given name and an application needs to choose the “best” address for both the source and destination addresses.

The RFC3484 algorithms are defined for:

• source address selection for a given destination.
• destination address selection to sort possible destination addresses.

From the RFC…

“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
::/0	40	1
2002::/16	30	2
::/96	10	3
::ffff:0:0/96	0	4

One effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4¹source addresses with 6to4 destination addresses, and v4-compatible² 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”

Can I have that in English please ?

When we break this down we get something like the following guidelines:

• Address pairs of the same scope or type (link-local, global) are preferred.
• A smaller scope for the Destination address is preferred (use the smallest scope possible).
• A preferred (non-deprecated) address is preferred.
• Transitional addresses (e.g., ISATAP or 6to4 addresses) are not used if native IPv6 addresses are available.
• If all criteria are similar, address pairs with the longest common prefix are preferred.
• For the Source address, global addresses are preferred over temporary addresses.
• In Mobile IP situations, home addresses are preferred over care-of addresses.

What I notice is that this “makes sense”. When an application gets a response from a DNS server which has multiple IP addresses (thus presuming that the application is not using Anycast) it will need to choose the IPv6 address that “makes sense” in the scope of either the query or the reply. That is, the source IP address of the IPv6 client will be selected according to the scheme above when sending the request to the DNSv6 server, and response, which may have many IPv6 addresses, will be selected according to the scope rules.

Wrap Up

I find this more than a bit confusing, and getting to grips with the idea of IPv6 scope is going to take me some time. Not to mention memorising this scheme so you know which IPv6 to use for troubleshooting.

I don’t think I have done this topic properly, but I learned a lot getting this together. IPv6 looked easy when I was only thinking about IP addresses and routing protocols, but when you add clients to the mix…. thats kinda scary and its going to take a while.

Reference

Source Address Selection is described in RFC3484, produced by Microsoft Research.

IPv6 Scope

Footnotes

1. Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056, February 2001. [back]
2. Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 2373, July 1998. [back]