Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt

From: Teemu Savolainen <[email-masked]>
Date: Thu, 18 Apr 2013 14:55:06 +0300

Med, all,

I gave this document a full read with following comments:
1) I think "mobile devices" is perhaps too wide a name - should this
explicitly say "3gpp mobile devices" or "cellular hosts".
2) In my opinion all references to 3316 should be changed to
draft-ietf-v6ops-rfc3316bis, and there is no need to compare RFC3316 with
3316bis draft in here (in section 1), as the 3316bis will obsolete the 3316.
3) The abstract talks about "device with LAN" capabilities. That is
ambiguous, as I think you mean LAN on "downlink" of the device? I mean a
device with WiFi connection has "LAN capability" even if it does not have
tethering capabilities:) "Both hosts and devices with capability to share
their WAN connectivity to LAN" or something?
3) Why some of the requirements of RFC6434 are duplicated herein with same
keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would
suppose a profile document could say that mobile device MUST follow
RFC6434, except when <exceptions> ?
4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in text:"in
addition to the IPv4 PDP context." Does this mean IPv4 PDP context is also
required, or is IPv4 PDP optional? Needs clarification.
5) Is it required to be able to support different PDP types in parallel,
e.g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS,
IPv4v6 for Internet), but do you wish to write it down?
6) REQ#3 says device MUST request IPv4v6 if the cellular host is
dual-stack. Well, this is how 3GPP writes it as well... but in reality all
this depends on provisioning. So you should say that this is the way,
unless provisioned to do otherwise..
7) REQ#3 bullet 1, I don't follow. It says that if network does not have
IPv4v6, but "IPv4 and IPv6", then the network will configure IPv4 address
and IPv6 prefix. This is does not tell really much, IPv4 address and IPv6
prefix are provided if IPv4v6 is supported, or if IPv4 and IPv6 are allowed
in parallel. Maybe this gets fixed if you change "and/or" to just "or".
Because if network gives only IPv4 or IPv6, then the device can ask for
parallel bearer.
8) REQ#3 bullet 1: I would change the MAY open initiate another PDP to
SHOULD or MUST. This is because device is dual-stack capable, has requested
IPv4v6, but only gotten IPv4 or IPv6. If the network does not indicate
"single bearer only", then IMHO the device MUST ask for parallel PDP -
which the network can reject. I.e. dual-stack host should ask for IPv4v6,
then IPv4 and IPv6 in parallel. Exceptions are provisioning or error codes
available at and after release-8.
9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in
addition to MUST for PCO option support.
10) REQ#6: should you clarify that MTU option really needs to be received
and acted upon?
11) REQ#9 says in title "must" but in text "SHOULD". Which way do you
intend? I could go for MUST in order to allow more flexibility in the
future, but SHOULD is ok as well
12) REQ#10 says in title "must", but why? What if device just does not need
anything via stateless DHCPv6? SHOULD would be better?
13) The DNS discovery is split into REQ#4, REQ#9, and REQ#10. The REQ#10 is
the only that says preference order (with PCP, should probably be PCO
instead). Could these REQs be combined? Should the preference order be a
separate requirement ?
14) REQ#11 do you have requirement
15) REQ#13 could have pointer/dependency to REQ#11? I take DNSSEC support
goes off-scope - but nevertheless REQ#13 is needed only if device supports
DNSSEC, or 464XLAT?
16) REQ#15 refers to MIF - I would probably simply drop the MIF reference
out, as if MIF is included also other problems start creeping in (specific
routes, DNS selection, provisioning domains...) - i.e. better exclude MIF
problematics from this document. You could explicitly state whether you
prefer DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as
that seems to be something currently more or less random.
17) Section 2.1 I would like clarification whether this applies to
"downlink" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but
please spell it out.
18) WiFi is a trademark owned by WiFi Alliance. Based on prior feedback to
me, I would rather talk about IEEE 802.11, or WLAN here as well.
19) REQ#19 I would remove the background text about "some recent tests
revealed" on some OS - it just does not suit well for profile document
living for a looong time. Alternatively you could have Appendix that
includes some of the real-world experiences of particular implementations?
20) REQ#22 why this is advanced requirement? I would call it basic.. and I
would like to emphasize capability to receive MTU option via RA.
21) REQ#23 - I am not convinced full RFC4941 is always required. Enough
private  addresses could be obtained by simpler ways as well, I believe.
Hence I would rephrase that hosts MUST have RFC4941 or other means for
providing privacy addressing. I.e. the requirement should be about privacy
addresses, not RFC4941.
22) REQ#24 is too ambiguous. Please state which ROHC profiles. AFAIK VoLTE
requires RTP/UDP/IP, but nobody is requiring TCP profile (because for
(Voice)/RTP/UDP/IP the savings in compressed headers are significant, but
for TCP bulk download the savings are insignificant and when compared to
overall costs (cost of compressing/decompressing) probably close to
negative).
23) Section 4 title - please clarify this is downlink LAN
24) REQ#27 makes 3GPP-wise sense only on Release-10 based networks. Do you
intent this requirement to cover all IPv6 hosts from 3GPP Release-99
onwards (cherry picking)? Please clarify in either case.
25) REQ#33 this is something handset vendors have only so much control
over.. but maybe this document can also be given for application writers?-)

Best regards,

Teemu

2013/3/27 <[email-masked]>

> Dear all,
>
> The changes in the new version are as follows:
>
> (1) Tweak the text in the Abstract and Introduction to answer to the
> comment raised by F. Baker here:
> http://www.ietf.org/mail-archive/web/v6ops/current/msg15672.html
> (2) Soften the tone for REQ#29 as discussed with Mickael here:
> http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html
> (3) Add a disclaimer some features require activating some functions at
> the network side as suggested by Jouni
> (4) Add an explicit reference to RFC6434 + whenever needed, indicate
> whether the new language form is stronger + Justification.
>
> The new version integrates all the comments received so far.
>
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De : [email-masked] [mailto:[email-masked]] De
> >la part de [email-masked]
> >Envoyé : mercredi 27 mars 2013 10:33
> >À : [email-masked]
> >Cc : [email-masked]
> >Objet : [v6ops] I-D Action:
> >draft-ietf-v6ops-mobile-device-profile-01.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           : Internet Protocol Version 6 (IPv6)
> >Profile for Mobile Devices
> >       Author(s)       : David Binet
> >                          Mohamed Boucadair
> >                          Ales Vizdal
> >                          Cameron Byrne
> >                          Gang Chen
> >       Filename        : draft-ietf-v6ops-mobile-device-profile-01.txt
> >       Pages           : 16
> >       Date            : 2013-03-27
> >
> >Abstract:
> >   This document specifies an IPv6 profile for mobile devices.
> > It lists
> >   the set of features a mobile device is to be compliant with to
> >   connect to an IPv6-only or dual-stack mobile network.
> >
> >   This document defines a different profile than the one for general
> >   connection to IPv6 mobile networks defined in [RFC3316].  In
> >   particular, this document identifies also features to ensure IPv4
> >   service continuity over an IPv6-only transport.
> >
> >   Both Hosts and devices with LAN capabilities are in scope.
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile
> >
> >There's also a htmlized version available at:
> >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-01
> >
> >A diff from the previous version is available at:
> >http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device
> >-profile-01
> >
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >_______________________________________________
> >v6ops mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: <[email-masked]>
Date: Thu, 18 Apr 2013 16:58:18 +0200

Hi Teemu,

Many thanks for your detailed review.

Please see inline.
Cheers,
Med

De : Teemu Savolainen [mailto:[email-masked]]
Envoyé : jeudi 18 avril 2013 13:55
À : BOUCADAIR Mohamed OLNC/OLN
Cc : [email-masked]
Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt

Med, all,

I gave this document a full read with following comments:
1) I think "mobile devices" is perhaps too wide a name - should this explicitly say "3gpp mobile devices" or "cellular hosts".
[Med] 3GPP Mobile Devices would be OK.

2) In my opinion all references to 3316 should be changed to draft-ietf-v6ops-rfc3316bis,
[Med] Will see how to update the text.

and there is no need to compare RFC3316 with 3316bis draft in here (in section 1), as the 3316bis will obsolete the 3316.
[Med] Are you referring to this text?

   [RFC3316] lists a set of features to be supported by cellular hosts
   to connect to 3GPP cellular networks.  Since the publication of that
   document, new functions have been specified within the 3GPP and the
   IETF whilst others have been updated.  Moreover, in the light of
   recent IPv6 production deployments, additional features to facilitate
   IPv6-only deployments while accessing IPv4-only service are to be
   considered.

Are you suggesting this text is to be removed?

3) The abstract talks about "device with LAN" capabilities. That is ambiguous, as I think you mean LAN on "downlink" of the device? I mean a device with WiFi connection has "LAN capability" even if it does not have tethering capabilities:) "Both hosts and devices with capability to share their WAN connectivity to LAN" or something?
[Med] I got your point. Will tweak the text.

3) Why some of the requirements of RFC6434 are duplicated herein with same keywords, e.g. REQ#1 has MUST for same thing RFC6434 has MUST. I would suppose a profile document could say that mobile device MUST follow RFC6434, except when <exceptions> ?
[Med] Isn't this covered by this text:

   Pointers to some requirements listed in [RFC6434<http://tools.ietf.org/html/rfc6434>] are included in

   this profile.  The justification for using a stronger language

   compared to what is specified in [RFC6434<http://tools.ietf.org/html/rfc6434>] is provided for some

   requirements.

If you think this is not clear, we can update the text to better clarify the logic.

4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in text:"in addition to the IPv4 PDP context." Does this mean IPv4 PDP context is also required, or is IPv4 PDP optional? Needs clarification.
[Med] The title focuses only on the IPv6-related PDP contexts. I don't think there is a value to use the normative language for IPv4 PDP.

5) Is it required to be able to support different PDP types in parallel, e.g. IPv4 in parallel with IPv4v6? That probably is (e.g. IPv4 for MMS, IPv4v6 for Internet), but do you wish to write it down?
[Med] IMHO, this is not specific to IPv6. I don't think there is a value to explicit this for IPv6-related PDP contexts.

6) REQ#3 says device MUST request IPv4v6 if the cellular host is dual-stack. Well, this is how 3GPP writes it as well... but in reality all this depends on provisioning. So you should say that this is the way, unless provisioned to do otherwise..
[Med] Would you be OK if the text is changed as follows:

OLD:
the cellular host MUST request ...

NEW:
the cellular host MUST request by default ...

7) REQ#3 bullet 1, I don't follow. It says that if network does not have IPv4v6, but "IPv4 and IPv6", then the network will configure IPv4 address and IPv6 prefix. This is does not tell really much, IPv4 address and IPv6 prefix are provided if IPv4v6 is supported, or if IPv4 and IPv6 are allowed in parallel. Maybe this gets fixed if you change "and/or" to just "or". Because if network gives only IPv4 or IPv6, then the device can ask for parallel bearer.
[Med] Fixed.

8) REQ#3 bullet 1: I would change the MAY open initiate another PDP to SHOULD or MUST. This is because device is dual-stack capable, has requested IPv4v6, but only gotten IPv4 or IPv6. If the network does not indicate "single bearer only", then IMHO the device MUST ask for parallel PDP - which the network can reject. I.e. dual-stack host should ask for IPv4v6, then IPv4 and IPv6 in parallel. Exceptions are provisioning or error codes available at and after release-8.
[Med] The text will be fixed.

9) REQ#4: What about RFC6106? I would think that could be MAY/SHOULD in addition to MUST for PCO option support.
[Med] This is discussed in REQ#9. No?

10) REQ#6: should you clarify that MTU option really needs to be received and acted upon?
[Med] Can you explicit what change you want to see added to the text?

11) REQ#9 says in title "must" but in text "SHOULD". Which way do you intend? I could go for MUST in order to allow more flexibility in the future, but SHOULD is ok as well
[Med] "must comply" with Section 7.3 means it needs to follow what is described in that section: i.e., SHOULD support 6106. This is indicated explicitly in the text.

12) REQ#10 says in title "must", but why? What if device just does not need anything via stateless DHCPv6? SHOULD would be better?
[Med] Idem as above.

13) The DNS discovery is split into REQ#4, REQ#9, and REQ#10. The REQ#10 is the only that says preference order (with PCP, should probably be PCO instead). Could these REQs be combined? Should the preference order be a separate requirement ?
[Med] Fixed the typo with PCP. OK to have a separate requirement for the preference order.

14) REQ#11 do you have requirement
[Med] See the justification text and also the DNSSEC case.

15) REQ#13 could have pointer/dependency to REQ#11? I take DNSSEC support goes off-scope - but nevertheless REQ#13 is needed only if device supports DNSSEC, or 464XLAT?
[Med] Added a pointer to REQ#11.

16) REQ#15 refers to MIF - I would probably simply drop the MIF reference out, as if MIF is included also other problems start creeping in (specific routes, DNS selection, provisioning domains...) - i.e. better exclude MIF problematics from this document. You could explicitly state whether you prefer DNS communications to use IPv4 or IPv6 in dual-stack scenarios, as that seems to be something currently more or less random.
[Med] No problem to remove the MIF reference. For the DNS case, are you suggesting to add a sentence such as:
"When both IPv4 and IPv6 DNS servers are configured, a dual-stack host MUST contact first its IPv6 DNS server."

17) Section 2.1 I would like clarification whether this applies to "downlink" WiFi, "uplink" WiFi, or both. It sounds like about uplink, but please spell it out.
[Med] What difference do you make between those two?

18) WiFi is a trademark owned by WiFi Alliance. Based on prior feedback to me, I would rather talk about IEEE 802.11, or WLAN here as well.
[Med] Fixed. Thanks.

19) REQ#19 I would remove the background text about "some recent tests revealed" on some OS - it just does not suit well for profile document living for a looong time. Alternatively you could have Appendix that includes some of the real-world experiences of particular implementations?
[Med] We put that text there to record the encountered issue with some implementations. If the requirement is supported, this wouldn't be an issue. I will discuss with my co-author how to handle this comment. Thanks.

20) REQ#22 why this is advanced requirement? I would call it basic.. and I would like to emphasize capability to receive MTU option via RA.
[Med] Would moving this REQ to be called out just after REQ#6 be OK with you?

21) REQ#23 - I am not convinced full RFC4941 is always required. Enough private  addresses could be obtained by simpler ways as well, I believe. Hence I would rephrase that hosts MUST have RFC4941 or other means for providing privacy addressing. I.e. the requirement should be about privacy addresses, not RFC4941.
[Med] Makes sense. What about this change?

OLD:

The cellular host must comply with Section 5.9.3 of<http://tools.ietf.org/html/rfc6434#section-5.9.3>

          [RFC6434]<http://tools.ietf.org/html/rfc6434#section-5.9.3> for the support of the Privacy Extensions for

          Stateless Address Autoconfiguration in IPv6.

             The activation of privacy extension makes it more difficult

             to track a host over time when compared to using a

             permanent interface identifier.  [RFC4941<http://tools.ietf.org/html/rfc4941>] does not require

             any DAD mechanism to be activated as the GGSN (or PDN-GW)

             MUST NOT configure any global address based on the prefix

             allocated to the cellular host.

NEW:

The cellular host MUST be able able to generate IPv6 addresses which preserve privacy.

             The activation of privacy extension (e.g., using [RFC4941<http://tools.ietf.org/html/rfc4941>]) makes it more difficult

             to track a host over time when compared to using a

             permanent interface identifier. Note, [RFC4941<http://tools.ietf.org/html/rfc4941>] does not require

             any DAD mechanism to be activated as the GGSN (or PDN-GW)

             MUST NOT configure any global address based on the prefix

             allocated to the cellular host.

22) REQ#24 is too ambiguous. Please state which ROHC profiles. AFAIK VoLTE requires RTP/UDP/IP, but nobody is requiring TCP profile (because for (Voice)/RTP/UDP/IP the savings in compressed headers are significant, but for TCP bulk download the savings are insignificant and when compared to overall costs (cost of compressing/decompressing) probably close to negative).
[Med] This is a very good point. I do personally agree with you. Let see what there other think, if no objection is raised, we will adopt your suggestion.

23) Section 4 title - please clarify this is downlink LAN
24) REQ#27 makes 3GPP-wise sense only on Release-10 based networks. Do you intent this requirement to cover all IPv6 hosts from 3GPP Release-99 onwards (cherry picking)? Please clarify in either case.
[Med] Just like REQ#29, the tone has been softened to not mention any 3GPP release as discussed here: http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html.

25) REQ#33 this is something handset vendors have only so much control over.. but maybe this document can also be given for application writers?-)
[Med] I was aware of applications developed by the same mobile device vendor but are not IPv6-compatible. The requirement as currently worded is valid for all applications.

Best regards,

Teemu

2013/3/27 <[email-masked]<mailto:[email-masked]>>
Dear all,

(1) Tweak the text in the Abstract and Introduction to answer to the comment raised by F. Baker here: http://www.ietf.org/mail-archive/web/v6ops/current/msg15672.html
(2) Soften the tone for REQ#29 as discussed with Mickael here: http://www.ietf.org/mail-archive/web/v6ops/current/msg15742.html
(3) Add a disclaimer some features require activating some functions at the network side as suggested by Jouni
(4) Add an explicit reference to RFC6434 + whenever needed, indicate whether the new language form is stronger + Justification.

Cheers,
Med

>De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De
>la part de [email-masked]<mailto:[email-masked]>
>À : [email-masked]<mailto:[email-masked]>
>Cc : [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Teemu Savolainen <[email-masked]>
Date: Mon, 22 Apr 2013 12:51:02 +0300

Hi Med,

Thank you for your prompt reply, further comments inline for some points
(rest cut):

Cheers,

Teemu

> draft-ietf-v6ops-rfc3316bis,
>
> [Med] Will see how to update the text.****
>
> ** **
>
> and there is no need to compare RFC3316 with 3316bis draft in here (in
> section 1), as the 3316bis will obsolete the 3316.****
>
> [Med] Are you referring to this text?****
>
> ** **
>
>    [RFC3316] lists a set of features to be supported by cellular hosts****
>
>    to connect to 3GPP cellular networks.  Since the publication of that***
> *
>
>    document, new functions have been specified within the 3GPP and the****
>
>    IETF whilst others have been updated.  Moreover, in the light of****
>
>    recent IPv6 production deployments, additional features to facilitate**
> **
>
>    IPv6-only deployments while accessing IPv4-only service are to be****
>
>    considered.****
>
> ** **
>
> Are you suggesting this text is to be removed? ****
>
> **
>

What I'm saying is that RFC3316bis will obsolete RFC3316, hence this
document should not be referring to obsolete RFC - assuming both these
complete roughly at the same time. Hence you should replace the RFC3316
with RFC3316bis and modify the text accordingly. I.e. describe what this
document brings in addition. Maybe something like:

   [RFC3316bis] lists a set of features to be supported by cellular hosts***
*

   to connect to 3GPP cellular networks.  In the light of

   recent IPv6 production deployments, additional features to facilitate****

   IPv6-only deployments while accessing IPv4-only service are to be****

   considered.
or something?

> **
> [Med] Isn’t this covered by this text:****
>
> ** **
>
>    Pointers to some requirements listed in [RFC6434 <http://tools.ietf.org/html/rfc6434>] are included in****
>
>    this profile.  The justification for using a stronger language****
>
>    compared to what is specified in [RFC6434 <http://tools.ietf.org/html/rfc6434>] is provided for some****
>
>    requirements.****
>
> **
Well I just don't see why to point to some requirements in RFC6434, except
to use stronger (or weaker) language for the requirements explicitly
pointed at.

Could the document perhaps state that RFC6434 is required but with
exceptions and additions listed in this document?

> 4) REQ#2 title does not include IPv4, but IPv4 PDP is mentioned in
> text:"in addition to the IPv4 PDP context." Does this mean IPv4 PDP context
> is also required, or is IPv4 PDP optional? Needs clarification.
>
> **
>
> [Med] The title focuses only on the IPv6-related PDP contexts. I don’t
> think there is a value to use the normative language for IPv4 PDP.****
>
> I was asking because the "Both IPv6 and IPv4v6 PDP contexts MUST be
supported in addition to the IPv4 PDP." sounds like normative text.  I was
thinking whether  this document allows a device with just IPv6 and IPv4v6
PDP context support. Probably no use for such device in near future, but I
was nevertheless wondering if IPv4 is explicitly required.

> IPv4v6 for Internet), but do you wish to write it down?****
>
> [Med] IMHO, this is not specific to IPv6. I don’t think there is a value
> to explicit this for IPv6-related PDP contexts.
>
True, ok for me not to talk about this here.

> unless provisioned to do otherwise..****
>
> OLD:****
> the cellular host MUST request …
>
> NEW:****
>
> the cellular host MUST request by default …
>
Yes, that would be fine.

> addition to MUST for PCO option support.****
>
True, probably by the time I hit REQ#9 I had forgotten this comment
already:)

> and acted upon?****
MTU communication via RA from SHOULD to MUST?

> future, but SHOULD is ok as well****
>
> [Med] “must comply” with Section 7.3 means it needs to follow what is
> described in that section: i.e., SHOULD support 6106. This is indicated
> explicitly in the text.
>
What does it mean when one "must comply" with "SHOULD"?-) If the normative
text says SHOULD, why the title could not be "The cellular host should
comply with.."

> 12) REQ#10 says in title "must", but why? What if device just does not
> need anything via stateless DHCPv6? SHOULD would be better?****
>
> [Med] Idem as above.
>
And same as above, "must comply" with "SHOULD" is confusing.

> 14) REQ#11 do you have requirement ****
>

This was a typo from me, I thought of something, checked it out, and then
forgot to delete the text I had started writing...

> **
> [Med] No problem to remove the MIF reference. For the DNS case, are you
> suggesting to add a sentence such as: ****
>
> “When both IPv4 and IPv6 DNS servers are configured, a dual-stack host
> MUST contact first its IPv6 DNS server.”
>
Yes, that would suit me, but I wanted to check whether you wish it that
way, or if "random" is ok (or e.g. happy eyeballs style approach).

> please spell it out.****
Never mind, I was thinking perhaps a bit too far. It talks already about
hotspots anyway.

> **
> [Med] We put that text there to record the encountered issue with some
> implementations. If the requirement is supported, this wouldn’t be an
> issue. I will discuss with my co-author how to handle this comment. Thanks.
>
I'm fine with the requirement, but if you need to keep it for a while still
that's ok.

> would like to emphasize capability to receive MTU option via RA.****
>
Yes.

> addresses, not RFC4941.****
>
> [Med] Makes sense. What about this change?****
>
> ** OLD:
>
> ** The cellular host must comply with Section 5.9.3 of<http://tools.ietf.org/html/rfc6434#section-5.9.3>
>
>           [RFC6434] <http://tools.ietf.org/html/rfc6434#section-5.9.3> for the support of the Privacy Extensions for****
>
>           Stateless Address Autoconfiguration in IPv6.****
>
> ** **
>
>              The activation of privacy extension makes it more difficult****
>
>              to track a host over time when compared to using a****
>
>              permanent interface identifier.  [RFC4941 <http://tools.ietf.org/html/rfc4941>] does not require****
>
>              any DAD mechanism to be activated as the GGSN (or PDN-GW)****
>
>              MUST NOT configure any global address based on the prefix****
>
>              allocated to the cellular host.****
>
> ** NEW:
>
> ** The cellular host MUST be able able to generate IPv6 addresses which
> preserve privacy.
>
> ** **
>
>              The activation of privacy extension (e.g., using [RFC4941 <http://tools.ietf.org/html/rfc4941>]) makes it more difficult****
>
>              to track a host over time when compared to using a****
>
>              permanent interface identifier. Note, [RFC4941 <http://tools.ietf.org/html/rfc4941>] does not require****
>
>              any DAD mechanism to be activated as the GGSN (or PDN-GW)****
>
>              MUST NOT configure any global address based on the prefix****
>
Would work for me.