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

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2008 08:12:09 -0700

>-----Original Message-----
>From: Robin Whittle [mailto:[email-masked]] 
>Sent: Monday, September 15, 2008 8:49 PM
>To: Routing Research Group; Steven Blake
>Subject: [RRG] 2 billion IP cellphones in 2103 & mass adoption 
>of IPv6 by currentIPv4 users
>
>Hi Steve,
>
>In "Re: [RRG] Re: Practical Proposals vs. endless theoretical
>discussions", you wrote:
>
>> In five years there will be > 2 billion new cell phones with IP
>> stacks.  How do you propose to provide global connectivity to
>> these?
>
>I usually mention that cellphones and perhaps some captive users
>with no alternatives in China are likely to use IPv6 in large
>numbers.   For brevity, I didn't mention it in the message you quote.
>
>Since the cellphone has its own inbuilt applications and typically
>local sources of stuff the mobile carrier is trying to sell to the
>customer, there is no major barrier to using IPv6.
>
>I suspect that many carriers will want to give their customers a
>public IP address, IPv4 or IPv6.  If they do that, the end-user can
>run their own VoIP software and bypass the carrier's voice system.
>The end-user might also be more able to purchase services, video
>etc. (AKA "content") from other companies than the carrier or its
>affiliates.
>
>I don't have any direct knowledge of IPv6 in China - its just
>something I heard of, which sounds likely.  I guess those people
>would not have a choice of an IPv4 service, because there is only
>one ISP in their area.
>
>All these are new users.
>
>For the next 5 or 10 or whatever years, I doubt that there will be
>an IPv6 routing scaling problem.  I think that the predicted masses
>of cellphone customers and likewise lots of users behind some
>massive ISPs in China will be connected via large ISPs, I guess with
>a small number of BGP advertised prefixes.
>
>I think that there would only be unsustainable growth in the number
>of IPv6 BGP routes if there was a widespread general uptake of IPv6
>by end users - including those who want to sell things to the
>legions of predicted mobile users.  A routing scaling problem for
>IPv6 would emerge if there was a few hundred thousand of these
>organisations who decided they need to be on IPv6, and that they
>want multihomed and/or portable space so badly that they get their
>own PI space.  Maybe this will happen.

Who says there needs to be growth in the number of IPv6
BGP routes? If we map/encaps the entire IPv6 space as an
overlay over the existing IPv4 Internet, we keep IPv6
prefixes out of the BGP routing tables and we get to
scale through mapping w/o affecting routing scaling.

Fred
[email-masked] 

>There is only one routing scaling problem at present - IPv4.  The
>only way IPv6 will help with that is if enough ordinary end-users
>like present-day end-users, with desktop PCs, applications, servers,
>server farms, hosting companies, office networks etc. decide that
>they want to pay for a service which is IPv6-only, and at the most
>share a single IPv4 address via something like Dual Stack Lite.
>
>It is really hard for me to imagine this happening - search for
>"lite" at: http://psg.com/lists/rrg/2008/maillist.html.
>
>Other folks have no trouble imagining this sort of thing.  But they
>have been imagining this for over a decade, and it hasn't happened
>yet.
>
>They tend to think of the IPv4 sky falling in ca. 2011 when the
>fresh blocks of unused address space are snapped up, but I think
>this will be the start of a long period of using the space more
>intensively.  I think there is a lot of scope for doing this, and
>that for a very long time it will be cheaper and better to keep
>looking after customers with connectivity to the Internet they want
>and need: IPv4, rather than trying to sell them a service to some
>other Internet which only connects to a fraction of users.
>
>I am not saying that there won't be a significant number of captive
>home/office customers and cell-phone users on IPv6 in by 2018 or
>perhaps 2013 - they may well be quite a few.  I am not saying that
>IPv4 will go forever, or that IPv4 NAT is a good thing.  I am not
>yet convinced by the various arguments for why large numbers of
>current end-users and their like will adopt IPv6-only services
>inside 10 years.
>
> -  Robin
>
>
>--
>to unsubscribe send a message to [email-masked] 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
>

--
to unsubscribe send a message to [email-masked] 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

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 16 Sep 2008 18:29:34 +0300

Well, I think that the IPv6 enabled terminals/sites would like to be
reachable natively through IP6. So it looks like there will be a lot of
multihoming needs as both IPv6 and IPv4 will co-exist.

And those sites/terminals that start to use IPv6 in parallel with IPv4
need to go through "renumbering" process; adding the IPv6 addresses into
the connectivity system (DCHP, DNS, FW, ACL). This renumbering should be
acceptable.   

- Hannu

---------
 >I think that there would only be unsustainable growth in the number of

>IPv6 BGP routes if there was a widespread general uptake of IPv6 by end

>users - including those who want to sell things to the legions of 
>predicted mobile users.  A routing scaling problem for
>organisations who decided they need to be on IPv6, and that they want 
>multihomed and/or portable space so badly that they get their own PI 
>space.  Maybe this will happen.

Who says there needs to be growth in the number of IPv6 BGP routes? If
we map/encaps the entire IPv6 space as an overlay over the existing IPv4
Internet, we keep IPv6 prefixes out of the BGP routing tables and we get
to scale through mapping w/o affecting routing scaling.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Sep 2008 17:35:10 +0200

[2 billion cell phones in the next 95 years seems on the low side.]

> scale through mapping w/o affecting routing scaling.

There still needs to be a box that takes an IPv6 packet and decides  
where that packet should go based on its destination address and  
therefore this box needs to run a protocol to learn which address  
prefixes go where.

The only thing that such an overlay buys us over multiprotocol BGP is  
that the routing in the overlay network can be less dynamic because it  
doesn't have to know about the status of the network in the middle. If  
the destination is single homed the mapping can even be static but if  
the destination is multihomed then the mapping must still react to a  
smaller set of routing changes.

(One might observe that if BGP had been designed better those same  
advantages could have been realized without an overlay or new  
protocols.)

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2008 08:40:34 -0700

>From: Iljitsch van Beijnum [mailto:[email-masked]] 
>Sent: Tuesday, September 16, 2008 8:35 AM
>To: Templin, Fred L
>Cc: Robin Whittle; Routing Research Group; Steven Blake
>Subject: Re: [RRG] 2 billion IP cellphones in 2103 & mass 
>adoption of IPv6 by currentIPv4 users
>

Call that box a LISP ITR, e.g., and the decision of where
the packet goes is based on resolving an IPv6 EID to an
IPv4 RLOC. That is a mapping function; not routing function.

Fred

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Sep 2008 17:44:16 +0200

> IPv4 RLOC. That is a mapping function; not routing function.

Wouldn't a rose by another name be just as unscalable?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2008 08:45:23 -0700

>From: Flinck, Hannu (NSN - FI/Espoo) [mailto:[email-masked]] 
>Sent: Tuesday, September 16, 2008 8:30 AM
>To: Routing Research Group
>Subject: RE: [RRG] 2 billion IP cellphones in 2103 & mass 

Simply call it "IPv6 enabled terminals reachable through
IPv6", then I am fine with it. "Native" may mean different
things to different people, and what does the terminal
care as long as it can send/receive IPv6 packets?

>the connectivity system (DCHP, DNS, FW, ACL). This renumbering 

I haven't followed the renumbering discussions all that
closely, but do you consider the assignment of IPv6
addresses/prefixes where there were none previously as
a "renumbering event"?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2008 08:51:37 -0700

>Sent: Tuesday, September 16, 2008 8:44 AM
>To: Templin, Fred L
>Cc: Routing Research Group

Eh? AFAICT we have the global DNS as an example of scalable
mapping and the global BGP as a counter-example of scalable
routing.

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2008 09:15:40 -0700

>Sent: Tuesday, September 16, 2008 9:03 AM
>To: Templin, Fred L
>On 16 sep 2008, at 17:51, Templin, Fred L wrote:
>
>> mapping
>The DNS will tell you (after some delay) that www.google.com has  
>addresses 66.249.91.99, 66.249.91.103, 66.249.91.104 and  
>66.249.91.147, but not which of them are reachable and which aren't.
>
>So for single homed destinations you're in business (if we ignore the  
>caching / initial packets lost issues) because you don't need to know  
>whether those are reachable, but for multihomed destinations you  
>either need a protocol that pushes out dynamic information (like BGP)  
>or you need to run an additional protocol to determine reachability  
>(like shim6 REAP).

[LISP], Section 6.3 addresses Routing Locator Reachability.
My understanding of the final paragraph of that section is
that LISP ITRs might benefit by 'pinging' potential ETRs
periodically. The SEAL explicit probing mechanism can be
used for that purpose.

Fred

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 16 Sep 2008 18:01:44 -0400 (EDT)

> From: "Templin, Fred L" <[email-masked]>

    > Call that box a LISP ITR, e.g., and the decision of where the packet
    > goes is based on resolving an IPv6 EID to an IPv4 RLOC. That is a
    > mapping function; not routing function.

Ah, no - if there is a substantial amount of deployed connectivity mesh (i.e.
network) in which there is native IPv6 routing.

_In that part of the network_, you will have to inject routes to all those
'mapped' IPv6 destinations, in order for IPv6 packets to those destinations to
be correctly forwarded through that deployed connectivity mesh.

Map+Encap is only a 'pure' mapping solution when it's deployed all the way at
the edges _everywhere_ (i.e. no IPv6 router has anything except a 'default'
route, and maybe a few local routes). If you have some parts of the network
where M+E is not deployed, then it has a routing component (see above) in
those parts of the network.

	Noel

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2008 15:28:05 -0700

Noel, 

>From: Noel Chiappa [mailto:[email-masked]] 
>Sent: Tuesday, September 16, 2008 3:02 PM
>To: [email-masked]
>Cc: [email-masked]

It seems like we are still early enough along in IPv6 deployment
such that the address space has not become sufficiently fragmented
to preclude rules such as:

  Prefix:    Action:
  *******    *******
  ABCD::/3   route
  XYZW::/3   map+encaps
  (etc)

So, if we have one or a few coarse-grained prefixes that a
router can use to tell whether something should be routed
or map/encaps'd, that should be sufficient to keep the
routing tables small - right?

Fred

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Sep 2008 19:01:25 -0400

>>> stacks.  How do you propose to provide global connectivity to

If this is true, and it sounds plausible, and if this $ 200 billion  
industry (2 billion x $ 100 per) needs IPv6 and
a new routing mechanism, why isn't this list flooded by cell-phone  
engineers ?
Do they believe in magic ?
Do they just don't know the IETF & IRTF exist ?
Or do they have other plans ?

Regards
Marshall

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 17 Sep 2008 10:57:23 +0800

On Sep 17, 2008, at 7:01 AM, Marshall Eubanks wrote:

> industry (2 billion x $ 100 per) needs IPv6 and a new routing  
> mechanism, why isn't this list flooded by cell-phone engineers ?

