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

[michael.dillon at bt.com]

No.

--Michael Dillon

> Is there any interest in seeing this as a formal proposal 
> after adding in the various adjustments some of you have suggested?
> 
> Regards,
> Bill Herrin
> 
> 
> On Sat, May 30, 2009 at 3:05 PM, William Herrin<bill at herrin.us> 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.
> 
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: 
> <http://bill.herrin.us/> Falls Church, VA 22042-3004 
> _______________________________________________
> 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.
>