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

[Pekka Savola <pekkas@netcore.fi>]

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

> In this case we know before
> activating the PDP Context i.e. L2 link. So this doesn't look like
> a flaw to me, although it could be improved with what you
> write above.

But we don't know it before the activation of PDP context (at least as far 
as I've understood).  If the network doesn't support it, the PDP context 
activation is denied (for PDP type IPv6).  This seems very much the same 
(both for the time consumed and otherwise) as sending re-transmissions for 
RFC2461/RFC2462 Router Discovery and ultimately deciding that IPv6 is not 
available.

On the other hand, if we knew beforehand which PDP context types were 
supported (and by which roaming partners), picking the one with IPv6 
support might be significantly easier.

The other improvement I was suggesting (just to rephrase, trying to
summarize) was referring to the ability to support gradual IPv6 deployment
of 3GPP operator's equipment. That is, to make the tunneling IP
protocol-transparent so that SGSN's, HLR's or GGSN's wouldn't have to
support the PDP context type they would be serving, but would tunnel it
nonetheless to its home network.

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

>  > >  > Or, i.e. we define that "roaming" is not "true roaming" 
>  > >  > unless you provide 
>  > >  > the support for the same PDP context types; that is, there 
>  > >  > is "partial 
>  > >  > roaming" as of today and "real roaming" of tomorrow.
>  > >  > 
>  > >  > IMHO, it seems ill-advised to call something "roaming" when 
>  > >  > they fail to 
>  > >  > provide critical infrastructure capabilities the users need.
>  > > 
>  > > Some people would see voice, IPv4 or MMS as critical so I don't
>  > > think it makes sense to get into a discussion here on what the word
>  > > "roaming" should mean.
>  > 
>  > Is there a significant number of roaming partners where 
>  > voice, IPv4 or MMS 
>  > are not supported (in regions where some other potential 
>  > roaming partners
>  > would provide support for them)?  Otherwise your analogy 
>  > does not seem 
>  > fitting.
> 
> 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.

>  > If you use IPv6 PDP context to a local GGSN, move over to 
>  > another country 
>  > and 3GPP operator but don't switch off your UE -- retaining 
>  > your old GGSN 
>  > -- does the IPv6 still work through the IPv6 PDP context through L2 
>  > tunneling?  If not, why not?
> 
> Don't think so. You would try to set up this type of handoff (which
> involves passing PDP Context info from old to new SGSN) and the local
> SGSN would reject it if it didn't understand PDP type IPv6.

Ok.
 
>  > If SGSN doesn't support IPv6 PDP contexts but GGSN does, 
>  > you're out of 
>  > luck? (without tunneling by the UE)
> 
> Yes. There's also another element involved (HLR) which needs
> to have some knowledge of IPv6 to authorise the user to use
> the IPv6 service. Basically the GGSN is not the only device
> that needs to know what IPv6 is in order for things to work,
> although it is the most important one from our IP-centric point
> of view.

Ok.
 
> 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.
 
>  > I'm not sure if my question got across, because I don't 
>  > understand the 
>  > answer in that context.
>  > 
>  > So, let's try again:
>  > 
>  > How exactly can UE's open multiple PDP _primary_ contexts to 
>  > different operators?  Is there anything in the capabilities of the 
>  > network(s) which may hinder your possibilities to open PDP 
>  > contexts to 
>  > different ISPs?
> 
> For one thing you cannot open multiple connections to different
> operators at the same time. Apart from that you can try and connect
> to any operator which has roaming agreements with your home operator.

Ok.
 
>  > When you're roaming, couldn't you just try opening IPv6 PDP 
>  > context, and 
>  > if it fails, try some other roaming partner (if available) 
>  > and try to open 
>  > an IPv6 PDP context there too?
> 
> You could if there are other roaming partners. 

Ok (typically there are..)

> But you could
> also just be wasting your time and it does waste quite a
> bit of time to detect the networks, pick an operator, check
> connectivity, detect again etc.

How long is that usually?  I'm not sure of your terminology, but I assume 
you'd actually only have to loop through "pick an operator" (simple) and 
"check connectivity" (when the PDP context activation has succeeded or 
failed).
 
>  > Or even try opening PDP contexts simultaneously (would be 
>  > more costly, I suppose -- depending on whether the billing 
>  > starts after or 
>  > before the PDP context activation is successful; in this 
>  > scenario, it's 
>  > the latter)?
> 
> You can't do that. You can only be connected to one operator at
> a time.

Ok.

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