As mentioned in [2. Addresses](../2.%20IPv6%20Basic%20Technology/Addresses.md), an IPv6 node may have multiple addresses. A trivial example is a home PC with both an Ethernet and a WiFi interface. As a minimum, it will have two link-local addresses (one for each interface) and two GUA (global unicast addresses), all assigned automatically by SLAAC. In practice, this situation presents no problems: the link-local addresses will not be used for external traffic, and the two GUAs will both be assigned under the home network's IPv6 prefix assigned by its ISP. It is of little importance which of the GUAs a particular outgoing application session uses, because routing is the same for either of them. If the PC is using temporary IPv6 addresses for privacy \[[RFC8981](https://www.rfc-editor.org/info/rfc8981)], they too will be under the same prefix and will present no routing problem.
Similarly, an enterprise network with a single IPv6 prefix (typically a /48) does not have any routing problems as a result of enterprise hosts using multiple GUAs under subnet prefixes derived from that prefix. (An enterprise might have other reasons, such as logging and auditing, for wishing to avoid multiple addresses per host; such an enterprise is likely to use DHCPv6 for address configuration, rather than SLAAC.) However, a problem arises if a network operator wishes to connect to two (or more) different ISPs, each providing its own prefix. Such prefixes are known as PA (provider-aggregatable) because they can be folded into a single BGP-4 route announcement for the ISP as a whole.
Here is an illustrative example. Suppose provider X has obtained the prefix ```2001:db8:a000::/36``` from its regional registry, and provider Y has obtained ```2001:db8:b000::/36```. Suppose our enterprise has then been assigned ```2001:db8:abcd::/48``` from X, and ```2001:db8:b123::/48``` from Y. These prefixes will the flow down to the subnets within the enterprise. We will assume that a particular subnet has been given the prefixes ```2001:db8:abcd:0101::/64``` and ```2001:db8:b123:0101::/64```. Therefore, hosts on that subnet will acquire at least two GUAs, one under each of those prefixes. A particular host, for example, might end up with the addresses ```2001:db8:abcd:0101::abc1``` and ```2001:db8:b123:0101::def2```.
(To make the example more legible, we have not used randomized IID values.)
*Intend to insert diagram here*
If, for some reason, there is more than one subnet router on the subnet, the host can be informed which one to use as suggested in [RFC8028](https://www.rfc-editor.org/info/rfc8028).
In normal circumstances, it isn't hard to configure routing so that traffic from ```2001:db8:abcd:0101::abc1``` exits the site towards ISP X, and traffic from ```2001:db8:b123:0101::def2``` exits towards ISP Y. A suitable source routing rule in the subnet router will do it. But what happens if the link to ISP X goes down? Presumably the reason for having two ISP connections is precisely for backup.
We can arrange low priority (high metric) routes between the two exit routers, such that when one ISP link is down, traffic is redirected to the other. However, this may fail if the backup ISP applies ingress filtering \[[BCP84](https://www.rfc-editor.org/info/bcp84)], so the enterprise needs to arrange for its ISPs to accept mutual backup traffic.
This complexity is why many enterprises have not opted for multi-prefix PA-based multihoming. Instead, they have paid to obtain provider-independent (PI) IPv6 prefixes, typically /48 in length, from an Internet registry. However, this is expected to be problematic in the long term, since every such enterprise adds to the size of the Internet-wide BGP-4 routing table. This may be viable for a few thousand enterprises, but not for millions, i.e. not for small businesses or even home offices that might benefit from multihoming.
Another use case for multiple prefixes is an enterprise (or home) that in addition to its PA or PI prefix, which is routeable anywhere on the Internet, also decides to use a Unique Local Address (ULA) prefix for strictly internal communication. Although unfamiliar to most operators, this is conceptually simple and creates a class of traffic that *by definition* cannot escape the site, which has obvious privacy and security attractions. Services that should only be accessed internally could be configured with ULAs *only* and those addresses may be entered in local split-horizon DNS (Section 4 of \[[RFC6950](https://www.rfc-editor.org/info/rfc6950)]). At the time of writing, there is an operational problem in this scenario: host computers configured with default settings from [RFC6724](https://www.rfc-editor.org/info/rfc6724) will not prefer ULAs over IPv4 addresses \[[draft-ietf-v6ops-ula](https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula/)].
