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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 10 Oct 2003 Andreas.Schmid1@swisscom.com wrote:
> > 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. 

Note that nowhere did I imply anything about Teredo at all. But I guess 
that's easily assumed by a reader.. :-)

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

No disagreement there, I certainly think this would be a very useful 
approach for many service providers.
 
> 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).

Configured tunneling methods don't need to be manually configured, unless 
you want them to be (see more below).

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

Right..

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

I suppose one can run your own applications on top of a Microsoft
operating system.  For example, a very simple GUI application which 
transparently configures/unconfigures configured tunnels.  Shouldn't be 
too difficult.

The point is, the current basic transition mechanism framework gives a lot
of tools, if one is just willing to take them and use them.

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

Some operators probably see this as more desirable than others.

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

Right.  The question is, is this scenario near-term enough?  Couldn't we 
be able to proceed with just "laptop tunneling" and recommending using 
IPv6 PDP context when the phones leveraging IPv6 emerge?

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

Note that "configured tunneling" refers to _somehow_ configuring the 
tunnel endpoints.  The configuration itself need not be done manually by 
the user.  At the face value, this may not be obvious..

For example, one might be able to use a number of different Over the Air 
techniques for configuring the tunnel -- see the section in the analysis 
document?  (I haven't discussed whether this is possible with 3GPP 
experts, but I don't see any reason why not..)
 
[...]
> 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....

Some others would probably count adding a few new 3GPP IPv6 features (as a 
start-up phase installation, until the services are there) as an 
acceptably cheap and automatic mechanism -- one which could be expanded 
easily when needed.

But I agree with you that the startup phase must be rather cheap and
relatively automatic.  Simplicity, reliability and security also come to
the mind.  I guess the argument is only about how much of these is enough
or too much..

[... snip to the end, except ...]

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

I'm seeing at least some convergence here, and clarifications on what 
"configured tunneling" means.  Therefore, it seemed useful to continue on 
list at least for now.  If you are more confortable with an off-list 
discussion, that's fine too.

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