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

From: <[email-masked]>
Date: Fri, 10 Oct 2003 15:55:47 +0200

> Clipping the text quite a bit and tailing it down..
> 
> On Tue, 7 Oct 2003 [email-masked] 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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Oct 2003 09:35:31 +0300 (EEST)

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

> service provider could offer the IPv6 tunnel server to get an acceptable

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

> 3GPP networks of today). 

Right..

> So ISATAP seems to be the solution of choice?!?

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.

> repeating this again. But you can believe me this!)

Some operators probably see this as more desirable than others.

[...]
> Where you want to use an application on the handset that is only running

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?

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

> 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