Re: Updated IID length text

Lorenzo Colitti <lorenzo@google.com> Fri, 20 January 2017 05:55 UTC

Return-Path: <lorenzo@google.com>
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 25F56129961 for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 21:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 wx77MDHU4s-6 for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 21:55:45 -0800 (PST)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB6512995B for <ipv6@ietf.org>; Thu, 19 Jan 2017 21:55:45 -0800 (PST)
Received: by mail-vk0-x22f.google.com with SMTP id k127so45338363vke.0 for <ipv6@ietf.org>; Thu, 19 Jan 2017 21:55:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VV70ZzCcHJw9nuJM8wCKsQoSytWDiEIEXz7FHWB72Nc=; b=KSAc37TPme8ipjstn0iD4ZwCPT2KPhBBDAtzWGFB9KY/GIB+GiivmCF3/1/fZawfXm zLKXxiixCGMr7RCh1eP5P98mRMAiRFOYDk/nUwkCpn9Z1WToE1rPONvv5P0A9Awh0Zu9 jtgBqJtbTpr42nlW49SrlRgFVDIRAtiBSgndFEm99ipfv00TI4TxQXq+X9mM56ZyzXZW UfMnvdvs+L4VgHlr4b/tgywDEmdWzH5ASn8Fm85Tr+KwFeIkuJjfyUDc7t15tKTbA7WG V0exuEo+n4A0vuQMgonLT4A3yIVJqDsnNcLt37ci9mdWXrW9tBkeTxb6TukCoVfdVVcp fqFA==
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=VV70ZzCcHJw9nuJM8wCKsQoSytWDiEIEXz7FHWB72Nc=; b=dKUBUfpXOCBakkvkMPk3gJ7mouI0TxZ8bv30eJaVEZ0f6EE3FptVxuli/8FCttrcf4 1guowTIL/+aIQDZDGqt5zUDe8wkZbujhRPGyDSqjjtobKAVUOVgJI3Dg+n+ngiOcNSGJ PSPTaFyhvRervP6s0gu7J3vuQI6laFg4N23zhi+nbDK+OmHyjnxeRrvQ1d/XzaM2rVKc a4r8a5RZ3bs2fYIfsCFe7er3UX6hI5SfLRQ51xXKWY/g9bDrTeJsUF7z/vyrkcoFJ1oO HpGRY0hYGIIAbUF1FqwWTQL5y+/FINsuE56nbjOyKHKCtGTKhEgkIpnidIK/dFfOTnx6 jUtw==
X-Gm-Message-State: AIkVDXKtmwqkHx8fRepyVjBMHioay7aupjBOHVy74ggmgYslVi6t0y9feVa746+ML0sOLIToD49767E9DQqWSWwH
X-Received: by 10.31.192.204 with SMTP id q195mr6327521vkf.155.1484891744062; Thu, 19 Jan 2017 21:55:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 21:55:23 -0800 (PST)
In-Reply-To: <CAN-Dau0X2MYxOADLdaVcangeJrHo98t=buh1J2uCpEQAs93GDQ@mail.gmail.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <F6953234-3F85-4E28-9861-433ADD01A490@gmail.com> <m2wpdzhncn.wl-randy@psg.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <m2d1frhjfn.wl-randy@psg.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <CAKD1Yr1cvZ8Y3+bHeML=Xwqr+YgDspZGnZi=jqQj4qe2kMc4zw@mail.gmail.com> <m2lguffnco.wl-randy@psg.com> <CAKD1Yr1TrTiPRdyutobmb_77XJ7guNzLrg=H_p7qi4BfQ8V=GA@mail.gmail.com> <m2d1frfm6m.wl-randy@psg.com> <CAKD1Yr2Njjd8_Mr+6TRFF6C5pdcX4yFgpFVyEkykDuytu2B8mg@mail.gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <CAN-Dau06R3iYRpYLADhvHox4C9qdsJCuxFsJapRhOQcWT4qk_g@mail.gmail.com> <CAO42Z2weZcoHiBzN94QAQ9WGhWR16PmMMFNg=5YLmr_dhPjjpA@mail.gmail.com> <fcc7f136-b5da-527e-b495-5a2d7f7a3ce8@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <bb79ce41f2cc465dab0a7f26466be26f@XCH15-06-11.nw.nos.boeing.com> <ed9fe2df-0dce-0ddc-bdee-561217d089bb@gmail.com> <e8b4d426-55b4-bd2e-ea4f-f8e56e831d44@gmail.com> <CAKD1Yr1no52iZ2NwfKse6tXi0QpOP+Qe-vU68M4g1ZhmsgQadg@mail.gmail.com> <CAN-Dau0X2MYxOADLdaVcangeJrHo98t=buh1J2uCpEQAs93GDQ@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 20 Jan 2017 14:55:23 +0900
Message-ID: <CAKD1Yr0_NBX6HZoDJifzYDmPqEiXpO+M2t6cxsJWhG+Ay1a+Qw@mail.gmail.com>
Subject: Re: Updated IID length text
To: David Farmer <farmer@umn.edu>
Content-Type: multipart/alternative; boundary=001a114388ccef98000546804c40
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/d_BnjCcrKNDAfKwSdiDawlCLVss>
Cc: 6man <ipv6@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, 20 Jan 2017 05:55:47 -0000

As Brian says, we can't change the normative effect in the context of
promoting the document to full standard.

As for making room for exceptions: isn't it a given that any standards
track document can update RFC 4291? (Assuming 6man has either reviewed and
gotten consensus on it, or not requested to review it)

On Fri, Jan 20, 2017 at 2:25 PM, David Farmer <farmer@umn.edu> wrote:

>
>
> On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colitti <lorenzo@google.com>
> wrote:
>
>> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <
>> brian.e.carpenter@gmail.com> wrote:
>>
>>> However, correct use of Stateless Address Autoconfiguration
>>>    (SLAAC)[RFC4862] requires all interfaces on a link to use the same
>>> length
>>>    of Interface ID. Furthermore, to guarantee robust interoperability of
>>> SLAAC,
>>>    a consistent length of Interface ID is desirable. For this reason,
>>
>>
>> I object to the text "for this reason", because SLAAC is not the only
>> reason. There are many reasons, many of which are written in 7421, and two
>> sentences in this paragraph are not sufficient to describe them. I propose
>> the following alternative, which I believe to be normatively identical:
>>
>>    IPv6 routing is based on prefixes of any valid length up to 128
>> [BCP198].
>>    For example, [RFC6164] standardises 127 bit prefixes on point-to-point
>>    links. However, the Interface ID of all currently allocated 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].
>>
>> Cheers,
>> Lorenzo
>>
>
> How should that be interpreted? Do my Point-to-Point links need addresses
> that begin with binary 000? How do I get an allocation of those?  Because
> it says I must use a 64 bit IID with the Global Unicast Allocation that I
> got from ARIN.
>
> Here is another problem, RFC 6164 probably should have updated 4291 for
> that reason.  And if there are any future exceptions should update 4291bis,
> for similar reasons.
>
> There are lots of good reasons to use 64 bit IIDs almost everywhere, but
> there are exceptions.  However this text doesn't leave room for any
> exceptions, even the one that it cites.
>
> Again keeping "required" I believe is a false imperative.  If we can't fix
> that by going to "should", can we at least make room for official standards
> track exceptions, like the one cited and any future ones we agree on?
>
> 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
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>