The following is a new policy proposal that has been posted to the ARIN
Public Policy Mailing List for discussion on that list.
Reminder: RSS feeds of all posts to the Public Policy Mailing List
(PPML) and just postings by ARIN to PPML are available at:
https://www.arin.net/participate/mailing_lists/rss.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
-------- Original Message --------
Subject: RE: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
(PP 121)
Date: Wed, 17 Nov 2010 11:20:32 -0500
From: ARIN <i...@arin.net>
To: arin-p...@arin.net
References: <4cd55b73.9030...@arin.net>
Policy Proposal 121: Sensible IPv6 Allocation for ISPs
ARIN acknowledges receipt of the policy proposal that can be found below.
The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.
The AC invites everyone to comment on the proposal on the PPML,
particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html
Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
-----Original Message-----
From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
Behalf Of Owen DeLong
Sent: Tuesday, November 16, 2010 9:10 AM
To: policy; p...@arin.net PPML
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
2. Proposal Originators
1. name: Owen DeLong
2. e-mail: o...@delong.com
3. telephone: 408-890-7992
4. organization: Hurricane Electric
1. name: David Farmer
2. e-mail: far...@umn.edu
3. telephone: 612-812-9952
4. organization: University of Minnesota
1. name: Andrew Dul
2. e-mail: andrew....@quark.net
3. telephone: 206-395-4004
4. organization: Cascadeo Corp.
1. name: Chris Grundemann
2. e-mail: christopher.grundem...@twtelecom.com
3. telephone: 303.542.6524
4. organization: TW Telecom
3. Proposal Version: 0.8
4. Date: 16 November, 2010 5. Proposal type: M 6. Policy term:
Permanent 7. Policy statement:
Amend section 2 as follows:
Delete section 2.9 (Obsolete)
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 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 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:
(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 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 (a number 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.
(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 = 48-(X+Y)
and 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.
(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.
(c) Provide ARIN a reasonable technical justification,
indicating why an allocation is necessary, including the intended
purposes for the allocation, and describing the network infrastructure
the allocation will be used to support. Justification must include a
plan detailing 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.
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.
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.
8. Rationale:
The current ISP policy for IPv6 allocations is both short-sighted and
insufficient for rational deployments by most ISPs. We have gained
significant operational experience with IPv6 in the time since it was
written and it is clear that current policy is driving many ISPs to
choices of excess conservatism that will eventually harm innovation in
the consumer space.
Under the proposed policy, the entirety of the ARIN region can still be
numbered in no more than 2 /12s (quite probably 1). There are still 506
/12s free within the current /3. It is unreasonable to shoot ourselves
in the foot with address scarcity thinking so early into the IPv6
deployment. This policy seeks to strike a more reasonable and
harmonious balance of the goals stated in NRPM 6.3.
The lower bound of /36 is intended to facilitate extremely small ISPs
getting a smaller block if they do not need to support more than ~4000
customers. It is hoped that the board will take subsequent action to
adjust the fee structure to eliminate the $1,000/year price hike for
those extremely small ISPs. These ISPs can, of course, get a /32 if
they wish.
The intent of section 6.5.4 is to create and preserve parity between
the requirements for LIR->End User and ARIN->End User policies. This
section presumes that 6.5.8 has already been modified as described in
draft policy 2010-8.
Some examples of determining the size of block for which an
organization is eligible:
Bill's Bait, Sushi, and IP Transit:
Largest serving site: 200 end sites
Number of serving sites: 5
200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 *
0.75), so, round up to 4096 (12 bits)
5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75),
so, no further round up. 16 (4 bits)
48 - (12+4) = 32 -- This organization could receive up to a /32.
Lee's Rural Internet, Inc.
Largest serving site: 1024 end sites
Number of serving sites: 30
1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072
(4096 * 0.75), so 4096 (12 bits)
30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 *
0.75), so, 256 (8 bits)
48 - (12+8) = 28 -- This organization could receive up to a /28.
Paul's Mega Metro ISP, LLC
Largest serving site: 3,500 end sites
Number of serving sites: 140
3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072
(4096 * 0.75), so, round up to 65,536 (16 bits)
140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 *
0.75), so, 256 (8 bits)
48 - (16+8) = 24 -- This organization could receive up to a /24
PON's CMTS mega DSL Corp.
Largest serving site: 30,000 end sites
Number of serving sites: 700
30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 <
49,152 (65536 * 0.75), so, 65,536 (16 bits)
700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072
(4096 * 0.75), so, 4,096 (12 bits)
48 - (16+12) = 20 -- This organization could receive up to a /20.
Sizing table:
Units Round-up Bits
0-11 16 4
13-191 256 8
192-3,071 4,096 12
3,072-49,151 65,536 16
49,152-786,431 1,048,576 20
9. Timetable for implementation: Immediate
END OF TEMPLATE
_______________________________________________
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (ARIN-announce@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.
