[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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