Re: Updated IID length text

David Farmer <farmer@umn.edu> Fri, 20 January 2017 07:31 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 CBD1E129A4E for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 23:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 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=-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=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 xsjZp3541I9H for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 23:31:18 -0800 (PST)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 2173B129A56 for <ipv6@ietf.org>; Thu, 19 Jan 2017 23:31:18 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 9F55C5C0 for <ipv6@ietf.org>; Fri, 20 Jan 2017 07:31:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8iFa9Akkn-F for <ipv6@ietf.org>; Fri, 20 Jan 2017 01:31:17 -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-p6.oit.umn.edu (Postfix) with ESMTPS id 5E751A97 for <ipv6@ietf.org>; Fri, 20 Jan 2017 01:31:17 -0600 (CST)
Received: by mail-vk0-f72.google.com with SMTP id t8so38907767vke.3 for <ipv6@ietf.org>; Thu, 19 Jan 2017 23:31:17 -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=qJYvSwA+MrxL2+rVDIyqXm/nUhkFuy3OSyWxrrT58ek=; b=O+YbRzx/p2qUg2b8iK4h8RXXFpkUP4weO2CiCBouDL05LQSK+qMtw5pFCQQ4b7y//j X+47EnMFI/o8d3veccnb3zDBDZcpOpUFVst8qsv7A9uvIGwa1DrJOE0a1aKi+q5suExD E8mjFjiUyLYer0BNzlYDDfnhu5g6rKizq6E2Eis9FAub5hnPRtAtopPLi5Vt0WgcZGAv XlIt7mk93pFq4RQv5l+wkvCTZif5/E67RFQ+YGz3WTGR4yvzaKLzPbMiM7vmtUoXnR2j sJj0M7d+JgwS1xebXYLmPt0KFIy8rla2zhVLiGI5SX5g4/r6AhkiifiXKKbpY4Bqfn7p An5Q==
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=qJYvSwA+MrxL2+rVDIyqXm/nUhkFuy3OSyWxrrT58ek=; b=qMqrN/OtU9k5NLqLUJrVno+MYpbC30+QZwltR1q8iVHGUI5xODAyt42RkoemqvZQoH UoSgl75wRoRbFQTcY0VEY+dz3sBDgHnWUkH1CFkDsWlaqcYYXvvvlzhHjI5OH8dQfjEk FxrFYR9w84dNqazgYLYVOJ4iHt/sReZj+PqR3DrQJGE+RuHtXFsM0fK/eokYNQ23HO2d uAQpVWK6dfFVomFBfLXsv6LBeUq4Y+T7DubgIc8tjTrNsvFwd6GWTWt/xTa0y+S2YEEx 6HofvxSV05Mp74u0yo6mnXjfOHT2Y04YyZ1a6OeMVXohabfhC9zIWswk9BxhFgkJVDku ev0Q==
X-Gm-Message-State: AIkVDXIBP1LPyE9inxP+8jUQFM7zAHzioUe9uIo6KC7HESVLy6UhQIimVewpVIN6fo+BB6uNFJY+bTdap9FOqapxTRaHUXrIDnKY/XPNYNGrfhXmRxkvdBtah1gIE3z0xlnWVSodldl6i5QsFzE=
X-Received: by 10.31.236.7 with SMTP id k7mr6710719vkh.96.1484897476738; Thu, 19 Jan 2017 23:31:16 -0800 (PST)
X-Received: by 10.31.236.7 with SMTP id k7mr6710707vkh.96.1484897476463; Thu, 19 Jan 2017 23:31:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.84.15 with HTTP; Thu, 19 Jan 2017 23:31:15 -0800 (PST)
In-Reply-To: <CAKD1Yr0_NBX6HZoDJifzYDmPqEiXpO+M2t6cxsJWhG+Ay1a+Qw@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> <CAKD1Yr0_NBX6HZoDJifzYDmPqEiXpO+M2t6cxsJWhG+Ay1a+Qw@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Fri, 20 Jan 2017 01:31:15 -0600
Message-ID: <CAN-Dau1bckN4XShgAPc=cX0At1rn3s=Q9BSTeF-cdpTBD_UfbA@mail.gmail.com>
Subject: Re: Updated IID length text
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary=94eb2c09617c9cf679054681a2a7
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/99wrW2VopepGt4xWsUzJsHpR34w>
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 07:31:22 -0000

I think the reference to RFC6164 need to be included within the exception
to the 64 bit requirement, something like the following;

IPv6 routing is based on prefixes of any length up to 128 [BCP198]. However,
the Interface ID of all currently allocated unicast addresses, except those
that start with the binary value 000 or when use to address point-to-point
link [RFC6164], is required to be 64 bits long. The rationale for the 64
bit
boundary in IPv6 addresses can be found in [RFC7421].

This is still a false imperative, but at least it is consistent with the
intent of RFC6164.


On Thu, Jan 19, 2017 at 11:55 PM, Lorenzo Colitti <lorenzo@google.com>
wrote:

> 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 <(612)%20626-0815>
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
>> ===============================================
>>
>
>


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