[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

inline below

Thanks,
Wes

On Fri, 26 Sep 2008, Robin Whittle wrote:


Hi Wesley,

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


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


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


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.
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
lead to a scaling problem - assuming anything less than the current
IPv4 260k routes is not regarded as a problem.
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? 


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

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

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