[arin-ppml] A modest proposal for IPv6 address allocations

[bmanning at vacation.karoshi.com]

 can you say,,,  A. B. C....

--bill


On Sat, May 30, 2009 at 02:11:38PM -0500, Scott Leibrand wrote:
> I think this could be a good framework for a serious simplification of 
> our IPv6 policy.  Not sure about all the details, but I like the fact 
> that we'd be able to do away with the ISP/end-user distinction, make it 
> easy to get a /48, and provide a simple growth path for the most common 
> cases...
> 
> -Scott
> 
> William Herrin wrote:
> >So here's a crazy plan:
> >
> >A. The first IPv6 allocation from ARIN is always a /48. To justify it,
> >you need to be multihomed. There are no other qualifications. The /48
> >will be allocated from a pool from which only /48's are allocated.
> >
> >B. The second IPv6 allocation from ARIN is always a /32. To justify it
> >you need to demonstrate that you've efficiently used the /48 for some
> >reasonable definition of efficient, that you've implemented SWIP or
> >RWHOIS for your downstream assignments and that you will run out of
> >space in the /48 within one year. The /32 will be allocated from a
> >pool reserved for allocating /32's.
> >
> >C. The third IPv6 allocation from ARIN is always a /24. To justify it
> >you need to demonstrate that you've efficiently used the /32, that you
> >will run out of space in the /32 within five years, and you have to
> >first return the original /48 you were assigned. The /24 will be
> >allocated from a pool reserved for allocating /24's.
> >
> >D. There is no fourth IPv6 allocation at this time. It is not
> >presently possible to consume an entire /24 without atrocious waste.
> >
> >What are the consequences of this plan?
> >
> >1. Efficient allocation of IP addresses. Orgs get what they need when
> >they need it and not before without a great deal of guesswork about
> >actual need.
> >
> >2. Efficient utilization of BGP routing slots. No single multihomed
> >org will ever announce more than 2 necessary routes.
> >
> >3. Traffic engineering routes are trivially filterable since any route
> >longer than the published allocation size can be presumed to be
> >traffic engineering, not a downstream multihomed customer, thus you
> >can filter distant small routes with confidence and ease.
> >
> >4. No need to define the difference between ISP and not ISP. Everybody
> >plays by the same rules.
> >
> >5. No complicated analysis for the first allocation. You're either
> >multihomed or you're not. If you're multihomed, you qualify.
> >
> >6. For those who can live within the /48 there are distinct
> >advantages: no swip or rwhois reporting and the generic end-user
> >annual fee instead of the ISP annual fee. Once you're up to a /32, you
> >pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize
> >the /32 requests too closely either.
> >
> >Thoughts? Criticisms?
> >
> >Regards,
> >Bill Herrin
> >
> >  
> _______________________________________________
> 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.