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

[Dean Anderson]

On Wed, 29 Aug 2007, Iljitsch van Beijnum wrote:

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

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


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

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. But, I do agree further investigation
is called for.

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

I'll report as soon I do some testing.

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

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

But 2) eventually, people will return IP addresses. So the disruption
isn't permanent.  When couple /8's come back in, it will be no problem
allocating /12's, and lots and lots of /22s.  As you said, the DoD alone
has 10 or so /8's.

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

This is true. Of course, the reports such as Hain's and Huston's also
send out quite clear messages. And those reports predict the future so 
you don't have to wait until a request is turned down.  

Rationing or no rationing, people get the message that the resource is
running out and start hoarding.  That's why you are wrong with the claim
that rationing causes hoarding.

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

I agree that its all too easy to lie on the first allocation. Of course,
the next time they apply, they need to demonstrate usage of the previous
allocation. That lie is much more difficult to maintain, and evidence of
fraud is easier to find.  So the existing policy of partial allocations 
works pretty well for this case, and will continue to work well.



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

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 don't understand how anyone can think IPv4 will be a viable long-
> term technology AFTER the IPv4 address space has been depleted.

Plainly, you misunderstand the effects of depletion, and the economics
of utility. I've been trying to explain that to you.

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

Its not an _assumption_ that people will return space. You agree that
when people convert to IPv6, and no longer need IPv4 space that this
space will be returned. There are other users who will also return
space.  Your problem on that count is merely a lack of self-consistency.

Space will eventually be returned. All that is uncertain is the when 
this will happen.

There is no bad engineering in keeping existing and useful networks
running smoothly

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

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.  But rationing would make that last longer,
too.

> > When MERIT dismantles its dialup network, at least a /8 will come  
> > back.
> 
> Right, because they operate 16 million dial-up modems right now.

Configure, perhaps. Operate? Doubtful.  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.

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

Wrong. You don't seem to be listening, so it seems pointless to keep 
repeating why you are wrong.

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

It sticks arournd because it is useful. Utility drives the market.

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

> > 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.  The utility of IPv4 is not that you can reach
everyone on the planet.  Maybe you daydream about having the 'world by
the tail'.  I don't. Others don't. 

I think part of your problem understanding this is that you can't see
the world from anyone else's perspective.

BTW, You can already reach everything connected to the internet.  What
you can't reach, isn't connected. Obviously, if you are connected, and
they are connected, then by transitivity you can reach everything
connected.  Otherwise, one of you isn't connected, and the network is
partitioned.

> (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)

> >> 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 agree, starvation is bad. Rationing prevents starvation by making it
more predictable when your next meal will be be. To continue the
analogy, that allows your to plan how many calories you can burn, so
that you don't die.

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

I don't push people over cliffs. I just write about them on a web page,
and let others know what they did.

> Personally, I've never had occasion to come up with a pithy cliff
> pushing line.

You already did.

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

You have given no reasons why there would be an expiration date. You've
only tried to create the false impression that running out of IPv4
addresses is the end of IPv4.  And you've tried to prevent prudent
resource management to prevent that exhaustion.

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

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.

> > So EDNSO is unsuitable for anycasted servers.
> 
> No it isn't and that doesn't follow from your earlier claims.

I won't go into that argument here. 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.  
Since then, I have collected experimental evidence of stateful anycast
instability that shows my analysis was correct. And I've also found
further routing mechanisms where anycast fails for stateful protocols.  
But that's another story, and you don't appear very good in that story.  

I won't say any more about Anycast on this thread, except to the extent
that the hardball on stateful Anycast was played by the same people, for
essentially the same reasons: to keep the existing root and tld server
operators for IPv6 so that they can keep profiting from selling those
services.


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

Nice try. Just become someone had a problem with their firewall doesn't
mean that's the only problem with universal EDNSO adoption.  The fact is
that resolvers doen't all support EDNSO. Even 8 years later. But, if
firewalls _also_ cause a problem for EDNSO, that just weakens your case.
It doesn't strengthen it.  Another case of 'shooting your own foot'.


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

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

> 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.  These
protocols could work over Appletalk, DecNet, or Novell etc, too. Some
do.

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

This is an entirely contrived example.  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.

It would plainly be equal or better to have two programs: one ftp
program for IPv4 and another ftp6 program for IPv6. Efforts to go out of
your way to mix things unnecessarily do not count as mixed applications.
Its just bad design and modularity to make a monolithic
every-stack-combined program.  It doesn't justify mixing DNS. It was
just contrived to _try_ to justify mixing DNS. The FTP protocol isn't
mixed. FTP requires only an error-free stream (such as TCP). Ethertalk,
DecNet, etc also provided error-free streams. Many computers implemented
those stacks. No one previously found it useful to have a single FTP
program for all stacks.  FTP isn't specific to IPv4 or IPv6; FTP is not
a mixed protocol.  All you've done is just mixed some code for no good
reason.  We do know the reason; it just isn't a good reason.

Try again...


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

Oh, yes. Two more things that sound "just fine" (not really).  Just like
the other example _you_ gave of not being able to do multivendor dialup.

What's becoming clear through this discussion is __exactly__ why no one
is rushing to convert to IPv6.

		--Dean


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