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

[Iljitsch van Beijnum]

On 31-aug-2007, at 1:24, Dean Anderson wrote:

>>> Aug 4, shows April 16th, 2010.  Tony Hain now says April 2010.

>> And I say during the London summer olympics.

> Ok. Except that you are just pulling your number out of your hat. The
> other two use some math to compute the rate and compute the remaining
> address space.

It's not that simple. Tony and Geoff take their assumptions (why use  
the last 1095 days and 1250 or 943?) and put them into formulas which  
then produce results with many digits after the decimal point. I take  
several possibilities, see where they lead and then try to come up  
with something that seems reasonable based on my interpretation of  
the past.

Tony and Geoff's approach would probably be better at projecting a  
trend into the future, but it's my contention that there is basically  
no trend so there's not much to project. The only thing that looks  
pretty solid is that there's almost always growth in the number of  
addresses used up per year. Anything else only persists for a few  
years and then changes.

> When they agree or even nearly agree, that's probably a
> pretty good number. Certainly, its better than your approximate  
> 'back of
> napkin' calculation.  Unless you can come up with some flaw in their
> methods or basis of calculation, you really don't have any credible
> basis to dispute their numbers;  So I don't think your number is very
> credible.

I don't think my number is very credible either, but I'm far from  
convinced that the others are better.

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

> The data doesn't seem to be very inconsistent. My read of Huston's
> graphs is that the rate of consumtion is remarkably steady, actually.
> More so than I would have thought.

Really? This is the past 10 years (note that the ARIN figures are  
problematic because they often backdate new allocations which I can't  
compensate for automatically):

                     44.86 M  1997
                     60.00 M  1998
                     42.22 M  1999
                     77.71 M  2000
                     84.51 M  2001
                     68.49 M  2002
                     86.85 M  2003
                    127.50 M  2004
                    174.97 M  2005
                    172.81 M  2006
                    137.02 M  2007

Now have a look at the ARIN numbers:

                     26.30 M  1997
                     45.35 M  1998
                     18.96 M  1999
                     30.53 M  2000
                     28.03 M  2001
                     20.80 M  2002
                     21.38 M  2003
                     32.74 M  2004
                     51.00 M  2005
                     50.43 M  2006
                     20.28 M  2007

The theme seems to be either stick close to last year or jump by more  
than 50%. Not exactly smooth.

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

> So: 1) we shouldn't pump the lake dry.

So people should go thirsty even though there is still perfectly good  
water left in the lake?

> But 2) eventually, people will return IP addresses.

This year, for the first time in many years, a legacy /8 was  
returned, even though only half of them show up in the routing table.  
So apparently, people aren't in a hurry to return what they no longer  
need. Also, as long as there are people who don't want to move to  
IPv6 it's useful to keep your own IPv4 address to communicate with them.

> So the disruption isn't permanent.

Your logic is "after the depletion, SOMEONE will be able to get IPv4  
space" (which is true) and then "if SOMEONE can get IPv4 space  
EVERYONE can get IPv4 space" (which is untrue). If you're an old  
tennis pro who had to stop because of injuries, you can heal and then  
play tennis again. That doesn't mean you can resume your career and  
win Wimbledon.

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

> Actually; Verizon seems to have worked out a way to use DHCP and PPPoE
> so that customers who aren't actively sending packets, lose their
> addresses.  This probably makes DSL address usage more like dialup
> again.

I doubt this results in a significant reduction in address use today:  
you wouldn't want to use 1024 addresses for 1200 customers and then  
have support calls when the 1025th can't get online. This could  
change in the future to some degree, but I'm still 99% sure that more  
broadband and less dial-up means more addresses, not fewer.

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

> Only one at the current rate.  That would be the same rate that
> rationing will slow down. One year is not too bad though,  
> considering it
> comes from just one source.

It's about a quarter of the total /8 legacy space and a little over a  
tenth of the total legacy space if you also include the class B nets  
but those will likely be even harder to reclaim because you need 256  
times as many to get the same amount of space.

> But rationing would make that last longer, too.

Whether you starve because there is no food or because it's rationed  
doesn't really make a difference...

