Re: [RRG] 2 billion IP cellphones in 2103 & mass adoption of IPv6 by currentIPv4 users

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

Hi Wesley,

On 17 September, http://psg.com/lists/rrg/2008/msg02506.html you wrote:

> Most mobile operators have a couple of different classes of users-
> The biggest category is what they call casual users - they use web
> access for a few minutes on a fairly limited-capability device, then stop.
> This allows the carrier to be fairly aggressive with things like DHCP
> leases, and helps to minimize the burn rate of IP addresses. If the
> device already uses some sort of optimizer or proxy, there's already a
> relatively easy insertion point in the infrastructure to do NAT of
> various flavors, but as of right now, mobile web access is not usually
> NATed. And yes this does mean that Skype and other third party IP
> communications programs will work on a phone, but if you want to receive
> inbound calls, your standby time goes to hell because the phone must
> maintain an active data connection at all times.


This looks like a fundamental limit on what sort of IP applications
can be run on a hand-held device, as long as a connection uses a
circuit-switched radio link.

3G systems support packet-based air interfaces, and one might think
the transmitter only operates when there is a packet to send.

However, the receiver uses power and there are
control/synchronisation channel packets to transmit on the uplink on
a regular basis.  Continuous Connectivity for Packet Data Users
(completed in March 2007 and part of 3GPP Release 7 -
http://www.3gpp.org/ftp/Specs/html-info/25903.htm) is an enhancement
to reduce the need for these regular uplink packets.  This would
result in lower power usage in the handset during periods when no
data is transmitted, and in a greater number of such handsets to be
operating in the same cell - since the noise created by these
regular packets is a limiting factor.


> There are still some optimizers that help to ensure that the RF is used
> as efficiently as possible and that the Web looks right on the tiny
> little screen, but they mostly aren't interfering with the IP address
> your phone gets and its ability to reach the internet directly.

I understand there are a lot of cell-phones out there with some kind
of web access.  I guess they all get an IPv4 address, whenever they
are actively connected for Internet access.

The 3GPP standards and the IP Multimedia Subsystem:

  http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

looks frighteningly complex and it would take a long time to
understand them, figure out how much of it is finished and can be
used, and exactly how it is used in the rapidly growing 3G networks
right now.  I understand IMS was originally designed for IPv6 only -
but I assume people must be getting IPv4 addresses if they are able
to browse websites and communicate with most other Internet hosts.


> The second category is heavy data users - these are the folks that have
> a card to plug into their PC, or a SOHO router with a cellular interface
> that they are using for primary or secondary internet access. These
> users typically require nearly direct access to the internet for some
> non-trivial period of time, because they are doing things like VPN back
> to work or other things that are generally unhappy with NATs and private
> addresses. While this is a big growth area right now, it's not in the
> same order of magnitude with the handsets, and therefore it isn't as
> much of a challenge to handle the IP addressing requirements.

OK.

> Depending on how much IP space they have, in that relatively static
> situation, carriers may be able to survive for quite some time without a
> significant driver to deploy IPv6 beyond when customer demand starts
> expecting it in order to access IPv6-only content.

It is hard to imagine why there would be IPv6-only "content".  If
someone has something to sell or give away, why only make it
available via IPv6?  Perhaps there would be IPv6-only material if it
was in a format which is only suitable for 3G cell-phones, and in
practice all such cell-phones used IPv6.

> However, the problem is that as carriers start looking at things like
> video, push-to-talk, next generation SMS, VoIP, and the like, those
> handsets start needing to keep IP addresses much longer, like until the
> user finishes watching "The Office" on their phone, or in the case of
> things like Next Gen push to talk and other VoIP applications, the
> entire time the phone is registered with the network.
> This created a lot of hand wringing internally when people in the mobile
> space started doing the math about their IP addressing needs, and
> banging it against what people like myself were showing them as to the
> projected IPv4 address exhaustion event horizon.

It doesn't seem to be reconcilable, considering the huge growth in
data capable handsets.


> Mobile phone manufacturers *are* very responsive in putting exactly what
> the carriers specify into a phone. However, many carriers were slow to
> realize that they were going to need IPv6 as soon as they did, and
> therefore are behind the curve on specifying IPv6 in their handsets.
> Even if they say the handset must be dual-stack, they may not be good
> enough at specifying their requirements of what the IPv6 stack must be
> capable of doing, and it might be very limiting. While all new handsets
> will likely have at least a rudimentary V6 stack, and the network itself
> will support v6 within the next year or two, there are still literally
> millions of legacy handsets that do not, and never will support IPv6
> that we must continue servicing until the customer upgrades.

OK.  I imagine all this work is done at a dizzying rate by folks who
need to sleep sometimes.


> So, now it's to the tactical problem solving. How do we address millions
> (or 10s of millions) of handsets with IPs that they'll likely keep
> indefinitely, assuming that some significant number of them won't
> support IPv6 anytime soon?
> If they have the stomach for it, they can do some really unholy things
> with NATs, where they are either segmenting the network into multiple
> NAT regions so that they can reuse the same 1918 space over and over, or
> leaving it relatively flat, but coopting large blocks of routable
> addresses (that likely do not belong to them, eg 11/8, 12/8, etc) to
> assign to devices inside the NAT boundary, taking care to never leak the
> routes to the internet.

Maybe someone will delurk and provide more details of how 3G
operators actually run things today.


> While some of that may be unavoidable to support legacy devices, there
> is a growing group of people at least within my tiny sandbox that
> believe that IPv6 is a much more elegant solution to this problem, and
> that therefore the best hope is to push as many things as possible to
> IPv6 as soon as possible.

I think this makes a lot of sense.  On a cellphone, most people are
not expecting to run their desktop applications - so they just go
with whatever applications are in the handset.  I guess there is a
way of doing basic web browsing from an IPv6 handset to the IPv4 web.

Google's 3G phone system may change that considerably, since there
will probably be a huge industry creating downloadable applications
for these devices.


> This conserves IPv4 space for those devices and applications that
> actually need it, but that puts us back into chicken-and-egg
> discussions, because the entire internet isn't reachable via IPv6, and
> won't be for some number of years.

> So then we're talking about possibly large deployments of NAT PT devices
> that allow us to shove more handsets into the IPv6-only part of the
> world, coupled with ensuring that the carrier-supplied content is
> reachable natively via IPv6 to reduce the amount of translation that we
> have to support.

I agree.


> It essentially trades one form of NAT for another, but at least there's
> less worry about running out of addresses or or having multiple layers
> of NAT, or showing up on CNN for blackholing someone's addresses because
> we leaked a block that we're using for an internal NAT pool, etc.

A technical glitch amplified up into a conspiracy theory and blasted
around the world via the Net!


> So what does this mean? Well, as more wireless devices support IPv6,
> there's a built-in scaling problem lurking. Debating timelines as to
> whether or not there will be a scale problem in 1 year, 2 years, 4
> years, or 16 years is not productive, because by the time there is a
> large-enough scale implementation of anything that comes out of RRG and
> makes it through the appropriate IETF groups and vendor implementations,
> even the slowest mobile operators will have implemented IPv6 in at least
> some capacity, and there will very definitely will be an IPv6 route
> scale issue.

How many mobile operators are there?   Or more to the point, how
many IP gateway sites will there be in the world in 2015?  Assuming
each advertises a prefix in the IPv6 DFZ, will that be a scaling
problem?

I can't imagine there would be more than 10,000 such IP gateway
sites.  So I don't think widespread IPv6 adoption in cellphones will
lead to a scaling problem - assuming anything less than the current
IPv4 260k routes is not regarded as a problem.

Along with such widespread adoption would be a growth in the number
of server sites which need IPv6 connectivity so they could give or
sell stuff to millions of IPv6-only cellphone users.  Even then, how
many such companies, or hosting companies they use, could there be?

I think it would be a long while before the sum of these figures
approached 100,000.

I don't know the breakdown of usage of the current IPv4 260k routes.


> I'm confused as to what we're trying to accomplish by endlessly debating
> if and or when the ship will sink instead of acknowledging that it is
> indeed taking on water and we might want to agree on a plan to prevent
> it from actually going down. 

The trouble is there are two ships.

One has a scaling problem which will surely accelerate as its most
pressing problem - shortage of address space - becomes more pressing
and the space is sliced and diced more finely.

The other has few passengers and no scaling problem, but a special,
growing, class of passenger - a billion or so I guess in 5 years
time - will soon be getting on board.

According to: http://www.comscore.com/press/release.asp?press=2434
there are about 64 million 3G devices in use in Europe (47% PA
growth rate) and the same number in the USA (80% growth rate) at
June 2008.  I couldn't easily find numbers for Japan, Korea, China,
India, the Middle East, South America, Africa or Russia.

The Paul Budde (http://www.budde.com.au) report "Global - Mobile -
3G - Overview, Statistics & Analyses" states: "In 2008 there are
close to 300 million subscribers to 3G technologies worldwide."


> If Robin is right, then we were prepared
> well in advance, and it gives us plenty of time to refine our
> implementation before we actually have a problem. If he's wrong, we're
> not caught by surprise and scrambling to band-aid what may well be a
> mortal wound.

I think the number of DFZ routes in IPv6 will trail the number in
IPv4 by many years for the foreseeable future.

I can't imagine how long it will take to get to 260k, for instance,
since I could only imagine that occurring with widespread adoption
by many companies, schools etc.  I doubt this would happen just
because of widespread native IPv6 connectivity for 3G cellphones,
since those devices will surely have some way of browsing the IPv4 web.

So I think the first problem to solve is the IPv4 scaling problem.
I think we should be planning how to solve the IPv6 scaling problem,
but I doubt that IPv6 adoption will be so rapid as to force us to
lock ourselves into a particular IPv6 approach before we have
operational experience with the IPv4 solution.

As for the IPv4 time-frame - I think this is a crucial question we
need to consider, despite there being no hard limits to how far the
IPv4 DFZ routing table can grow.

I think there are two ways to solve the IPv4 problem:

1 - Something like Ivip, starting with map-encap but in the longer
    term being able to switch over progressively to Forwarding:

     http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01

    which is 100% efficient and has no PMTUD problems.


2 - Something like Ivip, but using Forwarding only.  This requires
    upgrades to most or all DFZ routers and to quite a few ISP
    internal routers.   If this can be done in a short enough time,
    then it will be easier to do, since we don't have to develop
    and implement encapsulation and the extra complexities in ITRs
    and ETRs which support encapsulation and solve the PMTUD
    problems caused by encapsulation:

      http://www.firstpr.com.au/ip/ivip/pmtud-frag/

The central question in deciding between these two is how quickly
the routers could be upgraded.  If it could be done soon enough,
the rest of the process would take less time, since we wouldn't
have to work on the PMTUD problems, or build a dual-mode system.

Meanwhile, there is a somewhat similar approach to forwarding in IPv6:

   http://www.firstpr.com.au/ip/ivip/ivip6/

With the longer time we have before IPv6's scaling problem needs to
be solved, I think there is a better chance of having the DFZ
routers (internal routers are not so important for this approach)
upgraded in time to go straight to Forwarding, and so avoid
encapsulation entirely in the IPv6 scalable routing solution.
Encapsulation overheads are even worse in IPv6, due to the long header.


  - 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