[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
Randy Carpenter
rcarpen at network1.net
Tue Nov 16 16:03:17 EST 2010
I think this is a great idea. One thing that concerns me is that the fee structure is going to make it so that IPv6 done in this fashion is going to be very much more expensive. Handing out larger blocks to the same number of LIRs shouldn't have any higher cost to ARIN. If we define all allocations at nibble boundaries, then the fees should be done similarly:
x-small = /36
small = /32
medium = /28
large = /24
x-large = /20
xx-large = /16 and larger
For the LIRs that I deal with, which would be mostly x-small to medium these fees would line up pretty exactly with their IPv4 fees currently.
One other concern is how do we handle non-nibble-boundary allocations that are already out there? Allow them to be returned for a new block?
-Randy
--
| Randy Carpenter
| Vice President, IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (419)739-9240, x1
----
----- Original Message -----
> On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:
>
> > 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?
> >
> Assuming that 2010-8 is adopted as is, the end site would receive a
> nibble boundary assignment and that nibble
> boundary would be counted for purposes of this policy. If, for
> example, such an end site received a /44, then, under
> this policy they would count as 16 /48s fully utilized.
>
> > 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.
> >
> Thanks... Comments inline.
>
> > 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)
>
> OK... I'll incorporate that one in the next revision.
>
> >>
> >>
> >> 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.)
>
> OK... I like this one to... I will incorporate it.
> <snip>
> (There weren't any changes suggested beyond this point).
>
> Owen
>
> _______________________________________________
> 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.
More information about the ARIN-PPML
mailing list