[arin-ppml] Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement - revised

Mon Oct 1 15:57:06 EDT 2012

On Oct 1, 2012, at 11:57 , "Chu, Yi [NTK]" <Yi.Chu at sprint.com> wrote:

> Owen:
> Sorry if I missed prior discussions on the proposal.  I have a few concerns outlined below.
> 
> 1.  As we know, sites come with different sizes.  The approach is a good engineering guide, but would be much too open to abuse as a policy.  (For instance, someone could have one site big enough for a /36.  But does that mean all his 100 other sites get /36 as well?)
> 

Yes... That is current policy, so I'm not sure where the change is problematic.

> 2. safeguard at /12 is a very  scary thought.  I feel it is way too big.  /12 only left us with 10 bits (1k) to work with.  There is only four thousand /12, period.   At the LIR level, we know thousand is not a big number at all, with our experience of v4.   And who can justify a /12 and why?  I could give everyone of the 6 billion residents on the planet a /48 and would only barely use up one /15.
> 

First, your math is off by a factor of 2. A /12 leaves only 9 bits for the RIR to work with which is is 512, not 1k to work with. However, the number of organizations that could possibly qualify for /12s is probably much closer to 10 than it is to 100 (and may even be less than 10). If we happen to burn through 512 /12s in the less than 50 years under this policy, I'll be happy to support a more restrictive allocation policy as soon as that trend becomes evident. I'm sure such a policy can be enacted before the next 512 /12s are released into the free pool and even if that policy turns out to be short sighted, we still have another 5 /3s to try and get it right before we run out of IPv6 space.

> 3.  besides the point on nibble boundaries (which I agree), what other issue/problem the proposal is trying to address?  (no pun intended).
> 

I am not the proposal author, so I'm not sure why this question is directed at me, but, as I understand it, a provider could follow the current policy and find themselves in a situation where they do not have the ability to get additional space in order to grow into additional serving sites even though their current resources are all tied up in existing serving sites. As such, I think it is a reasonable proposal and I support it with the current safeguards.

Owen

> yi
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Wednesday, September 26, 2012 10:27 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement - revised
> 
> Draft Policy ARIN-2012-2
> IPv6 Subsequent Allocations Utilization Requirement
> 
> ARIN-2012-2 has been revised. This draft policy is open for discussion
> on this mailing list and will be on the agenda at the upcoming ARIN
> Public Policy Meeting in Dallas.
> 
> ARIN-2012-2 is below and can be found at:
> https://www.arin.net/policy/proposals/2012_2.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy ARIN-2012-2
> IPv6 Subsequent Allocations Utilization Requirement
> 
> Date: 26 September 2012
> 
> Policy statement:
> 
> 2.14. Serving Site (IPv6) When applied to IPv6 policies, the term
> serving site shall mean a location where an ISP terminates or aggregates
> customer connections, including, but, not limited to Points of Presence
> (POPs), Datacenters, Central or Local switching office or regional or
> local combinations thereof. It does not require the implementation of
> such aggregation in routing, only the implementation of an addressing
> plan that is subnetted along these topological boundaries to support the
> ability to aggregate.
> 
> 6.5.3. Subsequent Allocations to LIRs
> 
> a.      Where possible ARIN will make subsequent allocations by expanding the
> existing allocation.
> 
> b.      An LIR qualifies for a subsequent allocation if they meet any of the
> following criteria:
> 
> * Shows utilization of 75% or more of their total address space
> 
> * Shows utilization of more than 90% of any serving site
> 
> * Has allocated more than 90% of their serving site blocks to serving
> sites, and has sufficient actual utilization at their serving sites to
> continue to justify the block size being utilized for all serving sites
> as specified in section 6.5.2.
> 
> c.      If ARIN can not expand one or more existing allocations, ARIN shall
> make a new allocation based on the initial allocation criteria above.
> The LIR is encouraged, but not required to renumber into the new
> allocation over time and return any allocations no longer in use.
> 
> d.      If an LIR has already reached a /12 or more, ARIN will allocate a
> single additional /12 rather than continue expanding nibble boundaries.
> 
> Original Rationale:
> 
> If you are executing to a long term plan, you should be able to continue
> to execute on your approved allocation and assignment plan regardless of
> the number of regions/groupings you originally planned for. We want to
> promote tie downs on nibbles and long term planning.
> 
> Timetable for implementation: Immediately
> 
> _______________________________________________
> 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.
> 
> 
> ________________________________
> 
> This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
> 
> _______________________________________________
> 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.