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

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 12 Aug 2003 15:36:25 +0200

> 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: Pekka Savola <[email-masked]>
Date: Wed, 20 Aug 2003 20:44:06 +0300 (EEST)

Sorry for the delay.  Basically I think we disagree on some fundamental 
issues, and it may be best if we maange to get others to give their 
thoughts on the subject.

On Tue, 12 Aug 2003, Karim El-Malki (HF/EAB) wrote:
> to support IPv6 from day one. 

Sure, but is it reasonable to expect that you would be able to use IPv6 in 
everywhere you move to in the world, and expect IPv6 to work, from day 
one?

It may not be.  A possibly valid answer could be, "just use IPv4 then", I
don't know.

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

I do not know the tradeoffs in enough detail to say anything conclusive,
but ONE mechanism which:
 1) uses your uses an allocated ISP prefix, (i.e. not 6to4 or like)
 2) is simple, both specification and code-wise,
 3) does not have security problems,
 4) has a very clear and definitive sunset strategy, and
 5) is ACTUALLY NEEDED,

might be a possibility; but I don't want to really consider it because I'm 
not sure the most important point, 5), has benefited from enough feedback 
and we actually know that this is the right place and the right way to fix 
the problem.

[note: the list was made ad-hoc, and it probably isn't conclusive]

> cater for a case which we hope will be rare. 

The 100% same argument can be applied to including a transition mechanism 
like ISATAP in an UE.

> I would definitely limit

I fail to see how th euse of PPP would be any less disincentive to migrate 
to native IPv6, than to use IPv6-over-IPv4 tunneling as a backup.  (note, 
I'm not talking about moving *all* IPv6 communication to over PPP.)

[snip a non-technical part of discussion]

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

I think I disagree with this conclusion, but we need more review and 
feedback on this case.

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Aug 2003 20:44:06 +0300 (EEST)