3gpp-analysis: Recommendation on tunneling in the UE

[Pekka Savola <pekkas@netcore.fi>]

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