[arin-ppml] Revised version of 2010-13
Hannigan, Martin
marty at akamai.com
Tue Sep 7 16:04:55 EDT 2010
Owen,
While this is making progress, and from what I can tell, this proposal
continues to require a *substantial* amount of work in order to gain
consensus.
Best,
-M<
On 9/7/10 3:44 PM, "Owen DeLong" <owen at delong.com> wrote:
> Based on community input, draft policy 2010-13 has been updated to version
> 1.35.
>
> A summary of the changes:
>
> 1. Changed from surgical modification of 4.10 to outright full text
> replacement (improved clarity
> and a cleaner approach to the needed changes).
>
> 2. Added a reservation system allowing organizations to apply up front
> for up to 24 months
> of anticipated need from this pool, but, handing the space out only on
> a quarterly basis with
> strict obligations for proper usage of existing space prior to
> receiving each allotment.
>
> 3. Retuned sizing of certain categories of request.
>
> 4. Multiple cases of wordsmithing and reference cleanup.
>
> 5. Added case (e) to handle CDNs which need addresses for SSL terminators
> with strict
> limits on the amount of space available and stringent requirements on
> the number of
> hosts that must be dual-stacked.
>
> Here is the current revision of the policy:
>
> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
> Proposal Originator: Owen DeLong
> Proposal Version: 1.35
> Date: 5 September 2010
> Proposal type: modify
> Policy term: permanent
> Policy statement:
>
> Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment"
>
> Replace the text of section 4.10 in it's entirety with:
>
> 4.10 When ARIN receives its last /8 IPv4 allocation from IANA, that /8 will
> form a
> dedicated pool 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. Following IANA depletion, all
> IPv4 address
> space returned directly to ARIN except space to be reissued
> under an 8.3
> directed transfer will be added to this pool.
>
> 4.10.1 Reservation
>
> 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 reserved IPv4 space will be divided into
> one
> portion per quarter. If a shorter reservation is requested
> such that a quarterly
> allotment does not match a CIDR boundary, then each quarter's
> allotment
> except the last quarter shall be increased as needed to align
> on a CIDR
> bit boundary. The final quarter will receive only the space
> remaining in the
> full reservation.
>
> An org may request one reservation under each provision listed
> in section
> 4.10.4.
>
> 4.10.2 Addressing Plan
>
> Any organization wishing to recieve IPv4 addresses through
> this policy must
> submit a comprehensive plan detailing:
> (a) Their addressing needs over the entire reservation
> period and
> (b) Methods of meeting all requisite requirements
> (requirments are
> explained in section 4.10.4.) over the entire
> reservation period.
>
> A complete addressing plan must be submitted for each request
> made. If the
> submitted plan is accepted by ARIN staff as being complient
> with this policy, a
> reservation will be made and the first portion of the
> organization's reservation
> will be released.
>
> 4.10.3 Quarterly Obligations
>
> Once a reservation has been made by ARIN, the organization
> holding that
> reservation may request one additional portion of their
> reserved block each
> quarter until their reservation is exhausted or revoked.
>
> In order to recieve each additional portion, the organization
> must submit proof
> that:
> (a) The most recent 4.10 allocation/assignment is at
> least 80% utilized.
> (b) All utilization is permitted under the provision
> of section 4.10.4. which
> it was initially requested.
> (c) All prior 4.10 allocation/assignments are at least
> 90% utilized.
>
> For purposes of this computation, space received under each
> provision shall
> be considered separately if an organization has received
> resources through
> multiple provisions.
>
> Organizations must meet all obligations as above each quarter.
> An organization
> that fails only on utilization do to unanticipated address
> conservation shall not
> be penalized, but, such organization shall not receive an
> additional quarterly
> allotment until all obligations are met. An organization which
> does not receive
> a quarterly allotment for four consecutive quarters shall have
> their total
> reservation reduced by 2 quarterly allotments.
>
> If an organization does not meet all obligations in any given
> quarter, that
> organization shall not recieve a portion of their reserved
> block and their
> reserved block will be reduced by an amount equal to one
> portion.
>
> If an organization does not meet all obligations for three
> consecutive quarters,
> that organization forfeits the remainder of their reserved
> block.
>
> If an organization is using space received under 4.10 in a
> manner contrary to
> 4.10 et seq. that organization 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 and shall be exempt from any
> requirement to return
> space to the IANA.
>
> 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
> /19 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 under this
> provision.
> 2. The customer must not have any other IPv4
> allocations or assignments
> from the provider at the time of this
> assignment.
> 3. The customer must not have any direct
> assignments from ARIN at the
> time of this assignment.
> 4. The customer must not have more than a single
> IPv4 /32 from any
> other provider at the time of this assignment.
> 5. The customer must have IPv6 addresses with
> IPv6 connectivity to
> the ISP/LIR (must be dual-stacked).
> 6. The ISP/LIR must demonstrate that it already
> provides IPv6
> addressing and connectivity to at least one
> existing customer
> for each /32 requested, up to 90% of their
> total customer base.
> 7. No organization shall receive more than a
> total of a /14 or
> equivalent under this section.
>
> (b) An ISP/LIR or End user organization may request a
> block no smaller
> than a /29 and no larger than a /23 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 recieve 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 recieving organization must demonstrate
> that it already
> provides IPv6 addressing and connectivity to
> at least one
> existing server in addition to the server for
> which each
> /32 is requested, up to 100% of their total
> server base.
> (organizations which can show 100% dual stack
> are exempt
> from this requirement).
> 5. The recieving organization must 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. No organization shall receive more than a
> total of a /16 or
> equivalent under this section.
>
> (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. DNS64 or other transitional DNS enablers
> e. For 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.
>
> (e) A content distribution network providing SSL
> terminations for
> SSL application or content acceleration may receive
> space
> under the following conditions:
> 1. No organization shall receive more than an
> aggregate /20
> under this provision.
> 2. For each /32 issued under this provision,
> there must be at
> least 8 unique SSL named terminations
> converted to dual
> stack. (A unique named termination is one in
> which the
> certificate DistinguishedName and/or
> SubjectAltName
> is unique as well as the IP address
> terminating the
> connection). An organization which can show
> that they
> have dual stacked 100% of their SSL
> terminations shall
> be exempted from this requirement.
> 3. The total space issued under this provision
> shall not exceed
> an aggregate /11 or equivalent.
>
> End
>
> 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