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