Default IP Address Selection

 https://thirdinternet.com/default-ip-address-selection/

 

 

Default Address Selection in IPv4

In IPv4, each interface really has only one unicast address. It is possible for various reasons to assign additional IPv4 unicast addresses to a single interface, but those are called aliases. The node that the interface belongs to will accept connections to those addresses (and respond to ARP requests), but it will not typically use an alias as the source address when sending a packet from that interface unless for some reason the main address is unsuitable (e.g. maybe it is an APIPA address, and one of the aliases is a normal private or public address). Hence there is a very simple algorithm required to choose the source address in IPv4. You just use the first IPv4 unicast address assigned to the interface that is of an acceptable scope.

When you do a getaddrinfo() system call on an IPv4-only node, you typically get only one address. If you do get multiple addresses, DNS will rotate them “round robin” mode to sequential requests, which is a “poor man’s load balancer”. The default policy to reach the nodename you looked up, is to connect to the first address returned by DNS, as the destination address.

Default Address Selection in IPv6

In IPv6, an interface can have any number of unicast addresses. Typically each node has one autonomously generated Link-Local address, plus one or more global unicast addresses for each prefix in received Router Advertisement messages. It may also have one or more manually assigned addresses, and possibly one address from a stateful DHCPv6 server. A single interface may have quite a few IPv6 unicast addresses. So when the node goes to send a packet out that interface, which of those unicast addresses does it use as the source address? This is an important question, since the recipient will likely use that address as the destination in a reply to that node.

This issue usually comes up the first time someone goes to a site that displays the source address from the connection, such as v6address.com or www.sixscape.com. It usually displays something like “you connected from 2001:470:3d:3000::2:1”. When someone enables DHCPv6, or manually assigns an address, they try this and may be surprised when the site says you connected from some other address. If that site is restricting access to only certain addresses, if it chooses some other address, you won’t be allowed to access the site, even if your interface happens to have an acceptable address assigned to it. IPv6 students are often confused by this behavior. In the Windows ping command, you can specify the source address to be used with the -S option. Most commands (let alone GUI tools like browsers) do not have any way to manually choose the source address.

This issue is so important, there is an entire RFC devoted to it. That is RFC 6724, “Default Address Selection for Internet Protocol version 6 (IPv6)”, September 2012 (which replaces RFC 3484). There is a fairly complex algorithm involved. You can have some influence on which address is chosen by modifying the priority table on your node, but this is not simple (and is beyond the scope of this article).

There are several factors which can affect the selection of the source address:

• • • an interface may have both IPv4 and IPv6 addresses
    • address reachability scopes (Link-Local, global, etc)
    • address lifetime state (preferred / deprecated)
    • whether address is regular or “temporary” (RFC 4941)
    • mobile IPv6 and multihoming introduce even more factors
    • whether an address is for a native or tunneled/translated connection

If the packet is being sent to an off-link node, that eliminates any Link-Local address as source. The recipient would not be able to reply to the packet. In fact, the border router will not even allow such a packet to be forwarded – it will discard the packet and send a “packet undeliverable, source address out of range” ICMPv6 error to the sender.

When a node does a getaddrinfo() system call to perform a DNS query, it may get back a number of addresses. These will be sorted by the default address rules

The rules listed below will prefer destination/source address pairs for which the two addresses are of equal scope or type. It prefers smaller scopes over larger scopes for the destination address. It prefers non-deprecated addresses (ones still in the “preferred” state). It prefers native addresses to transitional addresses (e.g. tunneled or translated). All other things being equal, it will prefer the longest possible common prefix.

For source address selection, regular addresses are preferred over temporary ones. In mobile situations, home addresses are preferred over care-of addresses.

To override these rules, there is a policy override table that allows you to modify the default rules to influence the choice of source and/or destination addresses from the available choices.

Policy Table

The policy table is used in the decision making process. Each entry has three fields:

• • • An IPv6 prefix (e.g. 2002::/16)
    • A Precedence (e.g. 30)
    • A Label (e.g. 2) (this is the “Label” attribute referred to in the rules)

The default policy table is as follows:

Prefix       Precedence      Label       Significance


::1/128          50            0         Loopback address
::/0             40            1         Default route
::ffff:0:0/96    35            4         IPv4 Mapped IPv6 address
2002::/16        30            2         6to4 tunnel address
2001::/32         5            5         Teredo tunnel address
fc00::/7          3           13         Unique Local Address
::/96             1            3         IPv4 Compatible IPv6 address 
fec0::/10         1           11         Site-Local address (deprecated)
3ffe::/16         1           12         6Bone address (deprecated)

One effect of the default table is to prefer using native source addresses with native destination addresses, 6to4 source addresses with 6to4 destination address, etc.

