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

[Scott Leibrand]

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