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

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote:
> You're assuming that roaming is done at L3. Roaming is normally
> done at L2 so for example ISATAP is a relevant option.

(I think you should elaborate on "normally")

OK.  If roaming is done at L2, then IP addresses etc. should stay the same
when you roam, right?  Then IPv6 addresses will stay too, right?  So, why
do you need ISATAP there then?

>  > -----Original Message-----
>  > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
>  > Sent: den 24 juli 2003 14:35
>  > To: Pekka Savola
>  > Cc: v6ops@ops.ietf.org
>  > Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs; 
>  > 3GPP IPv6
>  > deployment
>  > 
>  > 
>  > 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
>  > 
> 

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