Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01

[<[e-mail]>]

Hi Jouni,

Many thanks for the review.

My answers inline.
Cheers,
Med


>-----Message d'origine-----
>De : Jouni Korhonen [mailto:[e-mail]]
>Envoyé : vendredi 19 avril 2013 10:08
>À : [e-mail] Operations; draft-ietf-v6ops-mobile-device-
>[e-mail]
>Objet : Review of draft-ietf-v6ops-mobile-device-profile-01
>
>Hi,
>
>I did a review of draft-ietf-v6ops-mobile-device-profile-01. Below are
>my comments. They are rather long, sorry about that ;)
>
>- JOuni
>
>---------------------------------------------------------------------
>
>1) General notes
>
>o The I-D mixes (throughout) PDP context, PDP Context, PDP-Context.
> suggest to use PDP-Context. (I have not noted any of those in
> the comments below)
[Med] Fixed.

>o The I-D mixes (throughout) dual-stack and dual stack. Suggest
> to choose one style; like dual-stack. (I have not noted any of
[Med] Fixed.

> those in the comments below)
>o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest
> to use only the latter one.
[Med] The text will be tweaked.

>o The I-D uses a "mobile device" in places where it should really say
> a "cellular device". Use consistent wording.
[Med] Will check the text.

>o The I-D uses a "mobile network" where it should really use "cellular
> network". In places where the network can be cellular or some other
> wireless technology, I would use "wireless network" as a generic
> term.
[Med] The text twill be checked.

>o The use of GGSN and PDN-GW should have more consistency. For example
> using GGSN/PGW throughout..
[Med] OK.

>
>2) 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
>                        ^^^^^^^^^^^^^

[Med] changed to "This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network)."

>
>o The document really is more about cellular devices than arbitrary
> mobile device. Suggest to reword "cellular devices".

[Med] As suggested by Teemu, "3GPP mobile devices" is used instead.

>
>  connect to an IPv6-only or dual-stack mobile network.
>                                        ^^^^^^^^^^^^^^
>o Since both cellular and Wi-Fi network are in scope, maybe
> saying "wireless networks" would be more appropriate?

[Med] See the proposed change above.

>
>  This document defines a different profile than the one for general
>  connection to IPv6 mobile networks defined in [RFC3316].  In
>                     ^^^^^^^^^^^^^^^            ^^^^^^^^^
>o RFC3316 is about cellular network. Even the RFC title says that.
>o Use RFC3316bis reference rather than RFC3316.

[Med] Will check the text and update when appropriate.

>
>  particular, this document identifies also features to ensure IPv4
>  service continuity over an IPv6-only transport.
>  ^^^^^^^^^^^^^^^^^^
>o Service continuity is IMHO overloaded in IPv6 space with
> Mobile IPv6 and similar. Suggest to use "service availability".

[Med] changed the wording to "deliver IPv4 connectivity service".

>
>3) Section 1 - Introduction
>
>  IPv6 deployment in mobile networks is the only perennial solution to
>                     ^^^^^^^^^^^^^^^
>o Suggest to use wireless networks.

[Med] OK.

>
>  operators already deployed IPv6 or are in the pre-deployment phase.
>        ^^^^^^^^
>o "..have already deployed.."

[Med] Fixed.

>
>  Some vendors are already proposing some mobile devices with a set of
>                                          ^^^^^^^^^^^^^^
>o Suggest using cellular devices.
>
>  Some vendors are already proposing some mobile devices with a set of
>  IPv6 features, but the majority of devices are still lacking IPv6
>  support.
>
>o For a profile or requirements, I would remove text like this
> since in few years time it will be outdated. Rather reword it
> stating the fact that cellular devices plain need to have IPv6
> enabled if they don't already have it.

[Med] Makes sense. Removed.

>
>  connection to IPv6 mobile networks defined in [RFC3316]; in
>                     ^^^^^^                      ^^^^^^^^
>  ...
>     implement basic IPv6 features in a mobile context.
>                                        ^^^^^^^
>o s/mobile/cellular. And reference to RFC3316bis

[Med] Fixed.

>
>  o  It identifies also features to ensure IPv4 service continuity over
>                                                ^^^^^^^^^^^^^^^^^^
>o Suggest using "service availability" to make a clear distinction
> to IP mobility..

[Med] Changed to "IPv4 service delivery"

>
>  required specifications produced by various SDOs (in particular 3GPP
>                                              ^^^^
>o Expand SDO on the first occurrence.

[Med] Fixed.

>
>      IPv6 connectivity and IPv4 service continuity (over an IPv6- only
>                                                             ^^^^^^^^^^
>o s/IPv6- only/IPv6-only

[Med] Fixed.

>
>4) Section 1.1 - Scope
>
>  user equipment such as a mobile telephone, a CPE or a machine-to-
>                                               ^^^^
>o Expand CPE on the first occurrence.

[Med] Fixed.

>
>  The requirements listed below are valid for both 3GPP GPRS and 3GPP
>  EPS access.  For EPS, "PDN type" terminology is used instead of "PDP
>  ^^^                    ^^^^^^^^
>  context".
>
>o Expand EPS on the first use and give a reference.
>o I assume this is supposed to be "PDN-Connection" not "PDN Type" ??
>o Expand GPRS on the first use.

[Med] Fixed. I didn't cited any ref as the document already points to RFC6459.

>
>5) Section 2 - Connectivity Requirements
>
>  REQ#2:  The cellular host MUST support both IPv6 and IPv4v6 PDP
>       Contexts.
>
>o for a MUST requirement I would like to see the 3GPP release to
> which this applies.

[Med] Like for other requirements, we avoided to mention the release as suggested by Mickael (check the v6ops ml archives).

>o there are also cases where IPv6-only cellular host is justified,
> thus I would point back here in the text to e.g. Section 1.1
> M2M scope clarification/narration.
>
>  REQ#3:  The cellular host MUST comply with the behavior defined in
>       [TS.23060] [TS.23401] [TS.24008] for requesting a PDP context
>
>o The list of references neglect non-3GPP accesses (TS.23402). I am fine
> with that but you should state it in e.g. Section 1.1 scoping that
> non-3GPP accesses except for some exceptions (Wi-Fi without 3GPP
> flavour) are out of scope.

Med: Section 1.1 states explicitly both 3GPP accesses and WLAN are in scope. No need to have an explicit reference to TS.23402.

>
>       the cellular host is not aware of connectivity types requested
>       by devices connected to it (e.g., cellular host with LAN
>       capabilities):
>
>o I would clarify this part of the text a bit more. The text in 3GPP
> standards are mostly coming from the Split-UE background where MT and
> TE are separate, not from tethering. Therefore, some rewording is
> needed here. As such the current text is not acceptable.

Med: I added an explicit reference to Section 4 in the example listed in the text you quoted.

>
>          cellular host will be configured with an IPv4 address and/or
>                        ^^^^^^^
>o s/will be/MAY be. There is no guarantee that an UE would always open
> two PDPs.

[Med] As suggested by Teemu "and/or" was changed to "or". As such, "will be" is accurate.

>
>          an IPv6 prefix by the network.  It MAY initiate another PDP
>                                                                  ^^^
>          request in addition to the one already activated for a given
>          APN.
>          ^^^^
>o "PDP request" I would use different wording like "PDP-Context activation"
>o Expand APN on the first occurrence.

[Med] Fixed.


>
>          Traffic Flow Templates are employing a Packet Filter to
>                                                 ^^^^^^^^^^^^^
>o "packet filter" ?
>
>          PDP-Context and radio resources can be provided by the mobile
>          network for certain IP traffic.                        ^^^^^^
>
>o s/mobile network/cellular network

[Med] Fixed.

>
>          This is a stronger form compared to what is specified in
>          Section 12.2 of [RFC6434].  The support of Neighbor Discovery
>          ^^^^^^^^^^^^
>o Section 5.2 should also be referenced here since e.g. RFC5942 is
>mentioned
> in there rather than in Section 12.2.

[Med] Done, thanks.

>
>          In particular, MTU communication via Router Advertisement
>                         ^^^^
>o Expand MTU on the first occurrence.

[Med] Fixed

>
>          standard MTU setting due to inconsistencies in GTP [RFC3314]
>                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>o Expand GTP on the first occurrence.
>o It is unclear what the "inconsistencies in GTP" are. The RFC3314
> definitely does not tell a thing about that. Also give a reference
> to a proper GTP specification(s).

[Med] re-used the same pointers as in RFC6459.


>
>  REQ#8:  The cellular host MUST support IPv6 Stateless Address
>       Autoconfiguration ([RFC4862]) apart from the exceptions noted in
>       [TS.23060] (3G) and [TS.23401] (LTE):        ^^^^^^^^^^^
>                  ^^^^                 ^^^^
>o What are the exceptions? If you mean the restrictions in 3GPP SLAAC
> point to other documents like RFC6459 or RFC3316bis that detail those
> out.
>o s/3G/GPRS
>o s/LTE/EPS
[Med] Fixed.

>
>          The cellular host MUST use the interface identifier sent in
>                                         ^         ^
>o s/interface identifier/Interface Identifier. For the consistency..
[Med] OK.

>
>          PDP Context Accept message to configure its link local
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^
>o Suddenly referencing to specific 3GPP signaling messages seems odd
> here. I suggest to reword "3GPP PDP-Context setup signaling from
> a GGSN/PGW to the cellular host" or something to that direction.
[Med] changed to "To configure its link local address, the cellular host MUST use the Interface Identifier conveyed in 3GPP PDP-Context setup signaling received from a GGSN/PGW."

>
>  REQ#9:  The cellular host must comply with Section 7.3 of [RFC6434].
>                            ^^^^
>o s/must/MUST
[Med] Fixed.

>o Generally about the "Req#9". The motivational text following the
> requirement title is not imho needed. The MUST for Section 7.3 of
> RFC6434 is quite clear.
[Med] No problem to remove it from my side.

>
>  REQ#10:  The cellular host must comply with Section 7.2.1 of
>                             ^^^^
>o s/must/MUST
[Med] Fixed.

>
>          1.  PCP
>          ^^^^^^^
>o I assume PCO is meant here?
[Med] Yes, this was a typo.

>
>       Translator (CLAT, [I-D.ietf-v6ops-464xlat]) function which is
>                          ^^^^^^^^^^^^^^^^^^^^^^^
>o RFC6877 yay!
[Med] Done.

>
>          application and IPv4-referals to work on an IPv6-only PDP.
>                                                      ^^^^^^^^^^^^^
>o I suggest replacing PDP with "network" or "access network" or
> "PDP-Context".
[Med] changed to "connectivity"

>
>          DNSSEC.  Means to configure or discover a PREFIX64 is also
>          ^^^^^^^                                            ^^^^^^^
>          required on the cellular device.
>          ^^^^^^^^
>
>o Add a reference to DNSSEC.
[Med] Add pointers to RFC4033, 4034 and 4035.

>o Pref64 discovery is already SHOULDed in Req11. Mentioning it here
> again seems unnecessary repetition.
[Med] As suggested by Teemu a reference to REQ#11 was added to the text.

>
>          The support of PCP is seen as a driver to save battery
>                                          ^^^^^^^^^^^^^^^^^^^^^^
>          consumption exacerbated by keepalive messages.  PCP also
>
>o This is a strong statement. Do we have documented proof of that?
> PCP itself does not solve or even help that much the battery
> savings since the host side applications still need to coordinate
> among themselves and it is a different issue & problem.

[Med] The text only says "is seen as a driver to save battery. This text is basically restating what is included on the base PCP spec: " This helps reduce bandwidth on the subscriber's
   access network, traffic to the server, and battery consumption on
   mobile devices. "

>
>  REQ#15:  When the cellular host is dual stack connected, it SHOULD
>                                     ^^^^^^^^^^^^^^^^^^^^^
>o Using what mechanisms? Two PDPs? IPv4v6 PDP or XLAT? Or should we
> actually not care? Some clarification would be nice here, though.

[Med] i.e., configured with an IPv4 address and IPv6 prefix. Text is updated now.

>
>          [I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices.
>                                                      ^^^^^
>o Care to expand..
[Med] Teemu suggested to remove the MIF reference...which I accepted.

>
>  REQ#17:  The cellular host SHOULD NOT perform Duplicate Address
>       Detection (DAD) for these Global IPv6 addresses (as the GGSN or
>       PDN-GW must not configure any IPv6 addresses using the prefix
>       allocated to the cellular host).  Refer to Section 4 for DAD
>       considerations on the LAN interface when the 3GPP connection is
>       shared.
>
>o This is already in RFC6459 and RFC 3316(bis). No need to repeat the
> requirement here again and Section 4 deals with the specific case
> that is not in the previously mentioned RFCs. I suggest removing
> the Req17.

Med: Done.

>
>6) Section 2.1 - Wi-Fi Connectivity
>
>2.1.  WiFi Connectivity
>                       ^^^^^^^^
>o Why not adding "Requirements" here as well?
[Med] Done.


>
>  REQ#19:  IPv6 MUST be supported on the Wi-Fi interface.  In
>         particular, IPv6-only connectivity MUST be supported over the
>         Wi-Fi interface.
>
>o Suggest rewording "..Wi-Fi interface without configuring IPv4
> on the interface."
>
>            Recent tests revealed that IPv4 configuration is required
>            to enable IPv6-only connectivity.  Indeed, some cellular
>            handsets can access a Wi-Fi IPv6-only network by
>            configuring first a static IPv4 address.  Once the device
>            is connected to the network and the wlan0 interface got an
>            IPv6 global address, the IPv4 address can be deleted from
>            the configuration.  This avoids the device to ask
>            automatically for a DHCPv4 server, and allows to connect to
>            IPv6-only networks.
>
>o I would delete this and just state that "Failing to configure an
> IPv4 address on the interface MUST NOT prohibit using IPv6 on the
> same interface."
[Med] "Recent test.." is now changed to " Some tests..".  I didn't removed that text as it provides the context. I added the explicit sentence you proposed.

>
>
>7) Section 3 - Advanced Requirements
>
>  REQ#22:  The cellular host must comply with Section 5.6.1 of
>                             ^^^^
>o s/must/MUST
[Med] Fixed

>
>  REQ#23:  The cellular host must comply with Section 5.9.3 of
>                             ^^^^
>o s/must/MUST
[Med] Fixed.

>
>            permanent interface identifier.  [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.
>
>  REQ#24:  The cellular host SHOULD support ROHC for IPv6 ([RFC5795]).
>
>o I would say which ROHC profiles SHOULD be supported. It makes no sense
> to require all, since IMHO ROHC has limited benefit in 3G/LTE. I would
> strongly recommend aligning this requirement to GSMA PRD.92.

Med: Profile 1 and 2 are explicitly included in the REQ now.

>
>o IMHO no need to repeat the DAD behaviour. I strongly suggest removing
> the last sentence.
>
>            This is a stronger form compared to what is specified in
>            [RFC6434].  The justification is some flags are used by the
>            GGSN (or PDN-GW) to inform cellular hosts about the
>            autoconfiguration process.
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^
>o Care to reveal the flags that do the justification? What are told now
> by GGSNs/PGWs more in extended flags? I am OK with the requirement as
> such but the justification text is just confusing. I suggest removing
> it.
>
>  REQ#26:  The cellular host must comply with Section 5.3 of [RFC6434]
>                             ^^^^
>o s/must/MUST
[Med] Done.

>
>8) Section 4 - Cellular Devices with LAN Capabilities
>
>4.  Cellular Devices with LAN Capabilities
>                         ^^^
>o So this is strongly about LAN, not WLAN?
>
>  are sharing the same GPRS, UMTS or EPS connection.  In addition to
>                       ^^^^  ^^^^    ^^^
>o s/GPRS/2G
>o s/UMTS/3G
>o s/EPS/LTE
[Med] OK, done.

>
>            WAN and the Delegated Prefix to be aggregatable, so the
>            ^^^
>o Expand WAN on the first occurrence.
[Med] Done.

>
>            (e.g., halving the Delegated prefix and assigning the WAN
>                              ^^^
>o s/Delegated/delegated
[Med] Fixed.

>
>         requirements specified in [RFC6204].
>                                    ^^^^^^^
>o I would suggest referencing to RFC6204bis since it has some language
> that takes cellular network particularly into considerations.

Med: RFC6204 is sufficient.

>
>            reduced to 1440 bytes.  While a host may generate packets
>                       ^^^^^
>o TS.23060 has specific MTU size recommendations. I would reference to
> that and also "reveal" the number stated in there.
[Med] Done.

>
>9) Section 5 - APIs & Applications
>
>  REQ#33:  Applications MUST be independent of the underlying IP
>         address family.
>
>o I think SHOULD/RECOMMENDED with some stressing would be more
> appropriate. There could be cases where IP version specific
> software is justified, e.g. diagnostic tools and such.. Maybe
> "MUST be independent of the underlying IP address family,
>  unless done purposely address family specific for a specific
>  reasons."

[Med] IMO, adding exceptions will nullify the REQ.

>
>10) Section 6 - Security Considerations
>
>  The security considerations identified in [RFC3316] are to be taken
>                                            ^^^^^^^^^
>o Use RFC3316bis and also reference to RFC6459 that has some additional
> security considerations to RFC3316.

[Med] Ok, done.