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

[George, Wes E [NTK]]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6753 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110425/74a14455/attachment.p7s>