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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 22 February 2017 19:02 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 ACB83129A58 for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 11:02:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
X-Spam-Status: No, score=-5.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, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 SdfjT3fjrGwj for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 11:02:45 -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 57079129A3F for <ipv6@ietf.org>; Wed, 22 Feb 2017 11:02:45 -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 v1MJ2gpi030921 for <ipv6@ietf.org>; Wed, 22 Feb 2017 20:02:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89EA3203AF0 for <ipv6@ietf.org>; Wed, 22 Feb 2017 20:02:42 +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 80097206FB0 for <ipv6@ietf.org>; Wed, 22 Feb 2017 20:02:42 +0100 (CET)
Received: from [132.166.84.61] ([132.166.84.61]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1MJ2f4L025115 for <ipv6@ietf.org>; Wed, 22 Feb 2017 20:02:42 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: ipv6@ietf.org
References: <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> <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org> <20170220235734.GA84656@Vurt.local> <CAKD1Yr3p=8b9Dmmb9GvGMq1u00xnE2ScmaF_a3FJXiteL=ZhBQ@mail.gmail.com> <20170221172739.GT84656@Vurt.local>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <839183d5-b37f-fe86-a339-07454dc92fed@gmail.com>
Date: Wed, 22 Feb 2017 20:02:34 +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: <20170221172739.GT84656@Vurt.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Y6dBBv9M_QcNNf7t6mgeb0fJrRU>
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: Wed, 22 Feb 2017 19:02:48 -0000


Le 21/02/2017 à 18:27, Job Snijders a écrit :
> On Tue, Feb 21, 2017 at 09:49:32AM +0900, Lorenzo Colitti wrote:
>> On Tue, Feb 21, 2017 at 8:57 AM, Job Snijders <job@ntt.net> wrote:
>>> ps. The "Write a draft" argument is weak at best, since we are
>>> already are discussing a draft (called
>>> 'draft-ietf-6man-rfc4291bis-07.txt'), which is in IETF Last
>>> call, which means it is in a place to discuss the contents of
>>> that draft. No reason to kick the can down the road.
>>
>> I'm sorry, but that's really how it is. The text you dislike has
>> been the standard for almost 20 years, and is it inappropriate to
>> change it in the context of reclassifying this document from draft
>>  standard to Internet standard.
>
> Or, perhaps it is inappropiate for the -bis document to target
> "Internet Standard" classification at this moment? ¯\_(ツ)_/¯
>
> Especially when solidifying recommendations in an architecture
> Internet Standard-to-be, the utmost care should be taken to verify
> whether the paper reality (RFCs) and operational reality (what people
> do, for $reasons) are aligned.
>
> In those years sufficient data has been collected to conclude that
> /64 is not the "be all and end all". The current paragraph does not
> account for staticly configured environments in which SLAAC plays no
>  role.
>
> Perhaps the following suggestion bridges the gap.
>
> -------
>
> OLD: 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]
>
> NEW: IPv6 unicast routing is based on prefixes of any valid length up
> to 128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface
> ID of unicast addresses is required to be 64 bits long. In other use
> cases different prefix sizes may be required. For example [RFC6164]
> standardises 127 bit prefixes on inter-router point-to-point links.
> For most use cases, prefix lengths of 64 bits is RECOMMENDED, unless
> there are operational reasons not to do so.

I agree with the NEW paragraph if Ethernet is mentioned, and if its last
paragraph gets updates.

I propose this:
NEW NEW:
> IPv6 unicast routing is based on prefixes of any valid length up to
> 128 [BCP198]. When using [SLAAC]/[Ethernet], [ILNP], or [NPT66] the
> Interface ID of unicast addresses is required to be 64 bits long. In
>  other use cases different prefix sizes may be required. For example
>  [RFC6164] standardises 127 bit prefixes on inter-router
> point-to-point links.  Prefix lengths of 64 bits were observed on
> popular connections and are taught on IPv6 lectures.  Prefix lengths
> of 96 bits were observed at Virtual Machine providers.

[note SLAAC alone can work with /65 too]


> OLD: As noted in Section 2.4, all unicast addresses, except those
> that with the binary value 000, Interface IDs are required to be 64
> bits long.
>
> NEW: *delete, its superfluous*

I agree.  But I dont know whether registries have not set this 000 apart
for maybe 200 years later or so. (it may sound not serious, but I know
there are serious public plans for such long term on other matters).

Alex

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