Re: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd)

[Suresh K Satapati <satapati@cisco.com>]

I would prefer to see as a recommendation:

"the operators deploy basic IPv6 support in their 3GPP networks (can in
most cases be done by making a sw upgrades)"

And UE based tunneling to be removed entirely from the document.

On Wed, 3 Sep 2003, Pekka Savola wrote:

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