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

From: [email-masked]
Date: Sun, 03 Aug 2014 18:07:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : IPv6 Roaming Behavior Analysis
        Authors         : Gang Chen
                          Hui Deng
                          Dave Michaud
                          Jouni Korhonen
                          Mohamed Boucadair
                          Vizdal Ales
	Filename        : draft-ietf-v6ops-ipv6-roaming-analysis-02.txt
	Pages           : 16
	Date            : 2014-08-03

Abstract:
   This document identifies a set of failure cases that may be
   encountered by an IPv6-enabled mobile customers in roaming scenarios.
   The investigations on those failed cases reveal the causes in order
   to notice improper configurations, equipment's incomplete functions
   or inconsistent IPv6 introduction strategy.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-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/

---

From: GangChen <[email-masked]>
Date: Mon, 4 Aug 2014 09:11:59 +0800

WG,

We have uploaded the new draft according to the comments received so far.
Please kindly check.

Many thanks

Gang

2014-08-04 9:07 GMT+08:00, [email-masked] <[email-masked]>:
> _______________________________________________
> 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: Ross Chandler <[email-masked]>
Date: Mon, 4 Aug 2014 17:18:56 +0100

> We have uploaded the new draft according to the comments received so far.

Hi All,

IMHO the main utility of this draft is to create a point of reference to the gap in 
the standards created by the introduction of support for dual-stack over a single 
radio bearer in separate 3GPP Releases for PDP/PDN context creation. 
To that end I’d like it to have clearer recommendations on how to close that gap.

e.g. New HLR/HSS functionality to by default restrict the sending PDP-Ext-Type/IPv4v6 
with a whitelist of known good networks. Also the complement the default allow sending 
of PDP-Ext-Type/IPv4v6 with a network blacklist.

Section 7, discussions,  says “dual-stack deployment is recommended in most cases”.
Is that still the consensus position?  Going straight to single-stack IPv6 is looking very viable now
when the UE supports a method of providing translated IPv4 access over the IPv6 PDP/PDN 
connection. 

Ross

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 4 Aug 2014 18:31:03 +0200 (CEST)

> To that end I’d like it to have clearer recommendations on how to close that gap.

My opinion is not that any part of the standard is the problem, but rather 
buggy implementations.

> e.g. New HLR/HSS functionality to by default restrict the sending 
> PDP-Ext-Type/IPv4v6 with a whitelist of known good networks. Also the 
> complement the default allow sending of PDP-Ext-Type/IPv4v6 with a 
> network blacklist.

These are operational requriements, and I fully support putting them in 
some kind of document, but the question is if it's really "roaming 
analysis" anymore. The language would need to be very careful not to make 
any recommendations then (?), but rather suggest possible ways of 
working around the problems seen.

> when the UE supports a method of providing translated IPv4 access over the IPv6 PDP/PDN

I don't think there is consensus here. The draft could point out pros and 
cons with each approach.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ross Chandler <[email-masked]>
Date: Tue, 5 Aug 2014 08:20:11 +0100

On 4 Aug 2014, at 17:31, Mikael Abrahamsson <[email-masked]> wrote:
> My opinion is not that any part of the standard is the problem, but rather buggy implementations.

Fair enough, whether through lazy/buggy implementations or a real gap, the resulting network reality requires significantly most commitment to IPv6 deployment from the mobile operator.
We have to make a not particularly paletable choice because of it, getting capex approval for spending on proprietary workarounds or deploy only on Android.

>> e.g. New HLR/HSS functionality to by default restrict the sending PDP-Ext-Type/IPv4v6 with a whitelist of known good networks. Also the complement the default allow sending of PDP-Ext-Type/IPv4v6 with a network blacklist.
> 
> These are operational requriements, and I fully support putting them in some kind of document, but the question is if it's really "roaming analysis" anymore. The language would need to be very careful not to make any recommendations then (?), but rather suggest possible ways of working around the problems seen.

Something like my above sentence could go into it as an observation. Analysis’s can have observations that stop short of being recommendations.

> I don't think there is consensus here. The draft could point out pros and cons with each approach.

Fred has generalised the scope of my question beyond 3GPP with an agenda for what might be required to update the consensus. I think the question is too broad for this draft.
Focusing on the mobile case, where there's near ubiquitous RFC1918/RFC6598 use to get to the provider NAT44, replacing that with IPv6 to get the legacy NAT64 gateway seems like such a compelling case that the one size fits all dual-stack recommendation is no longer fit for purpose.

Ross

---

From: GangChen <[email-masked]>
Date: Tue, 5 Aug 2014 18:28:28 +0800

> I don't think there is consensus here. The draft could point out pros and

I'm not a fan of dual-stack deployment. However, I have to point out
if you take look at TS23.060 or TS23.401, you may find the sentence "A
UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6".
GSMA quotes the similar language from 3GPP for roaming guidance.
Therefore, that is at least a consensus in other SDOs.

The draft intends to state the issues and potential workarounds in
various scenarios. Argument of selection of dual-stack or IPv6-only
may not be the goal of the draft.

BRs

Gang

---

From: Jouni <[email-masked]>
Date: Tue, 5 Aug 2014 13:53:50 +0300

> may not be the goal of the draft.

We had this discussion a long ago.. and back then we agreed not to promote any specific solution (like XLAT etc) but just give facts how different approaches work.

- Jouni

> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ross Chandler <[email-masked]>
Date: Tue, 5 Aug 2014 12:32:41 +0100

> We had this discussion a long ago.. and back then we agreed not to promote any specific solution (like XLAT etc) but just give facts how different approaches work.

The TS23.975 recommendations do allow for a second strategy. I can’t find TS23.975 explicitly saying dual-stack is preferred or recommended over single stack.
Although at the time they were writing it they were probably implicitly assuming that. TS23.975 mentions DS-Lite, NAT64 and BIH but was too early for 464XLAT, or MAP-T/E.

"The second strategy, consisting of providing the UE with IPv6-only connectivity, can be considered as a first stage or an ultimate target scenario for operators.”

So there’s an argument to remove “dual-stack deployment is recommended in most cases” from this draft, particularly if it has already been discussed and agreed not to promote any solution.

BR 
Ross

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 5 Aug 2014 15:53:04 +0000

>So there's an argument to remove "dual-stack deployment is recommended in most cases" from this draft, particularly if it has already been discussed and agreed not to promote any solution.

Agree.

Also the standards statement:
"A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6".
does not mean that the UE is placed into a dual stack mode of operation. It is signalling to the network that it can support all modes.
(We desire the UE to request IPv4v6 in the home network and we can let the core network push the UE to IPv6-only mode of operation.
When on legacy small-cells, where the access-points do not support the new PDN types, the device can gracefully fallback to IPv4, if it requests IPv4v6.)
Nick

From: v6ops [mailto:[email-masked]] On Behalf Of Ross Chandler
Sent: 05 August 2014 12:33
To: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-02.txt

On 5 Aug 2014, at 11:53, Jouni <[email-masked]<mailto:[email-masked]>> wrote:

2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>>:

Section 7, discussions,  says "dual-stack deployment is recommended in
most cases".
Is that still the consensus position?  Going straight to single-stack IPv6
is looking very viable now
when the UE supports a method of providing translated IPv4 access over the
IPv6 PDP/PDN
connection.

- Jouni

The TS23.975 recommendations do allow for a second strategy. I can't find TS23.975 explicitly saying dual-stack is preferred or recommended over single stack.
Although at the time they were writing it they were probably implicitly assuming that. TS23.975 mentions DS-Lite, NAT64 and BIH but was too early for 464XLAT, or MAP-T/E.

"The second strategy, consisting of providing the UE with IPv6-only connectivity, can be considered as a first stage or an ultimate target scenario for operators."

So there's an argument to remove "dual-stack deployment is recommended in most cases" from this draft, particularly if it has already been discussed and agreed not to promote any solution.

BR
Ross

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: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 10:09:35 +0100

> When on legacy small-cells, where the access-points do not support the new PDN types, the device can gracefully fallback to IPv4, if it requests IPv4v6.)

Proposed update 

4.  Failure Case in Attachment Stage

   3GPP specified PDP/PDN type IPv4v6 in order to allow a UE request
   both IPv4 and IPv6 within a single PDP/PDN request.

is changed to

4.  Failure Case in Attachment Stage

   3GPP specified PDP/PDN type IPv4v6 in order to allow a UE indicate its capability to support dual-stack, both IPv4 and IPv6 with a single or separate PDP/PDN connections.

BR
Ross

---

From: GangChen <[email-masked]>
Date: Wed, 6 Aug 2014 18:42:45 +0800

Ross and Nick,

The draft doesn't intend to advocate any deployment mode.
To be clear, "dual-stack deployment is recommended in most cases" will
be removed at the next update.

Gang

2014-08-05 23:53 GMT+08:00, Heatley, Nick <[email-masked]>:
>>So there's an argument to remove "dual-stack deployment is recommended in
>> most cases" from this draft, particularly if it has already been discussed
>> and agreed not to promote any solution.
>
> Agree.
>
> does not mean that the UE is placed into a dual stack mode of operation. It
> is signalling to the network that it can support all modes.
> (We desire the UE to request IPv4v6 in the home network and we can let the
> core network push the UE to IPv6-only mode of operation.
> When on legacy small-cells, where the access-points do not support the new
> PDN types, the device can gracefully fallback to IPv4, if it requests
> IPv4v6.)
> Nick
>
> Subject: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-ipv6-roaming-analysis-02.txt
>
>
> On 5 Aug 2014, at 11:53, Jouni
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
> 2014-08-05 0:31 GMT+08:00, Mikael Abrahamsson
> <[email-masked]<mailto:[email-masked]>>:
>
>
> We had this discussion a long ago.. and back then we agreed not to promote
> any specific solution (like XLAT etc) but just give facts how different
> approaches work.
>
> - Jouni
>
>
> The TS23.975 recommendations do allow for a second strategy. I can't find
> TS23.975 explicitly saying dual-stack is preferred or recommended over
> single stack.
> Although at the time they were writing it they were probably implicitly
> assuming that. TS23.975 mentions DS-Lite, NAT64 and BIH but was too early
> for 464XLAT, or MAP-T/E.
>
> "The second strategy, consisting of providing the UE with IPv6-only
> connectivity, can be considered as a first stage or an ultimate target
> scenario for operators."
>
> So there's an argument to remove "dual-stack deployment is recommended in
> most cases" from this draft, particularly if it has already been discussed
> and agreed not to promote any solution.
>
> BR
> Ross
>
> 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

---

From: GangChen <[email-masked]>
Date: Wed, 6 Aug 2014 19:14:41 +0800

2014-08-06 17:09 GMT+08:00, Ross Chandler <[email-masked]>:
>> >So there’s an argument to remove “dual-stack deployment is recommended in
>> > most cases” from this draft, particularly if it has already been
>> > discussed and agreed not to promote any solution.
>>
>> Agree.
>>
>> does not mean that the UE is placed into a dual stack mode of operation.
>> It is signalling to the network that it can support all modes.
>    3GPP specified PDP/PDN type IPv4v6 in order to allow a UE indicate its
> capability to support dual-stack, both IPv4 and IPv6 with a single or
> separate PDP/PDN connections.

It may could say "PDP/PDN type IPv4v6 implicitly allow network to
assign IPv4-only, IPv6-only, IPv4+IPv6 in single PDP/PDN bearer,
IPv4+IPv6 in separated PDP/PDN bearers." However, I don't think that
is the purpose of introducing IPv4v6 PDP/PDN.  The essential of IPv4v6
is to allow UE get IPv4 and IPv6 on a single bearer so as to reduce
network costs. RFC6459 also has similar description, i.e. This enables
parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6)"

Gang

---

From: Ross Chandler <[email-masked]>
Date: Wed, 6 Aug 2014 12:50:53 +0100

>> separate PDP/PDN connections.

Gang,

Shouldn’t the draft make both points.

 It is a capability indication (or otherwise expressed as implicit allow) from the UE that it can

> " allow network to
> IPv4+IPv6 in separated PDP/PDN bearers.”

And this point.

> However, I don't think that
> parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6)”

BR 
Ross

---

From: GangChen <[email-masked]>
Date: Thu, 7 Aug 2014 09:30:14 +0800

>> parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6)”

Sure. It will be added