Re: Updated IID length text

otroan@employees.org Fri, 20 January 2017 18:33 UTC

Return-Path: <otroan@employees.org>
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 A162A129C52 for <ipv6@ietfa.amsl.com>; Fri, 20 Jan 2017 10:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.335
X-Spam-Level:
X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 fwb-fxy5t9VP for <ipv6@ietfa.amsl.com>; Fri, 20 Jan 2017 10:33:20 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A46A1129C48 for <ipv6@ietf.org>; Fri, 20 Jan 2017 10:33:20 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 19 Jan 2017 22:09:12 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 41124D789B; Thu, 19 Jan 2017 14:09:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=+NOEZLVG+/pB9qrWPkaxpYTgW20=; b=qDlkjIbmGhv9UsyTcl IaZJOs4WioldQQhZCYWLG5yZpy7jgSM16D60XoiAC3nuLkdWjEH4yAUpQqowfJm0 +YMV7IKX5ELqT8z9Sm8LfFB2QYgg4AxMhyJSZ9vj/IujQk2+653W3Iw8GPFteH6l 2yPa6VSUcQXury4A4PiE3z/3E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=mefTrQTdPnAKws2uDA4loXondTuCbYqdf8JUVgnkwyo9NflVCFA u61Wqp3HLariCWDTLoSSiWlcHbZM9X1H1E5AGTXNmnfHWs0TErIeaZeTJ9p9afAB vN1NMD4O2lNPAe0PdiCEG1MObzjE2+ijJOyFEgkNvo7ZxkDyHq6hl+mA=
Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B8965D788F; Thu, 19 Jan 2017 14:07:27 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6A99478BB120; Thu, 19 Jan 2017 23:07:25 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Updated IID length text
From: otroan@employees.org
In-Reply-To: <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com>
Date: Thu, 19 Jan 2017 23:07:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D349D202-4AEE-474E-8F19-3B826B4EF0F0@employees.org>
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> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com>
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/W11MOazsOjfYa23ThrwiUGK0Ntg>
Cc: 6man WG <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 18:33:21 -0000

>>> 
>>> NEW NEW
>>>  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, 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, 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.
>> Background
>>>  on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
>> 
>> By changing "For all unicast addresses" to "all currently allocated unicast
>> addresses",
>> 
>> Are you proposing to reverse the decision that was made back when RFC3513
>> updated RFC2373?
>> Change log:
>> -  Revised sections 2.4 and 2.5.6
>> to simplify and clarify how
>>      different address types  are identified.  This was done to insure
>>      that implementations do not build in any knowledge about global
>>      unicast format prefixes.  Changes include:
>>         o  Removed Format Prefix (FP) terminology
>>         o  Revised list of address types to only include exceptions to
>>            global unicast and a singe entry that identifies everything
>>            else as Global Unicast.
> 
> Not speaking for Brian, my reaction to the RFC 3513 text would be that Brian's new text better responds to "This was done to insure that implementations do not build in any knowledge about global unicast format prefixes."
> 
> We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which has existed for too many years.

I asked the clarification because RFC2373 did use the format prefix, where only 2000::/3 was the Global Unicast prefix.
That was changed to making the whole remaining address global unicast; the worry was that this would make implementations treat different 1/8ths differently (and therefore classful).

I wanted to know if the intention of Brian's suggested text was to reverse that?

Ole