Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 23 February 2017 08:44 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188C11293FB for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 00:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.332
X-Spam-Level:
X-Spam-Status: No, score=-5.332 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, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 qcGPr69JyIV9 for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 00:44:21 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490AE12956C for <ipv6@ietf.org>; Thu, 23 Feb 2017 00:44:21 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1N8iJh6011885 for <ipv6@ietf.org>; Thu, 23 Feb 2017 09:44:19 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2D19B200F90 for <ipv6@ietf.org>; Thu, 23 Feb 2017 09:44:19 +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 242EA2008F3 for <ipv6@ietf.org>; Thu, 23 Feb 2017 09:44:19 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1N8iIVk011205 for <ipv6@ietf.org>; Thu, 23 Feb 2017 09:44:19 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: ipv6@ietf.org
References: <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com> <20170222144147.GC89584@hanna.meerval.net> <7960ff2d-359f-429c-6e82-ef592f90bf53@gmail.com> <CAKD1Yr1W+AVt4Dixo9epB5VazxBsVMD+mrshwaE=n7SuX6eGDw@mail.gmail.com> <m2a89dveop.wl-randy@psg.com> <CAKD1Yr1igJiL_2BVi=RL_Wkd6V0O6WaPJ5fMS+ggVkTRAOdPXw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <58d89d96-9975-1b0c-576f-f69a5383ec47@gmail.com>
Date: Thu, 23 Feb 2017 09:44:10 +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: <CAKD1Yr1igJiL_2BVi=RL_Wkd6V0O6WaPJ5fMS+ggVkTRAOdPXw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eWeZABFFvGF5J9m_A6L62n3AszU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 08:44:23 -0000


Le 23/02/2017 à 05:13, Lorenzo Colitti a écrit :
> On Thu, Feb 23, 2017 at 11:11 AM, Randy Bush <randy@psg.com
> <mailto:randy@psg.com>> wrote:
>
>     users do not notice, except when device programmers break things.  i am
>     a host operator, and i do not need classfulness.  slaac is nice in small
>     lans, and the /64 id is fine for the slaac niche.
>
>
> Please think about the arguments in RFC 7934. If some misguided operator
> assigns your device exactly one IPv6 address, that hugely constrains
> what the device can do and how well it does it. And I do think that
> users notice when their network is flaky.
>
>
>     > And it is absolutely inappropriate to change this nowin given that
>     the /64
>     > boundary has been the standard for the last 20 years.
>
>     the other week you were saying i should be patient and we could change
>     it in another decade from now.  now you say forever, it's cast in
>     concrete.
>
>
> Sorry, let me clarify: it is inappropriate to change that now *in this
> document*. As I said elsewhere, the IETF and 6man absolutely have the
> ability to change the standard, but it should follow the proper process:
> write a draft, get consensus, update whatever RFC RFC 4291bis eventually
> becomes. I'm not saying we need to wait a decade.
>
> (I do also happen to think that it would be better if we waited a decade
> before changing this, because we're only 5 or so years into large-scale
> deployment that will hopefully last at least 3 or 4 decades. However, I
> don't expect many people to agree with me on that, so I'm not trying to
> make that argument here.)
>
>
>     well, we are breaking that concrete, have broken it for years, and it's
>     time 6man wakes up, smells the coffee, and gets with reality.
>
>
> What you do in your network is your business. If it works for you -
> which we know it does - I have no problem with that. What I have a
> problem with is when someone tells me that OS code needs to change
> because some operator thinks that "we give this network a /120 subnet
> makes sense because that matches the /24 we use IPv4, and we should be
> free to do that".

You are not forced to change OS code: DHCPv6 runs in the userspace.

Alex

>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>