Subject: [v6ops] comments on mobile-network related drafts

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Nov 2010 13:53:59 +0800

I quickly read these drafts this morning:

http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00
http://tools.ietf.org/html/draft-zhou-v6ops-mobile-use-case-00

A few comments:

draft-tsou-v6ops-mobile-transition-guide:

> GPP has decided to use Gateway-
>    Initiated DS-lite [ID_GI_DS_lite <http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-ID_GI_DS_lite>] as the primary tool for subscriber
>    migration.

This seems incorrect. The 3GPP has a small set of tools that does 
include GI-DS Lite, but they have not picked a "primary tool". (And I 
might add that GI DS Lite doesn't actually affect the users in any way. 
Just an extension of existing tunnels a bit further into the center of 
the network.)

>    The transition to IPv6 must be carried out over a number of different
>    segments within the total network:
>
>    o  the operator's operational support systems, including AAA;
>
>    o  the operator's private IP network;
>
>    o  the portal to the operator's proprietary content and applications;
>
>    o  the user devices;
>
>    o  portals to the partner content and application providers.
>
>    These are listed in what is probably the preferred order for making
>    the transition, but in fact the operator will want to carry out a
>    number of activities in parallel.
>
>   

Its good that you cover these different aspects! It is indeed necessary 
to understand that many different things can or have to change. However, 
you are also stating this as if it was all tightly coupled. I normally 
like to classify some of these things into independent, parallel efforts 
with different timescales and deployment motives:

1) migrating user's traffic to Internet to IPv6; this probably means 
dual stack or nat64 since the other ends of the communication will for a 
long time be on IPv4.

2) migrating user's traffic to operator's own services to IPv6. Here you 
have more freedom, as the operator has some amount of control over both 
ends. Of course, there are still issues with roaming, handset support, 
etc. Note that own services are typically on a separate APN, not on the 
Internet APN.

3) migrating internal network underneath the mobility tunnels to IPv6. 
For instance, sending signaling messages on IPv6.

All of these have different impacts on additional infrastructure and 
operations, e.g., AAA, DNS, subscriptions, help desk, ...

I do not think we should dictate anything about the order of moving the 
above three parts. I've seen operators make very different choices here. 
And, as an example, #1 is quite doable without #2 or #3 (I know because 
we're doing it on one of the services that we operate for ourselves at 
Ericsson with the help of an operator whose signaling network is not on 
IPv6).

> 2. Steps In the Transition Strategy

I think there is an important part missing here, and that is the 
operator's connection to the IPv6 Internet. This implies peering, 
routing infrastructure out of their network, whitelisting agreements, 
monitoring, SLAs,  i.e., different things from enabling IPv6 in the 
internal network.

> The operator needs to build up the availabilty of IPv6-accessible
> applications and content as quickly as possible, to reduce the IPv4
> traffic on the network and thereby reduce the demand for public IPv4
> addresses.  One way to do this is to make the operator's own content
> and applications IPv6-accessible early on in the transition period.
>   

This is a good observation. I would add that if possible, being able to 
agree with a few key content providers would also significantly increase 
the amount of available IPv6 traffic. If you look at a recent NANOG 
presentation from the Arbor Networks guys, you can tell that a small 
fraction of destinations covers a very large part of Internet traffic.

>
>       .4. User Devices
>
>
>
>  3GPP specifications for mobile devices have required dual stack
>  support for at least a year (i.e., as of Release 8.) 

The specification for IPv6 support has been there since 1999 or so, I 
think. You could of course talk about the "Dual Stack PDP Context" but 
that is not the same as providing dual stack support as you can do that 
with IPv4 and IPv6 PDP contexts as well. Or you could talk about 
mandatory status, and I'm frankly unclear on what the status is on that, 
but I suspect it is not a mandatory requirement even today, because 
otherwise there are plenty of phones in the market today that shouldn't 
be passing certification :-)

> the most
>    likely strategy will be to interpose Gateway-Initiated DS-lite
>    [ID_GI_DS_lite <http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-ID_GI_DS_lite>] 

See above. I think this draft is incorrectly posing GI DS Lite as the 
solution. It is a solution.

> DNS access is an issue with Gateway-Initiated DS-lite.  The original
> DS-lite proposal had a point (the B4) at which all DNS queries could
> be intercepted and sent to an IPv6 DNS.  From here IPv4 queries could
> be forwarded to an IPv4 DNS, or the IPv6 DNS could maintain both AAAA
> and A records.  It is not so obvious that such interception can be
> carried out at the Gateway in Gateway-Initiated DS-lite, since the
> Gateway is essentially performing a layer 2 operation.
> [ID_GI_DS_lite <http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-ID_GI_DS_lite>] does not mention the issue.
>   

I think the draft could spend more text on explaining DNS setup, but I 
don't think specific problems with GW DS Lite is useful. That discussion 
belongs to some solution draft.

In general, the draft is quite short on actual transition guidelines, 
but yet focus too deeply in one specific solution. I think you should go 
much further in explaining the overall network issues, different 
aspects, and the key solutions.

