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

David Farmer <farmer@umn.edu> Fri, 17 February 2017 17:41 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 D8899129648 for <ipv6@ietfa.amsl.com>; Fri, 17 Feb 2017 09:41:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Level:
X-Spam-Status: No, score=-3.8 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, URIBL_BLOCKED=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 uFiXaYTVHLrZ for <ipv6@ietfa.amsl.com>; Fri, 17 Feb 2017 09:41:43 -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 7717D1295D3 for <ipv6@ietf.org>; Fri, 17 Feb 2017 09:41:43 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 2B4DB9F1 for <ipv6@ietf.org>; Fri, 17 Feb 2017 17:32:46 +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 JXT6rlUFXDtH for <ipv6@ietf.org>; Fri, 17 Feb 2017 11:32:46 -0600 (CST)
Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (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 E79FB668 for <ipv6@ietf.org>; Fri, 17 Feb 2017 11:32:45 -0600 (CST)
Received: by mail-ua0-f199.google.com with SMTP id 92so15582691uad.1 for <ipv6@ietf.org>; Fri, 17 Feb 2017 09:32:45 -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=E2kWQ4ULLlDTLwTDqL+DY4G8htYdqFYvHS+KripBCuo=; b=jzxNw+ei/ICqbrAn0VSBuoBwl55NbiFGjyR0xCSVJWOY1UIpdRTqVOUZbC1vdu5ver x8+wsvxSttKKuEFYH9y2NtiA2PVq66W3AB8cxcw1YAKpsuO4aRJLwh+L+ttX2T4cEDcY v+4dZNMBCbFtb1VzBHGnyvhFUgtZdgvfr8eJf0I0liwcXtOgUBnjKoUkWzgnw/UyKJAt 28EUuZQr//LYAh9XdgSxAi4TO2xa0cEzUa3CCLfqRYkbQyTP8akFUobonECtOPCo9lKt 2xOFjdYqb0xtZYR1lzsu6ROYI0cXc5cLUz3Vqjs15dqcD7eq7jwNpow7QPVf5GBedkk5 eHag==
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=E2kWQ4ULLlDTLwTDqL+DY4G8htYdqFYvHS+KripBCuo=; b=e+I8vSHmMifRn8z72OVdYKq7lOD3+zWA23PnzOIbx/51Mv/x50FDp/4h4B9SGltLug FE0VIItGVZxEIaz6he2OeGCbkcI0UeJHP0jYj4L4lWU8kc+strJAwkk01XUJttOOsnrz 4FSrEjTspNflEj/LE4MWl3RpPqn+lUaJcKMu4knKRAN/xyksw6xn9kE25D8oh3YQPRl0 5mzTdEJHxPqlNVcisj3GOYjBurxw7JI/UDbhvMu/GymSUDoAyYjjYIQadeOxdJv5oSs2 HCI9HF1XS3UG7GpnKw4bURHC6f8fh/rhtIQoJosxHRR8VLuN0RkLDPhHQY1TAvE8fRjz LJBA==
X-Gm-Message-State: AMke39nYAixnC+9C2znApZEAWQyzQnuSwjCJ+iKb5GUoz+nx9rWiaAMYH10kokobYbFMNtgSVKXu5Y2Ps4mL204SXK6qeGp3PDxvc/yKNN0/ue1IaBjS7Hm38ahgSs1bapRfnh3IzHjC5c6u1vA=
X-Received: by 10.31.49.81 with SMTP id x78mr4498661vkx.82.1487352765368; Fri, 17 Feb 2017 09:32:45 -0800 (PST)
X-Received: by 10.31.49.81 with SMTP id x78mr4498653vkx.82.1487352765180; Fri, 17 Feb 2017 09:32:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.13 with HTTP; Fri, 17 Feb 2017 09:32:43 -0800 (PST)
In-Reply-To: <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org>
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org>
From: David Farmer <farmer@umn.edu>
Date: Fri, 17 Feb 2017 11:32:43 -0600
Message-ID: <CAN-Dau3gXG8O2Fx_rdBJD8cokKMDJFN7D_MDsmzORmpgDUfVPQ@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Ole Troan <otroan@employees.org>
Content-Type: multipart/alternative; boundary=001a114388b0397b690548bd4d9f
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FDe-Vgl9MSHFFEoL8MAJVIOt6N4>
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, 17 Feb 2017 17:41:45 -0000

I had an epiphany this morning and I have to jump back to Brian's proposed
text.

On Wed, Feb 15, 2017 at 3:34 PM, <otroan@employees.org>; wrote:
>
> >> Do you think this change is appropriate in the context of advancing
> 4291?
> >
> > I don't think I have suggested text that would lead to a single
> instruction in
> > running code being changed.
>
> CURRENT (RFC4291bis):
>
>    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]
>
> PROPOSED:
>
>     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
> unicast
>    addresses used for Stateless Address Autoconfiguration [RFC4862] is
> required
>    to be 64 bits long. The rationale for the 64 bit
>    boundary in IPv6 addresses can be found in [RFC7421]
>
>
> My reading of the proposed text, which certainly may be wrong, given that
> English is not my first language, is that it leaves the Interface-ID length
> of links _not_ using SLAAC undefined, i.e. not fixed at 64. Is there any
> other way to interpret this sentence?
>

I would add ", in all other cases it is recommended to be 64 bits long."


> The proposed text appears to make the Interface-ID length an operational
> choice.
> How is that _not_ changing the 64 bit boundary?
>

This has always been an operational choice.  You are mis-interrupting the
intent of the 64 bit boundary, you seem to be saying it intends to specify
the IID length for every interface on the Internet. If that was the intent,
then RA's would never have needed a prefix length, nor would you need to
specify a prefix length when manually configuring an interface.  If this
requirement intended to specify the IID length of every interface on the
Internet, then the requirement would have been sufficient by itself, we
would have been done at that point. However, the fact that RAs have prefix
lengths, and we specify a prefix length when manually configuring an
interface, belies the argument that this was not intended to be an
operational choice from the beginning.

So, for other than SLAAC, the 64 bit boundary has only ever been in
operational guidance, there are serious consequences to not following the
IETF's operational guidance in this regard, this is discussed in
[RFC7421].  However, it is an operational choice to follow that guidance or
not. Interpreting this requirement as ever taking away that operational
choice, shows this as a false imperative.

Best regards,
> Ole
>

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