Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Thu, 24 Jul 2003 13:24:38 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi

Some comments on the tunnelling issues below.

 > 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).

We are not mandating tunnelling for generic cases. However we
analysed each scenario and where it made sense we recommended
certain mechanisms such as tunnelling. Tunnelling is not a generic
solution for all our problems and we are not claiming that.

 >  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.

It is not in conflict with any 3GPP goals. Note that the 3GPP operator
requires IPv6 for SIP-based IMS but this doc also covers generic access
(which is where we talk about tunnelling). On the contrary it helps
operators to start rolling out IPv6 without having to upgrade everything
all at once. This is an important issue which we have addressed. Also,
when a user roams to a network that does not support IPv6, the use of
ISATAP can allow access to IPv6 app.s. It is obvious that in the long
run native IPv6 access is the way to go. If that helps we can make
this more explicit.

 > 
 >  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 can't be done. The user doesn't choose GGSNs.

 >   That is, 
 > as long as the 
 > 3GPP operator has basically one IPv6-aware GGSN, SGSN and 
 > HLR, IPv6 users 
 > are happy.

That is not correct. If you happen to go to the wrong SGSN/GGSN
you just don't get IPv6 service, independently from the fact
that there may be another SGSN/GGSN somewhere else in the
network supporting IPv6.

 > 
 > 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..

You have left out the issue that when we're introducing a new
technology nowadays we don't do it all at once but gradually.
That means we will have to deal with IPv6 capable mobiles
trying to use IPv6 app.s even in areas where IPv6 native
connectivity is not possible. If we don't consider this case
then we won't be providing a full set of answers to 3GPP.

/Karim

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Fri, 25 Jul 2003 11:43:26 +0200

Answered this already in your list of questions.
It is the latter (L2 tunnelling) thus e.g. ISATAP is
applicable.
/Karim

-----Original Message-----
From: Pekka Savola
To: Karim El-Malki (HF/EAB)
Cc: [email-masked]
Sent: 2003-07-24 22:24
Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment

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.

Later, I thought of another issue here.

When you roam, your IP address typically changappes to one given by the
remote 3GPP operator.  Who provides Internet connectivity to this
address,
the remote operator or your "home" operator (e.g. via L2 tunneling)?

If the former, ISATAP would not really be applicable, as the operators
would not be in the same administrative domains, and moreover, the
addresses would likely be private.

>  > -----Original Message-----
>  > From: Brian E Carpenter [mailto:[email-masked]]
>  > Sent: den 24 juli 2003 14:35
>  > To: Pekka Savola
>  > Cc: [email-masked]
>  > 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 [email-masked]
>  > Try that if you get failure messages.
>  > 
>  > Pekka Savola wrote:
>  > > 
>  > > Hi,
>  > > 
>  > >  1) we *MUST NOT* require or recommend the implementation 
>  > of any automatic
>  > >  2) The use of ISATAP is misguided in this space: it's 
>  > only useful if the
>  > > user buys his service doesn't support IPv6, the user 
>  > cannot use IPv6 on
>  > > user from using some other GGSN for IPv6 support.  That 
>  > is, as long as the
>  > >  - We're concerned about 3GPP *deployment* not early 
>  > trials or piloting
>  > >  - There is a significant pressure for 3GPP operators to 
>  > do IPv6 properly,
>  > > Of course, if the UE implements something like 6to4, 
>  > there's nothing to
>  > > 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