Mobile operators, in many cases, appear in many cases to be slow to  
acknowledge that they are in fact SPs, and that their networks must be  
designed and operated as SP networks, even when they explicitly and  
aggressively market services like 3G connectivity for laptops/mobiles  
(as I'm typing this message, I'm sitting on a ferry, connected via an  
HSDPA USB adaptor to a wireless carrier's network).  I've personally  
held conversations with the senior technical management of multiple  
mobile operators wherein I pointed out to them that they were access  
SPs and ought to design/operate their networks as such, and they  
vehemently denied this, despite their aggressive marketing of GPRS/ 
EDGE/3G connectivity services, until I finally whipped out my mobile  
phone and started accessing Web sites and sending/receiving IMs over  
their respective networks in order to make the point in an irrefutable  
manner.

The result has invariably been a sort of chagrined epiphany, followed  
by varying degrees of bemusement, dismay, and incipient panic.

> Do they believe in magic ?

It would almost appear that way, in some cases, heh.

> Do they just don't know the IETF & IRTF exist ?

Oftentimes, only a few people within the mobile operator organization  
seem to really know about and understand IP, and very few of them  
participate in IETF/IRTF and/or other non-mobile standards bodies or  
industry conclaves (there are exceptions, of course, and awareness/ 
engagement seems to be increasing, over time).  In many cases, their  
IP-based networks appear to've have grown organically, without much in  
the way of conscious design and planning; once their higher-speed IP- 
based connectivity services start to receive significant uptake,  
there's a lot of concern and scrambling around to increase capacity,  
resiliency, redundancy, et. al.

In some ways, what's happening in the mobile broadband space seems to  
faithfully echo the various trends, challenges, and reactions which  
have taken place in the wireline broadband space, but compressed  
greatly in time due to the rapid uptake of such services and the even  
higher initial oversubscription ratios in the wireless spac

> Or do they have other plans ?

There's a lot of NATting going on in this space, and an active desire  
on the part of management to provide the minimum of 'true' IP  
connectivity which users will accept and pay for, due to fears of  
service bypass, the desire to keep the user in a 'walled garden' of  
metered services, oversubscription concerns, etc.  The service terms  
for many wireless services often explicitly forbid the use of P2P  
technologies like BitTorrent, and in some cases ftp and other  
protocols/services which are viewed as being undesirable due to  
typically heavy usage patterns.

Note that the handset manufacturers are very responsive to carrier  
requirements in terms of the capabilities that they design into the  
handsets, even in markets where unlocked, individually-purchased  
mobiles are the norm.  AFAIK, none of even the most modern smartphones  
support IPv6, or allow it to be enabled by the user (correction  
welcome); which is rather ironic, given that, at present, IPv6-based  
mobile networks would represent a garden with especially high walls.

Also, I've yet to see a wireless access service which supports IPv6  
even for general-purpose computers connected via wireless adaptors.   
None of the mobile network operators with whom I've interacted provide  
IPv6 connectivity at all, or have disclosed an intention to do so in  
the near-to-medium-term future.

As to long-range plans, my subjective impression is that most of the  
mobile operators to whom I've spoken are just now coming to grips with  
the implications and requirements of operating production-quality IPv4  
networks, and IPv6, even though it would at first blush seem quite  
attractive to them, is in many cases not even on their radar.  I'm  
sure this will change over time, but quite slowly, given the industry  
characteristics noted above.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // +852.9133.2844 mobile

      History is a great teacher, but it also lies with impunity.

                    -- John Robb

---

From: "Tony Li" <[email-masked]>
Date: Wed, 17 Sep 2008 01:16:42 -0700

|If this is true, and it sounds plausible, and if this $ 200 billion  
|industry (2 billion x $ 100 per) needs IPv6 and
|a new routing mechanism, why isn't this list flooded by cell-phone  
|engineers ?
|Do they believe in magic ?
|Do they just don't know the IETF & IRTF exist ?
|Or do they have other plans ?

The mobile operators largely are disconnected from packet networking
technology and  are much more accustomed to a telephony style model where
their vendors deal with the specific technical issues and present them with
a complete, prepackaged technical solution.  They are extremely unlikely to
get involved here.

Imagine your local TV broadcaster becoming involved in setting HDTV
standards.

Regards,
Tony

Disclaimer: my employer (and more specifically the parent company of my
employer) is exactly one such vendor.

---

From: Bruce Curtis <[email-masked]>
Date: Wed, 17 Sep 2008 09:35:49 -0500

On Sep 16, 2008, at 9:57 PM, Roland Dobbins wrote:
> There's a lot of NATting going on in this space, and an active  
> desire on the part of management to provide the minimum of 'true' IP  
> mobiles are the norm.  AFAIK, none of even the most modern  
> smartphones support IPv6, or allow it to be enabled by the user  
> (correction welcome); which is rather ironic, given that, at  
> present, IPv6-based mobile networks would represent a garden with  
> especially high walls.

   This is a handset manufacturer rather than a wireless provider but  
they seem to have given IPv6 some thought.

   About 8 minutes into this presentation they talk about one reason  
why they are interested in IPv6.

   About 11 minutes in there is a list of mobile devices that have  
support for IPv6,  this of course doesn't address the issue of whether  
it's allowed to be enabled by the user on a given wireless provider's  
network.

http://www.youtube.com/watch?v=o5RbyK0m5OY

> None of the mobile network operators with whom I've interacted  
> provide IPv6 connectivity at all, or have disclosed an intention to  
> do so in the near-to-medium-term future.
>
> mobile operators to whom I've spoken are just now coming to grips  
> with the implications and requirements of operating production- 
> quality IPv4 networks, and IPv6, even though it would at first blush  
> seem quite attractive to them, is in many cases not even on their  
> radar.  I'm sure this will change over time, but quite slowly, given  
> the industry characteristics noted above.
>

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 17 Sep 2008 22:53:03 +0800

On Sep 17, 2008, at 10:35 PM, Bruce Curtis wrote:

> support for IPv6,  this of course doesn't address the issue of  
> whether it's allowed to be enabled by the user on a given wireless  
> provider's network

I can set up a mobile provider data connection on my Nokia E61i and  
specify either IPv4 or IPv6 (but not dual-stack), but not much else; I  
believe that IPv6 is supported on the WiFi interface, as well, but it  
is always-on, and cannot be enabled/disabled or configured by the user  
in any way, AFAICT.

To date, I've not encountered a mobile provider nor a hotspot operator  
offering or actively planning to offer IPv6 connectivity, but that's  
just my subjective experience; perhaps others have examples they can  
share.  If I were to hazard a guess, it would be that IPv6 may show up  
in DCNs (as it has in the cable broadband access space) before it does  
on the production network.

                    -- John Robb

---

From: Bruce Curtis <[email-masked]>
Date: Wed, 17 Sep 2008 10:49:47 -0500

On Sep 17, 2008, at 9:53 AM, Roland Dobbins wrote:

> specify either IPv4 or IPv6 (but not dual-stack), but not much else;  
> I believe that IPv6 is supported on the WiFi interface, as well, but  
> it is always-on, and cannot be enabled/disabled or configured by the  
> user in any way, AFAICT.

   I think the presentation also mentioned that a lot of the  
applications supported IPv6 which is also important but still not  
useful if the wireless provider does not provide IPv6.

> To date, I've not encountered a mobile provider nor a hotspot  
> operator offering or actively planning to offer IPv6 connectivity,  
> but that's just my subjective experience; perhaps others have  
> examples they can share.  If I were to hazard a guess, it would be  
> that IPv6 may show up in DCNs (as it has in the cable broadband  
> access space) before it does on the production network.

   This hotspot operator is providing IPv6 access for free until the  
end of 2008.

http://hotspot.monzoon.net/downloads/Pressetext_Hotzones_IPv6_Monzoon_E.pdf

---

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 18 Sep 2008 00:37:51 +0800

> http://hotspot.monzoon.net/downloads/Pressetext_Hotzones_IPv6_Monzoon_E.pdf

This is very cool - I hope others will follow their example.

                    -- John Robb

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Sep 2008 21:12:18 +0200

> useful if the wireless provider does not provide IPv6.

We can tunnel v6 over v4 if necessary, lack of support in ISP  
infrastructure won't be a show stopper.

---

From: Wesley George <[email-masked]>
Date: Wed, 17 Sep 2008 16:31:12 -0400 (EDT)

> Marshall

Well... there are those of us that largely lurk here, and sort 
through the messages every fortnight or so because of time 
constraints and the signal to noise ratio on this list.

However, I do need to chime in on this one to provide some counterpoint to 
what I gather is Robin's personal opinion on IPv6 adoption timelines and 
how they reflect on RRG's course of action.

Disclaimer - this is all based on my own experience within one of these 
mobile operators, so YMMV with other networks. I am not trying to wave my 
employer around in this discussion, but I thought it would be helpful to 
respond with my perspective.

Roland brings up some good points about how long the mobile space has been 
in denial about their IP needs. They spend a lot of time thinking about 
voice, because it was always the cash cow, but IP Data is relatively new, 
and they're still not exactly sure what it means for their long-term 
plans and profits. It has a nasty habit of changing 
the entire planning paradigm, and many operators aren't keeping up.

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

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.

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.

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.

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.

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.

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

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.

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

Thanks,
Wes

On Wed, 17 Sep 2008, Roland Dobbins wrote:

>> industry (2 billion x $ 100 per) needs IPv6 and a new routing mechanism, 
>> why isn't this list flooded by cell-phone engineers ?
>
> aggressively market services like 3G connectivity for laptops/mobiles (as I'm 
> typing this message, I'm sitting on a ferry, connected via an HSDPA USB 
> adaptor to a wireless carrier's network).  I've personally held conversations 
> with the senior technical management of multiple mobile operators wherein I 
> pointed out to them that they were access SPs and ought to design/operate 
> their networks as such, and they vehemently denied this, despite their 
> aggressive marketing of GPRS/EDGE/3G connectivity services, until I finally 
> whipped out my mobile phone and started accessing Web sites and 
> sending/receiving IMs over their respective networks in order to make the 
> point in an irrefutable manner.
>
> The result has invariably been a sort of chagrined epiphany, followed by 
> varying degrees of bemusement, dismay, and incipient panic.
>
> Oftentimes, only a few people within the mobile operator organization seem to 
> really know about and understand IP, and very few of them participate in 
> IETF/IRTF and/or other non-mobile standards bodies or industry conclaves 
> (there are exceptions, of course, and awareness/engagement seems to be 
> increasing, over time).  In many cases, their IP-based networks appear to've 
> have grown organically, without much in the way of conscious design and 
> planning; once their higher-speed IP-based connectivity services start to 
> receive significant uptake, there's a lot of concern and scrambling around to 
> increase capacity, resiliency, redundancy, et. al.
>
> faithfully echo the various trends, challenges, and reactions which have 
> taken place in the wireline broadband space, but compressed greatly in time 
> due to the rapid uptake of such services and the even higher initial 
> oversubscription ratios in the wireless spac
>
> There's a lot of NATting going on in this space, and an active desire on the 
> part of management to provide the minimum of 'true' IP connectivity which 
> users will accept and pay for, due to fears of service bypass, the desire to 
> keep the user in a 'walled garden' of metered services, oversubscription 
> concerns, etc.  The service terms for many wireless services often explicitly 
> forbid the use of P2P technologies like BitTorrent, and in some cases ftp and 
> other protocols/services which are viewed as being undesirable due to 
> requirements in terms of the capabilities that they design into the handsets, 
> even in markets where unlocked, individually-purchased mobiles are the norm. 
> AFAIK, none of even the most modern smartphones support IPv6, or allow it to 
> be enabled by the user (correction welcome); which is rather ironic, given 
> that, at present, IPv6-based mobile networks would represent a garden with 
> especially high walls.
>
> Also, I've yet to see a wireless access service which supports IPv6 even for 
> general-purpose computers connected via wireless adaptors.  None of the 
> mobile network operators with whom I've interacted provide IPv6 connectivity 
> at all, or have disclosed an intention to do so in the near-to-medium-term 
> future.
>
> As to long-range plans, my subjective impression is that most of the mobile 
> operators to whom I've spoken are just now coming to grips with the 
> implications and requirements of operating production-quality IPv4 networks, 
> and IPv6, even though it would at first blush seem quite attractive to them, 
> is in many cases not even on their radar.  I'm sure this will change over 
> time, but quite slowly, given the industry characteristics noted above.
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Sep 2008 20:16:00 +0200

> AFAIK, none of even the most modern smartphones support IPv6, or allow 
> it to be enabled by the user (correction welcome)
Correction, there are devices that support IPv6. I expect there to be 
more in the future.

IPv6 being turned on in the operator networks is another matter, however 
-- very similar to consumer ISP situation on wired side.

The statistics on actual number of data capable phones are a bit hard to 
come by last time I checked. But I think we might already have 2 billion 
IP capable phones, the turnover rate in phones is very high so most 
devices are new. Though not every user is necessarily launching apps 
that use IP. And most people that do wouldn't have applications that are 
always on, yet at least.

Anyway, now back to your regularly scheduled discussion of attempting to 
fix routing and the Internet architecture...

Jari

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 19 Sep 2008 02:17:40 +0800

On Sep 19, 2008, at 2:16 AM, Jari Arkko wrote:

> Correction, there are devices that support IPv6. I expect there to  
> be more in the future.

My E61i *supports* IPv6, but it doesn't let me configure it in any  
meaningful way, or enable/disable it.  I assume it would work in a  
DHCPv6 scenario, though I've not tried it.

I should've worded that differently, though, you're right.

                    -- John Robb

---

From: Wesley George <[email-masked]>
Date: Fri, 19 Sep 2008 08:08:51 -0400 (EDT)

Win mobile supports IPv6 - appears it's supported it in some fashion since 
WM2003: http://msdn.microsoft.com/en-us/library/ms838090.aspx

Matter of fact, 6to4 appears to be enabled by default. One of my 
co-workers has an HTC Mogul running WM6 and he has a little software 
router application that allows him to create an ad-hoc WiFi network using 
the EVDO rev.a network as the internet connection. Brilliant, until my 
ipv6-enabled PC tried to actually use 6to4 and the appropriate relays are 
apparently blocked upstream "for security reasons."

Does not appear to be supported on the iphone (may be that ATT made them 
disable - carriers can ask for certain features to be locked down in their 
specific load of OS)

Symbian definitely supports it.

Can't find anything conclusive on PalmOS.

Thanks,
Wes

On Thu, 18 Sep 2008, Jari Arkko wrote:

>
>> AFAIK, none of even the most modern smartphones support IPv6, or allow it 
>> to be enabled by the user (correction welcome)
> Correction, there are devices that support IPv6. I expect there to be more in 
> the future.
>
> IPv6 being turned on in the operator networks is another matter, however -- 
> very similar to consumer ISP situation on wired side.
>
> The statistics on actual number of data capable phones are a bit hard to come 
> by last time I checked. But I think we might already have 2 billion IP 
> capable phones, the turnover rate in phones is very high so most devices are 
> new. Though not every user is necessarily launching apps that use IP. And 
> most people that do wouldn't have applications that are always on, yet at 
> least.
>
> Anyway, now back to your regularly scheduled discussion of attempting to fix 
> routing and the Internet architecture...
>
> Jari
>
>
> --

---

From: Robin Whittle <[email-masked]>
Date: Fri, 26 Sep 2008 22:52:52 +1000

Hi Wesley,

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

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

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

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

> 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

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.

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

> reachable natively via IPv6 to reduce the amount of translation that we

I agree.

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

> 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

---

From: Wesley George <[email-masked]>
Date: Mon, 29 Sep 2008 06:25:59 -0400 (EDT)

inline below

Thanks,
Wes

> circuit-switched radio link.
Well, there's ways around this like using the inbound paging channel (the 
thing that tells the phone to wake up its cellular radio from standby to accept 
an inbound call, and accepts SMS messages) to make always on, but mostly 
in standby, applications work, but you're right, it is a limiting factor 
to simply porting existing (chatty) applications over to the mobile 
space without help from the carrier and their infrastructure.

> practice all such cell-phones used IPv6.
Yes, that is one application. The other is when we actually do run out of 
IPv4 space in some indeterminate number of years. I'm not interested in 
debating whether you believe the projected dates or not, or what you 
think people will do when it happens, but if it does, IPv6-only content 
will crop up by necessity. IMO, whether some method will be employed to 
make it reachable via IPv4 is not germaine to the discussion, because it 
will still mean that there is an increase in IPv6 deployment.

> operators actually run things today.

that's sorta why I delurked. I are a 3G operator, and those examples are 
not theoretical. Scary, huh?

> So I don't think widespread IPv6 adoption in cellphones will

Admittedly the problem may be further off in the DFZ. However, I don't 
know why we would design something that only applies to the DFZ, since the 
route scale problem has potential to be much worse within a given network 
than outside it. What incentive do I have as an operator to deploy some 
fantastic new thing for the DFZ if I still have to have routers that cost 
millions to deal with my internal network routing table?
Assuming that always-on IP-enabled applications continue taking off, I have ~55M 
handsets to address. Accepting in the short term (5 yrs or so) there will 
be some significant amount of IPv4-only devices, as those age out, the 
IPv6 table continues to grow in my network. The DFZ may not have to see 
much of that except in some mobility cases (depends on implementation), 
but you can't argue with the idea that even with well-built address 
hierarchies, some routers in the network are going to have to deal with 
orders of magnitude more routes than they do today. What better place to 
test out a new scalable routing infrastructure than in a controllable 
network before it has to be implemented by the DFZ across multiple 
networks?
> The trouble is there are two ships.

No, I don't think so. I don't disagree that we have a potential problem on 
IPv4, but this isn't an either/or thing, or a phase I/phase II thing, because 
we're going to exist in a dual-stack environment indefinitely, so we need 
a dual-stack solution. Solving IPv4 first simply delays the inevitable, 
and while it may lead to a more efficient solution for IPv4-only and for 
IPv6-only, it's highly unlikely that two separate solutions run 
simultaneously will be as efficient in dual-stack as one solution that 
has some compromises to make it work for both simultaneously. Even if 
there are still separate processes for IPv4 vs IPv6, you still can take 
advantage of efficiences in implementation by being able to reuse 
algorithms and hardware components between the two stacks.

Consider that all routers have a finite amount of space for either IPv4 
routes, IPv6 routes, or some combination of the two. The very fact that a 
router has to exist in dual-stack means that the existence of the IPv6 
table, even if it's smaller, will exacerbate any scaling problems that 
we're experiencing at IPv4. Why not make both as efficient as possible?

Part of the issue we have here is talking about how you implement a fundamental 
change in routing architecture. There's never a good time to do it, and 
most of the debate I've seen focuses on what can and cannot change, 
levels of complexity, etc. Why woudn't we take advantage of IPv6's 
admittedly laggard deployment to ensure that we have a solution in place 
before it becomes mission-critical, deeply entrenched and therefore 
harder to change? Perhaps the necessity of scaling the routing table will 
become its own deployment incentive.
> time - will soon be getting on board.

So if I agreed with your two ships idea, what makes the two so 
fundamentally different that we can't solve 
the problem common to them both simultaneously? I don't disagree that the 
solution will have to be tweaked and evolved from its initial deployment 
as we learn how it works in a production environment, but are you 
actually suggesting that we'll have a different solution for IPv4 vs 
IPv6, rather than one solution that we continue to refine for both?

I'm sure you can speak for IVIP, but because I'm not an expert on any of 
the proposed solutions and variations on them, and don't want to assume, 
I'll risk showing ingorance and ask: 
Are any of the proposals so fundamentally wrapped around IPv4 that their 
basic implementation couldn't work for IPv6 without major alteration?
If the answer is no, why do we keep coming back to debate whether we 
should do IPv4 first vs IPv4+IPv6 simultanteously?

Given the long-term nature of any redesign of this magnitude, the 
timelines for implementation, challenges to deployment, etc, I can't see 
how any solution that didn't have a method for handling IPv6 would be 
seriously considered viable at this point.

Maybe we're all affected by a collective hysteria about the necessity of IPv6, 
and we'll realize later that it wasn't as big of a deal as we thought. 
However, the amount of my customers that are asking about IPv6 
connectivity and starting to treat it as table stakes to sell them 
service tells me otherwise in terms of the potential for increase in IPv6 
deployments over the next few years. The prognostication about IPv4 
exhaust has done a lot to force people to look more seriously at 
deploying IPv6, even if they don't necessarily have anything to worry 
about. In most cases, once the major SPs support IPv6, it's easier for 
all of those companies, schools, etc to simply enable it, rather than 
risking the possibility that some potential customer/user cannot reach 
them, but can reach a competitor. That may be the closest thing we get to 
a "killer app" on IPv6 anytime soon, but in my mind, that's enough to make 
sure we fix it so that it'll work right long-term.