Re: Text on 3GPP UE tunneling

[Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>]

-- Friday, January 23, 2004 17:13:39 +0200 Pekka Savola <pekkas@netcore.fi>
wrote/a ecrit:

> Hello,
> 
> (wg co-chair hat on)
> 
> The 3GPP analysis document is being finished, and as there was not so 
> much feedback, the chairs would like to avoid WG last-calling the 
> document again.
> 
> However, to avoid document revision churn and get an acceptable
> outcome, only the extensively discussed topic, UE tunneling, seems to
> warrant some discussion before shipping the document, on Monday or
> Tuesday.
> 
> Below is a proposal on the wording to use (pay attention to the middle
> paragraph).  The intent is to try to document all the sides of the
> argument and avoiding opening too many cans-of-worms, while being
> brief.
> 
> Please send feedback whether you think that OK or not on the list.  If 
> you do not think it is appropriate, you MUST supply an alternative 
> wording.
> 
> Thanks,
>  Pekka & Jonne
> 
> [...]
>     The use of private IPv4 addresses in the UE depends on the support
>     of these addresses by the tunneling mechanism and the deployment
>     scenario. In some cases public IPv4 addresses are required, but if
>     the tunnel endpoints are in the same private domain, or the
>     tunneling mechanism works through IPv4 NAT, private IPv4 addresses
>     can be used. One deployment scenario example is using a laptop
>     computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in
>     IPv4 packets in the laptop computer and IPv4 PDP context is
>     activated. The used tunneling mechanism in that case depends on the
>     support of tunneling mechanisms in the laptop computer. Another
>     deployment scenario is making IPv6-in-IPv4 tunneling in the UE
>     itself.
> 
>     Closer details for an applicable tunneling mechanism are not
>     analyzed in this document. However, a simple host-to-router
>     (automatic) tunneling mechanism may be a good fit.  There is not
>     yet consensus on the right approach. Primarily, ISATAP [ISATAP]
>     has been proposed, but some issues have been raised about it, 
>     such as its unnecessary features and relative complexity for a 
>     simple task like this, and its inadequacy in providing security 
>     when crossing administrative domains. Proposed solution 
>     alternatives have been (at least) a simplified, but probably 
>     non-interoperable, version of ISATAP, and STEP [STEP]. 

TSP is another alternative and should be noted. Suggesting:

version of ISATAP, STEP and TSP.

Marc.

>In any 
>     case, further work is needed to find out the requirements for the 
>     scenario and to specify the mechanism.
> 
>     To generally solve this problem (IPv6 not available in the 3GPP
>     network), this document strongly recommends the 3GPP operators to
>     deploy basic IPv6 support in their GPRS networks. That also makes
>     it possible to burden the transition effects in the network and
>     make the 3GPP UEs simpler.
> [...]
> 
> [STEP] refers to draft-savola-v6ops-conftun-setup-01.txt
> 
> If the middle paragraph does not seem to be agreeable, we may use 
> something more generic, like:
> 
>     Closer details for an applicable tunneling mechanism are not
>     analyzed in this document. However, a simple host-to-router
>     (automatic) tunneling mechanism may be a good fit.  Further
>     work is needed find out the requirements of the scenario
>     and to specify the mechanism.
> 
> 



------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------