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

[<Andreas.Schmid1@swisscom.com>]

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

True, but we made quite bad experiences with this kind of tunneling
mechanisms (Teredo). They are not stable enough and really just a hack. 

I think, that even if it's not a "real" 3GPP scenario, the (3GPP)
service provider could offer the IPv6 tunnel server to get an acceptable
performance.

We are looking at what is available in commercial products today. Most
of our customers are using Windows (even if we don't like it - it's a
fact). And there, you have Teredo, ISATAP and 6to4 as automatic
tunneling mechanisms (I don't count on configured tunnels since the user
should not have to configure anything for IPv6).
Teredo is not really stable and very complex. 6to4 is just applicable if
you have a public address (and this is not the case for most if not all
3GPP networks of today). So ISATAP seems to be the solution of choice?!?
Of course, you could argue that you could convince Microsoft to
implement something else. But this could be difficult....

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

Right. But still, the operations department don't want this today (I am
repeating this again. But you can believe me this!)

>     ==> in all other cases than this, the user pays (money, 
> performance) 
>         for the IPv6 tunneling overhead.

Yes, but it's not much....

> 
>   b) UE uses a form of tunneling for its IPv6 connectivity
>     ==> putting complexity to the UE

Yes, I know this is probably only useful for smartphones...

>     ==> which are the cases where 1) above is not applicable?

Where you want to use an application on the handset that is only running
on IPv6.

>     ==> could configured tunneling be made to work?

No, we need automatic tunnels. Configuring the handsets is already too
complex for our customers! We need something plug&play...

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

I hope that IPv6-capable apps will appear soon - even for use on the
handsets. I am talking to game developers and try to tell them what the
advantages are of IPv6.

Remember that IPv6 is an enabler. The services will not be developed if
the network is not there. If we put the network there (cheap but still
automatic) the services will appear. But if we wait for the services to
implement IPv6 to the handsets this will never happen....

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

No idea, but I don't see them.

> 
> > => 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? :-) 

Configured tunnels are not what we want (see my remark above). 

> can be rather 
> robust.  The more complexity you add, the more fragile it gets.

Yes, but a solution like ISATAP is quite stable (as said in an earlier
mail, we use it in our operational intranet for months without
problems).

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

As said above, I would not see 3GPP networks as unmanaged networks.....


This is a long discussion we have. I am not that used to IETF mailing
lists. But I am happy to send you my comments off the list if you like.
Just respond me off the list if you think this is better.


Regards
Andreas