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 ((Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056, February 2001.))source addresses with 6to4 destination addresses, and v4-compatible ((Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 2373, July 1998.)) 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.
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.
Source Address Selection is described in RFC3484, produced by Microsoft Research.
|IPv6 Name||Scope/Description||IPv4 Equivalent||Notes|
|Link-Local||Local LAN only. Usually EUI-64. Cannot be routed outside local LAN.||No real equivalent. Assigned IPv4 over ARP’d MAC.||Scoped address concept new to IPv6.|
|Site-Local||Optional. Local Site only. Cannot be routed over Internet. Assigned by user.||Private network address with multi-homed interface is closest equivalent.||Unlike the IPv4 private network address the IPv6 device can have, and most likely will have, Link-Local, Site-Local & a Global Unicast address. Site-Local is mostly deprecated.|
|Global Unicast||Globally unique. Fully routable. Assigned by Internet Registry’s||Global IP address.||IPv6 and IPv4 similar but IPv6 can have other scoped addresses.|
|Multicast||One-to-many. Hierarchy of multicasting.||Similar to IPv4 Class D.||Significantly more powerful than IPv4 version. No broadcast in IPv6, replaced by multicast.|
|Anycast||One-to-nearest. Uses Global Unicast Addresses||Unique protocols in IPv4 e.g. IGMP.||Some anycast addresses reserved for special functions.|
|Loopback||Local interface scope.||Same as IPv4 127.0.0.1||Same function|