Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP
Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 04 March 2017 13:01 UTC
Return-Path: <alexandre.petrescu@gmail.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 B73411295B2 for <v6ops@ietfa.amsl.com>; Sat, 4 Mar 2017 05:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no 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 2GJXAZTRBl8w for <v6ops@ietfa.amsl.com>; Sat, 4 Mar 2017 05:01:42 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883BE129596 for <v6ops@ietf.org>; Sat, 4 Mar 2017 05:01:42 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v24D1d5u021979; Sat, 4 Mar 2017 14:01:40 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E50ED203AAD; Sat, 4 Mar 2017 14:01:39 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D7B4A200CE9; Sat, 4 Mar 2017 14:01:39 +0100 (CET)
Received: from [132.166.84.121] ([132.166.84.121]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24D1dxQ013270; Sat, 4 Mar 2017 14:01:39 +0100
To: Lorenzo Colitti <lorenzo@google.com>
References: <d1193890-0066-ad01-e521-0d9e8df065a8@gmail.com> <CAKD1Yr2OZfYVJLna38Vq3YmfGUrxOpLKAEpRKcEPDNAsiP2CiA@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <12d65957-5261-b9ab-bf95-b7c95525c5c7@gmail.com>
Date: Sat, 04 Mar 2017 14:01:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr2OZfYVJLna38Vq3YmfGUrxOpLKAEpRKcEPDNAsiP2CiA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lrtHes0O0VbhmU-r8rAIt6CspTQ>
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: Sat, 04 Mar 2017 13:01:43 -0000
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. I could write another draft in support of DHCPv6-PD, or I could help someone to. In the past I already did for some RFCs supporting DHCPv6-PD. But isn't that enough documents already present? Arent they enough to warrant the invalidation of this particular RFC? > Personally I doubt you'll reach consensus, but you're free to take > that path. Thanks for encouraging me :-) But seriously I appreciate invitations to write drafts. Alex > > On 3 Mar 2017 10:37 pm, "Alexandre Petrescu" > <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> > wrote: > > Hi v6opsers, > > I suppose this RFC has been developped here in v6ops, otherwise > please excuse me. > > This RFC is an Independent Stream (not IETF Stream, no Standards > Track, no BCP) RFC7849 "An IPv6 Profile for 3GPP Mobile Devices". > > This RFC has a number of problems; they are related to its > recommendation of the INFORMATIONAL 64share RFC7278 at the loss of > DHCPv6-PD. > > I propose to make this RFC7278 HISTORICAL, or find some other way to > discard its contents with respect to 64share and DHCPv6 PD > (Errata?). > > I also propose to inform officially 3GPP that this specific document > should not be taken at face value, but just For Your Information, > if you like it. > > Here are the detail comments: > > ===== L_REC#1: For deployments that require that the same /64 prefix > be shared, > > > I think this formulation is a reverse formulation. > > Some deployments need more than one /64, and an INFORMATIONAL > solution is to share one /64 among many subnets. That does not mean > the deployment requires 'sharing' the same /64. Deployments require > multiple /64s. > > This should be either removed or corrected. > > (and I understand yes that the word 'share' may have been used by > some as in 'WiFi is a shared link, as opposed to 3GPP being a ptp > link', in which case - yes, some deployments require the use of > 'shared links/WiFi' connected to a cellular link; beware the > misinterpretations). > > the cellular device should support [RFC7278] to enable sharing a /64 > prefix between the LAN and the WAN interfaces. > > > That is a wrong recommendation. > > The right recommendation is the following: the cellular device SHOULD > support DHCPv6-PD. > > And the text MUST NOT recommend sharing a /64 prefix. > > The WAN interface is the one towards the Gateway GPRS Support Node > (GGSN) / Packet Data Network Gateway (PGW). > > Prefix Delegation (refer to L_REC#2) is the target solution for > > > It's not a 'target', it is a 'now'. It comes before 64share. > > distributing prefixes in the LAN side but, because the device may > attach to earlier 3GPP release networks, a means to share a /64 > prefix is also recommended [RFC7278]. > > > No! That recommendation is wrong. That RFC is INFORMATIONAL and we > should stop recommending it. I has huge problems, at least with > respect to scalability. > > This backwards-compatible requirement does not make much sense here. > We dont know what is a 'earlier 3GPP release network' with respect to > 64share or DHCPv6-PD. Since 64share puts no requirement on the > network, earlier 3GPP networks are precisely the same as newer 3GPP > networks when it comes to 64share. > > [RFC7278] must be invoked only if Prefix Delegation is not in use. > > > ... _and_ if it works for the network being deployed. If it does not > work, it MUST NOT be invoked. > > L_REC#2: The cellular device must support Prefix Delegation > capabilities [RFC3633] and must support the Prefix Exclude Option for > DHCPv6-based Prefix Delegation as defined in [RFC6603]. > > > Why is the 'prefix exclude' option a MUST? I may need to understand > that, by further reading... > > I am asking because that puts additional burden on the smartphone > implementer. > > I suggest to make 'prefix exclude' an option, not a must. Do not > block the deployment of DHCPv6-PD because 'prefix exclude' is > absent. > > Particularly, it must behave as a Requesting Router. > > > Yes, and it is a MUST, not a must. > > Cellular networks are more and more perceived as an alternative to > fixed broadband networks for home IP- based services delivery; > > > I agree. > > especially with the advent of smartphones and 3GPP data dongles. > > > _and_ M2M and IoT devices which are not 'dongles' (btw, 'dongles' are > only the USB dongles, there are no other kinds of dongles). > > There is a need for an efficient mechanism to assign larger prefixes > (other than /64s) to cellular hosts > > > I fully agree. > > so that each LAN segment can get its own /64 prefix > > > _if_ that LAN is an Ethernet, yes it needs a /64. Often it is the > case. > > and multi-link subnet issues to be avoided. > > > I agree, there is an RFC that must be cited there. > > In case a prefix is delegated to a cellular host using DHCPv6, the > cellular device will be configured with two prefixes: > > (1) one for the 3GPP link allocated using the Stateless Address > Autoconfiguration (SLAAC) mechanism and > > (2) another one delegated for LANs acquired during the Prefix > Delegation operation. > > > I dont know what you mean by 'configured', but this second prefix may > just be in the rt table of the device (not necessarily on its > interfaces). I dont understand why you say 'will be configured with > two prefixes'. > > How about the default route? > > Note that the 3GPP network architecture requires both the WAN and the > delegated prefix to be aggregatable so the subscriber can be > identified using a single prefix. > > > Yes, it's good to avoid waste. > > Without the Prefix Exclude Option, the delegating router (GGSN/PGW) > will have to ensure compliance with [RFC3633] (e.g., halving the > delegated prefix and assigning the WAN prefix out of the first half > and the prefix to be delegated to the terminal from the second > half). > > > So 'prefix exclude' is not mandatory in order to have DHCPv6-PD > working? Earlier it seemed mandatory. > > Because Prefix Delegation capabilities may not be available in some > attached networks, L_REC#1 is strongly recommended to accommodate > early deployments. ===== > > > This is wrong. We should _never_ recommend somehting we know it does > not scale. 64share does not scale, there is a 'multi-link subnets' > RFC and there is operational experience showing so. > > Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org <mailto:v6ops@ietf.org> > https://www.ietf.org/mailman/listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops> > >
- [v6ops] RFC7849 must not recommend 64share, and m… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Erik Kline
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Ca By
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Ca By
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Ca By
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Simon Hobson
- Re: [v6ops] RFC7849 must not recommend 64share, a… Erik Kline
- Re: [v6ops] RFC7849 must not recommend 64share, a… Lorenzo Colitti
- Re: [v6ops] RFC7849 must not recommend 64share, a… Ca By
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Fred Baker
- Re: [v6ops] RFC7849 must not recommend 64share, a… Brian E Carpenter
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Brian E Carpenter
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Brian E Carpenter
- Re: [v6ops] RFC7849 must not recommend 64share, a… mohamed.boucadair
- Re: [v6ops] RFC7849 must not recommend 64share, a… Alexandre Petrescu
- Re: [v6ops] RFC7849 must not recommend 64share, a… Fred Baker