STARK, BARBARA H | 28 Feb 19:43 2015

comments on draft-ietf-v6ops-mobile-device-profile-19

I've read through this draft and have some comments. I focused mostly on "must" requirements, because it's
always easy to justify not doing a "should". The authors are free to change nothing as a result of my
comments. I'm not voicing opposition. I'm simply expressing in more detail why I would not recommend to my
employer (or any other service provider) that they use this draft as an RFC reference without very careful
thought as to the desirability of each requirement.

Note that the term "[3GPP] cellular host" includes a wide variety of devices, including those which are
considered "IoT" or "M2M" (such as tracking/locating devices, health monitors, eReaders,
automobiles, etc.). Some of these devices are intended (by the service provider who procures them) to be
used with a service that does not support roaming to other providers'  networks. Some are single function
devices, where the function is fully specified at time of procurement. These devices are generally
intended to be as low-complexity and energy-efficient as possible. If a service provider is creating an
RFP for such a device, that service provider would be best advised to figure out their IPv6 architecture
before sending out an RFP with any of the requirements in this draft. For a service prov
 ider to say "I have no clue what my IPv6 architecture is going to be, so I want to require even the simplest and
lowest complexity cellular hosts to have support for all possible IPv6 architectures"
  is not an approach I would recommend. 

But that is exactly what this draft recommends:
   C_REC#1:  In order to allow each operator to select their own
             strategy regarding IPv6 introduction, the cellular host
             must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060].

There are also other requirements which appear to impose complexity on low-end
non-roaming/single-purpose cellular hosts in order to allow the service provider maximum flexibility
in ultimately deciding on an IPv6 architecture. I'm not enough of a cellular expert to be able to properly
identify all of these.

(Continue reading)

mohamed.boucadair | 24 Feb 08:18 2015

Mickael's Comments (was RE: I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt)

Hi Mickael, 

This new version integrates your comments

Please double check it and let me know if it OK with you.

Thank you.


> -----Message d'origine-----
> De : I-D-Announce [mailto:i-d-announce-bounces@...] De la part de
> internet-drafts@...
> Envoyé : mardi 24 février 2015 08:15
> À : i-d-announce@...
> Cc : v6ops@...
> Objet : I-D Action: draft-ietf-v6ops-mobile-device-profile-19.txt
> 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
>         Title           : An Internet Protocol Version 6 (IPv6) Profile
> for 3GPP Mobile Devices
>         Authors         : David Binet
>                           Mohamed Boucadair
(Continue reading)

Alexandru Petrescu | 23 Feb 13:38 2015

Status of CLAT implementation on iPhone? (IPv4 apps on IPv6-only PDP type)

Hello participants to v6ops WG,

What is the status of a CLAT implementation on iPhone?  Any hint in that

I am asking because in private conversation I have noticed doubts about
this being done.  Or, since the iPhone relies on a bsd derivative,
it would be technically feasible to implement CLAT on it; it is nothing
more than some iptables address translation plus a bit of python
scripting in case.

(CLAT is needed by some IPv4 apps to continue working on a smartphone
  connected solely with an IPv6-only PDP type).


v6ops mailing list

IETF Secretariat | 23 Feb 01:33 2015

Telechat update notice: <status-change-rfc-3068-anycast-prefix-for-6to4-to-historic-01.txt>

Placed on agenda for telechat - 2015-03-05
ID Tracker URL:

v6ops mailing list

internet | 23 Feb 00:22 2015

I-D Action: draft-ietf-v6ops-design-choices-05.txt

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           : Some Design Choices for IPv6 Networks
        Authors         : Philip Matthews
                          Victor Kuarsingh
	Filename        : draft-ietf-v6ops-design-choices-05.txt
	Pages           : 17
	Date            : 2015-02-22

   This document presents advice on certain routing-related design
   choices that arise when designing IPv6 networks (both dual-stack and
   IPv6-only).  The intended audience is someone designing an IPv6
   network who is knowledgeable about best current practices around IPv4
   network design, and wishes to learn the corresponding practices for

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at
(Continue reading)

