[arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call

Tue Apr 19 15:49:38 EDT 2011

I do not believe that this is ready for last call. Given the complexity of this policy, the significant amount of areas of NRPM that
it is changing, and the fact that the text discussed in PR was not really the text that is being proposed in this last call version
(there were significant changes), not to mention the lack of consensus that we should eliminate H-D ratio, I think that this needs
to come before membership and be discussed in its current (final?) form at the next meeting.

Wes George

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Monday, April 18, 2011 3:06 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call

The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send a revised version of the following draft policy to last
call:

   ARIN-2011-3: Better IPv6 Allocations for ISPs

Changes include:
1. Does not delete section 2.9 (request from staff, no impact on policy
meaning)
2. Limits LIR recursion to a single level and limit subordinate LIRs to /32. (community concern) 3. Restores PAU to the calculation
in 6.5.2.1(c) (from errata slide presented in meeting) 4. Preserves 2010-12 language in new 6.5.3.1 (from errata slide presented in
meeting) 5. Preserves verbiage allowing ISPs to allocate to their own internal infrastructure in 6.5.4.1 (from errata slide
presented in meeting) 6. Adds a statement to delete current NRPM 6.9 (from errata slide presented in meeting) 7. Adds language to
limit initial allocations to no more than a /16
(6.5.2.1(b)) and to limit subsequent allocations to no larger than a /12 (an organization may apply for additional /12s, but, no
single allocation larger than a /12 can be made at one time) (6.5.2.1(e)) (community concern)

Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for
2011-3 will expire on 2 May 2011. After last call the AC will conduct their last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Draft Policy ARIN-2011-3
Better IPv6 Allocations for ISPs

Version/Date: 18 April 2011

Policy Statement:

Amend section 2 as follows:

Replace section 2.10 with the following:

2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a
single tenant within said structure (a single customer location).

Add the following:

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

2.13 When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP
assigns to end sites (recommended /48).

2.14 The term utilized shall have the following definitions when applied to IPv6
policies:

(i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site.

(ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the
containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100,
for a /36 3072/4096 * 100 = 75% utilization)

Replace sections 6.5.1 through 6.5.3 with the following:
6.5.1 Terminology

(a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both
meanings.

(b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly
divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.)

6.5.2 Initial Allocations to LIRs
6.5.2.1 Size

(a) All allocations shall be made on nibble boundaries.

(b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more
than a /16 initial allocation.

(c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized
nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest
single serving site using no more than 75% of the available addresses.

This calculation can be summarized as /N where N = P-(X+Y) and P is the organization's Provider Allocation Unit X is a multiple of 4
greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site.

(d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in
6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy.

(e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same
policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in
determining the block sizing for the parent LIR.
LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate
LIRs which need more than a /32 shall apply directly to ARIN.

(f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine
the largest IP address block to which the LIR is entitled.

6.5.2.2 Qualifications
An organization qualifies for an allocation under this policy if they meet any of the following criteria:

(a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP
allocation under current criteria.

(b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.

In either case, they will be making reassignments from allocation(s) under this policy to other organizations.

(c) Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the
intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification
must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods,
with a minimum of 50 assignments within 5 years.

6.5.3 Subsequent Allocations to LIRs

(a) Where possible ARIN will make subsequent allocations by expanding the existing allocation.

(b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be
entitled to a subsequent allocation.

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

Renumber/move the second paragraph of existing section 6.5.2.1 to 6.5.3.1.

For reference, this would become:
6.5.3.1 Subsequent Allocations for Transition Subsequent allocations will also be considered for deployments that cannot be
accommodated by, nor were accounted for, under the initial allocation. Justification for the subsequent subnet size will be based on
the plan and technology provided with a /24 being the maximum allowed for a transition technology.
Justification for transitional allocations will be reviewed every 3 years and reclaimed if they are no longer in use for
transitional purposes. All such allocations for transitional technology will be made from a block designated for this purpose.

(This paragraph comes from 2010-12 which was adopted after this draft policy was written).

Replace section 6.5.4 with the following

6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the
requirements in 6.5.8.1 do not apply.

6.5.4.1 An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.

Add the following to 6.5.7

LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may
receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their
prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber
and return.

Delete section 6.9

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6753 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110419/34f31d83/attachment.p7s>