[arin-ppml] Set aside round deux

[Owen DeLong]

Marty,
	How do you expect anyone but the largest of the large and extra large
organizations to qualify for a /20 of IPv4 space under this proposal?

	This is a really interesting way to attempt to reserve the last /8 for use
only by the largest organizations ARIN serves, but, I really don't think that
is good policy.

Owen

On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:

> 
> 
> Hello PPML:
> 
> 
> Since it seemed to have been very helpful to vet the global policy idea on
> the list, I thought it might be helpful to use it to frame my non-support
> for 109. This is, just like the last time, very raw, but I expect to solicit
> some time during open policy hour to discuss a more polished version.
> 
> A few points. 
> 
> - This idea takes us in the direction of actual transition
> - Define an acceptable use list
> - Seeks to address COSTS
> - Levels the playing field between small and large
> - Reserves an entire /8 for transition, not for business as usual
> - Counters the high priced "market" that is emerging by deferring it's need
> 
> May not get us all the way through, but every month that we can avoid
> sending people to markets is a month of reduced costs IMHO. And it is about
> costs at this point. It's a given that it is going to happen.
> 
> Too soon for "for" or "against", but most definitely open to feedback. Don't
> focus on the words, focus on the ideas. Feedback very much appreciated.
> 
> 
> --draft, group working comments removed for ease of read
> 
> 1. Transition Pool
> 
> ARIN will set-aside the final /8 allocated form the IANA to facilitate
> transition from IPv4 to IPv6. The resulting "transition pool" will become
> immediately available for allocations under this policy. This pool will be
> known as the "transition pool".
> 
> 2. Minimum and Maximum Allocation Unit
> 
> The minimum allocation unit will be a /20. The maximum allocation unit will
> be /15. 
> 
> 2. Allocation Method
> 
> ARIN will determine and utilize the best method possible for allocations
> with the goal of maximizing what can be allocated balanced by minimum
> deaggregation. 
> 
> 3. Eligibility
> 
> An applicant will become eligible to receive IPv4 addresses from this pool
> when they meet the following requirements:
> 
> 1. Applicant will provide a written plan detailing how the addresses will be
> used and on what devices.
> 
> 2. Previous allocations or assignments under this policy must continue to
> meet the justification requirements of this policy.
> 
> 3. Must have applied for, been approved, received and be utilizing an ARIN
> allocated IPv6 allocation or assignment.
> 
> 4. All allocations or assignments made under this policy must be efficiently
> utilized to a rate of 80%.
> 
> 5. Applicant must demonstrate that no other allocations or assignments that
> they have received will meet their requirements.
> 
> 6. Applicants must provide documentation that demonstrates that the
> addresses received under this policy will be used only on dual stack devices
> that will have both an IPv4 and IPv6 address that will both be reachable
> natively.  
> 
> 7. Be in compliance with Section 4, Acceptable Use of Addresses.
> 
> 
> 4. Acceptable Use of Addresses
> 
> 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
> each layer 3 contagious v6 only customer networks thereby enabling IPv4
> connectivity for an IPv6-only customer networks. Customers must not have
> available IPv4 addresses.
> 
> 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
> each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
> addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
> an IPv6-only customer networks.. Customers must not have available IPv4
> addresses. 
> 
> 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
> additional IPv4 address to meet multi-homing traffic engineering needs or to
> address stand-alone NAT devices as specified below:
> 
> A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
> contiguous customer network that requires traffic engineering. For example a
> network with two interconnects to a single upstream provider can get one
> IPv4 /32 for each of their two interconnects, and distribute their internal
> hosts between the two outside NAT addresses for traffic engineering.
> 
> B. Customer networks that require stand-alone NAT devices (not integrated
> into their CPE router) qualify for enough IPv4 addresses to number the
> loopback addresses (if needed) for all edge routers that have one or more
> connections to a transit provider, enough IPv4 addresses to number each of
> the point-to-point links between those routers and their transit provider,
> as well as the point to point links between those routers and directly
> connected NAT appliances. As well as one IPv4 address for each of these
> directly connected NAT appliances.
> 
> 
> 4. Loopback addresses for edge routers that have one or more connections to
> transit providers and/or peers
> 
> 5. Address for point to point links between edge routers and their transit
> providers [why does it need to be unique v. 1918?] [that is an interesting
> point... We use globally unique as a matter of not breaking routing by
> accident. I have to think about if it would be generally acceptable to use
> RFC-1918. Interesting question!]
> 
> 7. A /32 for routers in a greenfield network that are dual stacked.
> [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
> routerID to make BGP work. If I want to be a green-filed IPv6 transit
> provider I need one IPv4 address for each router]
> 
> 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
> servers which are dual stacked and reachable on IPv4 and IPv6 networks.
> 
> 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
> 
> 
> 5. Reservation Forecasting
> 
> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
> need. ARIN will reserve the requested size in compliance with Section 2 and
> 3. When a reservation forecast is approved by ARIN, the applicant will then
> be authorized to draw down from the forecast quarterly. Prior to requesting
> reserved addresses, applicant will provide documentation to ARIN that they
> have maintained utilization requirements for previous allocation. If
> applicant fails to meet utilization requirements for two consecutive
> quarters, ARIN will cancel the reservation and return unused addresses to
> the pool. 
> 
> 
> Example: 
> 
> Applicant applies to ARIN under this policy and submits a thirty-month
> forecast requesting a /16. Using criteria established in the NRPM and this
> policy, ARIN will determine if applicant is eligible and has need. If the
> applicant meets the requirements for the allocation, they will reserve a
> /16. The applicant will then be allocated 3/30th of the forecasted
> requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
> will round down allocations or assignments to the closest CIDR single block.
> Rounding errors will be applied to the last allocation of the last quarter
> of the thirty month period and allocated then.
> 
> 
> 6. Dual Stack Requirement
> 
> Addresses from this pool may only be used on dual stack devices that are to
> be reachable via both IPv4 and IPv6 networks.
> 
> 
> 7. Application Frequency
> 
> Applicants may apply for address space from the transition pool once per
> quarter. If an applicant has an existing thirty-month forecast that has been
> approved by ARIN, they are ineligible to apply for more address space until
> their reservation has been exhausted. If an applicant has had a reservation
> cancelled due to policy compliance issues including utilization, they are
> not eligble to apply for addresses.
> 
> 
> 8. Post Exhaustion Refresh
>> From the point of the issuance of the final /8 from the IANA, ARIN will
> dispose of all address space that it may receive using this policy. 
> 
> _______________________________________________
> 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.