There is a serious difference between IPv4 and IPv6. Every interface has just a single address in IPv4. If you want to assign more addresses to the same interface, you have to use various hacks (i.e., virtual sub-interfaces) or vendor specific implementations that do not adhere to open standards such as DHCP.

IPv6 is different. Not only does it allow you to assign more addresses to the same interface, it even urges you to do so because multiple addresses are needed for the full complement of IPv6

functionality. Required addresses for a common host (computer, printer or any other device which does not forward the datagrams) are as follows:

• link-local address for every interface
• assigned (configured) unicast and multicast addresses for the interfaces
• loopback address (::1)
• all-nodes multicast addresses (ff01::1, ff02::1)
• solicited node multicast address
• assigned multicast addresses (identifying groups to which the node belongs)

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

• fe80::22a:fff:fe32:5ed1 (link-local)
• 2001:a:b:c:22a:fff:fe32:5ed1 (configured unicast)
• 2001:a:b:1:22a:fff:fe32:5ed1 (another configured unicast)
• ::1 (loopback)
• ff01::1 (all nodes on the interface)
• ff02::1 (all nodes on the link)
• ff02::1:ff32:5ed1 (solicited node multicast)
• ff15::1:2:3 (configured multicast)

A router has even more required addresses. It must support all the addresses obligatory for a node plus:

• anycast address for all routers in the subnet for every interface on which it acts as a router
• all assigned anycast addresses
• all-routers multicast (ff01::2, ff02::2, ff05::2)

Suppose that the aforementioned node is a router. It operates as a home agent (see Chapter 10 about mobility for the description of this) in both subnets, so it should listen to the corresponding all homeagents anycast addresses. In this case it must in addition to addresses already stated support:

• 2001:a:b:c:: (routers in first subnet)
• 2001:a:b:1:: (routers in second subnet)
• 2001:a:b:c::fdff:ffff:ffff:fffe (home agents in first subnet)
• 2001:a:b:1::fdff:ffff:ffff:fffe (home agents in second subnet)
• ff01::2 (all routers on the interface)
• ff02::2 (all routers on the link)
• ff05::2 (all routers in the site)

Having more addresses on the same interface brings a new problem: Which one should be used? Suppose for example that you typed www.somewehere.com into your WWW browser and the request to DNS returns four different IP addresses. The selection of particular address influences datagram routing and the behaviour of the network in general. So it is quite important.

RFC 3484 [RFC3484] brings the rules for this situation. It defines an imperative algorithm to select the sender and receiver addresses for an IP datagram. The general idea behind the address selection is following. The application willing to communicate will call some system service (typically the getaddrinfo() function) to obtain a list of available addresses for given target host. It takes the first of these addresses, selects some appropriate source address and tries to establish the communication. In the case of failure the next potential destination address from the list is used. We do not cover the exact rules to judge between addresses here because they are important for the implementers of IPv6, not for its users. But one aspect of these rules should be mentioned here – the policy table.

It is a dedicated data structure used to express relationships (affinity) between addresses. Every entry of the policy table contains: address prefix, precedence and label. When evaluating some address, the entry containing longest matching prefix is used to assign the precedence and label to the address. Generally speaking: two addresses (source and destination) having the same label are related which increases their chance to be selected.

Using the policy table you may influence the address selection algorithm by assigning labels to particular prefixes. Of course it is not obligatory, there is a default policy table defined by RFC 3484 which will be used in such case.