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

[Matthew Wilder]

No, I am not interested in this proposal.

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.  

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.