RE: Updated IID length text

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Thu, 19 January 2017 21:02 UTC

Return-Path: <albert.e.manfredi@boeing.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 AD61312957E for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 13:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AyalV63TVkfC for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 13:02:50 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 153CC12956C for <ipv6@ietf.org>; Thu, 19 Jan 2017 13:02:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v0JL2nUA045662; Thu, 19 Jan 2017 14:02:49 -0700
Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0JL2fvw045619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 19 Jan 2017 14:02:41 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 19 Jan 2017 13:02:40 -0800
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Thu, 19 Jan 2017 13:02:41 -0800
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: "otroan@employees.org" <otroan@employees.org>
Subject: RE: Updated IID length text
Thread-Topic: Updated IID length text
Thread-Index: AQHScowEqB5Tp7XZTkyunKSq9IrHHaFAy66A//98lQA=
Date: Thu, 19 Jan 2017 21:02:40 +0000
Message-ID: <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.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> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org>
In-Reply-To: <54AD315E-301D-4052-9F0F-5E085C026094@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QYfxr-Drnu_1aIt-CK475d3Gk_E>
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: Thu, 19 Jan 2017 21:02:51 -0000

> -----Original Message-----
> From: otroan@employees.org [mailto:otroan@employees.org]
> 
> Brian,
> 
> [...]
> 
> > 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.

Bert