You can use zone IDs (e.g. %eth0) to qualify addresses in the policy table to have that entry affect only the specified interface.

Source Address Selection

The rules for choosing the preferred source address are expressed in terms of two possible source addresses, “SA” and “SB”, and the destination address “D”. If there are more than two possible source addresses, then the rules are applied to each possible pair until there is an ultimate winner.

Rule 1: Prefer same address

If one of the source addresses is the same as the destination address, prefer that address.

Rule 2: Prefer appropriate scope

If Scope(SA) < Scope(SB), and Scope(SA) < Scope(D), prefer SB, else prefer SA.

If Scope(SB) < Scope(SA), and Scope(SB) < Scope(D), prefer SA, else prefer SB.

Rule 3: Avoid deprecated addresses.

If one of the source addresses is in the preferred state, and the other is in the deprecated state, prefer the one in the preferred state.

Rule 4: Prefer home addresses.

If one of the source addresses is both a home address and a care-of address, but the other isn’t, prefer the one that is both a home address and a care-of address.

If one of the addresses is just a home address, and the other is just a care-of address, then prefer the one that is just a home address.

Rule 5: Prefer outgoing interface.

If one of the source addresses is assigned to the interface that will be used to send to the destination address, and the other isn’t, prefer the one assigned to the sending interface.

Rule 5.5: Prefer address in a prefix advertised by the next-hop (added in RFC 6724)

If the prefix of one of the source addresses is assigned by the selected next-hop that will be used to send to the destination, and the prefix of the other source address is assigned to a different next-hop, the prefer the one assigned to the next-hop used to send to the destination.

Rule 6: Prefer matching Label (see priority table).

If the Label of one of the source addresses is the same as the Label of the destination address, and the Label of the other source address is not, then prefer the source address that has the same Label as the destination address.

Rule 7: Prefer temporary addresses.

If one of the source addresses is a temporary address and the other is a regular address (per RFC 4941), then prefer the temporary address. Note: this rule was reversed from RFC 3484. Implementations must provide a mechanism (e.g. API call) to use the old rule, if privacy considerations outweigh reliability issues.

Rule 8: Use longest matching prefix.

Prefer the address that has the most bits in common with the destination address, starting from the Most Significant Bit (up to the prefix length).

Destination Address Selection

All of the possible destination addresses (IPv4 and IPv6) are sorted to produce a new list, based on pairwise comparisons of the addresses in the list. An IPv4 address is evaluated based on the equivalent IPv4-mapped IPv6 address. Source(D) means the selected source address for the destination D. The rules for pairwise comparisons are expressed in terms of two possible destination addresses, DA and DB.

Rule 1: Avoid unusable destinations.

If one of the destinations is unreachable, or Source of that destination is undefined, then prefer the other address.

Rule 2: Prefer matching scope.

If the scope of one destination matches the scope of the source of that destination, but the same isn’t true of the other destination, prefer the destination with matching scope.

Rule 3: Avoid deprecated addresses.

If only one of the destinations is in the preferred state, prefer that destination.

Rule 4: Prefer home addresses.

If the source of one of the destinations is both a home address and a care-of address, but the same isn’t true of the other destination, prefer the destination that is both.

Rule 5: Prefer matching Label (see Priority Table)

If the Label of the source of one destination equals the Label of that destination, but the Label of the source of the other destination is not equal to the label of that destination, then prefer the destination with matching Label.

Rule 6: Prefer higher precedence (see Priority Table)

If the Precedence of one destination is higher than the precedence of the other destination, then prefer the destination with higher precedence.

Rule 7: Prefer native transport.

If one destination is reached by native transport, while the other is reached via tunnel or translation, prefer the destination reached by native transport.

Rule 8: Prefer smaller scope.

If one of the destinations is a smaller scope than the other, prefer the smaller scope.

Rule 9: Use longest matching prefix.

Assuming the two destinations are of the same IP address family, prefer the one that has the most bits in common with the source of that destination, starting with the Most Significant Bit.

Rule 10: Otherwise, use the original order

If one of the destination addresses was earlier in the original list, prefer that destination.

Examples of Source Address Selection

D = 2001::1
SA = 3ffe::1, SB = fe80::1

Prefer 3ffe::1
Prefer source and destination having same scope, which is global

D = 2001::1
SA = fe80::1, SB = fec0::1

Prefer fec0::1
Site-Local scope is more appropriate for Global than Link-Local scope is

D = fec0::1
SA = fe80::1, SB = 2001::1

Prefer 2001::1
Global scope more appropriate for Site-Local than Link-Local scope is

D = ff05::1
SA = fe80::1, SB = fec0::1, SC = 2001::1

