[v6ops] Re: IPv6 PI automatically delegated by RIRs

["[e-mail]" <[e-mail]>]

Hi Nick,

IPv6 PI prefixes have 2 beneficial aspects:
a) Having stable addresses.
b) Allowing your prefix to be announced.

The automatically delegated IPv6 PI has the following benefits
1) Having stable addresses that avoid collisions, renumbering, etc. So basically, avoid using ULAs. You could still use NPTv6, but with your own space.
2) Allowing multihoming for those that need it and are happy using their own IPv6 PI and NPTv6.
3) Allowing multihoming for those that prefer to not use NPTv6, but announce their own prefixes, probably in a very simple way, without path selection, prefix manipulation/filtering, etc.

Apart from that:
4) Bigger organizations, probably the same ones that today to IPv4 PI multihoming in the traditional way, announcing their own prefixes, can still keep doing the same IPv6 PI as they do today - this automatic protocol is not for them, they could use it, but is not the target.

Note that 1 & 2 are the same as when organizations that have internally IPv4 public addresses, don’t announce them. Probably not many right now because the business created transferring them with the scarcity.

What I’m trying to avoid is using NPTv6 with ULAs, because that’s a non-return path. We learnt the lesson with IPv4 NAT, let’t avoid repeating mistakes as much as possible. If the problem is that our definition of IPv6 PI doesn’t fit for this (I don’t think so) happy to use an alternative name, but considering the IPv4 cases I don’t think is different. May be in different RIRs policies mandate or not announcing it, and that could need a clarification or a policy amendment if it is mandatory that announcement.

What we achieve with something like this is, in the future, if an organization that is today choosing 1 or 2, wants to move to 3 (or even 4), don’t need to renumber, with very often is a big pain. Also, if we find a better solution for improving/replacing BGP that doesn’t present today's scalability issues, we can just remove NPTv6, still no need to renumber.

Hopefully is more clear now.

Regards,
Jordi

@jordipalet


> El 11 may 2026, a las 11:19, Nick Hilliard <[e-mail]> escribió:
> 
> [e-mail] wrote on 10/05/2026 11:32:
>> I don’t think there will be many residential, SOHO or SMEs that will announce their IPv6 PI, and even if this happens, it will be very slow and progressive. Also see my question to Gert approach with sending default routes to the upstreams. So the scalability that we need for BGP routers is much smaller and sustainable at our own pace.
> 
> Hi Jordi,
> 
> I'm not sure I'm fully understanding you here.  The whole point of PI address space in this context is to allow bgp multihoming. I.e. announcing the same address block via multiple upstream providers, which is to say, effectively full deaggregation of these PI blocks, most likely with multiple upstream paths (unless your network is simplistic / single homed).
> 
> This is deeply and fundamentally incompatible with route aggregation of the sort you're suggesting.
> 
> Nick
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.