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

Pierre Pfister <pierre.pfister@darou.fr> Fri, 24 February 2017 07:53 UTC

Return-Path: <SRS0=3dbs=2F=darou.fr=pierre.pfister@bounces.m4x.org>
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 462E01295F1; Thu, 23 Feb 2017 23:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-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 dOc8NDPJildy; Thu, 23 Feb 2017 23:53:30 -0800 (PST)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1313A129514; Thu, 23 Feb 2017 23:53:30 -0800 (PST)
Received: from [10.61.217.135] (unknown [173.38.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 060BA5646FA; Fri, 24 Feb 2017 08:53:25 +0100 (CET)
From: Pierre Pfister <pierre.pfister@darou.fr>
Message-Id: <A0EDE3AA-95AA-418B-A2B3-E9C8A74204A5@darou.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_357C3F7A-42B0-43C4-B43E-354CD3D5955E"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Date: Fri, 24 Feb 2017 08:53:25 +0100
In-Reply-To: <CAN-Dau3bHXOaJGe1UaLdDht9=+WiD4SEu8qw9Sc915tOes5seA@mail.gmail.com>
To: David Farmer <farmer@umn.edu>
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> <5ce34926-6bde-6410-9b1e-3f61e48e9a1d@gmail.com> <CAKD1Yr1yRTUPVTTicaTkA8fAFxHiHxdLG8ZzEHjCUDDzKg5zJg@mail.gmail.com> <CAN-Dau0xpjB4Z8CgSfW0W7y4F_wnXNS+Ws1UNBC-YnBDrPiTjQ@mail.gmail.com> <cf3496dc-47c6-6c6b-a42a-e0402789110a@si6networks.com> <CAN-Dau3bHXOaJGe1UaLdDht9=+WiD4SEu8qw9Sc915tOes5seA@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Feb 24 08:53:27 2017 +0100 (CET))
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_wnR8IGwnX_KbPIseA9q7hGAKx4>
Cc: 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, Fernando Gont <fgont@si6networks.com>, draft-ietf-6man-rfc4291bis@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: Fri, 24 Feb 2017 07:53:32 -0000

Hello David,


> Le 24 févr. 2017 à 08:15, David Farmer <farmer@umn.edu>; a écrit :
> 
> 
> 
> On Thu, Feb 23, 2017 at 9:13 PM, Fernando Gont <fgont@si6networks.com <mailto:fgont@si6networks.com>> wrote:
> I'd remove a few sentences here, as in:
> 
>    IPv6 unicast routing is based on prefixes of any valid length up to
>    128 [BCP198]. Subnet prefixes of /64 are RECOMMENDED for general
>    purpose use, subnet prefixes of /127 are RECOMMENDED for point-
>    to-point router links [RFC6164]. The rationale for the 64 bit
>    boundary in IPv6 addresses can be found in [RFC7421].
> 
> The problem is you have stripped out all the implementation guidance and only left operational guidance.  But maybe the the right idea is to separate the two, putting the operational guidance in Section 2.4 where we are talking about prefixes and the implementation guidance in section 2.4.1 where we are talking about IIDs.
> 2nd Paragraph of 2.4;
> 
>    IPv6 unicast routing is based on prefixes of any valid length up to
>    and including 128 [BCP198].  However, subnet prefixes of 64 bits in
>    length are REQUIRED for use with Stateless Address Autoconfiguration
>    (SLAAC)[RFC4862] and are RECOMMENDED for all other general purpose
>    use. The rationale for the 64 bit boundary in IPv6 addresses can be 
>    found in [RFC7421].

Except RFC4862(SLAAC) does not say anywhere that 64 bits long IIDs are required.
Only mention I find of 64 is given as an example for EUI-64 for ethernet links.

> 
> 4th paragraph of 2.4.1
> 
>    For all unicast addresses, except those that start with the binary
>    value 000, support for Interface IDs that are 64 bits long is 
>    REQUIRED, support for other Interface IDs lengths is OPTIONAL. The 
>    rationale for the 64 bit boundary in IPv6 addresses can be found in
>    [RFC7421].

1) The ::/3 rule is blatantly ignored by all implementations that I know of.
I don't see how something that has been ignored for years, and has 
no implementation and deployment experience, could make its way to full standard.

2) "support for other Interface IDs lengths is OPTIONAL" -> Wait. What !?
This is not a compromise. You are just relaxing the requirement even more than it already is.
This is not what is implemented, nor what is deployed.

- Pierre

> 
> This clearly say that implementations that only support 64 bit IID lengths are just fine, but also says implementations that allow IID lengths other than 64 bits are just fine too.  I think the current and historic text actually implies implementations are not to allow other IID lengths, is that what we really intended to say?  A lot of implementations seem to allow other IID lengths, are they wrong?  I don't think so.
> 
> This also gives strong operational guidance that 64 bit length subnet prefixes are expected in most situations.  Reinforcing the 64 bit boundary, however without outlawing the use of other subnet prefix lengths when implemented and they could be useful.  This is done without distracting from the 64 bit boundary, by not directly calling attention to RFC6164 or the other longer prefix lengths. Since BCP198 and RFC7421 both reference RFC6164 calling it out here doesn't seem necessary, and would unnecessarily weaken the focus on the 64 bit boundary that I'm trying to maintain.
> 
> I don't see how this text would require changes in any code, nor does it imply other IID lengths are not allowed operationally, again which a lot of implementations seem to allow. 
> 
> Thanks.
> -- 
> ===============================================
> David Farmer               Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SE        Phone: 612-626-0815 <tel:(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-9952>
> ===============================================