[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd)
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" <pekkas@netcore.fi>
To: <v6ops@ops.ietf.org>
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)
> 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: juha.wiljakka@nokia.com
> To: karim.el-malki@ericsson.com, pekkas@netcore.fi
> Cc: v6ops@ops.ietf.org
> 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:karim.el-malki@ericsson.com]
> Sent: 12 August, 2003 16:36
> To: 'Pekka Savola'
> Cc: 'v6ops@ops.ietf.org'
> 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
>
**********************************
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.