[ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses

[Iljitsch van Beijnum]

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

> 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  
>> resume
>> temporarily allow the hoarders to learn and become more effective.

> The people in charge of rationing also learn, and also become more
> effective.

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

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

> When MERIT dismantles its dialup network, at least a /8 will come  
> back.

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  
>> making
>> it harder to get IPv4 address space, which is already relatively hard
>> today.

> 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  
pushing line.

> The ill-intent of getting 'IPv4 over and done with' is already  
> apparent.
> 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
> discovery.

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  
with that.

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

http://searchwinit.techtarget.com/tip/0,289483,sid1_gci991813,00.html

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

Really?

# ftp ftp.arin.net
Trying 2001:500:4:1::21...

# ftp -4 ftp.arin.net
Trying 192.149.252.20...

> the RFC's and protocol details keep
> changing.  That's why different implementations of IPv6 stacks don't
> interoperate.

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.