Text on 3GPP UE tunneling

[Pekka Savola <pekkas@netcore.fi>]

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