[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)
[ post by non-subscriber. with the massive amount of spam, it is easy to miss
and therefore delete posts by non-subscribers. if you wish to regularly
post from an address that is not subscribed to this mailing list, send a
message to <listname>-owner@ops.ietf.org and ask to have the alternate
address added to the list of addresses from which submissions are
automatically accepted. ]
- the input I got from the business side is that IPv6-only UE is not so
real. They are v4 right now, and will be/are dual-stack now/later. So this
scenario of IPv6-only device (not PDP context) seems to me not useful to
consider and is the one that causes many issues.
- if the UE is dual stack (anyway), then to save one PDP context, you
tunnel the other IP version on the established PDP context. example:
+ your PDP context is IPv4. you need IPv6: tunnel v6 in v4.
+ your PDP context is IPv6. you need ipv4: tunnel v4 in v6.
Marc.
-- mercredi, septembre 03, 2003 15:11:14 +0300 Pekka Savola
<pekkas@netcore.fi> wrote/a ecrit:
> 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
>
>
>
------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------