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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 17 February 2017 10:35 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 A29281296DE for <ipv6@ietfa.amsl.com>; Fri, 17 Feb 2017 02:35:10 -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 N0JZvqDVIIzL for <ipv6@ietfa.amsl.com>; Fri, 17 Feb 2017 02:35:09 -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 F032C1294D1 for <ipv6@ietf.org>; Fri, 17 Feb 2017 02:35:08 -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 v1HAZ7HH015109 for <ipv6@ietf.org>; Fri, 17 Feb 2017 11:35:07 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 710BD204054 for <ipv6@ietf.org>; Fri, 17 Feb 2017 11:35:07 +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 6693D200BE9 for <ipv6@ietf.org>; Fri, 17 Feb 2017 11:35:07 +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 v1HAZ69O023387 for <ipv6@ietf.org>; Fri, 17 Feb 2017 11:35:06 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: ipv6@ietf.org
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <m2y3x6eutl.wl-randy@psg.com> <B76B6864-5827-4AC1-9BF7-8FFF069C10F1@employees.org> <m2lgt6ed7j.wl-randy@psg.com> <4514E052-25C1-4C85-AB1D-0B53FD9DA0E1@employees.org> <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com> <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org> <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com> <8767e370398045af989467a63747b29e@XCH15-06-11.nw.nos.boeing.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <028a2ff5-6f08-9404-0586-412e632bc2ca@gmail.com>
Date: Fri, 17 Feb 2017 11:35:05 +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: <8767e370398045af989467a63747b29e@XCH15-06-11.nw.nos.boeing.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XuEtZOLjjFKL2XtG4ovKyUnxOp4>
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: Fri, 17 Feb 2017 10:35:10 -0000


Le 16/02/2017 à 23:38, Manfredi, Albert E a écrit :
> RFC 7421 is informational. And many considerations are not so critical
> anymore, on a specific stateful format.
>
>
>
> I don’t think we need to reinforce the notion that IPv6 must have 64-bit
> prefixes, since that is not true now, and should not even be made to
> apply to the currently unused address space. So, I’m opposed to text
> that implies any such restriction, with the exception of (a) currently
> used unicast  address space, (b) SLAAC, (c) ULA, possibly other exceptions.
>
>
>
> In other words, *exceptions belong to requiring the 64-bit IID*. Any RFC
> that implies otherwise, IMO, ought to be subject to a –bis version.

I agree.  And RFC2464bis should give the example, as it always did.

Alex

>
>
>
> Bert
>
>
>
>
>
> *From:*ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *james woodyatt
> *Sent:* Thursday, February 16, 2017 17:21
> *To:* IETF-Discussion Discussion <ietf@ietf.org>;
> *Cc:* 6man WG <ipv6@ietf.org>;; draft-ietf-6man-rfc4291bis@ietf.org;
> 6man-chairs@ietf.org
> *Subject:* Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP
> Version 6 Addressing Architecture) to Internet Standard
>
>
>
> On Feb 16, 2017, at 13:25, otroan@employees.org
> <mailto:otroan@employees.org> wrote:
>
>     On Feb 13, 2017, at 14:32, David Farmer <farmer@umn.edu
>     <mailto:farmer@umn.edu>> wrote:
>
>
>
>         I have concerns with the following text;
>
>            IPv6 unicast routing is based on prefixes of any valid length
>         up to
>            128 [BCP198].  For example, [RFC6164] standardises 127 bit
>         prefixes
>            on inter-router point-to-point links. However, the Interface
>         ID of
>            all unicast addresses, except those that start with the
>         binary value
>            000, is required to be 64 bits long.  The rationale for the
>         64 bit
>            boundary in IPv6 addresses can be found in [RFC7421]
>
>
>
>         The third sentence seems to limit exceptions to 64 bit IIDs to
>         exclusively addresses that start with binary vale of 000.  There
>         are at least two other exceptions from standards track RFCs,
>         that should be more clear accounted for in this text. […]
>
>
>
>     […]
>
>     The challenge is to find text that enforces the 64-bit boundary
>     policy (ignoring the technical arguments for a moment), and at the
>     same time ensures implementors do the right thing and make their
>     code handle any prefix length. Of course these are interdependent
>     and doing the latter makes it harder to enforce the first.
>
>
>
> I propose the following:
>
>
>
>             IPv6 unicast routing is based on prefixes of any valid
>             length up to 128 bits [BCP198]. However, as explained in
>             [RFC7421], the Interface ID of unicast addresses is
>             generally required to be 64 bits in length, with exceptions
>             only provided in special cases where expressly recognized in
>             IETF standards track documents.
>
>
>
> Trying to help out here.
>
>
>
>
>
> --james woodyatt <jhw@google.com <mailto:jhw@google.com>>
>
>
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>