[arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs - Last Call
Leif Sawyer
lsawyer at gci.com
Thu Apr 21 18:09:21 EDT 2011
+1
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steve Howard
> Sent: Thursday, April 21, 2011 12:31 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-2011-3: Better IPv6 Allocations
> for ISPs - Last Call
>
> +1
>
> On 04/19/2011 04:03 PM, Randy Carpenter wrote:
> > I have ISP customers who are right on the edge of a /32 being not
> > enough for any kind of expansion. (~60,000 users, ~20 POPs,
> and plans
> > to expand. They have tried to get larger than a /32 block, but have
> > been denied. Some are putting off IPv6 deployment entirely,
> as they do
> > not want to be in the same situation with IPv6 that they
> are in IPv4
> > (having multiple separate blocks)
> >
> > Some change in policy needs to be done ASAP to encourage
> adoption. I
> > would be happy with whatever is doable that would align on nibble
> > boundaries, and allow for ISPs in this size category to get a /28
> > (which would almost certainly allow them to never need another
> > allocation)
>
> I agree with Randy.
>
> 2011-3 needs to move forward quickly. The delay with 2011-3
> is inhibiting our IPv6 implementation (and I presume elsewhere).
>
> If it is decided to delay 2011-3 or slice it into smaller
> draft policies, we should at least allow /20, /24, and /28's
> to be issued while the proposal finalization process
> continues (assuming the site/end-site requirements as
> outlined in 2011-3 are met). I suggest /20, /24, and /28
> because they are on nibble boundaries and don't seem to be
> affected by item #7 in the changes below.
>
> Thanks,
> Steve
>
>
> ---
> Steve Howard
> Paul Bunyan Communications
> http://paulbunyan.net
>
>
> > -Randy
> >
> > --
> > | Randy Carpenter
> > | Vice President - IT Services
> > | Red Hat Certified Engineer
> > | First Network Group, Inc.
> > | (800)578-6381, Opt. 1
> > ----
> >
> > ----- Original Message -----
> >> 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.
> >>
> >>
> >> _______________________________________________
> >> 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.
> > _______________________________________________
> > 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.
> >
> >
> _______________________________________________
> 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