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

From: <[email-masked]>
Date: Tue, 2 Sep 2003 17:00:31 +0300

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