Subject: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd)

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Sep 2003 15:11:14 +0300 (EEST)

Hi,

This is an explicit request for feedback from the WG on a very important 
issue.  To quote Juha,

 So, could I get more wg comments / discussion on this issue, please!? How
 should we mention UE based tunneling in this document, or should we not
 mention it at all?

That is, what kind of transition architecture should we suggest *in this
document* for 3GPP UE's?  (of course, v6ops is not mandating what
vendors/users/operators will or will not do regardless of that advice.)

Waiting for WG input..

 Pekka
 as WG co-chair

---------- Forwarded message ----------
Date: Tue, 2 Sep 2003 17:00:31 +0300
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6
    deployment [issue 6]

Hi,

ok, this is the last issue I have not yet commented on the list. The
comment sent by Pekka was about "IPv6 in IPv4" tunneling performed in the
UEs.  Pekka does not want to require or recommend the implementation of
any automatic (or configured)  tunneling methods in the UEs. Justification
for that: high number of IPv6-capable UEs, implementation footprint of
UE's is expected to be small, upgradeability of UE's is poor and we are
concerned about 3GPP *deployment* not early trials or piloting in this
document.  Quite a long discussion followed including 3GPP architecture,
different PDP context types, roaming (which has not been discussed so much
in our document, anyway, 3GPP roaming is happening at layer 2, not IP
layer), etc.

I must say that I agree on many points above - I do not believe that
tunneling in the UE is a scalable solution for a very large number of
terminals. What this section in our document tries to explain, is how to
solve such a situation when the operator does not support IPv6 in its
network (GGSN / SGSN / HLR is/are lacking IPv6 support) and the UE (user)
wants to access IPv6 services. And in that case you MAY use tunneling in
the UE to get IPv6 service.

The recommended (longer term) approach for this problem is that the
operators deploy basic IPv6 support in their 3GPP networks (can in most
cases be done by making a sw upgrades) - and we must convince them to do
that as soon as possible! What do you think, could that be one key
recommendation in our document? Karim also commented that the soon
starting IMS period also makes basic IPv6 support reality in 3GPP
networks. And it removes the need for tunneling to be done in the UEs.

So, could I get more wg comments / discussion on this issue, please!? How
should we mention UE based tunneling in this document, or should we not
mention it at all?

The current text is:

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

BR,
	-Juha-

-----Original Message-----
From: ext Karim El-Malki (HF/EAB) [mailto:[email-masked]]
Sent: 12 August, 2003 16:36
To: 'Pekka Savola'
Cc: [email-masked]'
Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6
dep loyment (fwd)

 > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote:
 > >  > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote:
 > >  > >  > Or let me phrase this differently:
 > >  > >  > 
 > >  > >  >  Would roaming with 3GPP UE work if the roaming agreements 
 > >  > >  > would include 
 > >  > >  >  an indication whether the foreign network 
 > supports the same 
 > >  > >  > PDP context 
 > >  > >  >  types as the original network.
 > >  > >  > 
 > >  > >  > I.e. the user can prefer those roaming partners which 
 > >  > >  > provide the services 
 > >  > >  > they want.  That should be enough of an economic incentive.
 > >  > > 
 > >  > > Basically the UE won't know until it tries to activate
 > >  > > a v6 connection and it gets refused.
 > >  > 
 > >  > This seems like a potentially fatal design flaw.
 > > 
 > > When I plug into Ethernet or WLAN I don't know if the network
 > > supports IPv6 until I get an RA. 
 > 
 > Very true, but the expectations are entirely different (or 
 > that's my take 
 > at least).  When I use my laptop and roam in the world, I generally 
 > *DON'T* expect IPv6 to be available.  Hence, I'm equipped 
 > with some useful 
 > tools to enable IPv6 in the case network doesn't support it 
 > (e.g. 6to4 or 
 > configured tunnels).
 > 
 > However, I think the expectation with 3GPP is entirely 
 > different: network 
 > supports IPv6, period. (And it would be unreasonable to 
 > assume the huge 
 > number of 3GPP devices to implement all the possible 
 > mechanisms required 
 > in every possible network scenario, be it 3GPP or regular 
 > old-fashioned 
 > Internet.)

To be precise it's 3GPP IMS services that support IPv6.
I hope this will get all operators to support IPv6 for the
obvious reasons such as peer-to-peer connectivity. However
it is a different thing to expect any 3GPP network in general
to support IPv6 from day one. In fact there are commercial
3GPP operators today (WCDMA and GSM) whose networks do not
support IPv6. Also, all I have been saying is to recommend
support for at least one type of tunnelling in this case.
ISATAP does what is needed IMO, so you don't need to support
every possible mechanism. 

 > >  > If UE's were to run PPP PDP Contexts, could the lack of IPv6 
 > >  > support in 
 > >  > remote SGSN's/GGSN's be avoided ?
 > > 
 > > You could do that, but it would be an overkill IMO to run PPP
 > > over wireless. Since we're dealing with an expensive bandwidth
 > > limited link it's not an attractive alternative.
 > 
 > I think it would be useful to try to analyze the overhead of 
 > PPP in this
 > scenario.  It might not be that high, and it might only be 
 > the fallback
 > solution where other mechanisms (i.e. finding an operator which would
 > support IPv6, or refraining from using IPv6) would not work.

