[RRG] IPv4 shortage, new features and IPv6 inevitability

[Robin Whittle <rw@firstpr.com.au>]

Hi Iljitsch and Xu,

I am responding to your replies to "Inviting people to join the RRG":

  http://psg.com/lists/rrg/2007/msg00512.html


Xu, regarding IPv4 address depletion and the routing scalability
problems you wrote:

> I agree that a new Internet architecture should address both
> issues. Otherwise, Internet will need another evolution after we
> just finished an evolution for routing scalability purpose. If
> the routing scalability issue is not so urgent as imaged, we need
> to give the matter further thought.

I think the only solution to address depletion is to divide the
remaining free space and currently allocated but underutilized space
into smaller blocks than has been the case (longer prefixes), down
to /30 or whatever.  With the existing reliance on BGP alone, that
would lead to a completely unsustainable explosion in the number of
prefixes.  So I think better utilisation of IPv4 space can only be
achieved with a more scalable routing architecture.

On its own, the current growth in the ~240k IPv4 prefixes is
regarded as alarming by some, but not by all.  Those who are not
alarmed are probably not on this list.  Few of the many people who
are concerned about IPv4 depletion seem to think there is scope for
better utilization - but I think that will change as the crunch
progresses and more and more space is in fact better used.

I and a few others - I think including Geoff Huston:

  http://psg.com/lists/rrg/2007/msg00512.html

- think there is a lot of room for improvement.

The stability and responsiveness of the BGP system is not ideal, but
is not nearly disastrous.

I understand (can someone confirm this?) that the CPU and memory
burden on each DFZ router scales roughly in proportion to the number
of prefixes multiplied by the number of peer routers, with a
significant contributing factor being the number of changed
advertisements.  This last factor is driven by outages, permanent
changes in network structure and in particular by a small subset of
operators chopping and changing their advertised prefixes between
different routers on an hourly or daily basis to achieve Traffic
Engineering of incoming traffic.

Since current routers are working with a wide range of numbers of peers:

  http://psg.com/lists/rrg/2007/msg00253.html

as far as I know, there isn't some threshold over which the number
of advertised prefixes would cause a precipitous increase in the
number of current routers being unable to perform their tasks
adequately.

I think that growth rate will increase enormously (unless we have a
new ITR-ETR scheme in place) once the only way of getting fresh
space is to carve smaller chunks out of larger slabs of space which
are currently not fully utilized.

>> 2 - All the ITR-ETR schemes are capable of slicing and dicing
>> IPv4 address space in many more pieces, and in finer pieces,
>> than is ever likely to be practical with BGP. 3 - Therefore,
>> any of the ITR-ETR schemes could make a major contribution to
>> the more efficient utilisation of IPv4 space.

> The current ITR-ETR schemes use IPv4 address as EID namespace,
> and they do make some contribution to the efficient utilization
> of IPv4 address space. But is that enough?

I think the continuing need for IPv4 address space, including
smaller chunks of it with greater use of NAT, will continue for the
foreseeable future - 5 to 10 years at least.  Having an IPv6 address
does not alter the need of the vast majority of users for direct (or
via NAT) access to IPv4.

My guess is that a combination of these two approaches, either of
which is effective on its own, will keep virtually all end-users
(apart perhaps from research and cellphone networks) connected to
the IPv4 Internet for the next 5 to 10 years at least - and perhaps
for much longer:

1 - Better utilisation of IPv4 space through more dense address
    usage by existing address holders, combined with splitting
    up space into far more, smaller, chunks for new ISPs and
    end-user networks.

2 - Increased use of NAT.  All home and office applications have
    to work with NAT now, so despite its ugliness and the terrible
    burdens it places on application developers and (when it doesn't
    work) on end-users and hapless ISP help-line people, I think
    NAT is part of life, except for servers, and will be used more
    and more.

I am not saying this is elegant or desirable.  Its just that no-one
has been able to convince me that IPv6 will in fact be widely enough
adopted in the next decade or two for ordinary end-users to be happy
without IPv4 access.  Until then, IPv6 is no solution to the IPv4
address crisis.


> Provided that a new address space needs to be deployed as EID
> namespace sooner or later in order to provide enough address
> space, should we go ahead further to embed some useful features in
> this new namespace from the start, such as build-in security
> mechanism?

Hmmm . . . If my prediction about continuing ubiquity of IPv4 turns
out to be valid, then the new ITR-ETR scheme should definitely be
amenable to important extensions such as this.  (I believe an
ITR-ETR scheme will be developed and widely deployed, though it will
probably take quite a few years.)

I think at this early stage of development it would be premature to
hard-wire a new feature into the ITR-ETR scheme, but I think it
would be good to ensure the system is expandable to do things we can
and can't think of now.  We may be stuck with the scheme for decades.

