[ARIN-consult] Fee Schedule Change Consultation

[Jesse D. Geddis]

Owen,

Been trying to keep on topic here but thanks for your long agreement.

While this sharing can be interesting I was hard pressed to find anything on topic in the response. Perhaps future off topic replies an be directed at me individually.

I did want to touch on your assertion about NAT as my experience has been vastly different from yours and this may help others who are tinkering with carrier level NAT or even wondering if its possible. I would hate for anyone to walk away thinking it breaks everything or detracts from a typical user experience.

As far as NAT being a "shadow" that's simply your experience and is really dependant on the vendor's implementation of the protocol. Apparently you guys use foundry/brocade at HE who has always had abysmal support for it if any. My users are NAT'd IPv4 and routed ipv6. In two years time I have not heard a single complaint of anything not working from vpns to Xbox to vonage to bittorrent and anything else you can imagine in a home on a massive scale. I've even tried natting 10,000 apartments on a single v4 IP just to see what would happen. No one noticed. You guys might want to check out some more mainstream hardware sometime like Juniper. I think your perception of how the Internet behaves may change :) Foundry/Brocade's marketshare is tiny. 

Jesse Geddis
LA Broadband LLC

On Oct 27, 2012, at 5:32 AM, "Owen DeLong" <owen at delong.com> wrote:

> 
> 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
>