If you have significant long-term plans for IPv4, you may want to  
look into putting the class E space (240.0.0.0 - 255.255.255.254)  
into use. My conclusion was that by now, we don't have enough time to  
roll out software updates to stuff like Windows that won't accept  
those addresses to make them usable in time, but if you're thinking  
on timescales past the lifetime of the current Windows version, this  
would be viable.

> But at some point, those modem
> pools will be dismantled, and the address space will either be  
> returned,
> or put to some other use---So either ARIN gets the space back or  
> ARIN is
> relieved of demand.

I think this has already been happening as modem pools have shrunk  
and broadband deployment grown the past years. I don't think there  
are heaps of IPv4 addresses waiting to be returned because modems are  
taken out of commission.

>>> There will continue to be IPv4 applications, because IPv6 is too
>>> heavy for some applications.

>> No. That's not a consideration at all.

> Not for you, perhaps. Buried head in sand, I see.

A 10 year old computer can easily handle IPv6. I'm sure there are  
embedded systems that are sized such that they can just about run  
IPv4 but the extra code for IPv6 is the staw that breaks the camel's  
back, but that just means they'll have to use a 7 cent chip instead  
of a 5 cent one. Boo hoo.

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

> Wrong analysis. Again.

I think this is the part where we have completely opposite views. You  
seem to think that there are some jobs that IPv4 can inherently do  
better than IPv6. The way I see it, and I'm positive this position is  
shared by pretty much the entire IETF, is that IPv4 and IPv6 are both  
mechanisms to move data from one system to another over the network,  
and apart from address-related issues that must be addressed in the  
relevant protocols/applications, IPv4 and IPv6 are functionally  
interchangeable.

>> (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 think you have a problem with the definition of "the internet".  
> There
> is the IPv4 network (an internet), and the IPv6 network (also an
> internet)

So you are saying that www.arin.net (visited over IPv4) is something  
other than www.arin.net (visited over IPv6)?

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

> Absolutely wrong nonsense. RFC 1191 (Path MTU Discovery) applies to  
> _IP_
> datagrams for IPv4. That includes UDP, TCP and other protocols  
> inside IP
> datagrams. DNS has nothing to do with MTU discovery.

When you use TCP and a "packet too big" ICMP message comes back, TCP  
reduces its packet size. So what do you suggest happens with a  
"packet too big" message comes back for an UDP packet so UDP needs to  
send packets that are no larger than 1476 bytes while the application  
wants to send a 2000-byte packet?

> But anycast isn't suitable for DNS,
> and that _does_ follow from my earlier claims. People resorted to
> hardball to suppress my claims and to promote false claims of  
> stability.

My opinion of anycast for the DNS isn't entirely favorable: over- 
using this mechanism means that too many eggs end up in too few  
baskets. It would be good to anycast only half or so of the root  
servers. But you can't argue with operational experience: so far, it  
has worked pretty well.

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

> Dhcp6 comes to mind. I think there are more that use IPv6-specific
> features.

I wouldn't exactly call that an "application", but yes, DHCPv6 only  
works over IPv6, DHCP only over IPv4.

>> Applications that support IPv6 also support IPv4.

> The protocols you quote have no changes for IPv6 because they aren't
> specific to the underlying protocol that carries the payload.

So? That's true for most protocols/applications.

> The 'combined' FTP program needs
> to link to both stacks and include a lot of extra and unnecessary  
> code.
> This is usually cited as a disadvantage, and poor, monolithic design.
> This is not an example of a mixed application, but an example of
> _contrived_efforts_to_mix_ IPv4 and IPv6, after the fact.

A few more examples:

Apace 2, sendmail, UW IMAPd, Internet Explorer, Firefox, Safari,  
Thunderbird, Mail.app, Windows Media Player, iTunes, QuickTime Player.

On most systems (most notable exception: Windows XP) you can write  
programs that only use the IPv6 API but can talk both to the IPv4 and  
IPv6 worlds. I haven't counted the bytes, but I'm pretty sure the  
code required to link both protocols is only very slightly larger  
than all the stuff you need for just one of them. All the work  
happens in the kernel anyway.

> It would plainly be equal or better to have two programs: one ftp
> program for IPv4 and another ftp6 program for IPv6.

So how do users know which they should use?

I normally read my mail over IPv6. But when I'm on the road, I  
usually don't have IPv6 connectivity so I find it rather helpful that  
my mail program automatically switches to IPv4 then.