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 09:03 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 09A4312956A for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 01:03:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Level:
X-Spam-Status: No, score=-0.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, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 oEm1dqR4bFsR for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 01:03:40 -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 131E6129C5B for <ipv6@ietf.org>; Thu, 23 Feb 2017 01:03:36 -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 v1N93ZVc008275 for <ipv6@ietf.org>; Thu, 23 Feb 2017 10:03:35 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 82C0A205565 for <ipv6@ietf.org>; Thu, 23 Feb 2017 10:03:35 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7948920080A for <ipv6@ietf.org>; Thu, 23 Feb 2017 10:03:35 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1N93ZLI011710 for <ipv6@ietf.org>; Thu, 23 Feb 2017 10:03:35 +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> <m2vas1ttsj.wl-randy@psg.com> <CAKD1Yr3cZxsFqkLf=obAngCp5W-1EMnn4bsx-JcvaEaHOYTOCw@mail.gmail.com> <CAAedzxoO5RgkP7cCL+bfUQEitFto6yQ7eGbLLbBU7_FD9PJPmg@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <bcb5182f-a844-742a-9f1a-d8deb79127a5@gmail.com>
Date: Thu, 23 Feb 2017 10:03:27 +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: <CAAedzxoO5RgkP7cCL+bfUQEitFto6yQ7eGbLLbBU7_FD9PJPmg@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/-Wh_XrAxGZ5U6ySctu9ET3ZeuE4>
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 09:03:42 -0000


Le 23/02/2017 à 07:58, Erik Kline a écrit :
> On 23 February 2017 at 15:05, Lorenzo Colitti <lorenzo@google.com
> <mailto:lorenzo@google.com>> wrote:
>
>     On Thu, Feb 23, 2017 at 1:28 PM, Randy Bush <randy@psg.com
>     <mailto:randy@psg.com>> wrote:
>
>         > the IETF and 6man absolutely have the ability to change the standard,
>         > but it should follow the proper process: write a draft, get consensus,
>
>         that is the process we are currently in.  but there seems to be
>         serious
>         disagreement over the draft.
>
>
>     AIUI the goal of the process is to reclassify the current
>     specification. That severely restricts the types of changes that are
>     possible. That is the basis on which this document gained WG
>     consensus and reached IETF last call.
>
>     If we want to say that we're no longer reclassifying the current
>     specification but are instead opening the door to bigger changes,
>     then the document should go back to the WG for further work because
>     the existing WG consensus was based on the stated goal of
>     reclassifying the document.
>
>
> I agree with the procedural concerns here.  Among other things, if we
> make substantial changes it's hard to claim we have experience running
> the new thing we've documented.
>
> I tend to think of IID concept's primary use as: if I have the IID
> ::dead:beef/64 then for every new /64 PIO that's announced *I* can
> reasonably expect to lay claim to prefix1::dead:beef/64,
> prefix2::dead:beef/64, and so on.  (Support for this mode operations,
> SLAAC, is a MUST.)

No.  It is a MAY.  When doing manual configuration one does need to run 
SLAAC too.

Alex

>
> I don't personally find any major conflict when considering static and
> stateful addressing.  For example, if there are 2 prefixes on a link,
> and the administrators are using static addressing then prefix1::cafe
> and prefix2::cafe do not in any way have to belong to the same interface
> on the same host. ... at least as far as I understand it.  If prefix1
> and prefix2 are each longer than /64 then each 64bit IID would still be
> unique--no problems.  But if each were <=64 then it's just violating a
> recommendation in the first paragraph of 2.4.1--not a big deal for the
> administrator that wants to run that way.
>
> I'm not sure if this adds anything useful to the discussion, though.
> -Erik
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>