IPv6:Which Source Address Is Used When You Have Many IPv6 Addresses ? Default Address Selection

Default Address Selection describes the default beha­viour for IPv6 cli­ents that have mul­tiple addresses. IPv6 is designed so that mul­tiple addresses must exist on any inter­face and the applic­a­tion may not neces­sar­ily 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 mul­tiple global IPv6 addresses.
• IPv6 addresses can also be con­sidered to have ‘state’: EUI-​​64 (Autoconfigured Stateless) or DHCPv6 (Autoconfigured Stateful).
• Mobile IPv6 addresses can also be per­man­ent (home address) or mul­tiple “care-​​of addresses.

For example a PC equipped with a single Ethernet net­work card hav­ing a MAC address of 00:2a:0f:33:22:11 sit­ting in two sub­nets (2001:1:2:0::/64 and 2002:1:2:1::/64) and par­ti­cip­at­ing 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 (con­figured unicast)
• 2002:1:2:1:22a:fff:fe33:2211 (another con­figured unicast)
• ::1 (loop­back)
• ff01::1 (all nodes on the interface)
• ff02::1 (all nodes on the link)
• ff02::1:ff33:2211 (soli­cited node multicast)
• ff15::1:2:3 (con­figured multicast)

And choos­ing the wrong address means the applic­a­tion may not select the right des­tin­a­tion. Therefore we can con­sider some of these address­ing types to be more ‘vital’ than oth­ers and to pri­or­it­ise them over other addresses.

RFC3484 defines algorithms that define the “best” address from the the mul­tiple addresses defined on the IP inter­face. Additionally, DNS can return mul­tiple addresses for a given name and an applic­a­tion needs to choose the “best” address for both the source and des­tin­a­tion addresses.

The RFC3484 algorithms are defined for:

• source address selec­tion for a given destination.
• des­tin­a­tion address selec­tion to sort pos­sible des­tin­a­tion addresses.

From the RFC…

“If an imple­ment­a­tion is not con­fig­ur­able or has not been con­figured, then it SHOULD oper­ate accord­ing to the algorithms spe­cified here in con­junc­tion with the fol­low­ing 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 nat­ive source addresses with nat­ive des­tin­a­tion addresses, 6to4¹source addresses with 6to4 des­tin­a­tion addresses, and v4-​​compatible² source addresses with v4-​​compatible des­tin­a­tion addresses. Another effect of the default policy table is to prefer com­mu­nic­a­tion using IPv6 addresses to com­mu­nic­a­tion using IPv4 addresses, if match­ing source addresses are available.

Policy table entries for scoped address pre­fixes MAY be qual­i­fied with an optional zone index. If so, a pre­fix table entry only matches against an address dur­ing 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 some­thing like the fol­low­ing guidelines:

• Address pairs of the same scope or type (link-​​local, global) are preferred.
• A smal­ler scope for the Destination address is pre­ferred (use the smal­lest scope possible).
• A pre­ferred (non-​​deprecated) address is preferred.
• Transitional addresses (e.g., ISATAP or 6to4 addresses) are not used if nat­ive IPv6 addresses are available.
• If all cri­teria are sim­ilar, address pairs with the longest com­mon pre­fix are preferred.
• For the Source address, global addresses are pre­ferred over tem­por­ary addresses.
• In Mobile IP situ­ations, home addresses are pre­ferred over care-​​of addresses.

What I notice is that this “makes sense”. When an applic­a­tion gets a response from a DNS server which has mul­tiple IP addresses (thus pre­sum­ing that the applic­a­tion 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 cli­ent will be selec­ted accord­ing to the scheme above when send­ing the request to the DNSv6 server, and response, which may have many IPv6 addresses, will be selec­ted accord­ing to the scope rules.

Wrap Up

I find this more than a bit con­fus­ing, and get­ting to grips with the idea of IPv6 scope is going to take me some time. Not to men­tion mem­or­ising this scheme so you know which IPv6 to use for troubleshooting.

I don’t think I have done this topic prop­erly, but I learned a lot get­ting this together. IPv6 looked easy when I was only think­ing about IP addresses and rout­ing pro­to­cols, but when you add cli­ents to the mix.… thats kinda scary and its going to take a while.

Reference

Source Address Selection is described in RFC3484, pro­duced 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]

Please rate this post:

(No Ratings Yet)

 Loading ...