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

[Dean Anderson]

On Mon, 27 Aug 2007, Iljitsch van Beijnum wrote:

> On 27-aug-2007, at 23:06, Dean Anderson wrote:
> 
> > Fact 1: The Available IP Pool (AIP) will be exhausted on or about  
> > March,
> > 2010 if no changes are made.
> 
> 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.

This seems to be a lot of variation from July, when both said March
2010.  This deserves further investigation.  I suspect that in Huston's
case, if he doesn't update the data from ARIN, etc, his program will see
this as no new allocations and compute a new (but wrong) exhaustion
date. I'll see if this is the case.

It would be nice if these reports were archived somewhere. I can see
about that, too.

> > Fact 2: If the AIP is exhausted, it is unknown when address space
> > will be returned that can be delegated.
> 
> Address space is returned all the time. Last time I check was two
> years ago IIRC, and that was 11 million addresses in a year. I'd say
> it's likely that this will go down as we run out of IPv4 space because
> people will want to hang on to what they've got and returning a few
> small blocks for a larger one won't happen anymore.

I agree.  It is however, still unknown and unpredictable after
exhaustion.

> It goes without saying that the returned address space won't be nearly
> enough to cover the requests that come in.

I agree.

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

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


> 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. The hoarders incur smaller losses in the meantime.

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

> > Fact 7: IPv4 allocation will eventually resume after exhaustion
> 
> Not in any meaningful way. Sure, if you need a /24, you'll be able to
> get it at some point, but if you need a /12, that's simply not going
> to happen.

Wrong again. Eventually, when the DoD converts to IPv6, some /8's will
come back.  When MERIT dismantles its dialup network, at least a /8 will
come back.  If MIT decides not to monetize its /8, that could come back.  
We just don't know when these things might happen.

> > However, after exhaustion, we won't be able to predict when
> > allocation might resume.
> 
> It's not a stop/wait/resume thing, what will happen is that large
> blocks will no longer be available but small blocks will continue to
> be assigned unless so many requests come in that seem legitimate
> enough to soak up all remaining space.

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

> > Your reason for objection is to promote IPv6.  IPv6 should have
> > nothing to do with IPv4 resource management.
> 
> 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. Likewise, we
will continue to use both IPv4 and IPv6.  There will continue to be IPv4
applications, because IPv6 is too heavy for some applications. Text
messaging and cheap cell phones did not entirely replace pagers.  

Likewise, IPv6 will never, ever entirely replace IPv4.  It may be that 
some applications only use IPv6, just like some applications only use 
cellphones.  

> > There is no expiration date for IPv4.  That's your fallacy (or
> > fantasy).
> 
> Right, when 9 billion people are running IPv6, the 900 million people
> running IPv4 have no reason to change protocols.

Just like fax, and pager networks, IPv4 will still have utility. You
don't seem to understand the concept of utility.

> >> I'm not trying to wreck IPv4.
> 
> > I think you are. You are attempting to stop prudent action to avert
> > a foreseeable and avoidable problem with a shortage in IPv4 IP
> > Address Availability.  That doesn't help keep it in a "usable
> > state".
> 
> Your mistake is focussing on IPv4 exclusively. The point is that we
> have a working internet. Today, we need IPv4 for that. In a few years,
> IPv4 won't be able to provide this function for new users, so we need
> to move to IPv6. Making it harder for new users sooner doesn't help
> those IPv4 and the market forces are such that it also delays the real
> solution = moving to IPv6.

Nonsense. Market forces are such that a good, free solution always wins.

There is no 'final solution'. There is a new, larger network, and an
older, smaller network. Both will exist for as long as civilation finds
them useful. And IPv4 will remain useful for a long time.

> > Your justification for your view is that you want to get IPv4 'over
> > and done with' to move onto IPv6.  That's just sabotage of IPv4.
> 
> Absolutely not. 

You and others said exactly that: 'get IPv4 over and done with'

> 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. I suppose if you push someone over a cliff,
you'd say you were just helping them get a better view, too.

The ill-intent of getting 'IPv4 over and done with' is already apparent.  
Your 'good intention' doesn't hold water.  Just like a claim of helping
your enemy 'get a better view' wouldn't hold water, either.


