[arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call

Scott Leibrand scottleibrand at gmail.com
Thu Apr 21 20:36:33 EDT 2011

On Apr 19, 2011, at 2:25 PM, "George, Wes E IV [NTK]"
<Wesley.E.George at sprint.com> wrote:

> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> On Tue, Apr 19, 2011 at 4:14 PM, George, Wes E IV [NTK] <Wesley.E.George at sprint.com> wrote:
>> Specifically, it does not include any guidance to ARIN staff
>> eliminating the intended uses for this space (NAT inside pools aka
>> IPv4 address extension) as valid justifications for standard address
>> space allocations
> Hi Wes,
> I think we all share that worry. And I think that following this proposal's adoption, ISPs should consider themselves on notice that
> NAT pools of all sorts are unlikely to continue to offer valid justification for retaining addresses that have been allocated in the
> past. This policy is the opening shot, not the final one.
> [WEG] Bill, the problem is that I explicitly asked for staff interpretation regarding this question at the mic in PR, and was told
> that there was nothing preventing internal NAT pools from being used as justification for space or in calculations in determining
> usage levels to reach 80% and justify new allocations. ARIN Staff will not make a distinction, so regardless of what the intent of
> the community, because this policy is not actually dictating a change in policy for staff, "ISP's should consider themselves on
> notice..." is mere hollow words. Realistically by the time a second policy correcting the gap in the current one would be
> implemented, the damage would already be done. If you agree that this is a legitimate concern, we should fix this policy, not patch
> it with additional policy later.


Given the state of the various free pools, I'm pretty sure that we
won't have a /10 free if this proposal waits until Philadelphia.
Given that possibility, how do you think we should proceed?  I'm
leaning towards adopting this proposal now, and then following it up
with another proposal to require that service providers use this (or
RFC1918) space when appropriate and technically feasible, rather than
getting globally unique space for the purpose.  While such policy
tightening may have been more effective if we had started working on
it earlier, I don't think we should hold up ARIN-2011-5 and require
service providers to use globally unique space for the purpose just
because we don't have policy in place to require them not to do so.
IMO we shouldn't let the perfect become the enemy of "better than what
we have now".


More information about the ARIN-PPML mailing list