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

[Brian E Carpenter <brian@hursley.ibm.com>]

If UE that normally uses IPv6 roams to a provider that only supports
IPv4, some kind of tunnel solution seems inevitable. ISATAP is
certainly irrelevant, because the IPv4 provider won't provide 
ISATAP machinery by definition. So either the home provider will
have to offer a tunnel broker or a 6to4 relay for use by its
subscribers when they roam on IPv4. I don't think the IETF
should worry about whether the UE has enough real estate for
this option; that's a vendor choice. 

I suspect the UE will have less overhead to support 6to4 than
to support a tunnel broker protocol.

     Brian-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NOTE: My email will soon change to brc@zurich.ibm.com
Try that if you get failure messages.

Pekka Savola wrote:
> 
> 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