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

From: <[email-masked]>
Date: Fri, 3 Oct 2003 11:09:20 +0200

> On Fri, 3 Oct 2003 [email-masked] wrote:
> > > On Thu, 2 Oct 2003 [email-masked] wrote: [...]
> > > > > According to my current understanding, the above does not 
> > > > > require big investments and in many cases software 
> upgrades are 
> > > > > sufficient.
> > > > 
> > > > It's not about investments. It's about touching the running 
> > > > system.
> > > > People do not trust IPv6 at the moment. Tunneling is a 
> way to show 
> > > > them what could be done in a very inexpensive and easy way.
> > > 
> > > Would it be easier to convince the ops folks that IPv6 is
> > > non-intrusive if 
> > > you _added_ (not upgraded_) one IPv6-capable GGSN, (and other 
> > > components 
> > > as needed), which would not serve regular IPv4 users?
> > 
> > Yes, easier but still not as easy as tunneling since there is other 
> > equipment to touch (as written by in an earlier email):
> > - SGSN support for IPv6 signalling
> > - HLR support for IPv6
> 
> Right.. but could these be served in some other node as well? 
> (I don't 
> know the 3GPP arch in enough detail..)

Also if you serve it in some other node, you have to implement the
functionality. There is less to implement if you do tunneling (very
little signalling).

> 
> > > Partially parallel infrastructure ("dedicated low-end IPv6 router 
> > > running tunnels") is how many have done it during the 
> first phases 
> > > in ISP space.  Would this be a possibility for 3GPP as well?
> > 
> > I'd prefer to do tunneling instead of a parallel infrastructure. 
> > Parallel infrastructures cost money to run them - tunneling 
> > infrastructure is probably cheaper.
> 
> The problem here is that this doesn't seem to do anything to 
> convince the ops folks that they should be enabling the v6 
> support in the main network
> -- which is the goal here.  They wouldn't get any experience 
> with native v6 or other nice new features this way.
> 
> So, it seems if we do something like this, it will stay 
> around for a long time, and we won't get to the goal, the 
> real IPv6 service, any time soon.
> 
> So, tunneling might be counter-productive here.  
> 
> (Note that the situation is slightly different when your home 
> networks support v6, but the network you roam to, doesn't.)

Maybe. But if the hurdle to go native is too high then we have no IPv6
at all. And that's even worse! 

Native IPv6 will come once IPv6 usage takes up and apps are around that
use IPv6. But to initiate the app development it is crucial to have a
network out that supports IPv6. This network has to be built without
business case. Therefore, tunneling is the only way to do this IMHO.

I don't think that this is counter-productive here.

>  
> > I still think that having tunneling mechanisms in the v6ops 
> standards 
> > is a good thing and would convince more service providers to do the 
> > first steps of the IPv6 introduction. And this is needed to 
> spread out 
> > IPv6 to the users and service developers to facilitate the 
> development 
> > of services using IPv6 which will finally lead to the full 
> success of 
> > IPv6.
> 
> There is a doubt that such mechanisms are counter-productive 
> for IPv6 deployment (see above for example), and whether such 
> mechanisms could be done reliably/easily/robustly/etc. enough 
> without influencing too much on what must be done at the UE 
> side (I'd prefer to keep that minimal).

I don't care too much about reliability/robustness/etc of the first IPv6
introduction step. By the way, often 3G UE will be used as modem for
PCs. And, on the PC side tunneling mechanisms are already implemented
and very easy to use (at least in the case of Windows XP with ISATAP).

I see tunneling as a quite easy and cheap mechanism to bring IPv6 to the
users. As in the IPv4-Internet, applications will just appear. And once
they appear for IPv6, native IPv6 will be needed (robustness, etc) but
the business case will be there to do this!

Regards
Andreas

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Oct 2003 10:27:35 +0300 (EEST)

> functionality. There is less to implement if you do tunneling (very

You'll have to implement _something_ anyway, because the tunnels have to
be terminated.  The termination need not be done at a 3GPP equipment
though..

I guess what you are saying that you don't want to implement any 3GPP IPv6
functinality before the business case, but would be OK to implement
generic IPv6 features which wouldn't clash with current v4 3GPP
operations?

> I don't think that this is counter-productive here.

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.

> introduction step. 

Oh, you should care! :-)  It has been a reason why IPv6 deployment hasn't 
kicked off yet.  A reason why vendors aren't putting on v6 by default, 
etc.  Everything is about reliability and robustness.  If folks try IPv6, 
and it doesn't work, they're not likely to try again any time soon!

For a couple of perspectives, have a look at:
http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-6bone-mess-01.txt
http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-01.txt

> By the way, often 3G UE will be used as modem for

This has nothing to do with 3GPP (except that it's done on top of v4 3GPP
network), right?  The UE doesn't know anything of v6, and the 3GPP network
doesn't know anything of v6.  The 3GPP operator is just acting as an IPv4
ISP, offering tunneled v6 service for folks using its private v4
addresses?
 
> the business case will be there to do this!

I fear the robustness etc. which you shrug away are preconditions for more 
generic deployment and application development.