That would be asking for equipment to support IPv4, IPv6 and PPP to
cater for a case which we hope will be rare. I would definitely limit
it to IPv4 and IPv6 so that people would have to tunnel for the special
cases and operators would have an incentive to migrate to native IPv6.
PPP will not solve the problem in a clean way and will be a disincentive
to migrate to native IPv6.

 > > For example today operators have gprs (IPv4) roaming agreements
 > > with certain operators and only voice with others. 
 > 
 > Do you know if there is a regional perspective to this?  
 > That is, if there 
 > are multiple potential roaming partners in an area, could 
 > you say that 
 > they often support different capabilities?
 > If they support different capabilties, it might be easier to 
 > conclude that 
 > it's reasonable to expect some of them to support IPv6 
 > (while some others 
 > wouldn't) -- and then cycling through roaming partners until 
 > finding a 
 > correct might be a thinkable approach.

Personally I wouldn't see why an operator would want to limit
its market to certain type of services in a certain area.
>From what I know the above cannot be taken as a rule. I don't
think I would design a standard based on a single business
model anyway.

 > > If you're in this special case (which will hopefully become
 > > rare in future) and you want to have a way of using IPv6 services
 > > then tunnelling is an attractive solution.
 > 
 > What I'm looking for is a way or two to work around that 
 > requirement; I 
 > would loath to see a requirement to implement tunneing 
 > solutions on mobile 
 > terminals to make the service work in areas where the 3GPP operator 
 > doesn't suddenly support IPv6.
 > 
 > I think we should try to ways to leverage 3GPP network's 
 > capabilities to 
 > ensure that either:
 > 
 >  1) the user is able to obtain IPv6 PDP context somehow; 
 > this is an issue 
 > when roaming to some other operator's network.  Whether from 
 > that operator 
 > or by trying someone else doesn't matter.
 > 
 >  2) the user is able to work around the issue by requesting PPP PDP
 > context until the roaming partner supports IPv6
 > 
 >  3) the user is able to stick to just using IPv4 when 
 > roaming in a network 
 > where there are no ways at all to get IPv6 using any means.

Number 1) is unworkable as I've explained before. There are also business
issues that will make it useless in many cases (i.e. there is only
one data roaming partner which is common today). Number 2) isn't workable
either. You're not going to convince operators to get support for PPP
(which is normally not there today) only because they need IPv6; they would
get native IPv6 directly. Tunnelling is fine as a migration tool and we've
tested it. It's the only feasible choice and it will lead to a migration
to native IPv6.

/Karim

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 3 Sep 2003 14:28:41 +0200

I think we can survive with only the 1st paragraph of the actual text, and forget the 2 that follow. Once the IPv4 PDP context is
established, with a private or public address for the UE, you can use any type of tunnel or transition mechanism that you like, just
obvious to me.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 03, 2003 2:11 PM
Subject: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd)

> tested it. It's the only feasible choice and it will lead to a migration

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 03 Sep 2003 10:44:41 -0400

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

- the input I got from the business side is that IPv6-only UE is not so
real. They are v4 right now, and will be/are dual-stack now/later. So this
scenario of IPv6-only device (not PDP context) seems to me not useful to
consider and is the one that causes many issues. 
- if the UE is dual stack (anyway), then to save one PDP context, you
tunnel the other IP version on the established PDP context. example:
 + your PDP context is IPv4. you need IPv6: tunnel v6 in v4.
 + your PDP context is IPv6. you need ipv4: tunnel v4 in v6.

Marc.

-- mercredi, septembre 03, 2003 15:11:14 +0300 Pekka Savola
<[email-masked]> wrote/a ecrit:

> (which is normally not there today) only because they need IPv6; they
> would get native IPv6 directly. Tunnelling is fine as a migration tool
> and we've tested it. It's the only feasible choice and it will lead to a
> migration to native IPv6.
> 
> /Karim
> 
> 
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

---

From: Suresh K Satapati <[email-masked]>
Date: Wed, 3 Sep 2003 11:44:55 -0700 (PDT)

I would prefer to see as a recommendation:

"the operators deploy basic IPv6 support in their 3GPP networks (can in
most cases be done by making a sw upgrades)"

And UE based tunneling to be removed entirely from the document.