[arin-ppml] ARIN-PPML Digest, Vol 63, Issue 32
Owen DeLong
owen at delong.com
Wed Sep 29 11:36:17 EDT 2010
Rudy,
The reason for the detailed criteria is to preserve these specific
final addresses in support of IPv6 transition rather than further consumption
under the business as usual rules.
The alternative, of course, is to leave policy as it is, consuming
the few remaining IPv4 addresses under the current system with
virtually nothing set aside to facilitate transition to IPv6 other than
a very limited subset of technologies specified in the existing 4.10.
Owen
On Sep 29, 2010, at 7:49 AM, Rudolph Daniel wrote:
> I cannot support 2010-13 presently because it still seems to me to be overtly complex prone to misunderstanding.
>
> One example: >ISPs can apply for /32s for customers as long as each customer
> > meets the policy's detailed qualification criteria. As an ISP, I may not be too happy imposing detailed qualification criteria which will be a beyond my commercial requirement and may simply frustrate and complicate the process at all levels.
>
> Rudi Daniel
>
>
>
> On Wed, Sep 29, 2010 at 10:33 AM, <arin-ppml-request at arin.net> wrote:
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
> 1. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
> (Hannigan, Martin)
> 2. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
> (Chris Grundemann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Sep 2010 17:55:37 -0400
> From: "Hannigan, Martin" <marty at akamai.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID: <C8C7DC99.11B97%marty at akamai.com>
> Content-Type: text/plain; charset="Windows-1252"
>
>
>
> I oppose this proposal. I think it's destructive; it's complicated and fails
> to establish any leadership and it's divisive; the reservation system and
> classes of requests create significant inequities for all that have need. It
> fails to allow anyone to plan. The end result is that we're going to pit all
> of our members against each other in open markets. Regardless of this
> proposal, that may happen still. When I supported the petition I had hoped
> that we could stretch this remaining space and provide some relief and
> define what's important with regards to continuing to grow the net while we
> transition. That is impossible with this proposal and perhaps impossible
> with any proposal and a single /8[1]. [ The recent CableLabs Draft is very
> interesting FWIW]
>
> This proposal still does not go far enough in offering some level of relief
> to all segments of the industry. I concur with the staff comments related
> and specifically comments related to the complexity.
>
> I did support "the concept" of the reservation system with different terms
> and provider relief with respect to CPE et. Al. The proposal fails to
> explain itself adequately with respect to both and if it were adequately
> explained it may seem less unfair if it were re-written. Transition not be
> without pain and some of us are already challenged by it.
>
> I don't have a suggestion other than a complete rewrite which is why I
> support completely abandoning it.
>
>
> Best,
>
> -M<
>
>
>
> 1. http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00
>
>
>
>
>
>
> On 9/27/10 4:02 PM, "ARIN" <info at arin.net> wrote:
>
> > Draft Policy 2010-13
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
> > version of the draft policy (it's currently at 1.55). It is noted that
> > the time frame for reserves has been reduced from 36 to 24 months in
> > version 1.55.
> >
> > This draft policy is open for discussion on this mailing list and will
> > be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.
> >
> > 2010-13 is below and available at:
> > https://www.arin.net/policy/proposals/2010_13.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
> > September 2010)
> >
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > 1. Proposal Summary (Staff Understanding)
> >
> > This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4
> > block to facilitate IPv6 Deployment?). It sets aside in its entirety
> > the last /8 ARIN receives from the IANA for issuance to networks
> > transitioning to a dual IPv4/IPv6 network rather than the /10 currently
> > cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
> > subject to a global or regional transfer policy) will be added to this
> > transition pool. Under this policy there are four major classes of
> > requestors:
> >
> > - ISPs can apply for /32s for customers as long as each customer
> > meets the policy's detailed qualification criteria.
> >
> > - Any operator can apply for /32s for issuing to devices used to
> > serve-up internet facing content, within the constraints of the defined
> > qualifying criteria.
> >
> > - From the /8, a /10 will be set aside so that any operator can
> > request space for use in infrastructure numbering for the purposes of
> > deploying IPv6. Space can be issued from this /8 for applicants who
> > qualify under ARIN's Micro-allocation Policy (with additional
> > restrictions).
> >
> > - Finally, space can be issued from this /8 for applicants who
> > operate content distribution networks, again, within the context of the
> > policy's qualifying criteria.
> >
> > Organizations can request address space to meet their 3-year needs.
> > Space is allocated/assigned in quarterly installments. After the first
> > quarter, the requestor can only return to ARIN if they have utilized 80%
> > of the most recent assignment, and 90% of past assignments (issued under
> > this policy). The organization must have also assigned all IP addresses
> > issued under the policy to uses that are acceptable under the policy.
> > If the organization fails to meet the utilization criteria for four
> > consecutive quarters, then the policy directs ARIN staff to reduce the
> > amount of space reserved.
> >
> > 2. Comments
> >
> > A. ARIN Staff Comments
> >
> > ? The policy text has become very complex and complicated and the
> > general community will have a very hard time understanding the concepts
> > and criteria proposed within the policy.
> >
> > ? It seems to be out of order ? it starts out with reservations
> > before ever mentioning the initial qualifying criteria. The author
> > might want to consider re-ordering to start with the essential
> > qualification criteria first.
> >
> > ? Section 4.10.2 suggests that all allocations made under this policy
> > will initially be made from a 3-year reservation. In light of the
> > imminent depletion of IPv4 address space, it doesn't seem fair to allow
> > some organizations to retain/reserve this valuable resource for up to 3
> > years while others will be denied.
> >
> > ? The policy text in (in 4.10.3) appears to contradict itself, as it
> > first directs staff to remove one quarter's worth of reservation, and
> > then, if the organization continues this practice for three consecutive
> > quarters, remove the organization's reserves completely. Later, it
> > explicitly directs staff to revoke addresses issued under this policy
> > that are used by the organizations for purposes not permitted under this
> > policy.
> >
> > ? This proposal will essentially supplant the recently ratified
> > policy "Waiting List for Unmet Resources". That list will consist of
> > people waiting for resources to be returned or revoked so that ARIN can
> > then reissue them to requestors in need of IPv4 address space. This
> > proposal says that any IPv4 address space that comes back to ARIN
> > immediately goes into the IPv6 transition pool and can only be used for
> > that purpose.
> >
> > ? Under 4.10.4.B5, how would staff be able to verify that x percent
> > of an organization?s content is IPv6 reachable?
> >
> >
> > B. ARIN General Counsel
> > This policy is unlikely to cause any legal issues of any importance.
> >
> >
> > 3. Resource Impact
> >
> > This policy would have moderate to major resource impact. It is
> > estimated that implementation would occur within 6 to 9 months after
> > ratification by the ARIN Board of Trustees. The following would be
> > needed in order to implement:
> > ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
> > delegations for blocks smaller than /24)
> > ? Updated guidelines
> > ? Staff training
> >
> >
> >> -----Original Message-----
> >
> >> From: Owen DeLong [mailto:owen at delong.com]
> >
> >> Sent: Thursday, September 23, 2010 7:26 PM
> >
> >> To: arin-ppml at arin.net List; policy
> >
> >> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)
> >
> >>
> >
> >> Changes:
> >
> >>
> >
> >> 1. Set maximum reservation period to 24 months. This avoids creating
> >
> >> a 4-year reservation by CIDR-rounding 36 month reservations.
> >
> >> 2. Reduced minimum size for 4.10.4(b) to /28
> >
> >>
> >
> >> These changes will make the policy more balanced and reduce the extent
> >
> >> to
> >
> >> which larger organizations could be disadvantaged relative to smaller
> >
> >> smaller organizations if reservations have to be resized.
> >
> >>
> >
> >> The change to a 2-year system resolves an issue with the CIDR-Rounding
> >
> >> where a 36-month reservation is mathematically guaranteed to become a
> >
> >> 48-month reservation. The other alternative was to round-down instead
> >
> >> of
> >
> >> up which would have mathematically converted all reservations to 2
> >
> >> years.
> >
> >> As such, a 2-year reservation system seemed the cleanest and most
> >
> >> straightforward approach.
> >
> >>
> >
> >> Owen
> >
> >>
> >
> >> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
> >
> >> Proposal Originator: Owen DeLong, Chris Grundemann
> >
> >> Proposal Version: 1.55
> >
> >> Date: 23 September 2010
> >
> >> Proposal type: modify
> >
> >> Policy term: permanent
> >
> >> Policy statement:
> >
> >>
> >
> >> Remove section 4.1.8 (Unmet requests) from the NRPM.
> >
> >> Replace the text of section 4.10 in its entirety (including the name)
> >
> >> with:
> >
> >>
> >
> >> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion
> >
> >>
> >
> >> When ARIN receives its /8 IPv4 allocation from IANA under the
> >
> >> global policy titled "Global Policy for the Allocation of the
> >
> >> Remaining IPv4 Address Space" ratified by ICANN Board
> >
> >> on 6 March, 2009, that /8 will form a dedicated pool to
> >
> >> facilitate IPv6 Deployment.
> >
> >>
> >
> >> Addresses returned to ARIN and not subject to a regional or
> >
> >> global transfer policy will be reserved for utilization in the
> >
> >> transition
> >
> >> pool.
> >
> >>
> >
> >> Allocations and assignments from this block must be justified by
> >
> >> IPv6 transition requirements.
> >
> >>
> >
> >> ARIN will use their discretion in determining whether a
> >
> >> particular
> >
> >> application meets the spirit of this policy.
> >
> >>
> >
> >> 4.10.1 Addressing Plan
> >
> >>
> >
> >> Any organization wishing to receive IPv4 addresses through this
> >
> >> policy must submit a detailed addressing plan for any request
> >
> >> that is made containing the following:
> >
> >> (a) Their addressing needs over the entire reservation period
> >
> >> and
> >
> >> (b) Methods of meeting all requirements (requirements are
> >
> >> explained in section 4.10.4.) over the entire reservation
> >
> >> period.
> >
> >>
> >
> >> 4.10.2 Reservation System
> >
> >>
> >
> >> Initially, all space assigned or allocated under this policy will
> >
> >> be
> >
> >> reserved in advance for a maximum period of 24 months, requests
> >
> >> for
> >
> >> shorter reservations will be accepted. The total reservation size
> >
> >> will be rounded up to a CIDR bit boundary.
> >
> >>
> >
> >> Each organization's reservation amount will be divided
> >
> >> into quarterly allotments. Allotments will be rounded up
> >
> >> to a CIDR bit boundary. The final quarterly allotment will
> >
> >> contain only the remaining space from the full reservation.
> >
> >>
> >
> >> An organization may request one reservation under each provision
> >
> >> listed in section 4.10.4. Once a reservation has been satisfied,
> >
> >> another may be requested.
> >
> >>
> >
> >> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool
> >
> >> Depletion
> >
> >>
> >
> >> Reservations will be accepted from the time that this policy
> >
> >> is adopted until the day that ARIN can no longer fill regular
> >
> >> requests from
> >
> >> space allocated to ARIN by IANA. At that time, if necessary, all
> >
> >> reservations
> >
> >> will be reduced by an equal amount to allow them to fit within
> >
> >> the total space available in the transition pool. No reservation
> >
> >> will be reduced lower than the minimum quarterly allotment for
> >
> >> it's category. Each organization may decide whether to adjust
> >
> >> the reservation period or the allotment size (within the stated
> >
> >> range) when reservations are reduced. Organizations must make
> >
> >> this decision within 30 days of announcement and may not alter
> >
> >> their choice once made. Any space added to the transition
> >
> >> pool during this time will cause a final recalculation of
> >
> >> reservation sizes. Once all necessary adjustments are
> >
> >> made, all reservations are guaranteed and the first quarterly
> >
> >> allotment is issued to each org.
> >
> >>
> >
> >> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion
> >
> >>
> >
> >> Reservation requests received after ARIN free pool depletion
> >
> >> as defined in 4.10.2.1 will not be guaranteed. If approved, such
> >
> >> requests will be placed in a queue. As space becomes available in
> >
> >> the transition pool it will be used to provide allotments to
> >
> >> organizations with reservations in the queue on a first-approved
> >
> >> first-served basis. Partially filled allotments will remain at
> >
> >> the
> >
> >> front of the queue.
> >
> >>
> >
> >> 4.10.2.3 Abandonment of Reservation
> >
> >>
> >
> >> Any organization may abandon their remaining reservation at any
> >
> >> time by informing ARIN of their desire to do so. Upon
> >
> >> abandonment,
> >
> >> the remaining space in the reservation will be returned to the
> >
> >> transition pool.
> >
> >>
> >
> >> 4.10.3 Quarterly Requirements
> >
> >>
> >
> >> Organizations with approved reservations and address plans
> >
> >> are entitled to quarterly allotments. In order to receive each
> >
> >> additional allotment, an organization must submit evidence of
> >
> >> compliance with the following sub-sections:
> >
> >> (a) The most recent 4.10 allotment is at least 80% utilized.
> >
> >> (b) All prior 4.10 allotments within the same 4.10.4
> >
> >> category are at least 90% utilized.
> >
> >> (c) All utilization is permitted under the 4.10.4 category for
> >
> >> which it was initially requested.
> >
> >>
> >
> >> For purposes of this computation, space received under each
> >
> >> provision shall be considered separately if an organization has
> >
> >> received resources through multiple provisions.
> >
> >>
> >
> >> If an organization does not meet all obligations in any given
> >
> >> quarter, that organization shall not receive that quarter's
> >
> >> allotment
> >
> >> and shall have their reservation reduced by one quarterly
> >
> >> allotment.
> >
> >> If an organization does not meet all obligations
> >
> >> for three consecutive quarters, that organization forfeits the
> >
> >> remainder
> >
> >> of their reserved block.
> >
> >>
> >
> >> Utilization requirements (a) may be delayed at ARIN's discretion.
> >
> >>
> >
> >> If an organization is using space received under 4.10 in a manner
> >
> >> contrary to 4.10, that organization forfeits their remaining
> >
> >> reservation and may have their entire allocation or assignment
> >
> >> revoked.
> >
> >>
> >
> >> All 4.10. space forfeited, revoked or otherwise reclaimed shall
> >
> >> be returned to the ARIN transition pool.
> >
> >>
> >
> >> 4.10.4 Specific types of transitional uses have specific
> >
> >> requirements:
> >
> >>
> >
> >> (a) An ISP/LIR may request a block no smaller than a /25 nor
> >
> >> larger than a /18 per quarter to be used to provide single
> >
> >> IPv4 /32s to their customers which could justify a /28 or
> >
> >> more of IPv4 under ARIN policies in effect at the time of
> >
> >> IANA depletion.
> >
> >> 1. No customer site may receive more than a single
> >
> >> IPv4 /32 per 1,000 Internet connected hosts upto 8
> >
> >> /32s.
> >
> >> 2. The customer site must not have any IPv4
> >
> >> addresses not issued under this policy.
> >
> >> 3. The customer site must use the /32 to provide
> >
> >> IPv4 connectivity for hosts which have IPv6
> >
> >> addresses with IPv6 connectivity to the ISP/LIR.
> >
> >> 4. The ISP/LIR must demonstrate that it already
> >
> >> provides IPv6 addressing and connectivity to at
> >
> >> least one additional existing customer site for
> >
> >> each /32 requested, up to 90% of all customer sites
> >
> >> served (across all customers).
> >
> >> 5. An ISP/LIR customer which is not large enough to
> >
> >> qualify
> >
> >> under this provision and has no unassigned IPv4
> >
> >> addresses
> >
> >> may receive an appropriate number of /32s from their
> >
> >> upstream provider for reassignment to their customers
> >
> >> under the terms of 4.10.4(a).
> >
> >> 6. A customer site which terminates multiple connections
> >
> >> from the same provider on separate routers may
> >
> >> qualify
> >
> >> for one /32 per unique router with a direct
> >
> >> connection to
> >
> >> the provider, up to a total of 8 /32s.
> >
> >> 7. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >>
> >
> >> (b) An ISP/LIR or End user organization may request a block
> >
> >> no smaller than a /28 and no larger than a /18 per quarter
> >
> >> to provide single IPv4 /32s to each physical server used
> >
> >> to provide Internet reachable content.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. No server may receive more than a single IPv4 /32
> >
> >> under this provision.
> >
> >> 3. The server must have IPv6 addresses with IPv6
> >
> >> connectivity (must be dual-stacked).
> >
> >> 4. The receiving organization must demonstrate that it
> >
> >> already provides IPv6 addressing and connectivity
> >
> >> to at least one additional existing server
> >
> >> (organizations which can show 100% dual stack are
> >
> >> exempt from this requirement).
> >
> >> 5. The receiving organization must IPv6 enable all of
> >
> >> their content on the following schedule:
> >
> >>
> >
> >> + 25% of content IPv6 reachable within six
> >
> >> months of receiving their first addresses
> >
> >> under this policy
> >
> >> + 50% of content IPv6 reachable within one year
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 75% of content IPv6 reachable within 18 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 90% of content IPv6 reachable within 24 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> 6. A network providing SSL terminations for applications
> >
> >> or content acceleration may receive a /32 for each
> >
> >> distinguished name by following all requirements in
> >
> >> this provision, substituting "distinguished name" for
> >
> >> "server."
> >
> >> 7. Networks using these addresses for authoritative
> >
> >> DNS servers can use 2 /32s per 1,000 authoritative
> >
> >> domains served up to 128 /32s total per organization.
> >
> >> 8. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >> (c) An ISP/LIR or End user organization may request a block no
> >
> >> smaller than a /29 and no larger than a /25 per quarter for
> >
> >> purposes relevant to their ability to deploy IPv6.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. Space issued under this provision must be used to
> >
> >> provide the required public IPv4 address(es) for
> >
> >> transitional technologies operated by the recipient
> >
> >> organization.
> >
> >>
> >
> >> Specific examples of permitted uses are:
> >
> >> a. Large scale or "Carrier Grade" NAT
> >
> >> b. NAT-PT
> >
> >> c. DS-LITE/B4/AFTeR
> >
> >> d. IVI
> >
> >> e. DNS64 or other transitional DNS enablers
> >
> >> f. Other technologies of similar purpose
> >
> >> and scope.
> >
> >>
> >
> >> 3. A /10 from the final /8 shall be reserved for
> >
> >> issuance
> >
> >> under this provision. In no case shall any addresses
> >
> >> from this /10 be issued for any purpose outside
> >
> >> of 4.10.4(c).
> >
> >>
> >
> >> (d) Applications which would qualify for IPv4 under section 4.4
> >
> >> of
> >
> >> the NRPM (critical infrastructure) may qualify for IPv4
> >
> >> space
> >
> >> under this policy if they meet the following criteria:
> >
> >> 1. The critical infrastructure to be numbered must also
> >
> >> have IPv6 addresses and must provide all services
> >
> >> provided on IPv4 over IPv6 on the same time table.
> >
> >> 2. Assignments under this provision shall be the
> >
> >> smallest technically feasible size for the critical
> >
> >> infrastructure in question.
> >
> >> 3. The total space assigned under this provision shall
> >
> >> not
> >
> >> exceed the equivalent of a /14.
> >
> >>
> >
> >> </pre>
> >
> >>
> >
> >> <pre>
> >
> >>
> >
> >>
> >
> >> Rationale:
> >
> >>
> >
> >> The current terminology in section 4.10 is vague and could allow a
> >
> >> variety of interpretations which could lead to allocations or
> >
> >> assignments being made to ISPs intending to misuse the space for
> >
> >> general deployment by using IPv6 overlay technologies as a "IPv6
> >
> >> deployments" requiring IPv4 space for transition. For example, the
> >
> >> current policy could be interpreted to enable an ISP to require IPv4
> >
> >> addresses for all IPv6 customers to roll IPv6 out as 6rd to customers
> >
> >> who would be otherwise unable to get IPv4 space. This is clearly
> >
> >> outside of the original intent of the proposal which created 4.10 (6rd
> >
> >> was not yet envisioned at the time that was written). This proposal
> >
> >> seeks to clarify that intent and tighten up the requirements for
> >
> >> organizations seeking to get space from this limited final resource so
> >
> >> that it truly is available to facilitate transitional technologies.
> >
> >>
> >
> >> Additionally, there are a number of community segments that are not
> >
> >> well served by the original intent of 4.10 and several community
> >
> >> members requested a mechanism for providing a certain amount of
> >
> >> certainty with regards to obtaining space at the end. While it would be
> >
> >> impossible to guarantee organizations all the space they need as runout
> >
> >> is upon us, this policy seeks to provide a way for organizations to
> >
> >> sign up for and receive a reservation from the final space
> >
> >> proportionate to their need. The policy also includes guidelines
> >
> >> intended to ensure that this vital community resource is given only to
> >
> >> organizations working towards a smooth transition to IPv6 to the
> >
> >> benefit of the full community.
> >
> >>
> >
> >> In order to meet these needs, this policy has become very complex. It
> >
> >> is an unfortunate artifact of the complex issue it seeks to address. A
> >
> >> great deal of effort has been made to simplify the policy as much as
> >
> >> possible, and, special thinks go out to several members of the
> >
> >> community for their assistance in this matter.
> >
> >>
> >
> >> One provision in this draft policy calls for utilization criteria which
> >
> >> may be waived by ARIN staff discretion. The intent of this clause is to
> >
> >> allow staff to avoid penalizing an organization for successful address
> >
> >> conservation efforts.
> >
> >>
> >
> >> Runout is upon us. IANA will run out of the IANA free pool and issue
> >
> >> the last /8 this policy seeks to regulate before the next ARIN public
> >
> >> policy meeting. If we are to make any attempt at fair distribution for
> >
> >> the sake of IPv6 deployment, this is our final opportunity to do so
> >
> >> outside of an emergency action by the ARIN board.
> >
> >>
> >
> >> Timetable for implementation: immediate
> >
> >>
> >
> >> For reference, here is the current text of 4.10
> >
> >>
> >
> >> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
> >
> >>
> >
> >> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> >
> >> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> >
> >> deployment. Allocations and assignments from this block must be
> >
> >> justified by immediate IPv6 deployment requirements. Examples of such
> >
> >> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-
> >
> >> PT or NAT464 translators. ARIN staff will use their discretion when
> >
> >> evaluating justifications.
> >
> >>
> >
> >> This block will be subject to a minimum size allocation of /28 and a
> >
> >> maximum size allocation of /24. ARIN should use sparse allocation when
> >
> >> possible within that /10 block.
> >
> >>
> >
> >> In order to receive an allocation or assignment under this policy:
> >
> >> 1. the applicant may not have received resources under this
> >
> >> policy in the preceding six months;
> >
> >> 2. previous allocations/assignments under this policy must
> >
> >> continue to meet the justification requirements of this policy;
> >
> >> 3. previous allocations/assignments under this policy must meet
> >
> >> the utilization requirements of end user assignments;
> >
> >> 4. the applicant must demonstrate that no other allocations or
> >
> >> assignments will meet this need;
> >
> >> 5. on subsequent allocation under this policy, ARIN staff may
> >
> >> require applicants to renumber out of previously allocated / assigned
> >
> >> space under this policy in order to minimize non-contiguous
> >
> >> allocations.
> >
> >
> >
> >
> > _______________________________________________
> > 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.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 29 Sep 2010 08:32:59 -0600
> From: Chris Grundemann <cgrundemann at gmail.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID:
> <AANLkTimUxYeYO-F8gm-WA3_VyMakaZ1O8BJZ7k1fkr_A at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> I think the fact that ARIN Staff is concerned that this policy may
> favor organizations who are granted reservations too much and Marty
> believes that it does not go far enough to provide relief to those
> same organizations illustrates that we have actually found a pretty
> decent compromise.
>
> On Tue, Sep 28, 2010 at 15:55, Hannigan, Martin <marty at akamai.com> wrote:
> >
> > This proposal still does not go far enough in offering some level of relief
> > to all segments of the industry.
>
> The simple fact is that we are running out of IPv4 space. Absolutely
> no policy can change that. Advancing transition to IPv6 across the
> board is the best way (perhaps the only way) to ease all of our
> growing pains going forward.
>
> > On 9/27/10 4:02 PM, "ARIN" <info at arin.net> wrote:
> >>
> >> ? A. ? ?ARIN Staff Comments
> >>
> >> ? ?? Section 4.10.2 suggests that all allocations made under this policy
> >> will initially be made from a 3-year reservation. ?In light of the
> >> imminent depletion of IPv4 address space, it doesn't seem fair to allow
> >> some organizations to retain/reserve this valuable resource for up to 3
> >> years while others will be denied.
>
> I would like to point out that although the initial reservations are
> for [now two years], there is a built in "fairness valve" as well.
> Please see section 4.10.2.1 in the draft policy, which starts thus:
>
> Reservations will be accepted from the time that this policy
> is adopted until the day that ARIN can no longer fill regular requests from
> space allocated to ARIN by IANA. At that time, if necessary, all reservations
> will be reduced by an equal amount to allow them to fit within
> the total space available in the transition pool.
>
> So everyone who is granted a reservation before run-out gets *some*
> reservation, although it is not likely that anyone will get the full
> reservation requested. I think this is the best balance of
> predictability and inclusiveness possible.
>
> Also note the second phase, post-exhaustion, detailed in section
> 4.10.2.2 which reads:
>
> Reservation requests received after ARIN free pool depletion
> as defined in 4.10.2.1 will not be guaranteed. If approved, such
> requests will be placed in a queue. As space becomes available in
> the transition pool it will be used to provide allotments to
> organizations with reservations in the queue on a first-approved
> first-served basis. Partially filled allotments will remain at the
> front of the queue.
>
> So, *everyone* gets a shot at the transition space, and it comes down
> to how much space ends up being available.
>
> Overall, I think we have come up with the best possible (most fair)
> soft-landing policy under the current constraints (constraints which
> will only get tighter).
>
> ~Chris
>
> >>
> > _______________________________________________
> > 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.
> >
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 63, Issue 32
> *****************************************
>
>
>
> --
>
> Rudi Daniel
> danielcharles consulting
> 1-784 498 8277
>
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100929/e3d326ab/attachment.htm>
More information about the ARIN-PPML
mailing list