Subject: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-02.txt

From: GangChen <[email-masked]>
Date: Tue, 5 Nov 2013 01:50:23 +0800

Wg,

We submit the new draft of IPv6 roaming. Please kindly check.
Your comments are appreciated

BRs

Gang

2013/11/5, [email-masked] <[email-masked]>:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title           : IPv6 Roaming Behavior Analysis
> 	Author(s)       : Gang Chen
>                           Hui Deng
>                           Dave Michaud
>                           Jouni Korhonen
>                           Mohamed Boucadair
>                           Vizdal Ales
>                           Cameron Byrne
> 	Filename        : draft-chen-v6ops-ipv6-roaming-analysis-02.txt
> 	Pages           : 12
> 	Date            : 2013-11-04
>
> Abstract:
>    This document intends to enumerate failure cases when a IPv6
>    subscriber roams into visited network areas.  The investigations on
>    those failed cases reveal the causes in order to notice improper
>    configurations, equipment's incomplete functions or inconsistent IPv6
>    strategy.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-roaming-analysis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-chen-v6ops-ipv6-roaming-analysis-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "cb.list6" <[email-masked]>
Date: Tue, 5 Nov 2013 11:19:45 -0800

Folks,

As a listed author, i am sorry for not having reviewed this document
prior to publication.  I probably should not be on the author list for
this reason :)

Nonetheless, this is a VERY important topic.

First, regarding the draft.  Failure case #5 does not exist since a
home routed PDP terminates on the home network GGSN so the visited
network does not need to deploy NAT64/DNS64.  The roaming user is only
exposed to the home NAT64/DNS64 and all IP packets are GTP tunneled to
the home.

Second, i do not recommend anyone attempt dual-stack (v4v6) 3GPP
roaming.  I am convinced that it is so broken that it may take more
than 5 years to fix.  Essentially, we need to wait of broken gear run
by disinterested networks to simply cycle out.  In fact, the 3GPP
roaming and home serving architectures are so entwined, that i cannot
deploy dual-stack in a 3GPP home network because this will result in
all subscribers to fail for all access attempts in these flawed
roaming partner networks.  This is not acceptable to the business.

It is truly a terrible situation where a roaming partner's flawed
deployment inhibits my ability to do dual-stack in my own network.

That said, there is only one path that i know of to thread this
needle.  If a mobile network operator wants to deploy IPv6 and NOT
break roaming, the mobile network operator MUST deploy an IPv6-only
solution in the home network (such as RFC6877 / 464XLAT) AND require
the phone / UE to request _IPv6-only while at home_ AND _IPv4-only
while roaming_.  The fundamental issue is that widely deployed gear
fails to handle v4v6 permissions correctly, and the mere presence of
this permission causes the user to fail to access anything at all.

I know 464XLAT at 3GPP home and IPv4-only while roaming works, because
i have deployed this.   I know that i can NOT deploy v4v6 because i
deployed that too, and had to roll it back when customers started
failing.

CB

On Mon, Nov 4, 2013 at 9:50 AM, GangChen <[email-masked]> wrote:
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: GangChen <[email-masked]>
Date: Wed, 6 Nov 2013 06:41:26 +0800

Hi Cameron,

> exposed to the home NAT64/DNS64 and all IP packets are GTP tunneled to

The case#5 is mainly for intra-PLMN mobility. It's not the
international case. That is also the case in our network when deploy
464xlat. We set APN-OI-Replacement flag, so the visited network would
direct traffic to local GW. The intra-PLMN mobility case is described
in the draft. I will highlight this condition both in the draft and
slides.

> deployment inhibits my ability to do dual-stack in my own network.

That is covered in case#1.

Best Regards

Gang

---

From: Tore Anderson <[email-masked]>
Date: Wed, 06 Nov 2013 09:08:26 +0100

* cb.list6

> exposed to the home NAT64/DNS64 and all IP packets are GTP tunneled to

My experience agrees.

This also applies to failure case 4, which says «Roaming to IPv4-only
networks with IPv6 PDP/PDN request would fail to get addresses.»

