IPv6 Provider Independent Addresses

If you want your network to remain multihomed when the Internet migrates to IPv6, you need your own Provider Independent (PI) IPv6 prefix. That’s old news (I was writing about the multihoming elephant almost two years ago), but most of the IT industry managed to look the other way pretending the problem does not exist. It was always very clear that the lack of other multihoming mechanisms will result in explosion of global IPv6 routing tables (attendees of my Upcoming Internet Challenges webinar probably remember the topic very well, as it was one of my focal points) and yet nothing was done about it (apart from the LISP development efforts, which will still take a while before being globally deployed).

To make matters worse, some Service Providers behave like the model citizens in the IPv6 world and filter prefixes longer than /32 when they belong to the Provider Assigned (PA) address space, which means that you cannot implement reliable multihoming at all if you don’t get a chunk of PI address space.

I was always focusing on the technical aspects of the problem; Greg Ferro added the business aspects in his The Importance of Provider Independent IPv6 Addressing post. Characteristically, he was unable to resist another Service Provider-focused rant, triggering a knee-jerk response from Russell Heilling (which resulted in another great post on the same topic, this time from the Service Provider perspective).

Anyhow, things are not as easy as Greg would like them to be. You have to satisfy certain requirements to get PI IPv6 prefix and while I’m positive Greg’s customer will always be in that group, smaller organizations that used NAT-based multihoming today will be left in the dark in the IPv6 world… and there is no good answer we could give them apart from “Use ULA addresses internally to reduce the eventual renumbering pain.”

Due to changes to source IPv6 address selection algorithms made after this blog post was written in 2011, it’s impossible to use ULA addresses in dual-stack networks.

More Information

To learn more about early IPv6 pitfalls and the first steps you have to take to prepare for the brave new world, watch the Enteprise IPv6 – the First Steps webinar.

Revision History

2023-03-10
Added a note about ULA uselessness

Latest blog posts in Site and Host Multihoming series

6 comments:

  1. Which ISPs have a max prefix length of a /32? This page:
    http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers
    shows only /48.

    I think most ISPs at this time are board with a /48.

    Frank
  2. @Frank: I think that /48 is for prefixes from PI space. Like Ivan said, many (most?) ISPs won't accept routes longer than /32 from PA space, which makes sense.

    @Ivan: AFAICT the simple desire to multihome provides justification to the RIRs for at least a /48. A couple of the docs I've found at RIPE suggest that this decision was made specifically to lower the barrier to adoption of IPv6 for smaller organizations.
  3. @Stretch: you're correct. ARIN has substantially the same policy (although it's a bit more convoluted to find) - you have to "demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user", which usually means (at least) having an AS.

    The IPv6 PI allocation policy is (almost?) identical to IPv4 PI allocation policy (in ARIN's case, an amendment to the IPv6 policy states you can get PI IPv6 prefix if you would be eligible to get IPv4 PI prefix).
  4. It would be really useful to know what ISPs are filtering on /32 boundaries for PA space - are you aware of a list, or documentation from such ISPs?

    I've been trying to find such a list/document, and have even asked some ISPs, but none (of the ones I have asked) have any policies in place yet.

    I would really appreciate more information on this - as I know some places which are hoping to split their PA /32 into /40s (or longer).
  5. in my humble opinion, the IPV6 addressing hierarchy must be preserved in order to maintain the manageability of the global routing table. LISP looks promising, although there are still some technical issues yet to be solved. there are already beta networks running on LISP, but not much heard on the results and reviews. From your opinion, will the global Internet community accepts LISP? Will it be a reality in 2-3 years from now?
  6. The IPv6 addressing hierarchy and corresponding aggregability is a lost battle. We'll either deploy a kludge like LISP or the global BGP routing tables will explode.
Add comment
Sidebar