[arin-ppml] Set aside round deux

[Hannigan, Martin]

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.