[arin-ppml] quantitative study of IPv4 address market

Owen DeLong owen at delong.com
Wed Sep 5 15:18:28 EDT 2012

On Sep 5, 2012, at 10:24 , Joe Maimon <jmaimon at chl.com> wrote:

> Paul Vixie wrote:
>> to me the most significant fact in all of this is that well capitalized
>> organizations do not act as if, in any way, there was an impending ipv4
>> exhaustion event, or even a shortage. they are by and large not treating
>> ipv6 as though it was an imminent necessity. they know they can get ipv6
>> and run dual stack or translators for it at any time. their panic is
>> limited to laying in a long term supply of ipv4 because they will need
>> one or more half-decades to turn ship. they imagine, dimly if at all,
>> that less well capitalized enterprises will move first their growth and
>> then eventually their installed base to ipv6 but will not lose the
>> ability to reach ipv4 -- ever. in this view, 2**32 addresses will go to
>> the highest bidder, except for the dribs and drabs needed for "the 99%"
>> to use various kinds of NAT or address translation.
>> i am appalled. this is the same attitude that melts polar ice caps.
>> paul
>> _______________________________________________
> Its really difficult to expect large quantities of entities to behave in ways immaterial or counter to their immediate self interest.
> IPv6 is a nice plan A, but plan B is to make sure you have enough IPv4 for your needs.
> As soon as Plan B is secure, there is much less incentive to focus on Plan A. This is not good for those focusing on Plan A and/or with limited accessibility to Plan B.
> This is why I advocate conserving and preserving ARIN's role in providing a Plan B for as much of the community that it can, and in particular, the segment of the community likely to be in the most need of it.

You have zero chance of making a meaningful difference here. Those horses have all left the barn. ARIN's ability to provide small amounts of address space long after effective runout is insured by the policy that prevents ARIN from distributing multiple non-contiguous blocks to satisfy a single request. So we've already got insurance in policy that ARIN will, to the extent possible be able to meet smaller requests for plan B longer than larger ones.

> Otherwise, the inequality will be between those who were able to execute their plan B and those who were not.

This inequality will occur no matter what ARIN does and is already present. Creating more barriers to rational planning and requests will only serve to further fragment the address space accelerating the time when the IPv4 routing table is accessible only to the very organizations you are worried about putting a strangle hold on the transfer market. Once that happens, you end up victimizing not only the very organizations you claim to be trying to help, but the existing small organizations as well.

> For most, there is still no first mover advantage to IPv6. Turning it on does not enlarge or enhance their audience now or in the near future.

Whether there's a first-mover advantage or not, we are so far beyond first-mover that I just can't see how that is relevant. There are way too many IPv6 deployments to call anyone moving now a "first-mover".

Among the notables:
	Hurricane Electric
	Kaiser Permanente
	US Government (all agencies)
	TIme Warner

I'm sure there are more. Those are just the ones I can readily remember off the top of my head right now.

> It does not even solve difficulties that some of the audience may be having with CGN or what-not, unless they can be convinced to go and get themselves v6.

I would think that anyone having difficulty with CGN would be pretty easily convinced to deploy IPv6 if their target web site was accessible via IPv6 as well.

> So for most, the thinking seems to be along the lines of, "if everybody else can send me email, then it is your problem if you cannot and I don't particularly care how you solve it".

I encourage my competitors to treat their customers in this way. It's been a great way for me to get new customers.


More information about the ARIN-PPML mailing list