Subject: 3gpp-analysis: Recommendation on tunneling in the UE

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 13:13:34 +0200 (EET)

Hi,

Having read the -07 document, I have some cooked up some text to make the 
related issues a bit clearer.  The original:

====
    However, the UE may attach to a 3GPP network, in which the Serving
    GPRS Support Node (SGSN), the GGSN, and the Home Location Register
    (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP
    contexts. This may happen in early phases of IPv6 deployment. If
    the 3GPP network does not support IPv6 PDP contexts, and an
    application on the UE needs to communicate with an IPv6(-only)
    node, the UE may activate an IPv4 PDP context and encapsulate IPv6
    packets in IPv4 packets using a tunneling mechanism.

    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 (automatic or configured)
    in that case depends on the support of tunneling mechanisms in the
    laptop computer.
=====

Consider rewording:
=====
    However, the UE may attach to a 3GPP network, in which the Serving
    GPRS Support Node (SGSN), the GGSN, and the Home Location Register
    (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP
    contexts. This may happen in early phases of IPv6 deployment.

    In theory, the user's own 3GPP operator might not support IPv6 at 
    all.  However, such scenario is considered out of scope of this 
    document; the considerations for Unmanaged networks would apply
    [UNMANSCEN] [UNMANAN].

    Presupposing some form of IPv6 support, there are two cases
    to consider when the visited network does not support IPv6 PDP 
    contexts:

       1. The UE is used as a "modem" with e.g. a laptop computer.
          The UE does not have to even support IPv6 PDP contexts,
          and all the transition issues are dealt with by the
          supporting equipment.

       2. The UE is used independently, running IPv6 applications,
          and would desire IPv6 connectivity.

    In both cases, it may be desirable to be able to create a tunnel
    between the UE (or the supporting equipment) and the user's 3GPP
    operator's IPv6 equipment.

    A way to easily manage the setup of a simple configured tunnel 
    would be sufficient, unless the basic IPv6 deployment in visited
    networks could be assumed and no tunneling would be needed at all.
=======

as part of this, the "no tunneling mechanisms thing" should be added back to
the security considerations in:

====
    In particular, this memo does not recommend the following technique
    which has security issues, not further analyzed here:

       - NAT-PT or other translator as a generic-purpose transition
          mechanism,
====

 ... I think this keeps the basic substance of the old text while trying to
pin down more explicitly what the problems are.  I explicitly defined
"tunneling from the UE to the general Internet" out of scope... I don't
think a complete non-support of v6 is a 3GPP scenario :-)

However, instead of vague "tunneling is needed" statement, I put a more
precise statement that a simple way to do configured tunnels would be
enough.  I may be biased :-).

-- 
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: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 14:58:42 +0100

> trying to catch up this interesting discussion and making 
 > some kind of summary:
 > - not needing to refer to Unman scenarios&analysis
 > - Karim provides text on tunneling (to be updated to revision -08)
 > - Pekka's concerns on ISATAP providing more features than we 
 > need => in that case, we should document which parts of 
 > ISATAP are necessary for the 3GPP case, i.e. making a 
 > "subset of ISATAP" may be the solution? Shall you, Karim, 
 > also consider this point when writing your text?

Makes sense. I will review the latest spec (draft-16) and do that
but I think it does not contain those extra features.

 > 
 > Furthermore, I personally don't believe that configured 
 > tunnels make a feasible solution for this specific problem 
 > (even though they provide a good solution for some other 
 > scenarios). You must remember the high number of UEs and 
 > dynamic addressing. And any extra configuration effort isn't 
 > nice for the users. If you make the extra configurations 
 > using SMS (like configuring APN settings for different 
 > applications), that means one SMS more. The point is: IPv6 
 > should be as easy as possible.

Fully agree.

 > 
 > And still: we prefer native IPv6 communication and describe 
 > the "tunneling in the UE" as an *optional* thing (that won't 
 > be needed any more after GPRS networks start to widely 
 > support IPv6). That should not make harm to anybody.

Again agree.

 > P.S. All this discussion already shows to me that v6ops wg 
 > should start working on transition mechanisms. This wg needs 
 > to work on issues that are relevant for IPv6 deployment and 
 > that can help IPv6 getting deployed. Of course, the 
 > scenarios & analysis work is important, but we have done it 
 > already for so long time that we start to see which 
 > mechanisms are relevant (and which aren't). IMHO, getting 
 > ISATAP published as an RFC would be a good step towards that 
 > direction.

That is my opinion as well. We need to have stable specs for
implementation/deployment now that we are wrapping up the last
details on 3gpp analysis.

/Karim