3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment

[Pekka Savola <pekkas@netcore.fi>]

Hi,

This is a slightly related point to "The use of 6to4" issue raised 
yesterday.

Section 3.1 goes and analyzes the case where the 3GPP network does not 
provide IPv6 support at great length.

I strongly believe that:

 1) we *MUST NOT* require or recommend the implementation of any automatic 
tunneling methods such as 6to4 or ISATAP on 3GPP UE's.  We SHOULD NOT 
require or recommend the implement configured tunneling on UE's (but I can 
be convinced otherwise).

 2) The use of ISATAP is misguided in this space: it's only useful if the
3GPP operator supports IPv6 (i.e. provides the ISATAP routers and other
infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, etc.  This
seems in direct conflict with 3GPP goals.

 3) we should be able to assume that unless the 3GPP operator where the 
user buys his service doesn't support IPv6, the user cannot use IPv6 on 
his gadget.  On the other hand, if the particular GGSN the user is 
connected using IPv4 supports only IPv4, there is nothing stopping the 
user from using some other GGSN for IPv6 support.  That is, as long as the 
3GPP operator has basically one IPv6-aware GGSN, SGSN and HLR, IPv6 users 
are happy.

The reasons for these points are mainly:

 - The number of UE's is expected to be very high,
 - The implementation footprint of UE's is expected to be very small, so 
any extra code is difficult to justify,
 - The upgradeability of UE's is poor, and we may not be able to retire 
such mechanisms,
 - We're concerned about 3GPP *deployment* not early trials or piloting 
 - There is a significant pressure for 3GPP operators to do IPv6 properly, 
and we should rather work on getting on with *real* IPv6 deployment than 
fiddling around with transition mechanisms in this space.

Of course, if the UE implements something like 6to4, there's nothing to 
stop them.  Just we shouldn't advocate that..

This, I'd suggest major reworking of the parts of the section 3.1.

===8<====
 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes
[...]
    However, the UE may attach to a 3GPP network, in which the SGSN
    (Serving GPRS Support Node), the GGSN and the HLR (Home Location
    Register) support IPv4 PDP contexts by default, but may not support
    IPv6 PDP contexts. 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. This might happen in very early phases of IPv6
    deployment, or in IPv6 demonstrations and trials.

    The UE may be assigned a private or public IPv4 address when the
    IPv4 PDP context has been activated, although it is more likely
    that it will receive a private address (due to the lack of public
    IPv4 addresses). 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 (one example is 6to4 [RFC3056]), but if the
    tunnel endpoints are in the same private domain or the tunneling
    mechanism works through IPv4 NAT (Network Address Translator),
    private IPv4 addresses can be used (examples are [ISATAP] and
    [TEREDO]). In general, if tunneling from the host is needed, ISATAP
    and 6to4 are preferred and TEREDO is a mechanism of last resort
    when neither of these are applicable.

    One deployment scenario example is using laptop computer and a UMTS
    UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the
    laptop computer and an IPv4 PDP context is activated. Although
    "IPv6 in IPv4" tunneling can be either automatic or configured (by
    the user), the first alternative is favored, because it is expected
    that most UE users just want to use an application in their UE;
    they might not even care, whether the network connection is IPv4 or
    IPv6.
[...]

 3.2.2 Tunneling outside the 3GPP Operator's Network
[...]
    On the other hand, usage of dynamic tunneling, such as "6to4", can
    also be considered, but scalability problems arise when thinking
    about the great number of UEs in the 3GPP networks. The specific
    limitation when applying "6to4" in 3GPP networks should also be
    taken into account, as commented in 3.2.1. Other issues to keep in
    mind with respect to the "6to4" mechanism are that reverse DNS is
    not yet completely solved and there are some security
    considerations associated with the use of "6to4" relay routers (see
    [6to4SEC]). Moreover, in a later phase of the transition period,
    there will be a need for assigning new, native IPv6 addresses to
    all "6to4" nodes in order to enable native IPv6 connectivity.


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings