[arin-ppml] Set aside policy?

Martin Hannigan marty at akamai.com
Mon Jul 12 13:53:19 EDT 2010




On 7/12/10 12:39 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:

> On Thu, Jul 1, 2010 at 22:33, Martin Hannigan <marty at akamai.com> wrote:
>> 
>> 
>> 
>> I¹m aware of 4.10 and your proposal.  I¹m not thinking about NAT devices or
>> small numbers of hosts as transition infrastructure. I¹m interesting in
>> other ideas. Thanks for pointing everyone at these though.
> 
> Section 4.10 is not necessarily limited to NAT or small allocations,
> or at least does not have to be. The title refers to facilitating IPv6
> deployment, not NAT. The majority of the examples listed are NAT but
> that is mostly (I assume) because no other transition methods have
> been readily identified. What if we expanded it to a /9 of the last /8
> and increased the maximum allocation a bit?


The last /8 and anything returned from the potential adoption of something
like this would be more beneficial in an reworked set-aside policy IMHO.

My rationale for opening this can of worms is cost. I'm trying to find a way
to help mitigate the cost of going to a market while trying to balance the
needs of the community and Internet.


Too soon for "oppose/support", but additional ideas welcomed if folks agree
that 4.10 does not go far enough. I have received some comments on the below
out of band. I'm looking for more here in PPML.

Best,

-M<



---snarf

3. Eligibility
 
An applicant will become eligible to receive IPv4 addresses from this
"pool"[better terminology TBD] when they meet the following requirements:

X1. Applicant will provide a written plan detailing how the addresses will
be used and on what devices.

X2. Previous allocations or assignments under this policy must continue to
meet the justification requirements of this policy.

X3. Must have applied for, been approved, received and be utilizing an ARIN
allocated IPv6 allocation or assignment.

X4. All allocations or assignments made under this policy must be
efficiently utilized to a rate of 80%.

X5. Applicant must demonstrate that no other allocations or assignments that
they have received will meet their requirements.

X6. 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. 

X7. Be in compliance with Section 4, Acceptable Use of Addresses.
 

4. Acceptable Use of Addresses


X1. A single IPv4 /32 for each layer 3 contiguous customer network to allow
for IPv4-IPv6 NAT which enables IPv4 connectivity for IPv6 only customer
networks. 

X2. A single IPv4 /32 for each interconnect for each multi-homed layer 3
contiguous customer network that requires traffic engineering.

X3. Customer networks that require stand-alone NAT devices to reach v4 and
v6 networks. 

X4. Loopback addresses for edge routers that have one or more connections to
transit providers 

X5. Address for point to point links between edge routers and their transit
providers 

X6. Point to point links between routers and public networks facing NAT
devices. 

X7. A /32 for routers in Greenfield networks that are dual stacked

X8. /32 for public facing name servers, NTP servers, SMTP servers and Web
servers which are dual stacked and reachable on IPv4 and IPv6 networks.
 

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 be allocated
a /16 or equivalent. The applicant will then be allocated 1/10th 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.


>Maybe drop the restriction
> to once every 3 months? We could also add some language around
> transition specifically but I am not sure that is absolutely necessary
> to allow the uses you envision...
> 
> $.02
> ~Chris


Hi Chris,





More information about the ARIN-PPML mailing list