[arin-ppml] Policy Proposal: Open Access To IPv6

[Owen DeLong]

Let's run some realistic numbers into this "unsustainable growth" we  
keep hearing about...

There are, currently, about 32000 actively advertised ASNs
Source: (http://www.potaroo.net/tools/asn16 Figure 11)

The IPv4 routing table is currently somewhere around 285,000 routes  
for an average of
nearly 9 routes per prefix.  The IPv6 reality is much more likely to  
be closer to 3 routes
per prefix (in fact, the vast majority of end-user ASNs should be very  
close to 1 prefix
and the vast majority of ISPs will be reasonably close to that for  
ORIGINating routes,
but, will advertise prefixes from other end-users, obviously).

If we multiply 32000 by 3, we find that we have a 96,000 route IPv6  
BGP table if
we did nothing but convert all the current origin ASNs to IPv6 at an  
expected 3 prefixes
per origin ASN average.

Inevitably, we are going to have to change the routing paradigm, and,  
research is
being done into things like LISP and other ID/Locator separation  
mechanisms.
I think that these will be required for sustained growth, but, to get  
from where we
are now to a workable IPv6 deployment at or near the time of IPv4  
runout (where
workable is defined as IPv6 only users being connected to the internet  
without
being unable to reach vast portions of the currently accessible  
content), I think
it is necessary to move forward with more liberal prefix delegation  
policies
and get IPv6 better deployed.

It will probably take 10 years or more for the IPv6 routing table to  
approach
200k routes, and, by that time, it is likely that new routing  
paradigms will have
some operational experience and acceptance. It's also likely that  
routers will
be able to handle still larger tables by then.  TCAM might even be  
more cost
effective by that time.

IPv6 is not IPv4. We don't need to deal with all the prefix  
fragmentation that
occurred as a result of trying to squeeze IPv4 assignments/allocations  
to the
smallest fit in an effort to conserve IPv4 space.

Indeed, the thing that could drive the greatest bloat in IPv6 routing  
tables over
time is failing to relax allocation policies and creating multiple  
prefixes per
entity all over again.

Owen

On May 30, 2009, at 9:15 AM, Tom Vest wrote:

>
> On May 29, 2009, at 5:58 PM, Matthew Kaufman wrote:
>
>> Leo Bicknell wrote:
>>>
>>> The end user policy gives out /48's.  If we want folks to get a
>>> network they can play with in their garage, let's do it under the
>>> end user policy.  This policy proposal affects the ISP section,
>>> giving out /32's for the express purpose of assigning /48's to other
>>> entities.  Let's leave it for folks who are really ISP's, and really
>>> providing services to others.
>>>
>> Ah. "Folks who are really ISPs". This is as bad as the com-priv  
>> list in 1992... We *don't know* who is/will be "an ISP". A school  
>> district providing service to all its schools? A corporation with a  
>> dozen subsidiaries around the world? A guy in his garage who gives  
>> away free wireless to his neighborhood?
>>
>> Really there shouldn't even *be* a distinction. If you need a / 
>> whatever of IPv6 and can write a convincing letter to that effect,  
>> you should be able to get at least that much unique IPv6 space.  
>> Whether it can be routed now or in the future is really between you  
>> and whichever transit provider you choose *should you even need  
>> external connectivity*.
>
> Unfortunately, distinctions of some kind are unavoidable as long as  
> the carry capacity of the routing system is finite, and jointly  
> produced by independent routing services providers. If IPv6  
> allocation policies cause, or simply facilitate/accelerate the  
> unsustainable growth of routing system requirements, then some other  
> mechanism will have to emerge to mitigate that risk. IPv4 allocation  
> policies have provided a flexible, transparent, limiting effect on  
> the growth rate for routing requirements by making aggregation not  
> only possible, but commonplace. In order to make aggregation  
> *possible*, there must be some kind of eligibility test for  
> justifying an institution's claim to a "top-level" role in the  
> routing system, i.e., as an aggregator or an independent. In order  
> to make aggregation *likely*, it's prudent to define those  
> eligibility criteria in a way that aligns the aspiring top-level  
> routing system participant's incentives with the continued sustained  
> growth of the routing table -- e.g., with "needs" related criteria  
> that demonstrate that the entity has invested real money in real  
> factors (hardware, network capacity, etc.) that can generate value  
> only as long as routing works, and that would be at risk of becoming  
> worthless if the routing system becomes unmanageable or fails  
> altogether.
>
> Since independents are by definition non-aggregatable, there needs  
> to be some other (probably arbitrary) criterion to limit their  
> absolute numbers, e.g., a steep up-front fee. And in order for the  
> whole arrangement to be sustainable over time, there must be a  
> clear, fair, and widely accepted mobility path for customers to  
> become providers, or "independents", and vice versa. To be  
> sustainable, everybody must have a clear "out" -- one that is clear  
> both to insiders and outsiders.
> You don't want to be aggregated, fine, go make some investments that  
> demonstrate that you've got chips in the same routing services game  
> that the rest of us are playing, and you can get address resources  
> of your own under community-defined policies. You just need to be  
> independent? Fine, then pay this sizable, community-defined fee that  
> demonstrates that your need is of roughly the same magnitude as the  
> burden that "just need to be independents" like you impose on those  
> who are playing by the rules of routing system sustainability. Don't  
> want to pay that fee either? Okay, here are some operators that can  
> provide you with aggregatable address resources bundled with routing  
> services...
>
> Even if the quantity of usable IP addresses were literally infinite,  
> it would prudent to think hard before dumping needs-related  
> allocation criteria. Because if/when this arrangement is abandoned  
> at the point of IP address distribution, something similar will just  
> have to be recreated at the level of routing service provision.  
> Unfortunately, at that level there won't be an "out" for anybody --  
> there's no credible way to tell an aspiring new entrant "fine, just  
> go build your own global-scale IP transit system."
>
> We like to remind ourselves that routing decisions are the absolute  
> sole prerogative of individual operators, but there are some  
> circumstances in which that would likely be more of a problem than a  
> point of honor. To date, the inter-domain routing system has been a  
> global scale "cooperative undertaking" -- but the only material  
> difference between a "cooperative undertaking" and a "collusive  
> cartel" is the non-discriminatory, non-adversarial, openness of that  
> system to new players. Absolute sovereignty over routing decisions  
> has no downside as long as somebody else (e.g., the address  
> allocator) guarantees market openness. But if/when that ceases to be  
> true, you're on the hook. You don't like "distinctions" applied at  
> the level of address allocation, fine -- what kind of distinctions  
> are you going to impose on aspiring customers who want you to  
> announce their PI prefixes? What kind of distinctions do you expect  
> will be imposed on your announcements by upstream providers? How are  
> you going to justify your own routing service rationing criteria to  
> critics, because there are always critics...?
>
> TV
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.