[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
Charles O'Hern
charles at office.tcsn.net
Tue Nov 16 15:07:29 EST 2010
I'd like to thank these gentlemen for including love for the x-small ISPs out there. We love you guys.
Question, section 6.5.2.1 (d) dealing with End Sites larger than /48, says "(they shall) count as the appropriate number of /48s that would be assigned under that policy." is that
number to be counted towards the total number of End Sites that is then rounded up to the next nibble boundary? Or should the End Site assignment be on the nibble boundary (16
/48's, 256 /48's, etc.) before adding to the total number of end sites per serving site?
Some minor language suggestions included inline below. No change in meaning is intended. The only intention is to make meaning more clear and language more precise. Please let
me know publicly if my suggestions imply that I'm misunderstanding your meaning. I noted my edits with pound (#) signs, hopefully facilitating visibility.
On 11/16/10 6:09 AM, Owen DeLong wrote:
> 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: owen at delong.com <mailto:owen at delong.com>
> 3. telephone: 408-890-7992
> 4. organization: Hurricane Electric
>
> 1. name: David Farmer
> 2. e-mail: farmer at umn.edu <mailto:farmer at umn.edu>
> 3. telephone: 612-812-9952
> 4. organization: University of Minnesota
>
> 1. name: Andrew Dul
> 2. e-mail: andrew.dul at quark.net <mailto:andrew.dul at quark.net>
> 3. telephone: 206-395-4004
> 4. organization: Cascadeo Corp.
>
> 1. name: Chris Grundemann
> 2. e-mail: christopher.grundemann at twtelecom.com <mailto:christopher.grundemann at 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 ###from the containing block### by the total number of provider assignment units _contained in the larger block_. 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 , 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
>
>
>
>
>
>
> =
>
>
>
>
>
> _______________________________________________
> 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.
--
Charles O'Hern
Network Operations
TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000 1-(800) 974-DISK
http://www.tcsn.net abuse at tcsn.net
More information about the ARIN-PPML
mailing list