> than 5 years to fix. [...]
> 

I feel that there is is a gap in this analysis. You say IPv4v6 roaming
is broken - ok, I'll accept that as fact. However, you do not explain
how this leads to a requirement for the UE to request IPv4-only while
roaming (as opposed to simply doing IPv6-only + RFC6877 exactly like
when in the home network).

Indeed, the draft calls out IPv6-only roaming as a working approach: In
Table 1, all variants of IPv6-only UE request (with or without 464xlat)
are noted as "OK" in the home routed case, regardless of visited network
capability.

> deployed that too, and had to roll it back when customers started

I know IPv6-only roaming works too, since I've been doing just that for
a couple of years already and, well, in my experience it Just Works,
regardless of the visited network's IPv6 capabilities (which are usually
non-existent).

If the draft ends up recommending against the UE requesting IPv6-only
(with or without 464xlat) while roaming, I believe it needs to discuss
why in much more detail.

(For what it's worth, doing IPv4-only while roaming would significantly
reduce my exposure to IPv6 connectivity, as I frequently roam onto the
incumbent's PLMN because my own home PLMN doesn't have nation-wide
coverage. The incumbent doesn't support IPv6 for their own subscribers,
but it works just fine for me when roaming, thanks to the GTP magic.)

Tore

---

From: "Heatley, Nick" <[email-masked]>
Date: Wed, 6 Nov 2013 13:38:47 +0000

Hi there Gang,
A useful draft thank you.

Some comments that, from my perspective, would make the content clearer. By all means take them or leave them :-))

Section 3
-Defining "failure" in this draft - in general I infer fallback is a success -so  you could adapt the middle sentences:
>There may be a mismatch between the subscriber request and network capability. In 3GPP networks a mismatch between the UE request and the bearer network could result in bearer negotiation and a fallback to a common bearer type. The failures here can be a result of no common bearer type existing and the UE is left disconnected. Or in the case of local breakout a failure could result from network functionality that is assumed by the UE configuration being absent in the visited network. The following table lists the potential failure cases.

Section3 - Table1
- I would prefer to say that the UEs request IPv4v6, rather than dual stack. That is also what you have defined at the start of section 3.
- I would prefer to see two tables in this section, one covering Home routing and one covering local breakout, because of the following specific comments
- Do you need to define what you mean by Dual Stack for the "Visited Network Capability"? I am wondering, in the case of Home routing, if "Visited Network Capability" is better expressed as "PDN/PDP IP Type permitted"? Then "dual stack" could become "all PDN/PDP IP types"? What do you think? 
Either way "dual stack" may leave some ambiguity to some readers not familiar with 3GPP networks here (especially as the terms appears in section 4.2. in association with separate single-IP-type PDP).
- The failure cases are potential failure cases - for the home routing table, I would like to see a middle column which describes "success" whether request is granted or a suitable fallback, as would be expected when visited networks are ready e.g. In an IPv4-only capable visited network, the terminal can request IPv4v6 and be downgraded to IPv4 PDP. I'd like to see all possible cases listed then, for example adding IPv4v6 request to "Dual Stack" visited network. If adding such a column is undesirable, then at least stressing that there is a *risk* of these failure cases, they are not an architectural certainty.
- So the current columns capturing failures could be labelled "potential failure cases (Home Routing)"
-Where there are no possible failure cases identified then "None" could replace "OK"
-To be clear I'd change"IPv6-only with 464xlat" to "IPv6-only (where UE is 464xlat enabled)" or similar. As this case is only highlighted for local breakout, then I'd not list it in the Home Routing table.

Section 4
- Would it make sense to keep section 4 as the "problem definition" text and split out the "mitigations" text? I am thinking some of the mitigations will mitigate more than one failure case?

Section4.2
-I am not clear whether failure case 2 is a failure or just a warning of knock-on effects? What is recommended at the home network or the visited network?
Would the approach of roaming profiles in HSS of section 4.1. also help here? Etc.

Section4.3.
>Since IMS roaming architecture will offload all traffic in the visited network
-Is this mandatory in all cases? I would suggest:
>In the IMS roaming architecture when traffic is offloaded in the visited network....

The next sections I must admit I found difficult - it may be my lack of understanding so apologies if so!
I assume you are trying to cover local breakout for both Data and IMS Voice use cases.

Section4.4.
-I am confused why this failure is not also applied to Home routing i.e. if visited network permits only IPv4 PDP?
Now I am wondering whether I understood the authors' intentions for "Visited Network Capability" column, if this is not a potential failure for Home Routing?
For local breakout do you mean specifically that the local breakout path at and beyond the GGSN /PGW is "IPv4-only" though the SGSN/SGW may allow all PDP/PDN types?
I would split out local breakout case into a table2, so the appropriate columns can be created and labelled.

Section 4.5
- So this is a local breakout issue where local DNS/NAT functionality is to be used?
-However, looking back at the table, a 464xlat capable UE could start by requesting IPv4v6, receive an IPv6 PDP, and try to invoke the CLAT functionality, could it not? 
So then it can go on to have the problems of case5. The bearer requested by the UE seems less relevant. Perhaps there are extra parameters assumed in the Local Breakout scenarios that I am missing e.g. the local breakout APN settings?; something more relevant to the case than what "UE requests"? I am not so familiar with all the local break out scenarios, but I would again suggest a separate table 2 for local breakout so that we can link the scenarios appropriately.
- Is the AAA server a solution for local breakout? I thought this was described by Dave as a Home Routing solution? The text is reasonable, just not sure why it appears specifically  in this section?

I hope this is useful.
Best Regards,
Nick Heatley

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of GangChen
Sent: 04 November 2013 17:50
To: v6ops
Cc: <[email-masked]>
Subject: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-02.txt

Wg,

BRs

Gang

2013/11/5, [email-masked] <[email-masked]>:
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

---

From: GangChen <[email-masked]>
Date: Thu, 7 Nov 2013 10:33:47 +0800

Hi Nick,
> A useful draft thank you.

thank you for the interest

> -Defining "failure" in this draft - in general I infer fallback is a success
> -so  you could adapt the middle sentences:
>>There may be a mismatch between the subscriber request and network
>> capability. In 3GPP networks a mismatch between the UE request and the
>> bearer network could result in bearer negotiation and a fallback to a
>> common bearer type. The failures here can be a result of no common bearer
>> type existing and the UE is left disconnected. Or in the case of local
>> breakout a failure could result from network functionality that is assumed
>> by the UE configuration being absent in the visited network. The following
>> table lists the potential failure cases.

The failure maybe not only about fallback. The cases can be
categorized as three types:
1) legacy can't parse the IPv4v6 (they even can't get chance to fallback)
2) Can't find a common bearer to fallback(I guess that is what you mentioned)
3) after the fallback, they found there is a mismatch with mobile
device expectation

1) is about home routed cases. 2) and 3) is about local-breakout

> Section3 - Table1
> - I would prefer to say that the UEs request IPv4v6, rather than dual stack.
> That is also what you have defined at the start of section 3.

Yes. It should be changed to PDP/PDN type IPv4v6

> - I would prefer to see two tables in this section, one covering Home
> routing and one covering local breakout, because of the following specific
> comments
> - Do you need to define what you mean by Dual Stack for the "Visited Network
> Capability"? I am wondering, in the case of Home routing, if "Visited
> Network Capability" is better expressed as "PDN/PDP IP Type permitted"? Then
> "dual stack" could become "all PDN/PDP IP types"? What do you think?
> Either way "dual stack" may leave some ambiguity to some readers not
> familiar with 3GPP networks here (especially as the terms appears in section
> 4.2. in association with separate single-IP-type PDP).

Your understanding is correct. We will take your comments into
consideration when we update the table. If the expression of "PDN/PDP
IP Type permitted" is adopted, the rows in the home routed mode may
only has two options: "all PDN/PDP IP types" and "PDP/PDN type IPv4v6
is not allowed". for the local breakout mode, they may have different
capabilities, i.e. "all PDN/PDP IP types", "PDN/PDP type IPv4", ,
"PDN/PDP type IPv6" and  "PDN/PDP type IPv4 & PDN/PDP type IPv6",

> - The failure cases are potential failure cases - for the home routing
> table, I would like to see a middle column which describes "success" whether
> request is granted or a suitable fallback, as would be expected when visited
> networks are ready e.g. In an IPv4-only capable visited network, the
> terminal can request IPv4v6 and be downgraded to IPv4 PDP. I'd like to see
> all possible cases listed then, for example adding IPv4v6 request to "Dual
> Stack" visited network. If adding such a column is undesirable, then at
> least stressing that there is a *risk* of these failure cases, they are not
> an architectural certainty.

In the home routed case, the failure is mainly about extended-PDP-type
AVP over Gr interface. The success can be achieved only if HLR/HSS
does send this AVP to vSGSN(it can be done by deleting or send
different profiles to vPLMN). Is this description you want to see?

> -To be clear I'd change"IPv6-only with 464xlat" to "IPv6-only (where UE is
> 464xlat enabled)" or similar. As this case is only highlighted for local
> breakout, then I'd not list it in the Home Routing table.
>
> Section 4
> - Would it make sense to keep section 4 as the "problem definition" text and
> split out the "mitigations" text? I am thinking some of the mitigations will
> mitigate more than one failure case?

That could be a way. But, I would like to wait for more comments on
the document structure.

> Section4.2
> -I am not clear whether failure case 2 is a failure or just a warning of
> knock-on effects? What is recommended at the home network or the visited
> network?

Splitting PDP type IPv4v6 into parallel two is a standard behavior in
3GPP. It may creates the failure when mobile devices have some
limitations to request IPv6. Local-break out option could be disable
in this case or mobile device could be configured to request IPv4 in
vPLMN

> Would the approach of roaming profiles in HSS of section 4.1. also help

HSS can only help to pass the attach process. But it can't address the
whole issue

> -Is this mandatory in all cases? I would suggest:

Yes. It's the GSMA recommendation

> Now I am wondering whether I understood the authors' intentions for "Visited
> Network Capability" column, if this is not a potential failure for Home
> Routing?

this failure is only for local breakout

> For local breakout do you mean specifically that the local breakout path at
> and beyond the GGSN /PGW is "IPv4-only" though the SGSN/SGW may allow all
> PDP/PDN types?

there is the case SGSN could understand all PDP/PDN types but GGSN
only assign IPv4 address

> - So this is a local breakout issue where local DNS/NAT functionality is to

yes

> -However, looking back at the table, a 464xlat capable UE could start by
> requesting IPv4v6, receive an IPv6 PDP, and try to invoke the CLAT
> functionality, could it not?

AFAIK, it's proper to only request PDP type IPv6-only for a 464xlat
capable UE. If you check with table, there only is IPv6-only with
464xlat.

> So then it can go on to have the problems of case5. The bearer requested by
> the UE seems less relevant. Perhaps there are extra parameters assumed in
> the Local Breakout scenarios that I am missing e.g. the local breakout APN
> settings?; something more relevant to the case than what "UE requests"? I am
> not so familiar with all the local break out scenarios, but I would again
> suggest a separate table 2 for local breakout so that we can link the
> scenarios appropriately.
> - Is the AAA server a solution for local breakout? I thought this was
> described by Dave as a Home Routing solution? The text is reasonable, just

I would like to point out the case 5 is mainly about intra-PLMN
mobility. therefore, AAA server here is deployed in the same operator.
I guess it aligns with Dave description.

> not sure why it appears specifically  in this section?

We would move the AAA server description into an independent section.

> I hope this is useful.

thank you for the effort

Best Regards

Gang

> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use
> for any purpose.
>
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments
> are free from any virus, but it remains your responsibility to ensure that
> viruses do not adversely affect you.
>
> EE Limited