Prefer fec0::1
Scopes of fec0::1 and ff05::1 are both Site-Local

D = 2001::1
SA = 2001::1 (in deprecated state), SB = 2002::1

Prefer 2001::1
Prefer same address higher priority than Avoid deprecated state

D = fec0::1
SA = fec0::2 (in deprecated state), SB = 2001::1

Prefer fec0::2
Prefer appropriate scope higher priority than Avoid deprecated state

D = 2001::1
SA = 2001::2, SB = 3ffe::2

Prefer 2001::2
Longest matching prefix

D = 2001::1
SA = 2001::2 (care-of address), SB = 3ffe::2 (home address)

Prefer 3ffe::2
Both choices are global scope, so Prefer home address

D = 2002:836b:2179::1
SA= 2001:836b:2179::dbe3:7953:13eb:22e8 (temporary), SB = 2001::2

Prefer 2001:836b:2179::d5e3:7953:13eb:22e8
Prefer matching Label

D = 2001::d5e3:0:0:1
SA = 2001::2 (regular), SB = 2001::d5e3:7953:13eb:22e8 (temporary)

Prefer 2001::d5e3:7953:13eb:22e8 - note: this is wrong in RFC
Prefer temporary address

Examples of Destination Address Selection

SA = 2001::2, SB = fe80::1, SC=169.254.13.78
DA = 2001::1, DB = 131.107.65.121

Prefer (2001::2 -> 2001::1), then (169.254.13.78 -> 131.107.65.121)
Prefer matching scope

SA = fe80::1, SB = 131.107.65.117
DA = 2001::1, DB = 131.107.65.121

Prefer (131.107.65.117 -> 131.107.65.121), then (fe80::1 -> 2001::1)
Prefer matching scope

SA = 2001::2, SB = fe80::1, SC = 10.1.2.4
DA = 2001::1, DB = 10.1.2.3

Prefer (2001::2 -> 2001::1), then (10.1.2.4 -> 10.1.2.3)
Prefer higher precedence

SA = 2001::2, SB = fec0::2, SC = fe80::2
DA = 2001::1, DB = fec0::1, DC = fe80::1

Prefer (fe80::2 -> fe80::1), then (fec0::2 -> fec0::1), then (2001::2 -> 2001::1)
Prefer smaller scope

SA = 2001::2 (care-of address), SB = 3ffe::1 (home address), SC = fec0::2 (care-of address), SD = fe80::2 (care-of address)
DA = 2001::1, DB = fec0::1

Prefer (3ffe::1 -> 2001::1) then (fec0::2 -> fec0::1)
Prefer home address

SA = 2001::2, SB = fec0::2 (deprecated), SC = fe80::2
DA = 2001::1, DB = fec0::1

Prefer (2001::2 -> 2001::1), then (fec0::2 -> fec0::1)
Avoid deprecated addresses

SA = 2001::2, SB = 3f44::2, SC = fe80::2
DA = 2001::1, DB = 3ffe::1

Prefer (2001::2 -> 2001::1), then (34ff::2 -> 3ffe::1)
Longest matching prefix

SA = 2002:836b:4179::2, SB = fe80::2
DA = 2002:836b:4179::1, DB = 2001::1

Prefer (2002:836b:4179::2 -> 2002:836b:4179::1), then (2002:836b:4179::2 -> 2001::1)
Prefer matching label

SA = 2002:836b:4179::2, SB = 2001::2, SC = fe80::2
DA = 2002:836b:4179::1, DB = 2001::1

Prefer (2001::2 -> 2001::1), then (2002:836b:4179::2 -> 2002:836b:4179::1)
Prefer higher precedence

Summary

The rules for determining which of many possible unicast addressees to use for the source address of outgoing packets are very complex and difficult for most people to predict. Influencing the choice by modifying the policy table is even more complex. To most people the choice of source address will appear random. If you want to be sure a particular address is used as source, the only certain way is to eliminate all the other global unicast addresses (except for the autonomously generated Link-Local address). This means you would need to disable SLAAC (at least on that node). The single global unicast address can be

• • • manually configured
    • assigned via DHCPv6
    • configured by some other automated address management scheme

With manual configuration, the default gateway and addresses of DNS would need to be manually configured, in addition to the global unicast node address, for every node.

With DHCPv6, the default gateway would need to be manually configured (unlike DHCPv4, DHCPv6 cannot advertise the default gateway of the subnet). The IPv6 addresses of DNS can be obtained from DHCPv6. In the absence of SLAAC, you would need to set the Managed Address option on the node to use DHCPv6. To link a specific global unicast address to a node, you would need to set up address reservations in DHCPv6 for each managed node.