Re: draft-ietf-ipv6-ula-central-02.txt

[Per Heldal <[e-mail]>]

On Tue, 2007-07-10 at 14:11 -0500, Stephen Sprunk wrote:
> Thus spake "Per Heldal" <[e-mail]>
> > 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.
> 

My understanding was that the dominating argument supporting PI-policies
was simply to match the capability of ipv4 ... bummer. Even back then I
thought the randomness implied with ULA would make it useless for this
purpose.

> > 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.
> 

Since when did anyone argue that pfxlen affects the size of a fib-entry?

> 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?
> 

I'd expect operators to implement relatively aggressive schemes for
prefix-filtering for ipv6 in their own interest to secure an environment
with stable services for their customers. 

FC00::/8 represent 2^40 /48s. With registries handing out unique
prefixes using a random algorithm to choose from the available pool how
do you pick which ones to make exceptions for and still prevent abuse?
The number of exceptions it is possible to handle will eventually be
limited by known factors such as storage for configuration and
route-filter processing capabilities.

Compare that to PI /48s (or even PA /32s) allocated _sequentially_ from
an address-block as recommended by the RIR-community. With allocations
made from a huge block your prefix filters don't need to allow more than
a fraction of that block initially. Maybe it's enough to accept the bit
that is actually used + x% for growth in the immediate future and then
add procedures for frequent updates.

To achieve operational stability it is necessary to make sure the
potential max no of prefixes given maximum fragmentation (within limits
given by RIR-policies) of currently allocated address-space doesn't
exceed the capacity of DFZ hardware, while even leaving space for TE and
local routing. General acceptance of random /48s out of a /8 doesn't fit
well in that picture and it makes ULA-C very different from PI from the
backbone operator perspective. 


//per


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------