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
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:
On Sep 17, 2008, at 7:01 AM, Marshall Eubanks wrote: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 ?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 spacOr 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 <rdobbins@cisco.com> // +852.9133.2844 mobile History is a great teacher, but it also lies with impunity. -- John Robb -- 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
-- 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