[ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses
Iljitsch van Beijnum
iljitsch at muada.com
Wed Aug 29 07:31:07 EDT 2007
On 28-aug-2007, at 23:53, Dean Anderson wrote:
>> Geoff Huston predicts june 2010 for the IANA pool and march 2011 for
>> the RIR reserves.
> This is a recent change in Huston's predictions. A few months
> from his previous prediction in July. Google cache of this page from
> Aug 4, shows April 16th, 2010. Tony Hain now says April 2010.
And I say during the London summer olympics.
> This seems to be a lot of variation from July, when both said March
> 2010. This deserves further investigation.
It's very simple: the data is extremely inconsistent. You need to do
a lot of smoothing to make the curves fit any particular model. So a
small change in the data or the interpretation can make a big
> I suspect that in Huston's
> case, if he doesn't update the data from ARIN, etc,
I believe this happens daily, not sure though.
>>> Fact 3: Disruptions of unknown duration are more harmful to business
>>> planning than disruptions of known duration.
>> Even more harmful is thinking a disruption is temporary when it is in
>> fact permanent.
> And how is this disruption permanent?
The IPv4 address factory only built 3706.65 million usable ones, when
those are gone, they're gone. When you pump the lake dry, you'll have
rain from time to time but that doesn't mean you will be going
swimming any time soon.
>>> Fact 5: Rationing any kind of limited resource inhibits hoarding
>> No, it just makes it start sooner
> You are wrong: The start time for hoarding is the realization that a
> resource is running out.
Nothing sends that message better than a request turned down because
there are no addresses available, regardless of whether this is
artificial or real.
>> and the iterations as new blocks come available and assignments
>> temporarily allow the hoarders to learn and become more effective.
> The people in charge of rationing also learn, and also become more
They'll never be effective as long as address allocation is done
based on information supplied by the organization that requests them,
it's too simple to lie.
>>> Fact 6: IPv4 usage will not end because of AIP exhaustion.
>> Growth will end, and many economic models require growth.
> Nonsense. Dead applications like dialup are replaced by new
> applications. Growth of new business eventually resumes. It is merely
> disrupted, unnecessarilly.
With dial-up you only need one address per modem, which is something
like one address per 4 - 10 customers. When dial-up is replaced by
broadband, you need 1 address per customer.
I don't understand how anyone can think IPv4 will be a viable long-
term technology AFTER the IPv4 address space has been depleted. I
agree that IPv4 won't go away over night because it will continue to
function for those who already have addresses, but building networks
based on the assumption that at some point, someone will return some
addresses and you may be able to get some of those is very bad
> Wrong again. Eventually, when the DoD converts to IPv6, some /8's will
> come back.
So? We burn /8s up in a month, currently. If the US government
returns the ~ 10 /8s they have that's only one year worth of address
> When MERIT dismantles its dialup network, at least a /8 will come
Right, because they operate 16 million dial-up modems right now.
> It is a stop/wait/resume thing, if we exhaust the available pool:
> Allocation will _stop_, Then one will have to _wait_ until enough IP
> space comes back to fullfil their request, at which point, allocation
> will _resume_.
After we run out, there is simply NO WAY that enough address space
comes back to continue current IPv4 practices. It's nice if 25% of
the requests can still be fullfilled from reclaimed address space,
but it still means that 75% of the requests will be denied so the
people doing those requests will have to find some other way to
address their needs.
>> A smooth transition from IPv4 to IPv6 is in everyone's interest. IPv4
>> is a sinking ship. You don't have to jump in a life boat right this
>> minute, but planning new trips is not a smart thing to do.
> IPv4 is not a sinking ship at all. People said Fax would be totally
> obsolete in the 1990s, replaced by email. Now we use both.
Hm, I was just thinking the other day whether I needed to keep my fax
number the other day since I hadn't received any faxes in almost a
year. But this is not a good analogy. Email and fax provide a very
different experience. For a user, IPv4 or IPv6 are completely
identical. I can't tell whether I'm using IPv4 or IPv6, let alone
users who can't even spell "RFC". But for the same reason that we
don't use iron gall ink any more, IPv4 will go the way of the
dinosaurs at some point. So will IPv6, or pretty much any technology
that we use today. The reason why old technology sticks around longer
than expected is usually because it has properties that are
desireable in certain situations, but is effect deminishes as the
technology is further removed from the user experience.
> There will continue to be IPv4 applications, because IPv6 is too
> heavy for some applications.
No. That's not a consideration at all.
> Just like fax, and pager networks, IPv4 will still have utility. You
> don't seem to understand the concept of utility.
The utility of IPv4 is that you can reach everything connected to the
internet. As soon as you can also reach everything connected to the
internet over IPv6, IPv4 has no use anymore.
(Of course it's not going to happen like that: there will be a period
when you can only reach everything connected to the internet if you
have BOTH IPv4 and IPv6.)
>> I want IPv4 to remain useful as long as it can, which means NOT
>> it harder to get IPv4 address space, which is already relatively hard
> Interesting logic. However, the harms of exhaustion mean that we need
> to prudently restrain the consumption of IPv4 space until more
> space is
> returned to the free pool.
This way, we don't go from a model where there is a reasonable amount
of IPv4 address space available to a model where there is an
abundance of IPv6 space, but rather to a model where we stick to
IPv4, but are starved for addresses. That would be very bad.
> I suppose if you push someone over a cliff,
> you'd say you were just helping them get a better view, too.
What do you say when you push someone over a cliff?
Personally, I've never had occasion to come up with a pithy cliff
> The ill-intent of getting 'IPv4 over and done with' is already
> Your 'good intention' doesn't hold water.
My intent includes keeping IPv4 as useful as possible for as long as
possible. But IPv4 has an expiration date, people need to realize that.
>>> Its kind of hard to find a good book that hasn't been obsolesced by
>>> the continuing changes to IPv6, judging by the RFC index.
>> Anything published in 2003 or later should be in reasonable shape in
>> that department. My book is now 2 years old and I don't think there
>> are significant issues in this area. Sometimes it helps that the IETF
>> moves so slow. :-)
> Apparently, you also need to review the RFC index, for the slew of
> changes since 2003. There have been 1500 RFCs published since then.
> Quite a few of those are for IPv6. I'd say anything published before
> 2007 is obsolete. And even that might not last long.
A book from 2003 probably doesn't talk about the site local issue,
but it should have the current situation for IPv6 in the DNS and
DHCPv6. So I'd say "usable". As for my own book (late 2005), the only
thing that I'm aware of that is missing in it is the whole RH0 issue.
>> EDNS0 is your friend,
> Yes, EDNSO is so servers can send larger packets. However, many
> resolvers do not support EDNSO responses.
Come on, this is the 21st century. EDNS0 is 8 years old, apply the
same policy as you do to your tech books.
> Further, EDNSO packets may
> need to be fragmented, requiring state on the server for Path MTU
With IPv6 this is possible in theory but the minimum maximum packet
size is 1280, which holds a very significant DNS response. The DNS/
UDP protocol doesn't support reducing its packet size so you can't do
path MTU discovery for IPv4, you need to let fragmentation happen.
This has been an IPv4 feature for 26 years so I don't see the problem
> So EDNSO is unsuitable for anycasted servers.
No it isn't and that doesn't follow from your earlier claims.
>> people who use stupid firewalls get what they deserve. I don' see a
>> problem. (But then again, I'm not a root server operator.)
> Its not the firewalls that prevent universal EDNSO.
> That was a red-herring: An IPv6 application doesn't need to know
> if a system is reachable over IPv4. An IPv4 application doesn't
> need to
> know if a system is reachable via IPv6.
Hm, let's see, how many applications are out there that work over
IPv6 and not IPv4? Let me do a quick count... That would be two:
ping6 and traceroute6.
Applications that support IPv6 also support IPv4.
> There are no mixed applications,
# ftp ftp.arin.net
# ftp -4 ftp.arin.net
> the RFC's and protocol details keep
> changing. That's why different implementations of IPv6 stacks don't
They interoperate just fine. I've used Cisco, Juniper, MacOS X,
Linux, Windows XP and FreeBSD and they all work together just fine
except for IPv6 over PPP and there is some path MTU discovery
blackholing if you make the XP machine an IPv6 router.
More information about the ARIN-PPML