Noel Chiappa wrote:
> From: "Stephen Sprunk" <stephen(_at_)sprunk(_dot_)org>
> .. ULA-C/G leaks will not collide with each other. This means that,
> unlike RFC1918 which is _impossible_ for ISPs to route for multiple
> customers, ULA-C/G routes _can_ be routed publicly. Any prohibition
> on doing so by the IETF or RIRs can (and IMHO, will) be overridden by
> customers paying for those routes to be accepted.
Which would argue that the only realistic way to make *absolutely certain*
that IPv6 "private" addresses truly *cannot* be used out in the 'main'
internetwork is to allocate the same ranges of addresses to multiple
parties.
Perhaps, but then we end up with all of the problems associated with
ambiguous addresses, and we lose all of the advantage of IPv6.
Anything else is just PI with a few speedbumps, and a different label.
Maybe, maybe not. In practice, today, not every IPv4 address prefix is
PI. Today, the length of your IPv4 prefix has some influence on whether
your prefix gets advertised. There may not be an absolute boundary, but
there is a barrier nonetheless. So I can certainly imagine that it
would be harder to get ULA prefixes as widely advertised as PA
prefixes. How much harder, I cannot say.
So the speedbumps might be useful. But people wanting to absolutely
forbid any ISP from advertising a ULA prefix will probably be
disappointed. That doesn't bother me, because I don't think it's
necessary to have that absolute prohibition in order for networks to
push back on routing table size and routing complexity.
Sooner or later, routing scalability will be a problem in IPv6. When
that happens, each network will pick some means to decide which prefixes
get advertised within its network and which get filtered. It's not
rocket science to guess that networks will favor their own customers,
the networks with which they have explicit agreements, and the networks
from which their customers derive the most value. That probably puts
most ULAs and PIs fairly far down in the preference list.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf