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

Job Snijders <job@ntt.net> Tue, 21 February 2017 17:28 UTC

Return-Path: <job@ntt.net>
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 2B62C129533; Tue, 21 Feb 2017 09:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 2mR3FlzCgdkZ; Tue, 21 Feb 2017 09:28:10 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 7FDF212952D; Tue, 21 Feb 2017 09:28:10 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cgEEL-000EPp-IQ (job@us.ntt.net); Tue, 21 Feb 2017 17:28:10 +0000
Date: Tue, 21 Feb 2017 18:27:39 +0100
From: Job Snijders <job@ntt.net>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <20170221172739.GT84656@Vurt.local>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKD1Yr3p=8b9Dmmb9GvGMq1u00xnE2ScmaF_a3FJXiteL=ZhBQ@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DGaK0-RJPdscJFeGKa19Nz8rZlo>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
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: Tue, 21 Feb 2017 17:28:11 -0000

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.

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*

-------

Kind regards,

Job