> >> China has gotten 30 million addresses so far this year. That's more
> >> than all year last year. Once China has caught up, the really poor
> >> countries are next in line. IPv4 can't sustain our growing
> >> communication needs, it's as simple as that.
> 
> > Then they'll be happy to move to IPv6. You won't have to mismanage
> > IPv4 to encourage them.
> 
> Oh so it's only the poor people that should use IPv6?

You are the only one making that assertion.  I'm just pointing out that
you still won't have to mismanage IPv4 to encourage them. Or anyone
else.

> >> I recommend reading a good book about it.
> 
> > 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.

> > Here's one DNS example: Recently, a Country code (cctld) domain
> > operator tried to add IPv6 AAAA record support to their cctld name
> > service.  If I recall correctly, they found that they could only
> > have 6 A records, and 3 AAAA records before they ran out of the
> > (IPv4) packet size limitations (512 bytes).
> 
> EDNS0 is your friend,

Yes, EDNSO is so servers can send larger packets. However, many
resolvers do not support EDNSO responses.  Further, EDNSO packets may
need to be fragmented, requiring state on the server for Path MTU
discovery.  So EDNSO is unsuitable for anycasted servers. Hmm. Haven't 
we discussed that before. Something about hardball came into play....Why 
do you suppose people play hardball?  Do you suppose they just started 
that?

But one could have dropped a lot of cruft in IPv6 for DNS.  IPv4 DNS is
one of the early, ugly protocols, that can't be changed easily because
of the installed base. IPv6 didn't have an installed base. It _could_
have used a totally new and clean DNS protocol. Certain influential
people associated with root and TLD operators didn't want to do that.  
They had their reasons, I'm sure. Those reasons just weren't in the
public's best interest.


> 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. But there is a
problem that you obviously "don't see". The market has a way of dealing
with blindness such as yours; it doesn't adopt the product. And rather
than 'open your eyes', you want to coerce the market to adopt your
product by sabotaging the competition, IPv4.

> > There is no technical reason that IPv6 DNS should talk to an IPv4
> > nameserver.
> 
> The DNS is used to determine if a remote system is reachable over IPv4
> or IPv6. This means that address records for both protocols must be
> present in the same name space and then separating the two protocols
> makes no sense.

Yep. 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. There are no mixed applications,
except for root and TLD DNS; there are no mixed applications for mixed
root/TLD DNS to serve.  So, there is still no technical reason for
putting both in the same DNS server.

The only people who even want to mix them are the Root and TLD
operators. And the only reason is so that they can continue on the same
IP address not have to compete to be new IPv6 operators.

> > So, there is a lot of cruft and limitation in IPv4 DNS that would be
> > quite good to remove from IPv6.  None of that happened.
> 
> I'm with you on that one, they could have made EDNS0 mandatory for
> IPv6. Although I think the real issue here is the IPv6 socket API,
> which happily continues the layer violations that were unavoidable for
> IPv4 but could have been cleaned up when IPv6 required changes.

API's have nothing to do with it. There were many API's for IPv4; many
stacks.  You can always write a new API. You can write a new API for
IPv6, and even a new stack. Of course, which RFC's and protocol the
stack implements is difficult, since the RFC's and protocol details keep
changing.  That's why different implementations of IPv6 stacks don't
interoperate.

> > IPv6 is designed in someways to profit some people.
> 
> Yeah right. People are making money off of IPv6 left and right...

Root server operators and TLD operators are selling anycast clones. I
hear they get between $2k and $5k a month for servers.  Multiply that
times 47 (last number I had, about a year ago) for ISC, and Verisign
announced it expected 70 a while back. The money adds up. But yes:  
Almost no one else is making money off IPv6; that was my point.

> > The other part is that IPv6 seems to be so unstable (due to
> > continuous changes) that nothing works very well.
> 
> Actually it works extremely well. There are lots of times when IPv4
> requires hacks that are completely unnecessary with IPv6.
> 
> Unfortunately, IPv6 doesn't (yet) do everything IPv4 does. For
> instance, you can't do dial-up over IPv6 in a mixed vendor
> environment.

There you go, then. I'd say that is not working extremely well.

		--Dean



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000