I can't imagine a new feature giving benefits to the end-user
without host changes.  Perhaps some new features might work with
only an OS change, or only an application change.  Others would
require both.  Assuming the new features were genuinely useful and
elegant - so as not to tangle the Net with complexities of marginal
value - perhaps this could encourage adoption of the ITR-ETR mapped
address space.


>> 4 - We are stuck with IPv4 for the next decade or so.  IPv6
>> provides few, if any, benefits for ordinary end-users, is
>> complex and is not ubiquitously supported by applications,
>> firewalls etc.  No ordinary Internet user is likely to be
>> happy with an IPv6-only address in the foreseeable future.

> Agree.

Thanks for agreeing with this, which is an unpopular view in some
quarters.

> Sooner or later we will need a global unique EID namespace
> and locator namespace with enough space in order to realize
> ubiquitous communication. It's better not to patch the Internet
> architecture again and again because each upgrade will be a hard
> experience.

I agree.

Both NAT and an ITR-ETR scheme are kludges, with real costs and
limitations.  Neither would have been necessary if IPv4 had more
than 32 bits of address space - probably 48 would have been fine -
and if the routing system could cope with millions or billions of
separately routed prefixes.

The first might have been vaguely possible, but most computers were
32 bits.  The latter could only be achieved by some really elaborate
protocols and far more CPU power, memory and bandwidth than could
have been contemplated in the early 80s.  I think this latter goal
can really only be solved by an ITR-ETR scheme.  As far as I know,
no single, unified, routing system can scale to those sizes and at
the same time remain responsive to changes.


Iljitsch, despite what you wrote and what quite a few people believe
about IPv6 and about IPv4 utilization, still I believe (for all the
reasons I stated) that IPv6 offers no short to medium term (1 to 5
years) benefit to ordinary Internet users (and therefore their ISPs)
compared to the costs of adopting it.

I still believe that for the next 5 to 15 years most users will find
it better to squeeze more usage out of IPv4 address space than to
adopt IPv6-only space, where they can only communicate with other
IPv6 users or with IPv4 users via a strictly limited range of
protocols (via proxies or a handful of dual-mode applications).  I
still believe any of the ITR-ETR schemes can and should be used to
finely slice and dice IPv4 space.

NAT is ugly but I think that most most users would prefer it to
having no direct IPv4 reachability.  Theoretically, IPv4 can't be
the long-term (~forever) future, but either can burning fossil
fuels.  Still, most folks will be burning coal, oil and natural gas
until the immediate (personal, a few years timeframe) incremental
costs exceed the alternatives.

I think we may be stuck with IPv4 and NAT for a very long time
(decades), with higher overall costs than would be entailed by a
wholesale upgrade to IPv6 - because the shorter term costs of
abandoning direct (including via NAT) IPv4 connectivity are too high
at any one time for most users.

You wrote:

>> 1 - IPv4 address depletion is the most urgent architectural
>> problem facing the Internet - and far better recognised than
>> BGP stability and router scaling problems with the growth of
>> advertised prefixes.
>
> Ah, but that's a solved problem. RRG = research, IETF =
> engineering. IPv4 depletion = operation. We all know what needs
> to be done here. A wise man once said: just do it.

I see no consensus at all on what needs to be done regarding IPv4
address depletion.

I think you imply that we all agree the answer is to move to IPv6.

The trouble is, as I outlined above, IPv6 only solves the IPv4
address depletion problem once everyone - or almost everyone - has
moved to IPv6.  Until then, IPv6 offers no benefit to most users,
since they can't do anything with it they can't already do with
IPv4.  An important exception is the highly complex IP Multimedia
Subsystem - which was apparently designed to work only over IPv6.
This was intended for 3G cellphone systems, but is apparently being
considered for other uses as well.

It is not IPv6's fault that this is the case.  IPv4 had no upgrade
path.  I think it was a mistake for IPv6 to have such long
addresses, adding to the length of every packet.  64 bits should
have been fine - this would have saved 16 bytes of overhead per
packet.  But that is not what is holding up IPv6 adoption.  It had
to be a completely new address space, with correspondingly new
protocols.  It had to have a major impact on the OS and
applications, making life costly and difficult for developers,
network administrators and often users.


>> 2 - All the ITR-ETR schemes are capable of slicing and dicing
>> IPv4 address space in many more pieces, and in finer pieces,
>> than is ever likely to be practical with BGP.
>
>> 3 - Therefore, any of the ITR-ETR schemes could make a major
>> contribution to the more efficient utilisation of IPv4 space.
>
> I'm not convinced. The issue isn't the number of places that need
> an address block, but the number of places that need an
> individual address.

