Subject: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

From: The IESG <[email-masked]>
Date: Thu, 02 Oct 2014 08:45:53 -0700

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices'
  <draft-ietf-v6ops-mobile-device-profile-13.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-10-16. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This is the second iteration of this document to be IETF Last Called having
previously been here at draft 04. Substantial changes to the document have 
occurred inclusive of the removal of much of the normative language. 

Abstract

   This document defines an IPv6 profile that a number of operators
   recommend in order to connect 3GPP mobile devices to an IPv6-only or
   dual-stack wireless network (including 3GPP cellular network and IEEE
   802.11 network).

   This document defines a different profile than the one for general
   connection to IPv6 cellular networks defined in the IPv6 for Third
   Generation Partnership Project (3GPP) Cellular Hosts document.  In
   particular, this document identifies also features to deliver IPv4
   connectivity service over an IPv6-only transport.

   Both hosts and devices with capability to share their WAN (Wide Area
   Network) connectivity are in scope.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Oct 2014 16:30:18 +0900

> occurred inclusive of the removal of much of the normative language.

That assessment of the changes is incorrect, unless "removal of the
normative language" means "replace all upper-case MUST with lower-case
must".

The diff from -04 to -13 is at
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-v6ops-mobile-device-profile-04.txt&url2=draft-ietf-v6ops-mobile-device-profile-13.txt
. The attentive reader will see that that most of the text is identical.

That aside:

1. This text is incorrect and should be removed:

   The key words "must", "must not", "should", "should not", and "may"
   in this document are to be interpreted as described in RFC 2119
   [RFC2119].

It is meaningless to say, in the same document, that "must" is to be
interpreted as described in RFC 2119 ("an absolute requirement of the
specification"), and simultaneously that "this document is not a standard".

2. I stand by my earlier assessment that this document's requirements are
over-broad, and in fact so broad as to harm adoption. There may well be
operators or device implementers that seeing with such a high number of
requirements may shy away in terror and think that deploying IPv6 in a
mobile network is an impossibly high amount of work. That said, given that
this document says clearly that it is not a standard, and that compliance
is not required, the harm it does will be limited.

Regards,
Lorenzo

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 7 Oct 2014 09:30:33 +0000

2. I stand by my earlier assessment that this document's requirements are over-broad, and in fact so broad as to harm adoption. There may well be operators or device implementers that seeing with such a high number of requirements may shy away in terror and think that deploying IPv6 in a mobile network is an impossibly high amount of work. That said, given that this document says clearly that it is not a standard, and that compliance is not required, the harm it does will be limited.

There may well be operators and device implementers that see the many individual “IPv6” RFCs and shy away. Transitioning technologies are still perceived as issues for the network.
If this cross-operator document states what is required on terminals to work in all major/predictable IPv6 scenarios, then it is giving such people a view of what a “healthy and robust” terminal implementation would consist of. If they are able to deliver on these requirements then they can supply a terminal ready for all business areas /all operator network scenarios.
(It certainly stops the feedback I’ve had from certain corners “that no other operators are asking for IPv6”, and “what you are asking for is a single operator roadmap which we won’t do”. That has been the reality here). So I don’t see how a consolidated demand-side view from operators who are really trying to introduce IPv6  in mobile can harm adoption in any way.
Regards,
Nick

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 06 October 2014 08:30
To: IETF Discussion
Cc: [email-masked] WG; IETF-Announce
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

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: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Oct 2014 19:20:28 +0900

On Tue, Oct 7, 2014 at 6:55 AM, <[email-masked]> wrote:

> Also, if you're documenting a protocol that's not an IETF Standard, the
> protocol
> description can still benefit from RFC2119 semantics.  If there's a spot
> where the protocol semantic should have a 'MUST NOT', and a client does it
> anyhow, what happens?
>

Sure. But this is not a protocol, this is a recommended set of features.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Oct 2014 19:30:41 +0900

On Tue, Oct 7, 2014 at 6:30 PM, Heatley, Nick <[email-masked]> wrote:
>
> If this cross-operator document states what is required on terminals to
> work in all major/predictable IPv6 scenarios, then it is giving such people
> a view of what a “healthy and robust” terminal implementation would consist
> of. If they are able to deliver on these requirements then they can supply
> a terminal ready for all business areas /all operator network scenarios.
>

It depends on your point of view. The way I see it, it's giving such people
a view of what a kitchen sink consists of.

 (It certainly stops the feedback I’ve had from certain corners “that no
> other operators are asking for IPv6”, and “what you are asking for is a
> single operator roadmap which we won’t do”. That has been the reality
> here). So I don’t see how a consolidated demand-side view from operators
> who are really trying to introduce IPv6  in mobile can harm adoption in any
> way.
>

Show me an operator whose rollout is genuinely blocked on terminal features
and I will believe you. But word from everyone I've talked to is that
terminal features are not the blocker. Operators such as Verizon Wireless
and T-Mobile in the US have deployed tens of millions of IPv6-capable
devices, and none of those devices (and, I'd argue, no commercial devices,
anywhere) implement all the features in this profile. The vast majority
only support a handful.

The main problem I have with this document is it provides one more excuse
to naysayers who believe that IPv6 is hard. The truth is that various
operators have built perfectly functioning IPv6 mobile networks which
implement only a handful of these features. But if the naysayers see this
document, they'll say "See? Told you - IPv6 is so complicated that it will
cost us a boatload of money, and it will bring no additional revenue. No
point in implementing it."

---

From: <[email-masked]>
Date: Tue, 7 Oct 2014 11:42:39 +0000

On Tue, Oct 7, 2014 at 6:30 PM, Heatley, Nick <[email-masked]<mailto:[email-masked]>> wrote:
If this cross-operator document states what is required on terminals to work in all major/predictable IPv6 scenarios, then it is giving such people a view of what a “healthy and robust” terminal implementation would consist of. If they are able to deliver on these requirements then they can supply a terminal ready for all business areas /all operator network scenarios.

It depends on your point of view. The way I see it, it's giving such people a view of what a kitchen sink consists of.
[DB] Maybe you are right, maybe not.

Show me an operator whose rollout is genuinely blocked on terminal features and I will believe you. But word from everyone I've talked to is that terminal features are not the blocker. Operators such as Verizon Wireless and T-Mobile in the US have deployed tens of millions of IPv6-capable devices, and none of those devices (and, I'd argue, no commercial devices, anywhere) implement all the features in this profile. The vast majority only support a handful.
[DB] Do we consider that all features are mandatory in the draft ? Not at all and it demonstrates that RFC 2119 terminology is useful. Whatever you think, it is still a problem to get some IPv6-ready devices and that explains why some on-going IPv6 deployment still rely on some limited number of devices in some areas. The document will not solve everything but it could help some operators to discuss with vendors about their requirements, as it has been mentioned by several ones on this mailing list.

The main problem I have with this document is it provides one more excuse to naysayers who believe that IPv6 is hard. The truth is that various operators have built perfectly functioning IPv6 mobile networks which implement only a handful of these features. But if the naysayers see this document, they'll say "See? Told you - IPv6 is so complicated that it will cost us a boatload of money, and it will bring no additional revenue. No point in implementing it."
[DB] Operators do not need any excuse for some strategy elaboration. And the document does not add any new hurdles for IPv6 deployment since it list some requirements based on existing specifications. We should speak for ourselves and should not imagine how other people will consider such document.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Oct 2014 21:21:42 +0900

On Tue, Oct 7, 2014 at 8:42 PM, <[email-masked]> wrote:

>  Show me an operator whose rollout is genuinely blocked on terminal
> features and I will believe you. But word from everyone I've talked to is
> that terminal features are not the blocker. Operators such as Verizon
> Wireless and T-Mobile in the US have deployed tens of millions of
> IPv6-capable devices, and none of those devices (and, I'd argue, no
> commercial devices, anywhere) implement all the features in this profile.
> The vast majority only support a handful.
>
>  [DB] Do we consider that all features are mandatory in the draft ? Not
> at all and it demonstrates that RFC 2119 terminology is useful.
>

Ok, then. So here are examples of musts that are not required for IPv6
operation in a mobile network, and not supported in widely deployed mobile
platforms:

C-3 PDP context fallback
C-9 RDNSS
C-10 DHCPv6
C-11 DNS provisioning order
C-12 PDP type limitation
W-1 IPv6-only wifi
A-1 Privacy addresses (because the IID is provided by the network)
A-5 Prefer IPv6 DNS server
L-1 DHCPv6 PD
L-2 Full Customer Edge Router support
A-2 Applications must be IP agnostic
A-3 URI format

Whatever you think, it is still a problem to get some IPv6-ready devices
> and that explains why some on-going IPv6 deployment still rely on some
> limited number of devices in some areas.
>

Then please explain to me how Verizon Wireless supports IPv6 on all its LTE
devices, and has done since 2011?

> the document does not add any new hurdles for IPv6 deployment since it
> list some requirements based on existing specifications.
>

But it does add hurdles for IPv6 deployment. Because it lists lots of
requirements that are not required for IPv6 deployment in mobile networks,
and that are not widely supported by mobile devices.

> We should speak for ourselves and should not imagine how other people will
> consider such document.
>

Sorry, no. As IETF contributors it is our job to consider what other people
will think when they read the documents that we produce.

---

From: Ross Chandler <[email-masked]>
Date: Tue, 7 Oct 2014 14:45:27 +0100

On 7 Oct 2014, at 11:30, Lorenzo Colitti <[email-masked]> wrote:

> It depends on your point of view. The way I see it, it’s giving such people a view of what a kitchen sink consists of.

There are a few of these RFCs giving lists.  On the fixed side I ask vendors to support RFC 6092 and RFC 7084 and that starts a dialogue on want we really need for initial deployment. I’ve got spreadsheets back from vendors listing point by point what they support, have road-mapped, don’t plan to support. That’s often fine as I don’t need all the features initially.

> Show me an operator whose rollout is genuinely blocked on terminal features and I will believe you. But word from everyone I've talked to is that terminal features are not the blocker. Operators su…

If Apple iOS supported IPv6-only/464xlat and all mobile devices had better support for problem roaming cases then I might think this might not provide a needed signal but it would still be useful to have a document listing desired features.

> The main problem I have with this document is it provides one more excuse to naysayers who believe that IPv6 is hard. The truth is that various operators have built perfectly functioning IPv6 mobile networks which implement only a handful of these features. But if the naysayers see this document, they'll say "See? Told you - IPv6 is so complicated that it will cost us a boatload of money, and it will bring no additional revenue. No point in implementing it.”

The majority of work implementing the appropriate subset of the features is with the mobile device vendor. There’s a growing list of operators to look at that are doing it under restricted circumstances. Items from the list could help operators broaden the scope of their IPv6 deployments.

BR
Ross

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Oct 2014 22:54:54 +0900

On Tue, Oct 7, 2014 at 10:45 PM, Ross Chandler <[email-masked]> wrote:

> If Apple iOS supported IPv6-only/464xlat and all mobile devices had better
> support for problem roaming cases then I might think this might not provide
> a needed signal but it would still be useful to have a document listing
> desired features.
>

I agree with you that these two are problems, and that solving them would
improve the state (and the amount of) IPv6 in mobile networks. It would be
good to have discussions and publish documents on real issues that actually
affect deployment. But the way to do so is not to bury those real issues
into a laundry list of requirements. (Not to mention that this document
classes 464xlat as "should".)

> The majority of work implementing the appropriate subset of the features
> is with the mobile device vendor. There’s a growing list of operators to
> look at that are doing it under restricted circumstances. Items from the
> list could help operators broaden the scope of their IPv6 deployments.
>

Other than the two features you mention above, which ones are likely to
have an impact? Perhaps this document should focus more on those.

---

From: "Heatley, Nick" <[email-masked]>
Date: Tue, 7 Oct 2014 16:29:24 +0000

Lorenzo,
I have had another look at the list of reqts you highlight. I find each referencing a valid RFC or 3GPP section, and each explaining the context in which the reqt is valid.
Simply arguing that they do not exist widely today is not reason to discount these.
[For your info on privacy extension, the IID is not provided by the network, a temp IID is provided during the attach to the PGW but this is then superseded by the SLAAC process after the network prefix is learnt via RA. Major handset OS including yours provide temporary addresses with pseudo-random IID.]
Regarding DHCPv6 and Prefix Del, then I know of no operator network using this today. However this is the only requirement that a mobile operator can give to their product marketing people, I feel we would be foolish to lose these. An IPv6 requirement that actually could bring new business ☺

May I remind you of the objectives set out in section 1
The objectives of this effort are:

   1.  List in one single document a comprehensive list of IPv6 features
       for a mobile device, including both IPv6-only and dual-stack
       mobile deployment contexts.  These features cover various network
       types such as GPRS (General Packet Radio Service), EPC (Evolved
       Packet Core) or IEEE 802.11 network.

   2.  Help Operators with the detailed device requirement list
       preparation (to be exchanged with device suppliers).  This is
       also a contribution to harmonize Operators' requirements towards
       device vendors.

   3.  Vendors to be aware of a set of features to allow for IPv6
       connectivity and IPv4 service continuity (over an IPv6-only
       transport).

I find the objectives clear and the document goes on to meets those objectives.

In this paper both IPv6-only and dual stack are valid, and the reqts that apply to IPv6-only tend to state that; this is an operator choice.
As I understand it:
Verizon Wireless have achieved their fantastic IPv6 penetration using a dual stack deployment model (perhaps they would therefore argue that 464xlat is only a “should”).
T-Mobile US also have great results with 464xlat on an IPv6-only APN, however tethering/wifi hotspot is via another APN.

To provide IPv6-only on a single APN including tethering/Wifi Hostspot is difficult due to breadth of terminal support, including some poor tethering integration (L_REQ#4 deficiency).
As Orange Poland have embarked on this deployment, a view from Orange Poland and terminals would be welcomed!
My perception is that, in this scenario, a number of OS and OEM implementations that can support dual stack perfectly well have not achieved suitability here.
For operators who need to decouple their growth from IPv4 addressing, your synopsis of “terminals not blocking rollout” is not the reality. Terminals remain an issue.
But it is not the intention to list problems but to highlight what is required for service continuity.
Regards,
Nick

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: 07 October 2014 13:22
To: BINET David IMT/OLN
Cc: Heatley, Nick; [email-masked] WG; IETF Discussion; IETF-Announce
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

On Tue, Oct 7, 2014 at 8:42 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Show me an operator whose rollout is genuinely blocked on terminal features and I will believe you. But word from everyone I've talked to is that terminal features are not the blocker. Operators such as Verizon Wireless and T-Mobile in the US have deployed tens of millions of IPv6-capable devices, and none of those devices (and, I'd argue, no commercial devices, anywhere) implement all the features in this profile. The vast majority only support a handful.
[DB] Do we consider that all features are mandatory in the draft ? Not at all and it demonstrates that RFC 2119 terminology is useful.

Ok, then. So here are examples of musts that are not required for IPv6 operation in a mobile network, and not supported in widely deployed mobile platforms:

C-3 PDP context fallback
C-9 RDNSS
C-10 DHCPv6

Whatever you think, it is still a problem to get some IPv6-ready devices and that explains why some on-going IPv6 deployment still rely on some limited number of devices in some areas.

Then please explain to me how Verizon Wireless supports IPv6 on all its LTE devices, and has done since 2011?

the document does not add any new hurdles for IPv6 deployment since it list some requirements based on existing specifications.

But it does add hurdles for IPv6 deployment. Because it lists lots of requirements that are not required for IPv6 deployment in mobile networks, and that are not widely supported by mobile devices.

We should speak for ourselves and should not imagine how other people will consider such document.

Sorry, no. As IETF contributors it is our job to consider what other people will think when they read the documents that we produce.

NOTICE AND DISCLAIMER

EE Limited

---

From: [email-masked]
Date: Mon, 06 Oct 2014 17:55:45 -0400

> specification"), and simultaneously that "this document is not a standard".

We've probably already done that same exact thing in close to a thousand, if
not more, 'Informational" RFC releases.  That ship has long since sailed.

Also, if you're documenting a protocol that's not an IETF Standard, the protocol
description can still benefit from RFC2119 semantics.  If there's a spot
where the protocol semantic should have a 'MUST NOT', and a client does it
anyhow, what happens?

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Wed, 8 Oct 2014 13:52:40 +0000

Hi,
Majority of modern smartphones from Sony, HTC, LG, Samsung, Nokia WP8.1 are compliant with CLAT+NAT64/DNS/DNS64
Together with Michał Czerwonka we created document with mandatory IPv6 requirements, close cooperation with vendors succeeded and we managed to launch first terminal (Xperia Z1) in September 2013, after 12 months we have 13% of IPv6 only mobile users in a network. If you are mobile operator and you thinking about IPv6 migration you won’t have any problems with Smartphones (except Iphones=NO CLAT support) the way is paved for you...

  1.  Network Configuration (CLAT+NAT64+DNS)
Internet access is done by establishing one dedicated IPv6-only PDP/PDN context, network supports 464xlat architecture with DNS Dual-Stack (DNS64 feature is available only for domain “ipv4only.arpa”) - RFC 6877. CLAT implementation is mandatory for all devices

  1.  UE, CPE vendor IPv6 mandatory requirements
2.1.Dynamic IPv6 Address Allocation + IID randomly generated (privacy address) +  UE shall use the IID given in PDP activation response message to configure its LLA (3GPP TS  23.060<http://www.3gpp.org/ftp/Specs/archive/23_series/23.060>) http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/.
2.2.Customer Side Translator function (CLAT) must be embedded (smartphone/tablet/router) as part of 464xlat architecture  RFC 6877. The CLAT must support ICMP, UDP, TCP, GRE and fragmented packet. clatd.conf  - may be generic where the domain for nat64 prefix discovery must be “ipv4only.arpa” –  static configuration may be required.
https://android.googlesource.com/platform/external/android-clat/
2.3.MTU size & device interfaces - If the network send MTU size in RA message, then device must set it to the radio interface otherwise set the default value=1500B. The CLAT demon will calculate MTU size automatically for its interfaces (clat and clat4).

  1.  IPv6 tethering - the CLAT helps Dual Stack tethering solution both USB/WIFI on the device , when APN is IPv6-only. The Global IPv6 and private IPv4 (clat) must be enabled on tethered LAN.
http://tools.ietf.org/html/rfc7278 (scenario 2)
3.1.RA – device sends RA message to tethered host with Ipv6 prefix information. Router lifetime set=9000 secs. Router sends periodically RA message – max. value 9000 secs.
3.2.DHCPv6 – device server relays PCO Ipv6 DNS'es addresses to tethered hosts.
3.3.DHCPv4 – device server relays  private IPv4 address and send DNS IPv4 (CLAT DNS-proxy)
3.4.Tethering & MTU size – device propagates MTU size 1500B to tethered clients interfaces ( Ipv4&Ipv6)

  1.  IPv6 LTE UE  - the device must set EIT bit=1 in “Initial Attach” message.
Roaming - when APN with IPv6 protocol fails in roaming it must automatically revert back APN protocol to IPv4

One thing is still missing – different APN profiles(APN name+PDP type) for roaming –, there are two use cases:
Euinterent – (“EU Roaming Regulation III”) Internet APN available in UE countries (VPLMN subscriber is allowed to use VGGSN APN)
“Roaming Fallback to IPv4” creating separate roaming profile with APN name/PDP (now roaming fallback is based only on PDP type Android4.x/WP8.1)

Here are the benefits of extending APN profiles:

-       APN profiles and its “zones” HPLMN/VPLMN can separate IPv6 form IPv4

-       Separate APN for HPLMN (Ipv6 only APN for HPLMN)

-       Separate  APN for VPLMN roaming (fallback to IPv4 based on APN name)

-       Euinternet APN as secondary roaming profile for manual selection

Best Regards,
Tomasz Kossut

From: Heatley, Nick [mailto:[email-masked]]
Sent: Tuesday, October 07, 2014 11:31 AM
To: Lorenzo Colitti; IETF Discussion
Cc: [email-masked] WG; IETF-Announce
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 06 October 2014 08:30
To: IETF Discussion
Cc: [email-masked]<mailto:[email-masked]> WG; IETF-Announce
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

NOTICE AND DISCLAIMER

EE Limited

---

From: Ross Chandler <[email-masked]>
Date: Wed, 8 Oct 2014 19:47:40 +0100

On 8 Oct 2014, at 14:52, Kossut Tomasz - Hurt <[email-masked]> wrote:

> Network Configuration (CLAT+NAT64+DNS)
> UE, CPE vendor IPv6 mandatory requirements
> 2.1.Dynamic IPv6 Address Allocation + IID randomly generated (privacy address) +  UE shall use the IID given in PDP activation response message to configure its LLA (3GPP TS  23.060)http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/.
> 
> IPv6 tethering - the CLAT helps Dual Stack tethering solution both USB/WIFI on the device , when APN is IPv6-only. The Global IPv6 and private IPv4 (clat) must be enabled on tethered LAN.
> IPv6 LTE UE  - the device must set EIT bit=1 in “Initial Attach” message.

Hi Tomasz,

Nice post.

Regarding the EIT bit=1, are all the above vendors setting that or any not setting it? I haven’t had to explicitly request that in any of the smartphone UEs I’ve tested. It just worked. 

Is the automatic fallback, when roaming, from APN protocol IPv6 to APN protocol IPv4 when there’s a problem with IPv6 something you _already_ have with your UEs or a desired behaviour? 
I don’t see fallback to IPv4 when the network or HLR/HSS denies IPv6. The RIL only fallbacks from IPv4v6 to IPv4, or parallel IPv4 and IPv6. 

BR
Ross

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

---

From: Jouni <[email-masked]>
Date: Wed, 8 Oct 2014 23:44:13 +0300

Hi Kossut,

Few questions just for my clarification.. See inline..

On Oct 8, 2014, at 4:52 PM, Kossut Tomasz - Hurt wrote:

> 	• Network Configuration (CLAT+NAT64+DNS)
> 	• UE, CPE vendor IPv6 mandatory requirements
> 2.1.Dynamic IPv6 Address Allocation + IID randomly generated (privacy address) +  UE shall use the IID given in PDP activation response message to configure its LLA (3GPP TS 23.060) http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/.
> 

Why aren't you using (in an UE case) the "safe" default MTU sizes defined in TS23.060 when there is no MTU sent in an RA?

> 	• IPv6 tethering - the CLAT helps Dual Stack tethering solution both USB/WIFI on the device , when APN is IPv6-only. The Global IPv6 and private IPv4 (clat) must be enabled on tethered LAN.
> 	• IPv6 LTE UE  - the device must set EIT bit=1 in “Initial Attach” message.

You mean PDN Connectivity Request message, right?
Anyway, what does EIT setting have to do with IPv6? Just curious..

- Jouni

---

From: joel jaeggli <[email-masked]>
Date: Sun, 19 Oct 2014 15:53:59 -0700

Summarizing What I see here.

The concerns about the breadth or appropriateness of the document are
well understood. The will never be entirely ameliorated but I think we
can live with them.

The substantial changes between the previous last call around draft 8
and the present one draft 13 produced something that I think with minor
misgivings represents working group output and IETF consensus.

Concerns with requirements  for PCP exist related the privacy
implications for such direct mappings,  we were mindful of in the
context of RFC 6887 which we saw fit to publish so I don't see a reason
understanding that, that we would take PcP off the table at this time.

I would characterize the consensus as good enough and would thank those
who invested the time, in commenting and contributing.

Thanks
joel