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 07:15 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 16C9F1295B8 for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 23:15:54 -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 8oP-X1zbKVJW for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 23:15:52 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 3026C1295BA for <ipv6@ietf.org>; Thu, 23 Feb 2017 23:15:51 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 7389AC64 for <ipv6@ietf.org>; Fri, 24 Feb 2017 07:15:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqiMRivEB52x for <ipv6@ietf.org>; Fri, 24 Feb 2017 01:15:50 -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-p8.oit.umn.edu (Postfix) with ESMTPS id 324B2BD6 for <ipv6@ietf.org>; Fri, 24 Feb 2017 01:15:50 -0600 (CST)
Received: by mail-vk0-f72.google.com with SMTP id x75so7758200vke.5 for <ipv6@ietf.org>; Thu, 23 Feb 2017 23:15:50 -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=QXiRWZU3C+aKDj3v20Tqd4EFZX1NoiGKtjGwBulchH0=; b=kfy2xG3fuzf6wtlftCram9l5YT22dQXpsZaoWnXU8hHXsAinuLhHiILFOEojtKz+ag JC9Sh9LHAM2D2E+Y7lw+8Xj8e3dHxj5QvEW45dKrQ/9b+uKIbUHQz7egCSNmjAUEmJ3h PFhfSfwNpwHh7bQ1eul7W8n2UQPZ/5B6Vv7kClQ4Gcl/d+8dIc2yhJ2Q9VbZihpnPsAs HfBasZ5fdCIxTIIA06OWSBk07v+CzxDXNV7IHboZEZYI1ZjBw3NK/CHLjiIrNoQguwN+ zYwyltBhDjfK1F1GxOzBMl4Y9e6bT4dMdUSLAhM3KYTSSIvmTiVwNCLsFwu1UA/EpQ7W ymNQ==
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=QXiRWZU3C+aKDj3v20Tqd4EFZX1NoiGKtjGwBulchH0=; b=Hi/A/FHx8LD9/V0KsiBDg/qUTB34vTlYd5tMpBhsy1Q3otgSqKXXQz7dnZ51aHiZVL CSKgyzwx51cOGqp+OE4hR0TwzSWBLu52d2NYT5uvoX0EEbukKZynlZ9WVwBKIT4Yh83x bAtxLHrI0Gqe23Ric99qBJddepwLkUJeanm/aiZxZmh3YyRohV7tYrFiitrFPMCkhxat i8bJPsN/jU32I+uk52HKOuhdVpS/M8WZMMgeUK0mClrXcwmRJfi2VW0MRlPERlHrJ0bt o/SijCcJrDnxQJJkMYiOJeSnw1E9qd5+yUQA3IFh/fp9KFFv2AoWTMPetdFbK7D/OQwS EKwg==
X-Gm-Message-State: AMke39lEk0Di9eMdn2poPgK8EUcCiWzFmjn3+UKCCNLa51NAo2KdhQklJsUam9V+4DZy64U59LIRDKicidK+DMBFcLuZhMPDNoA3+LyuS8gYJGa7Obe9I50G9Za+Hsas/9r8xcDspR8EeAvpofw=
X-Received: by 10.31.252.77 with SMTP id a74mr520186vki.46.1487920549587; Thu, 23 Feb 2017 23:15:49 -0800 (PST)
X-Received: by 10.31.252.77 with SMTP id a74mr520179vki.46.1487920549349; Thu, 23 Feb 2017 23:15:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.71 with HTTP; Thu, 23 Feb 2017 23:15:48 -0800 (PST)
In-Reply-To: <cf3496dc-47c6-6c6b-a42a-e0402789110a@si6networks.com>
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>
From: David Farmer <farmer@umn.edu>
Date: Fri, 24 Feb 2017 01:15:48 -0600
Message-ID: <CAN-Dau3bHXOaJGe1UaLdDht9=+WiD4SEu8qw9Sc915tOes5seA@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=94eb2c149b28cc6b950549417f36
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JRoAQ6Pt19fBT6xYI03BXB_j2Zw>
Cc: 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org, draft-ietf-6man-rfc4291bis@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:15:54 -0000

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

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

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
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================