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

[Owen DeLong]

I favor adding that provision. I don't think it's important to do so, but, I think
it is a good idea and it seems it would help build consensus.

Owen

On Apr 24, 2011, at 7:12 PM, Scott Leibrand wrote:

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