description: IPv6 multihoming and multi-prefix operation explained: why running two provider-assigned prefixes is hard, what actually works, and how portable address space from isp6 turns failover into a routing change instead of a renumbering project.

Multihoming IPv6 Without the Renumbering Tax

Why two uplinks the naïve way is harder than it looks, what the industry actually settled on, and how address space registered to you makes redundancy routine.

Audience: isp6 members, network and platform engineers, cloud architects, and anyone responsible for connecting a site, or a cloud footprint, to more than one provider for resilience.

Last updated: July 2026

1. Introduction: multihoming is the real test of ownership

Multihoming means connecting a site to the Internet through more than one link, ideally through more than one provider, so that a single failure does not take you offline. Redundancy, load sharing, a clean provider-exit story: these are the reasons engineers reach for a second uplink in the first place.

It sounds like it should be a solved problem. In IPv6 it is only half solved, and the half that trips people up has nothing to do with cables or BGP sessions. It has to do with addresses: specifically, whose pool your addresses came from, and what your hosts do with them when a link goes down.

This article walks through why the obvious approach (two providers, one prefix from each) is fragile, what the industry actually settled on, and why the deciding factor turns out to be a governance question, not a routing one: is your address space tied to a provider, or to you?

On this article's sources. The engineering analysis below, covering the difficulty of provider-assigned (PA) multihoming, the source-address-selection failure mode, and and the routing-table cost of provider-independent space, draws on the treatment in book6: A Collaborative IPv6 Book, the open-source IPv6 textbook maintained by Brian E. Carpenter and its contributors. We have summarised and re-framed its findings for isp6 members rather than reproduced them, and we recommend the book itself as further reading; the primary standards it cites are linked throughout and collected at the end.

2. One prefix, many addresses: the easy case

Before the hard case, the easy one, because it is worth being clear about what is not a problem.

An IPv6 host routinely holds several addresses at once. A laptop on wired and wireless at the same time has a link-local address per interface, at least one global unicast address (GUA) per interface, and, if privacy extensions are enabled (RFC 8981), one or more temporary addresses on top. That is entirely normal and causes no trouble, for one reason: all of those GUAs sit under the same site prefix. A network with a single /48 can hand out as many addresses per host as it likes, because routing is identical for every one of them. Whichever address a session picks, the packet leaves through the same door.

The moment that stops being true is the moment multihoming gets hard.

3. Two providers, two prefixes: where it gets hard

Now connect the same site to two ISPs, X and Y, and take a provider-assigned (PA) prefix from each: say 2001:db8:abcd::/48 from X and 2001:db8:b123::/48 from Y. Both flow down to your subnets, so a host on one segment ends up with two GUAs, one under each provider's prefix, for example 2001:db8:abcd:101::a and 2001:db8:b123:101::b.

Getting packets out correctly now takes real work. A packet whose source is X's address must leave towards X, and a packet sourced from Y's address must leave towards Y, otherwise the provider's anti-spoofing ingress filter (BCP 84) drops it on the way out. That means source-based routing policy on every router that has a choice to make: steer by source prefix, not just destination.

Then comes the reason you multihomed in the first place: a failure. Suppose the link to ISP X goes down. You want traffic to fall back to Y, so you configure low-priority backup routes between the exit routers. But two things bite:

• Ingress filtering. If Y filters by source address, it may refuse to carry packets that still carry X's source prefix. You have to arrange with your providers in advance to accept each other's traffic as mutual backup, an operational deal, not a config line.
• Source-address selection. Even with the backup route in place, your hosts keep choosing X's now-dead source address, because nothing has told them to stop (see the next section). Client sessions sourced from the failed prefix simply stall.

book6 puts the failure mode plainly: if you do not set up source routing and backup routes and the filtering exceptions, losing one of two ISP links takes down every session using addresses under that ISP's prefix, which is the opposite of what a second link was supposed to buy you. And even done perfectly, PA multi-prefix multihoming does not give you transport session survivability: an in-flight TCP or QUIC connection bound to the failed address does not migrate, it breaks.