Merlin Owens | 21 Feb 03:24 2015

(no subject)


v6ops mailing list
Ross Chandler | 20 Feb 13:13 2015

Re: I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD

It’s unfortunate this wasn’t captured in the roaming-analysis I-D. IMHO it looks like that operators must try harder to sort out their networks and billing mediation systems so IPv6 roaming is allowed.


On 20 Feb 2015, at 11:09, Kossut Tomasz - Hurt <> wrote:


IMHO EIT settings should be part of customization – vendor&generic  controlled by (MCCMNC) just like APN settings it has direct impact in HPLMN on IP (IPv4) allocation.

If network has IPv4 default bearer and EIT bit is not enabled in IPv6 terminals it results in default bearer activation and “selected”(IPv6) bearer activation, IPv6 terminal in a network with IPv4 default bearer will always establish 2 bearers. It’s observed in HPLMN for generic Google devices in our network:

vvvvvv CALLID   MSID            USERNAME               IP                                 TIME-IDLE

------ -------- --------------- ---------------------- ----------------------------- ---------

xTC.AT 0c3a069c 26003000000000 n/a                    2a00:f41:XXXX:XXX::4d1d:7001 00h00m02s

xTC.AI 0c3a069c 26003000000000 n/a            00h00m02s

IPv6 subscriber is allocating unwanted IPv4 resource here - this apply to HPLMN only.

For VPLMN (roaming LTE) situation  gets complicated if you choose to use IPv4 for VPLMN (APN settings - use IPv4 when roaming)

Terminal in LTE with EIT bit=1 located in VPLMN will always request “selected” IPv6 bearer for attach (terminal attaching in LTE has no idea whether this is HPLMN or VPLMN) once terminal learned ”I’m in roaming” according to APN settings(use IPv4 when roaming) terminal will establish secondary IPv4 bearer –it results in multiple bearer activation…



From: jouni korhonen [] 
Sent: Thursday, February 19, 2015 9:31 PM
To: Ross Chandler
Cc: Alexandru Petrescu;; Kossut Tomasz - Hurt
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - DHCP-PD


I still fail to see how EIT setting relates to IPv6 as a requirement.  It is a normal procedure when the UE wants to connect (during the initial attach) to another APN than the default one.

- Jouni


On Wed, Feb 18, 2015 at 12:48 PM, Ross Chandler <> wrote:


On 18 Feb 2015, at 16:47, jouni korhonen <> wrote:




On Wed, Feb 18, 2015 at 4:57 AM, Alexandru Petrescu <> wrote:


Le 18/02/2015 12:13, Kossut Tomasz - Hurt a écrit :


Inline comments:


Thank you for the report. It is good to see how good consideration
is given to IPv6, and the two separated paths IPv4/IPv6.

It is encouraging to see numerous smartphone manufacturers having
embraced the CLAT technology.

(tk) - this is not only CLAT, (CLAT is in generic Android thanks to
Lorenzo, Cameron, Dan & others) each vendor has its own
customization based on MCCMNC/region to control "features" per
operator. In our case we have :  dedicated clatd.conf (not generic
one), IPv6 tethering(DHCPv6, RA, Relay IPv6 DNS)

It's good to see these mentioned.

For tethering - is the network offering DHCPv6 Prefix Delegation
service?  Or is the device performing '64share' RFC7278?

There are some advantages on doing the former rather than the latter.

EIT bit =1,

What is the EIT bit?


My wild guess is that it is the ESM information transfer flag bit in the ESM information transfer flag information element. If it is, it does not really have anything to do with IPv6 IMHO.

- Jouni


As far as I can tell from a previous answer on v6ops by Orange PL the EIT bit (think it is ESM info transfer flag IE) has an effect when the HSS has a default APN different from the one requested by the UE.  Without the EIT bit set the network doesn’t let the UE requested APN override the default from the HSS, so two PDN connections are set up, one with IPv4 (assuming the default is an IPv4 only APN) and the other IPv6 (assuming that was requested by the UE).  So strictly speaking it does look independent of IP version but it is being noticed as operators introduce IPv6.


v6ops mailing list
Fred Baker (fred | 19 Feb 21:59 2015

IETF 92 Agenda

As I noted a few weeks ago, Lee and I are starting to plan the agenda for the meeting in Dallas. If you have
drafts you intend to post, now would be an excellent time to do so, so there can be list discussion prior to
the event.

Where we stand at this instant, according to me:


    Oct 19  draft-ietf-v6ops-ipv6-roaming-analysis (RFC Editor)
    Jan 28  draft-ietf-v6ops-6to4-to-historic (On agenda of 2015-03-05 IESG telechat)

Exiting WGLC; on its way to IESG:
    Feb 13  draft-ietf-v6ops-cidr-prefix (Lee doing writeup)
    Feb 18  draft-ietf-v6ops-mobile-device-profile (ongoing discussion from WGLC requested by IESG)

Working Group Document updated since IETF:

    Dec 18  draft-ietf-v6ops-siit-dc
    Jan 27  draft-ietf-v6ops-siit-dc-2xlat
    Feb 18  draft-ietf-v6ops-design-choices

Individual Submission updated since IETF:

    Dec 31  draft-sun-v6ops-xlat-multi
    Jan  8  draft-anderson-v6ops-siit-eam

Working Group Document NOT updated since IETF:

    Oct 27  draft-ietf-v6ops-dhcpv6-slaac-problem
    Oct 27  draft-ietf-v6ops-ula-usage-recommendations

Individual Submission NOT updated since IETF:

    Aug 24  draft-v6ops-pmtud-ecmp-problem

Note that we chose to adopt this, but draft-ietf-v6ops-pmtud-ecmp-problem has not yet been posted.

    Sep 10  draft-gont-v6ops-ipv6-ehs-in-real-world

Fernando has done a lot of work and discussed it with the chairs. I expect him to post an updated draft, a
report, for discussion in IETF 92 that distinguishes clear among the extension headers implicated and
whether the drop occurs in the same AS as the destination or a different one.

    Oct 11  draft-liu-v6ops-running-multiple-prefixes
    Oct 27  draft-chen-v6ops-nfv-ipv6
    Oct 27  draft-liu-v6ops-dhcpv6-slaac-guidance

I'll note that these three didn't see discussion in IETF 91, at least in part, because a number of Chinese
participants didn't get to the meeting or didn't arrive for a Monday meeting. I have polled for working
group interest.

Drafts that probably belong in some other working group:
    Sep 18  draft-elkins-v6ops-multicast-virtual-nodes
    Sep 18  draft-wang-v6ops-xlat-prefix-discovery
    Sep 25  draft-ybai-v6ops-ipv6-for-openstack
    Oct 27  draft-osamu-v6ops-ipv4-literal-in-url
    Oct 27  draft-vyncke-v6ops-happy-eyeballs-cookie
v6ops mailing list

Fred Baker (fred | 19 Feb 21:54 2015

Inviting discussion: draft-liu-v6ops-running-multiple-prefixes
  "Considerations for Running Multiple IPv6 Prefixes", Bing Liu, Sheng
  Jiang, Yang Bo, 2014-10-11,

This draft was prepared for IETF 91, but didn't get discussed in part because a number of Chinese
participants didn't make it to Honolulu for a Monday meeting. Is there interest in discussing it at IETF 92?
v6ops mailing list

Fred Baker (fred | 19 Feb 21:54 2015

Inviting discussion: draft-chen-v6ops-nfv-ipv6
  "IPv6 Considerations for Network Function Virtualization (NFV)", Gang
  Chen, Hui Deng, 2014-10-27

This draft was prepared for IETF 91, but didn't get discussed in part because a number of Chinese
participants didn't make it to Honolulu for a Monday meeting. Is there interest in discussing it at IETF 92?
v6ops mailing list

Fred Baker (fred | 19 Feb 21:37 2015

Inviting discussion: draft-sun-v6ops-xlat-multi

I'd like to understand working group viewpoints, technical and operational, on Does it belong on the agenda for IETF 92?
v6ops mailing list