Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[e-mail]]
Envoyé : jeudi 19 février 2015 13:48
À : BOUCADAIR Mohamed IMT/OLN
Cc : Heatley, Nick; Ca By; IPv6 Ops WG ([e-mail])
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Thu, Feb 19, 2015 at 9:32 PM, <[e-mail]<mailto:[e-mail]>> wrote:
It is obvious there is a void filled by this draft. It is built on existing RFCs already published in this area. This document is not original in its ambition nor it is different in its structure.

Actually, I don't see a void.
[Med]

Short answer :

The void is (at least):

·         Existing profile RFC does not cover IPv4 service continuity features, devices with lan capabilities, etc.

·         Existing profile RFCs conflicts with other others.

·         There are still broken IPv6 implementations. Deterministic behaviors is encouraged. Saying a device supports IPv6 is meaningless.

Long version: is documented in the I-D that I suppose you already read:

This profile is a superset of that of the IPv6 profile for 3GPP
   Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node
   Requirements [RFC6434].  It targets cellular nodes, including GPRS and
   EPC (Evolved Packet Core), that require
   features to ensure IPv4 service delivery over an IPv6-only transport
   in addition to the base IPv6 service.  Moreover, this profile covers
   cellular CPEs that are used in various deployments to offer fixed-
   like services.  Recommendations inspired from real deployment
   experiences (e.g., roaming) are included in this profile.  Also, this
   profile sketches recommendations for the sake of deterministic
   behaviors of cellular devices when the same configuration information
   is received over several channels.

   For conflicting recommendations in [RFC7066] and [RFC6434] (e.g.,
   Neighbor Discovery Protocol), this profile adheres to [RFC7066].
   Indeed, the support of Neighbor Discovery Protocol is mandatory in
   3GPP cellular environment as it is the only way to convey IPv6 prefix
   towards the 3GPP cellular device.  In particular, MTU (Maximum
   Transmission Unit) communication via Router Advertisement must be
   supported since many 3GPP networks do not have a standard MTU
   setting.

   This profile uses a stronger language for the support of Prefix
   Delegation compared to [RFC7066].  The main motivation is that
   cellular networks are more and more perceived as an alternative to
   fixed networks for home IP-based services delivery; especially with
   the advent of smartphones and 3GPP data dongles.  There is a need for
   an efficient mechanism to assign shorter prefix than /64 to cellular
   hosts so that each LAN segment can get its own /64 prefix and multi-
   link subnet issues to be avoided.  The support of this functionality
   in both cellular and fixed networks is key for fixed-mobile
   convergence.


IPv6 deployment on mobile networks (ok, perhaps not those of the authors)

[Med] I thought you already mentioned Orange in one of your answer as an example of those deploying IPv6 (https://www.ietf.org/mail-archive/web/v6ops/current/msg21399.html). Anyway, all the operators co-authoring this draft are active in IPv6 deployment.

is happening now. Tens of millions of mobile devices are running IPv6 today. And a lot of it happened before this draft was even written.

[Med] This draft was edited because operators having IPv6 deployment project are seeking for a reference document for the device part.