4. The source-address trap (RFC 6724)

When a host has several addresses and an application does not pin one, the operating system chooses the source/destination pair for you, following the algorithm in RFC 6724. It sorts candidate pairs by a fixed list of rules (prefer the same address already in use, prefer an appropriate scope, avoid deprecated addresses, prefer a matching label, use the longest matching prefix, and so on) and takes the top of the list.

The rule that matters for multihoming is "avoid deprecated addresses." A source address under a failed uplink is only skipped if something marks it deprecated. Nothing does so automatically when a distant BGP session drops. So the host keeps handing out a dead address, and every new connection from it fails, even though a perfectly good address under the other provider is sitting right there on the same interface.

The policy table that drives this is, on almost every host, left at its operating-system default: the /etc/gai.conf you have never edited. It can be steered:

• Deprecate the address on failure, so RFC 6724 skips it.
• Conditional Router Advertisements (RFC 8475) that withdraw or de-preference a prefix when its uplink is down.
• RFC 8028 guidance so a host learns which first-hop router goes with which source prefix, when a subnet has more than one router.
• Address labels (ip addrlabel on Linux, netsh interface ipv6 add prefixpolicy on Windows) to pin source/destination pairings, which is powerful and almost never deployed at scale.

Every one of these is real, and every one is extra machinery you have to build, test, and keep working across a fleet of hosts you may not fully control. That is the crux of why PA multi-prefix multihoming, however elegant on a whiteboard, rarely survives contact with a production estate.

5. The fixes the industry tried, and why they did not stick

This is not a new problem, and it is not for want of trying. The IETF set out formal goals for site multihoming back in 2003 (RFC 3582): redundancy, load sharing, performance, policy control, simplicity, and session survivability, and a solution that delivers all of them at once has proved genuinely hard to find. A useful overview is RFC 7157. The notable attempts:

The honest summary is the one book6 reaches: for multihoming with multiple providers using multiple PA prefixes, a clean, universally-deployable answer is still an open question at the IETF. Which is why, in practice, everyone who needs real multihoming does something else.

6. What actually works: one prefix, advertised from many places

Strip the problem back and the source of the pain is obvious: it comes from your hosts holding two different providers' addresses and having to guess which one still works. Remove that, and the whole class of problems disappears.

The tried-and-tested approach for a site that genuinely needs to be multihomed is to stop taking a prefix from each provider and instead hold one prefix that belongs to you, historically a provider-independent (PI) /48 from an Internet registry, and have every uplink advertise a BGP route to that same prefix. Now:

• Hosts have one stable GUA per interface. RFC 6724 has nothing to get wrong.
• Failover is a routing change, handled by BGP and your interior routing metrics, not a host-addressing change. In-flight sessions survive, because the address they are bound to never went away.
• You never renumber. The prefix is tied to your organisation, not to an ISP, so changing, adding, or dropping a provider is a routing edit, not a rebuild of every DNS zone, firewall rule, and allow-list.

There is one honest caveat, and book6 is careful to make it: every such prefix you advertise is one more route in the global BGP table. In late 2023 that table carried on the order of 200,000 IPv6 routes, and the routing system cannot absorb an independent prefix for every one of the world's small businesses. Provider-independent multihoming by your own BGP is the right tool for a substantial site with the routing skills to run it, which is not for everybody. For everybody else, the cloud era has quietly provided a second answer.

7. The cloud-era shortcut: multi-cloud BYOIP

Most organisations no longer terminate their own BGP sessions; their cloud providers do it for them. Bring Your Own IP (BYOIP) turns the "one prefix, many places" model into something you can operate without an ISP negotiation or a router estate: you hold a portable prefix registered to you, and you authorise a cloud provider to announce it from their Autonomous System.

Because the block is yours rather than the cloud's, the same prefix, or slices of it, can be provisioned into more than one cloud at once:

