Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP

<mohamed.boucadair@orange.com> Mon, 06 March 2017 07:02 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46521128DF6 for <v6ops@ietfa.amsl.com>; Sun, 5 Mar 2017 23:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-2SF_zI7lCF for <v6ops@ietfa.amsl.com>; Sun, 5 Mar 2017 23:02:24 -0800 (PST)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D125127A90 for <v6ops@ietf.org>; Sun, 5 Mar 2017 23:02:24 -0800 (PST)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 721DE12029E; Mon, 6 Mar 2017 08:02:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 5789C180065; Mon, 6 Mar 2017 08:02:22 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Mon, 6 Mar 2017 08:02:22 +0100
From: mohamed.boucadair@orange.com
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Thread-Topic: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP
Thread-Index: AQHSlKO0E1bptndPKUmhAHrg3rUgN6GElOaAgALMAgA=
Date: Mon, 06 Mar 2017 07:02:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E1CA47@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <d1193890-0066-ad01-e521-0d9e8df065a8@gmail.com> <CAKD1Yr2OZfYVJLna38Vq3YmfGUrxOpLKAEpRKcEPDNAsiP2CiA@mail.gmail.com> <12d65957-5261-b9ab-bf95-b7c95525c5c7@gmail.com>
In-Reply-To: <12d65957-5261-b9ab-bf95-b7c95525c5c7@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/TAqhPouta1juq4MIjOd1BBCaxmg>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2017 07:02:27 -0000

Alex, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Alexandre
> Petrescu
> Envoyé : samedi 4 mars 2017 14:02
> À : Lorenzo Colitti
> Cc : v6ops@ietf.org WG
> Objet : Re: [v6ops] RFC7849 must not recommend 64share, and must not be
> recommended itself to 3GPP
> 
> 
> 
> Le 04/03/2017 à 05:56, Lorenzo Colitti a écrit :
> > RFC 7849 is not a product of v6ops.
> 
> Seems so... although I remember there was some discussion here about it.
> 
> > It's an independent submission and has no standards value. It even
> > says:
> >
> >
> >
> > This document is not an Internet Standards Track specification; it is
> > published for informational purposes.
> 
> I agree.  I would like to echo that.
> 
> > This is a contribution to the RFC Series, independently of any other
> >  RFC stream.  The RFC Editor has chosen to publish this document at
> > its discretion and makes no statement about its value for
> > implementation or deployment.  Documents approved for publication by
> >  the RFC Editor are not a candidate for any level of Internet
> > Standard; see Section 2 of RFC 5741
> > <https://tools.ietf.org/html/rfc5741#section-2>.
> >
> >
> > If you don't like it, take it up with the authors.
> 
> There are very many.
> 
> Is there one that is the main author?
> 
> > If you want the IETF to declare RFC 7278 historic or say that it
> > should not or must not be used, write a draft and see if you can get
> > consensus on it in v6ops.
> 
> There is already such an RFC - it is DHCPv6-PD and other Stds Track RFCs
> that cite it.

[Med] For the matters discussed in RFC7849, the only available RFC with an IETF consensus is: RFC7066. This RFC reflects the current 3GPP documents: 

   Starting from Release-10, DHCPv6 Prefix Delegation was added as an
   optional feature to the 3GPP system architecture [RFC3633].  The
   Prefix Delegation model defined for Release-10 requires that the /64
   IPv6 prefix assigned to the cellular host on the 3GPP link must
   aggregate with the shorter delegated IPv6 prefix.  The cellular host
   should implement the Prefix Exclude Option for DHCPv6 Prefix
   Delegation [RFC6603] (see [RFC6459], Section 5.3 for further
   discussion).

I'm quite sure that language is not what you are looking for. If so, you can add RFC7066 to your list of RFCs to be updated. I will be supportive.

FWIW, you can grab some motivation text from RFC7849, that says explicitly the following: 

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

Unless you have a better solution to share a single /64 prefix over a cellular network when PD is not supported (device, network, or both), the recommendation in RFC784 is the way the proceed (of course, from the standpoint of the authors of that RFC). 

Cheers,
Med