[arin-ppml] Internet Fairness
frnkblk at iname.com
Sat Dec 20 09:37:48 EST 2014
For those of us in the "NAT is bad"
(https://www.youtube.com/watch?v=v26BAlfWBm8) camp, the risk I perceive with
a purely capitalistic model is that many organizations will sell their IPv4
address space to the highest bidder (who may hoard it) and even more NAT
will be deployed. While the effects of CGN are documented (i.e.
https://tools.ietf.org/html/rfc7021), I think that many network operators
will (choose to) ignore those (to the detriment of their end users) or
capitalize on that by charging extra to those who don't want to go through
CGN. In reaction, applications and services will be further modified to
address CGN, the opposite of my preferred approach towards end-to-end
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Adam Thompson
Sent: Friday, December 19, 2014 9:43 PM
To: Randy Carpenter; ARIN-PPML at arin.net
Subject: Re: [arin-ppml] Internet Fairness
On 14-12-19 08:02 PM, Randy Carpenter wrote:
> A capitalistic model does not work for a finite resource like IP
I'm not even a Smithian capitalist, and I see the first problem here:
Why doesn't it work?
Market stability will be reached according to every economic theory I've
read, regardless of whether the resources are finite or not. It may be
that stability means a gradually-increasing price for a while followed
by rapid inflation, but estimates I've heard posit that IPv6 deployment
will be widespread by the time the market price would otherwise skyrocket.
> All that would happen is that a large company could just buy up all of the
space, and then set its own price for everyone else.
Really? How many universities and large organizations have /8s, /9s,
and /10s, that they would almost immediately start the process of
monetizing? It's "easy" (*cough*) - switch to NAT'd private addresses,
switch to IPv6, whatever. Heck, simple disaggregation of large blocks
would release tons of /16 and longer prefixes based on the usage
patterns I've seen at most large organizations. ISPs are not generally
included in this, they tend to use what they have. IBM, HP/Compaq/DEC,
MIT, Princeton, Harvard, etc., etc., however, are the poster children
for low usage. They just don't have a big enough incentive to worry
about it yet.
Also, see my previous posts for references to academic treatment of the
fact that hoarding *isn't a bad thing* in the free market. Of course,
this isn't a free market yet, so there's an argument to be made there...
> How's that for "fairness" ?? I don't see how you can argue for treating
smaller orgs more fairly by proposing to allow large companies to set
whatever ridiculous price they want.
The playing field is then level - all new entrants get to simply pay the
going rate, with no (perceived?) favouritism towards incumbents or large
entrants. This assumes there's a reasonable relationship between the
price of a /16 and the price of a /24, of course. Smith's "invisible
hand" should, in theory, assure this...
> I still don't get the needs argument at all. If an org can't show that it
needs the addresses, then why do they need the addresses?
Why should I have to disclose to a third party exactly what my plans
are? Even the IRS (or CRA, here) doesn't need that level of detail.
I'm sure the NSA knows exactly what my plans are, but if I have deep
enough pockets, I don't see why this resource - almost alone among all
common resources both natural and artificial - should be forbidden to me.
The only other example I can think of that is widely-known is New York
(and elsewhere) Taxicab licenses... and almost everyone except taxicab
license owners thinks that system is, shall we say, suboptimal.
All of the points above here are posited on the fact that the US is, at
least supposedly, a Smithian capitalist society that embraces the free
I happen to think capitalism is fundamentally broken, but at the same
time I'd rather let the market control what I can and can't do rather
than a handful of regulators who I *know* don't have my interests at
heart. (Nor is that their mandate, I don't mean they're behaving
In essence, above is theory, below is practical.
Moving on to problems in the areas of policy, bias, and technical:
> I agree that in the past it was difficult for small non-multihomed orgs to
get space. But now that the minimum is a /24, it is so ridiculously easy.
Does multihoming, per se, meet the (v4) needs test after the policy
changes in 2014? If yes, I can live with the situation. If no, then
small entities are still getting screwed.
As a small-to-medium-sized enterprise, I probably NAT my entire company
behind one or two (possibly not even contiguous) IP addresses, with
maybe another half dozen publicly-visible servers. But if I want to be
multi-homed, I must first use >64 public IPs, and come up with a reason
to use >128 public IPs within a year. What if I just need those 6 or 7
IPs to be highly available?
Under the current NRPM, the only apparent way a small org can multi-home
(v4) is to get a reassignment from an ISP, at which point they're stuck
with that ISP pretty much forever, barring a painful and expensive
renumbering process (say, ~1000 incoming static VPN tunnels, not all of
which are under their direct control?).
(I also note that the multihoming justification for IPv6 direct
assignment is still there, even as the IPv4 justification is gone.)
This is the primary example today of how the NRPM is heavily biased
towards large organizations and SPs in the end-stages of IPv4 runout.
Meanwhile, if there were no needs test for /24s, and a healthy transfer
market, the organization would have the *choice* of paying for PI space
or choosing alternate workarounds with higher TCO (e.g. DNS-based
load-balancing, manual load-balancing, etc.). Right now, the small
organization that doesn't wish to become a sharecropper for their
incumbent SP is - as far as I can tell from reading the NRPM tonight -
The fact they can still get a direct IPv6 allocation is meaningless
until IPv6 deployment reaches some reasonable density of penetration
(>40%, roughly), and I don't hear anyone here claiming that will happen
until we actually run out of IPv4 space, and SPs are no longer able to
acquire v4 space on demand. Small organizations already can't acquire
v4 space on demand - but they don't carry much weight with SPs.
Yes, the reasoning here is *partially* circular, because there are two
related problems converging to screw the small organization (which group
includes most of my customers, and in fact, most businesses in Canada).
Another way to view this, which has some relevancy to the problem
(mentioned earlier today) with separation between ARIN and NANOG, unlike
APNIC and RIPE which largely combine those functions, is that this
wouldn't be an issue if global routing tables carried prefixes longer
than /24. The main reason that's the case today - as far as I can tell
- is TCAM space on hardware routers, which directly translates into: Money.
[Rant about certain short-sighted & self-centered ISPs removed, didn't
add any value to the discussion, no matter how much it made me feel better.]
Right now we have this mixture of regulatory oversight and "market"
forces that indirectly control said regulatory oversight... this isn't
IMHO a healthy model, and any steps we can take to move either to a pure
regulatory function *or* a pure market-driven regime should improve the
situation. Given that ARIN is located in the U.S., a pure market-driven
regime seems like a better idea right now.
Regardless, small organizations are - right now - impossibly
disadvantaged if they want PI space for any reason, especially multi-homing.
If I've misread the NRPM v2014.4 (2014-Sep-17), feel free to correct my
interpretation... the only provision for low-usage multihoming of IPv4 I
could find is 126.96.36.199, which is commercially punitive, at least in my
athompso at athompso.net
Cell: +1 204 291-7950
Fax: +1 204 489-6515
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML