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

[Jouni Korhonen <[e-mail]>]

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)
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
 those in the comments below)
o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest
 to use only the latter one.
o The I-D uses a "mobile device" in places where it should really say
 a "cellular device". Use consistent wording.
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.
o The use of GGSN and PDN-GW should have more consistency. For example
 using GGSN/PGW throughout..

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

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

  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?

  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.

  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".

3) Section 1 - Introduction

  IPv6 deployment in mobile networks is the only perennial solution to
                     ^^^^^^^^^^^^^^^
o Suggest to use wireless networks.

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

  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.

  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

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

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

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

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.

  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.

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.
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.

       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.

          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.

          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.

          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

          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.

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

          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).

  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

          The cellular host MUST use the interface identifier sent in
                                         ^         ^
o s/interface identifier/Interface Identifier. For the consistency..

          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.

  REQ#9:  The cellular host must comply with Section 7.3 of [RFC6434].
                            ^^^^
o s/must/MUST
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.

  REQ#10:  The cellular host must comply with Section 7.2.1 of
                             ^^^^
o s/must/MUST

          1.  PCP
          ^^^^^^^
o I assume PCO is meant here?

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

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

          DNSSEC.  Means to configure or discover a PREFIX64 is also
          ^^^^^^^                                            ^^^^^^^
          required on the cellular device.
          ^^^^^^^^

o Add a reference to DNSSEC.
o Pref64 discovery is already SHOULDed in Req11. Mentioning it here
 again seems unnecessary repetition.

          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.

  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.

          [I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices.
                                                      ^^^^^
o Care to expand..

  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.

6) Section 2.1 - Wi-Fi Connectivity

2.1.  WiFi Connectivity 
                       ^^^^^^^^
o Why not adding "Requirements" here as well?

  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."


7) Section 3 - Advanced Requirements

  REQ#22:  The cellular host must comply with Section 5.6.1 of
                             ^^^^
o s/must/MUST

  REQ#23:  The cellular host must comply with Section 5.9.3 of
                             ^^^^
o s/must/MUST

            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.

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

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

            WAN and the Delegated Prefix to be aggregatable, so the
            ^^^
o Expand WAN on the first occurrence.

            (e.g., halving the Delegated prefix and assigning the WAN
                              ^^^
o s/Delegated/delegated

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

            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.

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."

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.