Why Can’t We All Use Provider-Independent IPv6 Addresses?

Here’s another back-to-the-fundamentals question I received a while ago when discussing IPv6 multihoming challenges:

I was wondering why enterprise can’t have dedicated block of IPv6 address and ISPs route the traffic to it. Enterprise shall select the ISP's based on the routing and preferences configured?

Let’s try to analyze where the problem might be. First the no-brainers:

  • A consumer device with high-availability requirements: use two independent uplinks (WiFi + 5G). As long as the traffic from both uplinks doesn’t merge before being sent to upstream ISPs you don’t have a problem (the proof is left as an exercise for the reader);
  • An organization with a single uplink to a single ISP: no problem. Use provider-assigned IPv6 address (ideally delegated via DHCPv6 IA_PD) and put all your services into a cloud, or use dynamic DNS if you want to save $10/month.
I described the customer- and provider side of this setup in the Building Large IPv6 Networks webinar.
  • A large single-site organization with one or more Internet uplinks: get your own IPv6 address space and use BGP to advertise your prefix(es) to upstream ISPs. The same approach works for an enterprise with multiple large sites.
It’s worth noting at this point that an Internet service that includes provider-independent address space advertised by BGP tends to be an order of magnitude more expensive than a residential service with the same speed… just because customers with such requirements are willing to pay more.

Now for the trickier use case: small office of a large enterprise. Even if they’d be willing to pay for enterprise-grade Internet access for every 3-person sales office in the middle of nowhere, do you really think that the global Internet would survive carrying provider-independent /48 prefixes for every single small office of every rich-enough organization out there?

A similar one: small organization with two uplinks. They won’t pay for enterprise-grade Internet service, and won’t get provider-independent IPv6 address space because it’s too expensive. IETF has been tackling various aspects of this elephant for a decade and still hasn’t got anywhere close to solving it.

You might wonder how many small sites really need two uplinks. Lots of SOHO offices or remote workers do – one the uplinks is a site-to-site VPN with the mothership. You could solve 95% of this problem with host-based IPsec VPN or SSL VPN (in both cases you don’t care about the transport IP address of the client) or with SSL proxy, but there’s always the problem of remote printers and IP phones. Johannes Weber described the challenges of using VPNs with dynamic IPv6 prefixes in his Troopers 2018 presentation… and it’s not a pretty picture.

Anything else I’ve missed? Please write a comment.

Revision History

Updated based on feedback from Dan Wing. Thank you!

Latest blog posts in Site and Host Multihoming series


  1. For dual-PA-/48 multihoming, the IETF homenet protocol suite was very promising for the longest time. I even had a test setup built which worked nicely.

    Alas, they took too long to finish their standards - now vendors are shipping IPv6 CPEs with a "non-homenet" protocol suite - and there is little commercial interest anywhere to change that.

    But there is an interesting twist to SoHo multihoming - I think "network multihoming" is a dead end for these setups, because nowadays almost all devices have a LTE chip anyway, so if the SoHo Wifi network looses Internet connectivity, you just fall over to LTE - and with MP-TCP or a good VPN solution, you don't even notice anything...
  2. One doesn't need TLS (née SSL) VPN to ignore transport address. IPsec can do that, too. Microsoft DirectAccess and Apple's Back-to-my-Mac both use IPsec to bring a remote network local.

    Remote VoIP phones doesn't have a problem -- ICE works fine for those.

    Remote printers could work fine, if the printers used service discovery via DNS, such as mDNS, and the enterprise's printer queues embraced that technique instead of their crusty IPv4 dotted-decimal addresses.
    1. "One doesn't need TLS" << True. Updated. Thank you.

      "ICE works fine for those" << I know way too little about VoIP, but it seems to me ICE is nothing more than NAT traversal, and we might still need to encrypt the VoIP traffic.

      Same for remote printers - some organizations would want to encrypt the traffic in transit.
Add comment