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

[Scott Leibrand]

Ok.  So it sounds like you'd like to modify ARIN-2011-5 to add
language stating that, for purposes of NAT pools and internal
management, globally unique addressing would no longer be justified
unless there was a compelling technical reason this /10 couldn't be
used instead?

Do you have any language suggestions?  (If not, I and probably a
number of others would be happy to help draft something if people feel
it's needed...)

Does anyone else feel this is important to add to ARIN-2011-5 now, as
opposed to submitting it as another policy proposal for discussion in
Philadelphia?

Scott

On Apr 24, 2011, at 7:01 PM, "George, Wes E [NTK]"
<Wesley.E.George at sprint.com> wrote:

> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Thursday, April 21, 2011 8:37 PM
>
>> [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.
>
> Wes,
>
> 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.
> [WEG] Well, it may be true that there won't be a /10 left. However, one thing to note is that in previous discussions, no one said
> it had to be *contiguous* space as long as it was equivalent in size. In fact, I'd think that this would be a great use of all of
> the miscellaneous dregs space, because it'll keep those small blocks from inflating the global routing table as badly. That would
> have the net effect of pushing the smaller players (who might be able to make use of the dregs) to the transfer market sooner, but
> given the lack of any enforcement language, I'm starting to think that this policy is more about making things easier for large ISPs
> than it is trying to preserve space for needs-based allocations. (and no, the irony of that statement given my employer is not lost
> on me)
>
> 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".
> [WEG] I strongly disagree. This isn't about perfect. This is about getting policy that actually achieves its general goal. If we're
> really worried about the space being exhausted before October, then this policy is *already* too little too late.
> IMO this policy will do nothing to reduce ISP requests for IP space for customer growth. They'll continue requesting space BAU until
> it's gone, because there is no incentive to deploy NAT before it's absolutely required by a lack of addresses (and even then, they
> may go to the transfer market instead of deploying NAT). Given that, the only purpose is to prevent requests from multiple ISPs for
> IPs for inside NAT pools over and above that growth in preparation for deploying CGN that would accelerate the depletion of the free
> pool. If we want it to succeed in this aim, we need it to prohibit use of public space for this purpose, both in new justifications
> and in calculation of utilization levels. Otherwise it's not going to move the needle, and we've lost a /10 for convenience, not for
> conservation.
> That said, I'm not advocating that this policy be updated for all of the possible ways that this shared space can potentially be
> used. That'll take forever, and be out of date as soon as it's adopted. What I am advocating is to ensure that the most often-cited
> use cases (the ones in the current rationale, for example) are included as guidance to ARIN staff regarding justifications. If we
> want follow-on policy to further tighten things, I'll consider that when it's written, but I'm not confident that it'll have wide
> support if we try to start legislating usage beyond the current justification for the policy.
>
> Wes George
>