[arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension]

[George, Wes E [NTK]]

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: Tuesday, February 22, 2011 11:09 AM
Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address
Extension]

On Tue, Feb 22, 2011 at 10:19 AM, George, Wes E [NTK] <Wesley.E.George at sprint.com> wrote:
>> What I expect will happen is that they will, instead, each seek large 
>> allocations from ARIN to support their NAT444 intermediary addresses 
>> and get them under current policies, thus accelerating
>> IPv4 exhaustion.
>
> [WEG] We're going around in circles again. If they were able to 
> justify this allocation, they would have already requested it (prior 
> to IANA exhaust) in an effort to reduce or eliminate the need for NAT in the first place.

>Wes,

>What makes you think they haven't? Have you looked at Verizon Wireless' holdings lately?
[WEG] Well, let's refrain from calling out specific companies and making conjecture as to what they
are or are not doing with their address resources unless you have facts to back up your accusations.
However, generically you make a fair point that this is at least possible, and I never said
otherwise. But this policy does nothing for anything already allocated unless it is changed to
*require* use of the shared space for certain applications, thereby invalidating those as
justification for even existing resources. I'm specifically responding to the recurring scare tactic
that if $ISP doesn't get this shared space, they're going to go decimate the remaining RIR free pool
with a big request. 

>I'd like to see those addresses come on the market. If they're tied up doing NAT444, they can't.
[WEG] I think you're being overly optimistic if you believe that the simple presence of a /10 of
shared space for NAT pool inside addresses is magically going to shake loose addresses on the open
market, especially in the context of mobile networks which number their users in the multiple tens
of millions (for whom a /10 isn't nearly enough space unless used multiple times).
Also, people are fond of accusing carriers with large NAT implementations of using NAT as a crutch
to continue doing IPv4 and delay IPv6. This discussion has been derailed several times on several
lists by folks saying "I'm opposed because you shouldn't do NAT or anything that will delay IPv6
adoption." If you think about it, anything that generates a bunch of additional IPv4 address
availability early in the exhaust cycle is actually MORE likely to cause this problem, because it
potentially extends carriers' abilities to deploy real IPv4 service (no degradation due to NAT in
the middle) by continuing to justify new allocations with BAU usage.

Wes George

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