## Multi-prefix operation 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 both connected to the same local segment. 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-assigned or sometimes provider-aggregatable) because they can be summarized 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 then 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.) The following diagram shows the example: Routers and routing clouds as described above 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). For this to work as intended, it is necessary 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. Suitable source routing rules in the subnet router and the rest of the enterprise routing cloud will do it. Such source routing rules typically have to be set up as routing policies, including the relevant source prefixes, configured on each router by a proprietary mechanism. 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 configure 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. If these steps (source routing *and* backup routes *and* filtering exceptions) are not taken, a failure of one of the two ISP connections will cause the failure of all user sessions using addresses under that ISP's PA prefix. Even with backup routes in place, there may be a problem if user client sessions originating *within* the enterprise use IPv6 source addresses under a failing PA prefix. This will happen unless the host is somehow caused to deprecate such source addresses, so that the algorithm of [RFC6724](https://www.rfc-editor.org/info/rfc6724) will not select them. An additional technique that has been suggested is for a site to deploy _conditional_ router advertisements \[[RFC8475](https://www.rfc-editor.org/info/rfc8475)\]. This whole topic is discussed in more depth in [RFC8678](https://www.rfc-editor.org/info/rfc8678). The need for complex configuration and the resulting failure modes explain 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. At the time of writing, the most practical solution for multihoming with multiple providers of IPv6 service (known as MHMP) remains under discussion in the IETF. Another use case for multiple prefixes is an enterprise (or home) that in addition to its PA or PI prefix, which is routable 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/)\]. A site using DHCPv6 can change the default settings via [RFC7078](https://www.rfc-editor.org/info/rfc7078), but unfortunately this is not widely implemented. A partial work-around for this problem is for a host to have two AAAA records in DNS, e.g. `www.example.com` for its GUA and `w3.example.com` for its ULA, the latter only being present in local split-horizon DNS. ### [Previous](Security%20operation.md) [Next](Multihoming.md) [Chapter Contents](6.%20Management%20and%20Operations.md)