Thus spake "Per Heldal" <[EMAIL PROTECTED]>
On Mon, 2007-07-09 at 10:05 -0500, Stephen Sprunk wrote:
> * ULA-C/G are NOT ment to be used on internet
OTOH, there's no way for the IETF or RIRs to stop it from happening. I'm
not saying it will, but it is irresponsible to claim it won't when
there's
no mechanism to enforce that.
<sarcasm>
What is the mechanism to force operators to carry ULA prefixes?
</sarcasm>
Money.
Sooner or later, we're going to run out of IPv4 space. Let's say Ebay
hadn't been able to get their PIv6 /41. The only other viable way they'd be
able to reach all of the new IPv6-only eyeballs is to use ULA-C/G addresses.
The only way ISPs would be able to give their eyeballs access to that
content is by accepting that route. Voila, ULA-C/G becomes the de facto PI
space.
Note that this scenario is one of several that caused ARIN to pass its PIv6
policy last year.
Until such mechanisms are in place ULA-prefixes are likely to be
rejected by the majority of transit operators. ULA-blocks split in their
individual /48s (due to incompetence, accident or malice) won't fit in
any current or near-future routing hardware nor is there a reliable
mechanism to manage exceptions on a mass-scale.
Routers in the DFZ are limited by the number of slots available, not by the
length of the prefixes. Routers don't care whether they've got a million
/32s or half a million /32s and half a million /48s.
PI /48s do work just fine in the DFZ. There's no reason why ULA-C/G(/L)
/48s wouldn't work just as well. As Jeroen showed, some ISPs can't even be
bothered to filter 10/8 from the DFZ and that doesn't even do anything
useful due to collisions. Why are we expecting they'll filter ULA space
much better, or even at all -- just because the IETF asked nicely?
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
