RE: 3gpp-analysis-05: miscellaneous non-critical issues

[<Andreas.Schmid1@swisscom.com>]

> Well, let's add a comment from an operator here...
> 
> Here are some facts:
> - Today's 2.5/3G networks are running on IPv4.
> - Today's economic situation is quite difficult.
> - Nobody operating a network wants to touch a running system 
> if not absolutely necessary.
> 
> It is therefore very much needed to think about a phased 
> introduction of IPv6. It is just _not_ realistic to think of 
> a direct move from IPv4 to native IPv6 - let's make this clear here!
> 
> Operators _need_ mechanisms to introduce IPv6 in phases. A 
> first phase should be fully non-intrusive, cheap but still 
> secure. Tunneling from the UE (e.g. using ISATAP) seems to 
> perfectly be suited to meet these requirements. 
> 
> I expect the v6ops WG to write guidelines that help the 
> operators in the introduction of IPv6 in their networks. Such 
> guidelines just have to consider a phased introduction. 
> Everything else is just not realistic and not of use for 
> operators. I am looking forward to such documents from this group.
> 
> JW: I know that the current situation is not an easy one. And 
> I fully agree that the principle of phased IPv6 induction is correct.
> 
> I can also see that IPv6 can be tested / demonstrated etc. 
> using tunneling in the UE. But putting basic IPv6 support in 
> the GPRS network is not that difficult. IPv6 support in a 
> GPRS nw includes (at least) the following points:
> 
> * Upgrading (a) GGSN to support IPv6 PDP contexts (that 
> basically means dual stack support in the GGSN). This is only 
> needed on the "upper IP layer" / user layer in the 3GPP 
> architecture. Network layer (below GTP tunnels) can still be 
> IPv4. See RFC3314, Figure 2.
> * SGSN should support IPv6 PDP context signalling (especially 
> if charging is considered..), i.e. it must be possible to 
> activate an IPv6 PDP context.
> * HLR support for IPv6
> * IPv6 Access Point Names should also be configured to the 
> packet core DNS
> * you also might want to put up a (configured) IPv6-in-IPv4 
> tunnel from the GGSN e.g. to the IPv6 island (can be in the 
> operator's network or elsewhere) that provides IPv6 services
> * IPv6 capable firewall can also be considered

Thanks for that. However, we know what is needed. We run extensive tests
in our R&D site for years. But the transfer to the operating unit is
much easier if the running systems is just not touched at all.

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

> 
> Furthermore, introducing (some) IPv6 support in the network 
> does not cause problems with the current IPv4 network, i.e. 
> IPv6 can be run simultaneously without disrupting IPv4 
> traffic! This is not a 3GPP-specific thing; this is one of 
> the good sides of the dual stack deployment. There is no need 
> to immediately move from native IPv4 to native IPv6 support 
> in the cellular networks.

Of course, still you have to touch the running system. Operating people
don't like that.

One of the hidden problem might be that IPv6 testing had been done
mainly in the R&D site. These guys know what it is all about and have
enough trust to implement it. The operations guys have to go through
this step first. 

Regards
Andreas

> 
> Best Regards, 
> 		-Juha W.-
>