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

David Farmer <farmer@umn.edu> Fri, 24 February 2017 08:27 UTC

Return-Path: <farmer@umn.edu>
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 640CD129624 for <ipv6@ietfa.amsl.com>; Fri, 24 Feb 2017 00:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Level:
X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 u6DJ13F0xfSg for <ipv6@ietfa.amsl.com>; Fri, 24 Feb 2017 00:27:15 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 86336129421 for <ipv6@ietf.org>; Fri, 24 Feb 2017 00:27:15 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 4FAD4C53 for <ipv6@ietf.org>; Fri, 24 Feb 2017 08:20:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1FNLrnz9dd8 for <ipv6@ietf.org>; Fri, 24 Feb 2017 02:20:12 -0600 (CST)
Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 0643CC4E for <ipv6@ietf.org>; Fri, 24 Feb 2017 02:20:11 -0600 (CST)
Received: by mail-vk0-f72.google.com with SMTP id 130so8454399vkn.2 for <ipv6@ietf.org>; Fri, 24 Feb 2017 00:20:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1TMAmfx/iFF1nFBFM7I4LDSQmO0B3V9NVlTDDK9e0OE=; b=FPrkVTrDYBY2pTMrR2O2HmO2q60MGTANDsRpyYQl+A8PrX6OcaQQ7KPFkMYgpXyNkC cpWWfJrHam6npspPItD4FOvTzOX8NiqI70v5Eh++GAzjFoDDz+SojI7LmjGJ9qifG7X6 KDMvzW9ognMtrXhDbe+mxPvZOB84u8kvvoHCLAuL1wqHGM5Siq5BaOKTYSC35dXHSyyh 7iQy0w32Es7iQpXw09f8/IdXjxeBSOeDZ6fMLZH5GMt1rwaka3fMT3RzYR53ppEJP9aR JjUnnY6oR6axDghpcQTwH+CjS2boVEIq9rJvbj3jBuILcZ/VKvX9a9uAkZ6ZaQwbvrQp u6MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1TMAmfx/iFF1nFBFM7I4LDSQmO0B3V9NVlTDDK9e0OE=; b=JvVaHHPc693ffUPrZFTwGai0UAlskSriGt4YSSQIY0G1b0g9LsCXYneSRdrgyF1E1v K67Sm3wCtFz/W6Ucu6B7FuWBHfY1sKPypIkuNoxRAjIDcGu/HS2VM43HoEr0+zJ3/OtQ rBJEhBHBq93CNKRSgwjlDZbGkecIBSTcmSeMcu+KwVVG0oXun6KaPNTBOR98mLe/WPw5 DqIrDnMIkL7aE0LN1LPiZp8jpTIFlTkdkhqoEXtxC6tQVrlfk9biEKKB2SBd4BuM63RD +D555cNzI9ycAZnQzchpbFYjZqSjSgIFfVed2O1Ef2TjKG77vqvqwylwIBay8LRM7eaw Vg/A==
X-Gm-Message-State: AMke39k2dhL70drVXImHuHEnssXW3PJzPprSSNzNHyo//V++ihcmWjA5e9JVxytvI5Rnim/b3M4xRt9esaD9SK32VNInkqC5aooKfnJvdKpg8WbHWYj15AJoiD8us4PwVVm3v5dM4rr1pIzmVSE=
X-Received: by 10.31.114.133 with SMTP id n127mr632583vkc.129.1487924411323; Fri, 24 Feb 2017 00:20:11 -0800 (PST)
X-Received: by 10.31.114.133 with SMTP id n127mr632570vkc.129.1487924410984; Fri, 24 Feb 2017 00:20:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.71 with HTTP; Fri, 24 Feb 2017 00:20:09 -0800 (PST)
In-Reply-To: <A0EDE3AA-95AA-418B-A2B3-E9C8A74204A5@darou.fr>
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> <A0EDE3AA-95AA-418B-A2B3-E9C8A74204A5@darou.fr>
From: David Farmer <farmer@umn.edu>
Date: Fri, 24 Feb 2017 02:20:09 -0600
Message-ID: <CAN-Dau3shR-f9hA0Thnv7caRKQieiaqnA-4MweDikWk4kBqiUg@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Pierre Pfister <pierre.pfister@darou.fr>
Content-Type: multipart/alternative; boundary="94eb2c1497b4f87bbc0549426585"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EtJwXdxluNBsru8Oc32E4-eyl_g>
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 08:27:16 -0000

On Fri, Feb 24, 2017 at 1:53 AM, Pierre Pfister <pierre.pfister@darou.fr>
wrote:

> 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>
> 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.
>

I believe most implementations of SLAAC require /64, but I could be wrong.

> 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.
>

I'm willing to let that go too, but it was there so I left it for now.


> 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.
>

Most routers let you specify any subnet length you want they default to /64
usually.  Also, many host OSes when you manually config let you specify any
subnet length too.  By making it OPTIONAL, I'm saying it ok to do that, or
not if the you don't want too.


> - 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.
>
>


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================