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

[Chu, Yi [NTK]]

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

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.

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

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.