The provider carries the global-table cost on their existing Autonomous System, so you get provider-independent behaviour, moving without renumbering and announcing from more than one place, without having to run BGP yourself or add a route the DFZ would not otherwise carry. For the mechanics per platform, see the isp6 guides for AWS, Azure, and Google Cloud.

One piece of routing hygiene applies to any multi-origin setup, cloud or BGP: each Autonomous System that announces your prefix needs a valid RPKI Route Origin Authorisation (ROA) with an appropriate maxLength, or RPKI-validating networks will drop the announcement as invalid. Multihoming means more than one authorised origin, and every one of them has to be signed.

8. Where isp6 fits

isp6 is a RIPE NCC accredited Local Internet Registry. The reason any of the above is relevant to us is specific and, we hope, un-hyped: the deciding factor in every option above was whose address space it is. That is exactly the thing an LIR allocation changes.

• A prefix registered to you, not to a provider. Order a /48 or /44 through the isp6 portal and it is drawn fresh from isp6's own RIPE NCC pool, registered in the RIPE Database with you as the holder, and portable via BYOIP. It is the "one prefix that belongs to you" from Section 6, the input the robust designs assume, without your having to become an LIR yourself.
• ROAs for every origin, managed for you. The subnet dashboard lets you author and monitor RPKI ROAs for each Autonomous System that announces your space. The AWS, Azure, and Google ASNs are built into the cloud panel, so a multi-origin, multihomed announcement stays RPKI-valid across all of them.
• Provider-independent space and an ASN when you need them. For an organisation that wants to run its own BGP with a true PI assignment and its own AS number, isp6 acts as the sponsoring LIR and handles the RIPE NCC application, route objects, and ongoing compliance.
• route6, reverse DNS, and keys handled. The registry paperwork that used to gate a multihoming project (inet6num, route6, reverse-DNS delegation, and the key pair that proves ownership to a cloud) is part of the allocation, not a separate quest.

None of this makes RFC 6724 or BGP go away. What it removes is the one problem underneath all the others: addressing you cannot move. With a prefix that is yours, multihoming stops being a renumbering project and becomes what it always should have been: a routing decision.

9. A practical checklist

• Do not multihome with two PA prefixes unless you have accepted the trade-offs in Sections 3–4 and can drive host source-address behaviour across your whole fleet.
• Hold one portable prefix registered to you as the foundation, from isp6 as your LIR, and announce it from every location that needs to reach the Internet.
• Sign a ROA for every origin AS that will announce the prefix; verify each shows valid in the dashboard before you rely on it.
• If you run your own BGP, plan interior metrics for steering and backup, and confirm your upstreams will accept mutual-backup traffic.
• If a cloud announces for you, use BYOIP into each provider and treat failover as a re-advertisement, never a renumber.
• Keep internal-only services on ULAs where it suits you, and reach for provider-independent space plus your own ASN only when the site is large enough to justify a global routing-table slot.

10. Further Reading

Related isp6 articles

• Digital Sovereignty Starts at the Network Layer: the leadership case for owning, rather than renting, the address space your multihoming depends on
• Planning Your isp6 Allocation: sizing and structuring the /48 or /44 you will advertise from every location
• Bring Your Own IPv6 to AWS, Azure, and Google Cloud: the per-platform mechanics of announcing your portable prefix
• Stop Thinking in IPv4: the mental models, including NAT and addressing, that need updating before you design for IPv6

External references

• book6: A Collaborative IPv6 Book: Brian E. Carpenter et al.; see the Multihoming, Multi-prefix operation, and Source and Destination Address Selection sections, on which this article's analysis draws
• RFC 6724: Default Address Selection for IPv6
• RFC 8678: Enterprise Multihoming using Provider-Assigned IPv6 Addresses
• RFC 7157: IPv6 Multihoming without Network Address Translation
• RFC 8028: First-Hop Router Selection by Hosts in a Multi-Prefix Network
• RFC 8475: Signaling Multiple Provisioning Domains with Conditional RAs
• BCP 84: Ingress Filtering for Multihomed Networks
• RIPE NCC: Provider Independent (PI) Assignments

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.