draft-zhou-v6ops-mobile-use-case:

> To achieve service continuity during handover, legacy mobile devices
>    support MIPv4 [RFC3344 <http://tools.ietf.org/html/rfc3344>].
Not sure this is really the case, at least not for 3GPP based networks. 
Its in the specs, but not implemented/used. AFAIK, of course.

> Approaches To IPv4 / IPv6 Coexistence

I like this section in terms of contrasting each approach and some of 
the challenges they have.

> Issue: In dual stack mode, every UE still needs an IPv4 address.  As
> the number of subscribers grows, the lack of additional public IPv4
> addresses will force the use of private rather than public IPv4
> addresses for some UEs.  Aside from anything else, this will
> complicate the operation of mobile IP.
>   

Again, I'm not sure that's a practical consideration.

> Gateway-Initiated Dual-Stack Lite

Again, this draft is quite focused on this one solution. You also do not 
explain some of the implications of this architecture, e.g., that you 
are moving all end-to-end traffic to a central entity.

> Protocol Translation

This section seems out of date with regards to what 3GPP has already 
decided on this. We don't need to revisit history... the IETF-3gpp 
meeting last Mawrch for instance said clearly that stateful NAT64 for 
this type of scenario is their desired solution.

> 6rd

Not mentioned in the draft but got mentioned in the presentation. As 
noted in the meeting, I think 6rd may not be a good match. There are 
already tunnels (= PDP context mobility tunnels) so if the service 
provider wants to turn IPv6 on then he can already do so. If he doesn't 
want to turn it on, then 6rd isn't going to help as it is a 
service-provider technology AFAIK.

Overall, I'm not sure we really need IETF documents as there's already 
quite a bit of documents and past co-operation between the IETF and 3GPP 
on this. Or at least if we are starting an effort, please be aware that 
it will imply making a significant effort, we have to get it right, 
align with our friends in 3GPP, do something that has not yet been done.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 12 Nov 2010 06:41:47 -0800

More clarifications. Adding to what Jari said.

1. GI-DS-lite is one of the tools in the transitioning tool kit. As Jari
correctly pointed out, it is not the only tool listed in 3GPP TR 23.975. The
document includes few other tools including NAT64, Per-Interface Bindings
..etc. The 3GPP study item reviewed various transitioning considerations,
scenarios and solution approaches and finally identified some of the key
approaches, but with no recommendation to *one* specific approach. The chair
report from the 3GPP-IETF meeting in San Francisco summarizes the analysis
correctly.

ftp://ftp.3gpp.org/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/docs/IPW100060
.zip 

2. To be fair to the authors of the below listed drafts, GI-DS-lite was the
only solution listed in the main section of the document till the recent
revision of the document, the other approaches made it to the main section
of the document after the last SA2 meeting. That may have been the reason
for the confusion. 

3. As Jari pointed out, GI-DS-lite does not impact end users or DNS access.
It only applies DS-lite approach to mobile architectures, leverages the
tunneled architecture of 3GPP and enables an interface between a CGN and PGW
and a deployment model.

4. Like discussed and many folks pointed too, there is no one transitioning
tool, or approach. Each of the approaches is useful in a specific deployment
context, may be needed in some cases and may not be needed in some other
cases. It is dependant on the operator requirements, network design,
infrastructure investment and million other considerations. It is a
subjective opinion when it comes to the recommendation for one specific
approach, that discussion never converges, as the considerations vary from
operator to operator and so do the solutions.

Regards
Sri

On 11/11/10 9:53 PM, "Jari Arkko" <[email-masked]> wrote:

>>    Initiated DS-lite [ID_GI_DS_lite
>> <http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-I
>> D_GI_DS_lite>] as the primary tool for subscriber
>>    migration.
> 
>>    [ID_GI_DS_lite
>> <http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-I
>> D_GI_DS_lite>] 
> 
>> [ID_GI_DS_lite 
>> <http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-I
>> D_GI_DS_lite>] does not mention the issue.
>>   
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tina Tsou <[email-masked]>
Date: Wed, 17 Nov 2010 19:57:40 -0800

Hi Jari,
Thanks for taking the time to review the drafts. As Tom mentioned, we will
be doing a complete rewrite in the next week or so, with the final product
being a single draft that points out areas that seem to have been missed.
We'll take your comments into account to the extent that the content to
which they pertain remains in the draft.

Whether the draft continues to exist on its own or gets folded into other
work is a matter for discussion.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 9:54 PM
To: 'IPv6 Operations'; Tina TSOU; [email-masked]
Subject: comments on mobile-network related drafts

A few comments:

>    Initiated DS-lite [ID_GI_DS_lite
<http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-
ID_GI_DS_lite>] as the primary tool for subscriber

>    likely strategy will be to interpose Gateway-Initiated DS-lite
<http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-
ID_GI_DS_lite>] 

> Gateway is essentially performing a layer 2 operation.
<http://tools.ietf.org/html/draft-tsou-v6ops-mobile-transition-guide-00#ref-
ID_GI_DS_lite>] does not mention the issue.

Jari