[ARIN-consult] Fee Schedule Change Consultation

[Owen DeLong]

On Oct 26, 2012, at 2:14 PM, Jesse D. Geddis <jesse at la-broadband.com> wrote:

> Owen,
> 
> 	If you believe how things have been handled in the past have served us
> well I guess none of us would be having this conversation about rolling
> out IPv6 right now at all, right? Thank you for your reply but lets try to
> keep things constructive. A couple people have since suggested a sort of
> flat fee but this takes it a step further. Below is my response to a
> couple of John's questions:

I disagree. I think that protocols become obsolete for a variety of different
reasons. The problem with IPv4 is that it was designed for a different target
audience than is currently using it. As a result, it was sized for a dramatically
smaller internet than what we see today. It has become obsolete because it
ran out of numbers. Frankly, EUI-48 is facing a similar problem at this point
and the IEEE is now looking at it as well. That does not change the fact that
the process for handing out EUI-48s has served us well, it simply indicates
that the expected number of EUI-48 devices underestimated demand.

The internet with NAT is not the internet. It is a shadow of what the internet
should be. We have lived in that shadow for so long that the vast majority of
internet users have no comprehension that they live in shadow. Nonetheless,
they do, in fact, live in shadow. There are roughly 6.8 billion people on the
planet. We are moving towards an era where each person will have, on average,
a lap top, smart phone, tablet device, and two desktop computers (one at home
and one at the office). In addition, you need to account for content servers,
home entertainment devices, sensor networks, utility devices (refrigerators,
thermostats, intelligent cupboards, etc.), routers, network infrastructure,
etc. The mere multiplication of 6.8E9 * 5 reveals that 4.3E9 is a woefully
inadequate address space for the future internet regardless of the allocation
policies.

We are discussing IPv6 because the internet has outgrown the IPv4 address
space. I suppose one could argue that the prior allocation policies have
accelerated the time at which this has become an issue, but, in reality, I
would argue that the unfortunate deployment of NAT and it's deleterious
effects on the internet have artificially delayed that date by roughly 25
years.

From my perspective, policies in the past have, in fact, served us quite
well and contributed greatly to the fact that we even have this problem.
Had policies been different, we might never have had the internet escape
from the laboratory and the web, the popular consumer internet, etc. might
never have come to fruition. I believe that the ability to readily get
free addresses and naming references deployed quickly and easily drove
much of the early adoption that lead to the internet becoming the one
driving force in consumer networking above all others. Perhaps you do not
remember when there was a choice of walled garden consumer networking
experiences most of which did not even contemplate connection to the
internet. Prodigy, AOL, CompuServe, etc. all began as separate services
which had no connection with each other or with the internet. Most of
them just sort of glazed over when you asked about internet connectivity
and said "no, we don't do that". Over time, the open internet with its
easy adoption and diverse functionality won out, but this was never
a certainty before it happened and a more conservative set of allocation
policies or higher fees at the time might well have prevented it.

It is very common and popular to ignore the context of the past when
judging the actions of the past. However, doing so is fraught with
peril and rarely yields a valid perspective or conclusion.

> 
> John,
> 
> Thanks for your note. You're right about the policy part, however, it was
> purely a fee conversation and I didn't want to steer things off topic ;)
> Further, I think there is a mindset that comes with the existing
> progressively cheaper fee structure that encourages the kind of waste
> we've seen with IPv4. However, the issue of policy is of greater
> importance.
> 
> I think there are a couple of ways to address it:
> 
> 1. The current practice is to award larger and larger blocks to orgs. I
> think this has proven troublesome.
> 	1. The point of this was to keep the table small but I think since newer
> hardware is required to support ipv6 in the first place this is no longer
> relevant. Besides ARIN can't really dictate how an org advertises their
> space <http://www.cidr-report.org/cgi-bin/as-report?as=AS35908&view=2.0>.

Indeed, the current IPv6 policy definitely does this in that if you
consume a /32, you get at least a /28 next time. The intent is that you
immediately stop making allocations into the /32 and eventually return
it through attrition if it ever becomes empty.

> 	2. It creates waste because an org who has run out of their /16 would be
> foolish to request a /22 even if that's all they require. They are
> incentivized by allocation practice to request the largest they can and
> hoard it. VPLS is a prime example of that
> <http://whois.arin.net/rest/org/VPLSI/pft>. They have only 20 cabinets of
> dedicated servers but over half a million IP's. 98% of which they aren't
> using because they have abused ARINs progressive allocation practice in an
> effort to later sell those resources on ARIN's market at vastly inflated
> prices.

In IPv4 (which is where the prefix sizes you describe would make sense), this
actually isn't the case. One needs to demonstrate not only that they have used
up their /16 (80%), but also that they actually need a larger block. If they
can only demonstrate need for a /22, ARIN will only issue a /22. Admittedly,
ARIN uses the rate at which they consumed their /16 as a partial predictor of
this need, but also considers the statements made by the applicant regarding
their future intended utilization.

> 
> 
> 2. A linear fee might be worth looking into rather than a progressive one
> (i.e. A flat tax). One for IPv4 and one for IPv6.
> 	1. It may help encourage more efficient usage
> 	2. It wouldn't penalize smaller organizations as severely and be fair
> across the board.
> 	3. Much simpler billing structure. Say you were to bill $x per /64
> starting with allocations made in 2013. For orgs that predate that move
> (because /32's used to be all that were issued) them to the new fee
> structure once they request more resources. For v4 you could do $x per /24
> or per IP.
> 

I personally believe that the logarithmic fee introduced in the APNIC
region will actually be disastrous. It will incentivize residential
broadband providers to issue tiny amounts of address space, possibly as
restrictive as /64 to their customers and will once again set back
innovation on the internet almost to the extent that NAT has degraded
things.

Conserving IPv6 space in this way is quite harmful and will result in
costs beyond mere dollars.

> 
> 3. I think ARIN could more aggressively enforce existing policies
> 	1. During a transfer request ARIN affords itself the opportunity to
> revisit the allocation and reclaim it altogether. I haven't seen this
> happen in cases where it should have based on policy.
> 	2. For IPv4 requests or transfers the question needs to be asked "why
> aren't you natting"? AT&T is a fabulous example of this. I have tens of
> thousands of residential users IPv4 NAT'd with no loss of functionality. I
> dual stack them with IPv6. If I can do it why can't AT&T? Why do they need
> tens of millions of IP's? There is simply no technical requirement for
> every end user on dsl and uverse to have a public IP.
> 

How on earth can you claim no loss of functionality. They cannot put up a
web server. They cannot have a DNS entry that points to any of their devices.
They cannot receive a SIP call without involving an external rendezvous host.

There is tremendous loss of functionality.

NAT is a disastrous problematic hack designed to temporarily cope with a
shortage of addresses. It certainly isn't a desirable steady state and I
most strenuously object to codifying extreme implementations of it in policy
as you suggest.

Owen