RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues]

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Clipping the text quite a bit and tailing it down..

On Tue, 7 Oct 2003 Andreas.Schmid1@swisscom.com wrote:
> > [me:]
> > I'm not saying the networks have to be native through-out.  
> > Tunneling can very well be applied in many places if folks 
> > feel like it.  However, recommending tunneling at the 3GPP 
> > network <-> UE interface would have a significant impact on 
> > how 3GPP networks would get deployed & implemented.  
> > The changes at this interface would not be transparent.
> 
> True. But I still think that recommending a tunneling approach to the UE
> would help a lot to convince operators making the first steps to the
> IPv6 introduction. Remember, that this is just a first step. And, the
> native solution would follow within 1-2 years (which would again bring
> transparency back).

I'm not sure how much that would help.

There seem to be two cases, one with two subcases here:

 1) UE is used as a "modem" for a laptop (seems common in current GPRS 
networks)
   o UE doesn't have to know about IPv6 at all
   o UE implements only IPv4 stack, and not even much of that
   o The laptop performs the tunneling and has IPv6
  ==> this is not really (IMHO) a 3GPP scenario, but could perhaps be 
considered here as the "zeroeth step".  The solutions are probably pretty 
much the same as with Unmanaged/ISP scenarios behind NAT.  One could 
employ some tunneling mechanism at the laptop.

 2) UE is used standalone or as IPv6 router for a laptop
   o UE implements IPv6
   o Native IPv6 packets flow between the UE and the laptop (if plugged in)
   o UE acts as an IPv6 router/bridge for the laptop
   o compared to the above, useful mostly if you want IPv6 connectivity at 
     the UE as well as the laptop

  a) UE uses an IPv6 PDP context for its IPv6 connectivity
    ==> pretty straightforward, and long term good approach
    ==> in all other cases than this, the user pays (money, performance) 
        for the IPv6 tunneling overhead.

  b) UE uses a form of tunneling for its IPv6 connectivity
    ==> putting complexity to the UE
    ==> which are the cases where 1) above is not applicable?
    ==> could configured tunneling be made to work?

My initial take on this is that 1) would probably be pretty useful in the 
short term, but doesn't really require much at all.  2.b) seems like a 
case which is not so short-term solution, maybe needed if the UE 
implements and wants to use IPv6 services itself -- but aren't we then 
already quite far in the transition process, and IPv6 PDP context should 
be used instead.

(Are there other cases, like the laptop initiating a PDP context of its 
own or something.. I'm not sure..)

> => as stated above, tunneling is quite robust. Just performance is a
> problem. But application development is exactly the reason why I am in
> favor of a quick (and dirty) IPv6 introduction in the networks. You
> know, it's a quicken-egg problem. We have to see that we "lay the egg"
> as soon as possible to let application developers start implementing
> applications using IPv6. And tunneling is for me one very viable way to
> do the first step (of course it is still somehow "quick and dirty").
> Remember, that sometimes it is better to go for a 80/20 solution than to
> wait for the 100% solution...

I agree that some simple forms of tunneling, at least (configured tunnels,
what more do you need? :-) can be rather robust.  The more complexity you add, the more
fragile it gets.

But I'm not sure whether the tunnels (especially the more complex forms
of) are best applicable in 3GPP networks; the tunneling is absolutely a
major way in some other cases, like unmanaged networks. The 3GPP scenarios
are supposed to be somewhat special.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings