[arin-ppml] Set aside round deux

Owen DeLong owen at delong.com
Sun Aug 1 09:28:21 EDT 2010


On Jul 31, 2010, at 9:13 PM, Roger Marquis wrote:

> Benson Schliesser
>> That said, we can learn from all of these comparisons. Spectrum: the FCC
>> uses a market approach (monetary value/cost) to make sure that spectrum is
>> allocated efficiently.
> 
> Problem is radio frequency is a physically limited spectrum, where the
> need for restrictions is natural.  IP exhaustion is anything but natural.
> It is an artificial shortage imposed on the community by those who stand
> to profit.  It is artificial because the barriers to adoption are well

No, it really isn't. First, nobody really stands to profit in a meaningful way
from IPv4 exhaustion (note, it's IPv4 exhaustion, not IP exhaustion).
Sure, a few address holders might make some as yet unknown amount
of money from address trading, but, that's pretty much a one-time
transaction. Real profit comes from repeatable business.

> known, basically NAT 64 and 66 standards.  These bridges from IPv4 to
> IPv6 have been blocked by the most specious, inconsistent, and fabricated
> arguments imaginable. 

NAT64 hasn't been blocked by any argument so much as nobody has been
able to deploy a particularly workable version of it. As to the arguments against
NAT66, I would hardly call them specious:

1.	It's unnecessary and provides zero benefit.
2.	It's tremendously harmful and costly with most of the costs not borne
	by the organizations deploying or wanting to deploy it.

In essence, the argument against NAT66 is about on par with the argument
against subsidizing a factory to produce toxic waste and dump it into the
environment.

> We know NAT works because it is nearly ubiquitous
> in the IPv4 world.  We know there is no good security alternative to NAT,
> no good multi-homing alternative to NAT, and no business case for GUA.

Actually, all of those arguments are quite specious:

1.	We know NAT can be coerced into minimal functionality because
	we've managed to do so at great cost in the IPv4 world. We have
	given up much functionality along the way and we have accepted
	a large number of tradeoffs. Herpes type 1 is nearly ubiquitous
	among humans. That doesn't make cold sores any more desirable
	than any other less prevalent disease.

2.	We know that NAT does absolutely nothing for security. Security
	comes from the stateful inspection that is a prerequisite for
	the kind of NAT you are imagining provides security.

3.	The good multi-homing alternative to NAT is PI GUA. In IPv4, there
	simply weren't enough addresses to make that possible. In
	IPv6, there is no such address shortage, so, there is no need
	for NAT as a workaround or alternative to using PI GUA for
	multihoming.

	The next-best multi-homing alternative in IPv6 is PA GUA with
	prefixes from each of your two providers. This requires a bit
	of intelligence on your routers to detect when a provider goes
	down and deprecate the RAs for that prefix, but, it's do-able.
	It also requires some amount of source address selection
	policy to be deployed to your hosts. Again, not as convenient
	as PI GUA, but, do-able if you're determined not to pay $100/year
	for PI GUA.

4.	No business case for GUA? That's such an individual and
	subjective measure that is unique to each organization, it
	is hard to comment meaningfully. I can say that many
	organizations have PI GUA and PA GUA, so, at least for
	many organizations, that simply isn't true. I find it really
	hard to imagine a situation where I could justify the cost
	of multihoming to dual service providers and the routers
	to support that, but, couldn't justify an
	initial $1250 and a recurring $100/year to keep the
	organization humming along with connectivity to the internet

> Despite this market intelligence a very small minority of vocal
> "interests", who claim to be full time network engineers yet seem to have
> many hours a day to post technically ridiculous criticisms of NAT, have
> been able to prevent the adoption of NAT64 and 66.  This, and only this,
> is why we are facing address exhaustion.  If NAT 64 and 66 had been
> implemented years ago we would not even be discussing it today.
> 
An interesting characterization of those who disagree with you.

The failure to implement NAT64 will increase the pain threshold of the
transition and probably shorten the duration of the transition, frankly, but,
it is not a significant reason not to deploy IPv6. If anything, it's a reason
to deploy IPv6 in a dual-stack fashion on your IPv4-capable equipment.

The lack of NAT66 may be giving some organizations pause, but, in
most cases, that represents ignorance of the above 4 points or
some form of religion. Such organizations do not represent the
majority of organizations that have not yet deployed IPv6, however.

I was a full time network engineer up until about May of last year.
Since that time, I took on a new role attempting to help people
learn about, understand, and ultimately deploy IPv6. As such, I talk
to many organizations that have not yet deployed IPv6 on nearly
a daily basis. I also work for a major IPv6 provider and have access
to pretty good data about what is connected to the IPv6 internet,
connection rates, traffic growth, etc.

The adoption rate of IPv6 is definitely accelerating.

In talking to organizations that have not deployed IPv6 yet, the
major reasons I hear most often are:

1.	"We didn't know we needed to. Thanks for letting us know
	what was going on."

2.	"We know it's coming, but, we didn't realize it was coming so
	soon and we've been focused on other priorities."

3.	"We'll deploy IPv6 when we have to. We don't see the need
	yet."

4.	"We're waiting for our upstream providers to support it."

5.	"Our vendors haven't enabled it in our gear yet."

You are actually the only person to ever tell me that the lack of
NAT66 is a barrier to IPv6 deployment.

>> For IP we should strive to create a fair field of play, but that doesn't
>> oblige us to artificially de-value address resources. Accepting a thesis
>> that IP addresses are "private assets" might actually benefit the community
>> more than the alternative.
> 
> That is the line IP squatters would have us believe, but there's no
> business case other than profitability to speculators and squatters.

While I don't agree with your reasoning, i do feel that treating integers
as property is absurd and certainly not in the public interest.

> Nothing new here that Enron didn't try 10 years ago.  Claims of benefit
> from an address shortage can only be sustained by ignoring the lessons of
> history.
> 
While the rhetoric is entertaining, the shortage of IPv4 addresses is neither
artificial, nor is it being created by people who seek to profit from runout.
The simple reality is that when you consider the number of devices that
require IP addresses per person. I expect this number to be an average
of somewhere around 5 when you consider:

	Laptop
	Cellphone
	Desktop @work
	Desktop @home
	Portable Entertainment/e-Book device (iPad/Nook/Kindle/etc.)

Now, multiply that by 6.8 billion people (http://www.census.gov/main/www/popclock.html)

Now, add in some amount for servers. For now, I'll leave this at zero because
I don't have a good source for a meaningful number to put in. As such, I would
say that my number of required IP addresses below is rather conservative.

When I do the math, 5*6.8e9, I come up with 34,000,000,000.

When I look at the IPv4 unicast address space, I come up with 3,706,650,624.
(This factors in Loopback, RFC-1918, 0.0.0.0/8, 224/4, and 240/4 as non-unicast).

According to my math, that leaves us with a shortage of 30,293,349,376 addresses
in IPv4 just for the world population without accounting for servers.

That does not seem artificial to me.

Now, you can argue that some portion of that belongs behind NAT, but, I don't
buy that argument. People should be free to choose whether they want to
provide content or services to the outside world or not. That requires that
they have globally unique addresses. Inflicting NAT upon them removes
that choice and is unacceptable in the long run.

Owen




More information about the ARIN-PPML mailing list