[arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization

[George, Wes E [NTK]]

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
Sent: Saturday, October 10, 2009 3:19 PM
To: michael.dillon at bt.com; ppml at arin.net
Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization

>I haven't intervened in this debate even though it is a highly interesting one. One element seems to be       >lacking from the discussion. To me, it is an incredibly clear demonstration of the complete breakdown of the  >needs-based allocation principle as soon as scarcity arises.

Milton, I'm not convinced it's so black and white. My support of this potential policy is not an attempt to prevent any market or need-based controls for future IPv4 allocations. In my opinion, this is an appropriate extension to put some teeth in a recommendation ARIN made *2 years ago* which said "...The available IPv4 resource pool has now been reduced to the point that ARIN is compelled to advise the Internet community that migration to IPv6 is necessary for any applications that require ongoing availability from ARIN of contiguous IP number resources."
https://www.arin.net/announcements/2007/20070521.html


>What Michael Dillon has been saying, in effect, is that organizations that can demonstrate a perfectly viable >technical "need" for IPv4 addresses shouldn't get them.

This is providing technical/policy guidance as to what is indeed a valid need. In a way, it is empowering ARIN staff to say, "you do not actually have a valid technical need for IPv4 addresses, because you could and should use IPv6 instead". Yes, this is a slippery slope because this argument can be applied to a lot of applications depending on how stringent the test is, but I think it differs in this case because we're talking about a greenfield deployment of custom-spec devices here. If we had thought about it 2 or 3 or 4 years ago, we might have been able to force the mobile wireless industry in a similar direction, but now, as others have said, that ship has sailed because of the cost to replace the embedded base of handsets, and must happen as devices are naturally replaced by those that do have IPv6 support.

This is targeting new entries, which have the ability due to their application to use a large amount of the remaining resources. They are by their definition starting at ground zero - they have little or no existing "business" that they must work to preserve by using IPv4 until they can transition to IPv6, and therefore no justification to use a scarce resource at the expense of those that do. This is the same drill as changes to building codes and grandfather clauses covering the existing construction. It's unfair to the new entries because they have to do something different, but otherwise it would never change. One can draw parallels in attempts to legislate energy conservation as well. We all benefit, and it's unfair to have existing installations held to a lower standard, but the economics of the situation end up making that the reality, because it's usually cheaper to force a new design in a certain direction than it is to retrofit the entirety of the existing industry.

We want to be able to force this issue before we get to a repeat of other applications, where the cost of replacing the embedded base in order to support IPv6 becomes a valid concern. I'm not interested in "but power company X didn't use IPv6 because their vendor didn't offer it..." because a contract of that size has a way of forcing the issue if it's actually important to the deployment of the application, nor is it a reason for the hardware to not have been designed to support both IPv4 and IPv6 for forward compatibility.

Thanks
Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.