I think it is both, although NAT tends to reduce the quantity of
addresses each end-user network needs.

>> 4 - We are stuck with IPv4 for the next decade or so.  IPv6
>> provides few, if any, benefits for ordinary end-users, is
>> complex and is not ubiquitously supported by applications,
>> firewalls etc.  No ordinary Internet user is likely to be happy
>>  with an IPv6-only address in the foreseeable future.
>
> The alternative is NAT, which is worse.

NAT sucks immensely, but people live with it now.  Just like
Windoze.  (I am using both at this moment.)

Virtually no Internet user can live without IPv4 connectivity.  So
expecting them to be happy with only an IPv6 address any time in the
next 5 years is like expecting them to stop breathing entirely -
rather than expecting them to continue to suck as they (we) have
learned to do already.


>> 5 - IPv4 address space utilisation could easily be improved if
>> there were suitable policies and slicing and dicing
>> technologies. Ping responsive host rates in advertised space
>> are around 4%:
>
> Meaningless. First of all, they also pinged unrouted space.

It is not meaningless.  My survey and the much better work at USC ISI:

  http://www.isi.edu/ant/address/
  http://www.firstpr.com.au/ip/host-density-per-prefix/

both surveyed address space which was advertised in BGP.

If you criticise these results as being so quantitatively inaccurate
as to be meaningless, I think you need to provide quantitatively
verifiable estimates of how many genuinely used addresses are not
being picked up by ping.

The ISI people face the same critique, also without any quantitative
estimates of how inaccurate their figures are.


> Second, current Windows doesn't respond to pings.

Googling indicates Vista doesn't respond to pings.  Firstly, not
that many people use Vista.  Secondly, many who do would have their
machine behind NAT - and plenty of NAT devices such as DSL and cable
modems do respond to ping.

> Third, there's NATs and firewalls.

I got high ping response rates from prefixes with reverse address
mapping indicating they were DSL blocks.  Also, the cable modem
block 24.0.0.0/8 had a 17.6% response rate.


> Fourth, not all systems are
> turned on 24/7. Fifth, this is an average that includes both stuff
> given out under the current fairly tight policies and large
> amounts of stuff given away to people who aren't using it anymore.

There is a wide distribution of ping response rates, as the graphs
at my site show:

  http://www.firstpr.com.au/ip/host-density-per-prefix/all-graphs/

This wide distribution of rates is surely explained, to quite a
large degree, by genuine variations in utilization.

>> So there is plenty of room for improvement.
>
> No. Any effort spent on getting back IPv4 space for new uses is
> wasted effort, because we need to move to IPv6 in the slightly
> longer run anyway.

Geoff Huston estimates 5 to 20% utilization.

http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-ipv4.pdf

Even with 20% - which means 3/4 of used addresses don't respond to
pings - there is great scope for improvement.

In the really long term, IPv4 with an ITR-ETR scheme and ubiquitous
NAT would be a horrible kludge - but perhaps it may still be
tolerable enough to keep sucking at, unless and until so many people
have fully IPv6 compatible OSes and applications, without any
investment of effort on their own, that the few people without IPv4
addresses can be forgotten about, except via proxies for a few key
protocols.

IPv6 is years - probably decades - away from being sufficiently
widely and robustly deployed in applications and OSes.

>> We are attempting to devise something really challenging here -
>> and I think more expertise, more energy and wider perspectives
>> would be very helpful.
>
> Again: no. We made our beds over the past 15 years. We have
> another few years to fluff the pillows, then it's time to go to
> sleep. Even if it's possible to go back and redo the IPv6 effort
> and arrive at substantially better results (debatable), it's too
> late for that now. The message should be: you have three more
> years to start running IPv6 if you don't want to be left behind
> on a network that isn't going anywhere in the medium- to long
> term.

That is the message from the IPv6 camp.

But why would I, or most other end-users (and their ISPs) get IPv6
connectivity, ensure our most important devices, hosts OSes and
applications are IPv6 compatible, when there is no benefit now or in
the next few years over continuing to use IPv4 and leaving my
computer undisturbed?

That is just the first stage - to convince individual end-users and
network operators to adopt IPv6, whilst retaining IPv4 connectivity.
 I can't think of a single practical, businesslike reason most users
should do this.

But in order for IPv6 to help at all with the IPv4 address shortage,
you need to get "enough" end-users to adopt IPv6 in order that a
significant number of end-users will be happy not to have an IPv4
address.  "Enough" is probably close to 100%.

Year after year we hear the same thing from the IPv6 camp and
nothing substantial in user-land or ISPs happens - because IPv6
adoption involves effort and confusion and no tangible benefits.

I am not saying it is good that the only viable complete alternative
to IPv4 is so hard to get going.  I am just saying it is.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg