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

[Joe Maimon]

Matthew Wilder wrote:
> No, I am not interested in this proposal.

I think a proposal should be formulated, if for the only reason that we 
are already debating it.

> 
> This could be a catastrophic policy when paired with the ambiguity of 6.5.2.1 (Subsequent [IPv6] Allocation Criteria).  This section states:
> 
> "Subsequent allocation will be provided when an organization (ISP/LIR) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments."
> 
> If the majority of sites receive /48 assignments, I can only assume that would imply a 100% utilization of /56 assignments within that /48.  That in turn implies that any time you assign any subnet to a site (could be /40, maybe even /32) then that address block is 100% utilized as far as this criteria is concerned.  

This is a problem whether or not such a proposal exists, because if you 
can justify your utilization quicker with /48 per customer, you would be 
neglecting your own interests not to do so.


> 
> Adding the proposed policy into the mix with 6.5.2.1 could help a lot of organizations to get a /24 mighty fast.  I doubt that is the intention of the proposal, but any proposal needs to take loopholes and abuses into consideration.
> 
> Regards,
> Matthew Wilder
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
> Sent: Thursday, June 04, 2009 11:50 AM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] A modest proposal for IPv6 address allocations
> 
> Yes.
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
>> Sent: Wednesday, June 03, 2009 3:02 PM
>> To: ppml at arin.net
>> Subject: Re: [arin-ppml] A modest proposal for IPv6 address 
>> allocations
>>
>>
>> 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.
>>>
>> _______________________________________________
>> 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.
>>
> _______________________________________________
> 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.
> _______________________________________________
> 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.
> 
>