[ppml] Revising Centrally Assigned ULA draft

[Owen DeLong]

On Jun 18, 2007, at 11:34 AM, Leo Bicknell wrote:

> In a message written on Mon, Jun 18, 2007 at 11:09:17AM -0700,  
> David Conrad wrote:
>>> Here's the simple problem, you give up all aggregation day one.
>>
>> Not really.  The fact that PI /48s are available does not
>> automatically mean everyone must obtain them.
>
> Everyone, no.  However, would you not agree a lot of people who
> don't try for PI today because it's hard/complicated/expensive would
> be more inclined to get it if it were as easy as filling out a web
> page and sending in a check for $100?
>
Yes... However, this is not necessarily a bad thing...
>> a) huh?  Last I checked, there were 800 IPv6 prefixes being routed
>
> Entirely the wrong metric.  We're in a start-up mode.  Since we're
> likely to see a relatively full transition to IPv6 in under 5 years,
> looking at the start up figure now is worthless.  There will be
> somewhere between the number of AS's allocated and the number of
> current IPv4 routes in the DFZ in the future IPv6 DFZ, and that's
> the interesting number.
>
Yep... Probably around 60,000.  This is 1/4 of the current routing table
size.

>> b) I have been told that folks from both Juniper and Cisco have
>> stated publicly that they can easily meet short term routing
>> requirements and have no concerns about meeting longer term
>> requirements.
>
> And yet, the major operators keep standing up and telling the RIR
> community it's BS.  I think there are three major factors why the  
> two do
> not intersect:
>
> 1) Operators want to hold on to legacy hardware longer than they
>    probably should, so in many cases are constrained by 2-3
>    generations back in routing gear.
> 2) Vendors believe that since their current product, introduced last
>    month can do the job that operators should just swap out their  
> entire
>    network in the next 6 months and be happy.
> 3) Customers are pushing for technologies like Layer 3 VPN's which are
>    eating up routing slots in the new wizbang hardware far faster  
> than DFZ
>    growth.
>
All of those things are probably true.  Still, the fact remains that  
just because
the RIR issues space does not require ISPs to route it.  The ISPs  
have gotten
a free ride on the RIRs performing the routing police role in IPv4.   
They've
perhaps even become used to that fact.  However, the fact is that  
role was
given to the RIRs because of the need to balance that issue with the  
issue
of address space conservation.  In IPv6 that need no longer exists.  
As such,
the role of Routing Table Police needs to transition back to the ISPs  
who
are best suited to address the issue.

>> Even if the RIRs started paying people to take IPv6 prefixes, you
>> wouldn't see a jump "jump by at least one order of magnitude
>> overnight, perhaps closer to two orders of magnitude."  The fact that
>> someone has address space does not mean ISPs must route it.
>
> I disagree.  If we put a policy like this in place before the rush
> to get IPv6 space really hits in a big way I think you would find
> the IPv6 DFZ would surpass the IPv4 DFZ in a matter of 2-3 years
> after the rush starts.  I'm not sure that's a problem if it happened
> slowly, but if over 2 years ISP's go from having to route 200,000
> IPv4 prefixes to 200,000 IPv4 + 400,000 IPv6, that alone will be
> quite painful.  Step functions are hard on budgets and people.
> I think in the 5-10 year timeframe you would easily be one order of
> magnitude larger than our current predictions for DFZ growth.
>
Nothing in the RIRs issuing 400,000 IPv6 prefixes requires ISPs to
route them.  As such, I think it is up to the ISPs to decide which
of those prefixes they are willing to route and which ones they are
not.
>> More to the point, the allocations of /19s and /20s (and shorter)
>> could be seen as egregious and unconscionable wastes of vast tracts
>> of address space.
>
> On this point we are in violent agreement.
>
Yep.

In fact, I'm half tempted to propose policy that makes the justification
documents for any IPv6 allocation or assignment shorter than /24
subject to public review.

Owen