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

<> Thu, 19 February 2015 13:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A03901A906A for <>; Thu, 19 Feb 2015 05:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UXWUupftEZbL for <>; Thu, 19 Feb 2015 05:20:10 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60F0E1A906B for <>; Thu, 19 Feb 2015 05:20:09 -0800 (PST)
Received: from (unknown [xx.xx.xx.4]) by (ESMTP service) with ESMTP id 5DF033B43DA; Thu, 19 Feb 2015 14:20:07 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 22BCD23808F; Thu, 19 Feb 2015 14:20:07 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Thu, 19 Feb 2015 14:20:06 +0100
From: <>
To: Lorenzo Colitti <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Thread-Index: AQHQTEJGixBJZ1L350WogIuKXDMPO5z38OtA
Date: Thu, 19 Feb 2015 13:20:06 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300490E5EE@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <> <> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <> <> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300490DAE5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6536E263028723489CCD5B6821D4B21303E097FB@UK30S005EXS06.EEAD.EEINT.CO.UK> <> <787AE7BB302AE849A7480A190F8B93300490E4E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490E5EEOPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.2.19.124820
Archived-At: <>
Cc: "IPv6 Ops WG \(\)" <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Feb 2015 13:20:12 -0000


Please see inline.


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

On Thu, Feb 19, 2015 at 9:32 PM, <<>> 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.

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

   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

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