IETF Logo Mail Archive

RE: draft-bourbaki-6man-classless-ipv6-00

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Fri, 09 June 2017 19:30 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 4933012944A for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 12:30:58 -0700 (PDT)
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 PzJJ1D4zETl2 for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 12:30:56 -0700 (PDT)
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 CD740128ACA for <ipv6@ietf.org>; Fri, 9 Jun 2017 12:30:56 -0700 (PDT)
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 v59JUuSH038172; Fri, 9 Jun 2017 12:30:56 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v59JUnUC038114 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 9 Jun 2017 12:30:50 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Jun 2017 12:30:49 -0700
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.1263.000; Fri, 9 Jun 2017 12:30:49 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: David Farmer <farmer@umn.edu>, Fernando Gont <fgont@si6networks.com>
CC: Job Snijders <job@instituut.net>, Erik Kline <ek@google.com>, 6man WG <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
Subject: RE: draft-bourbaki-6man-classless-ipv6-00
Thread-Topic: draft-bourbaki-6man-classless-ipv6-00
Thread-Index: AQHS4Ng5/DxYTgHcokuMXsgWu2kKXaIciQIAgACE74CAAAUqAIAAMrCA//+Xg3A=
Date: Fri, 09 Jun 2017 19:30:49 +0000
Message-ID: <d4997fdca7714841b1efde137d980586@XCH15-06-11.nw.nos.boeing.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <CAD6AjGTjikAWutcenW8qn7OW8kPM9c_x_yDUy5vQxJmXKL85dg@mail.gmail.com> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <CAKD1Yr0_WR_TB+OC0U1Qt2h6WzUp9EGvrqC1ZKW2mwFeBd3bCQ@mail.gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <CAAedzxppjnBhVAHF4L4B7WTtwxPGhpOv8ruXOhm=zGwjQ5-OsA@mail.gmail.com> <780257e6-749e-ad9b-4d7a-08e39f46fd1c@gmail.com> <89A69730-B9F3-49B4-942D-EB664A728BDD@employees.org> <dc950594-cb1a-3c36-4538-3b62f58806ed@gmail.com> <CACWOCC93jbqhw+Pigjx5CdHcAmubcx=nQLbOOtjOb81+u6MQow@mail.gmail.com> <CAJE_bqdcR+-6AxODiokcSRhRNb-5gcbRx0xwBqQ8AeOqYd2Daw@mail.gmail.com> <CAN-Dau08sssc6WnfYL0+7pvC_R5gAdQZu2bKxTyFWcSm0xFh=A@mail.gmail.com> <CAKD1Yr2pxzCb_99UA5aR202OE8hMxc_vSwy5TohzSB2etG-Ftg@mail.gmail.com> <143f152c-1854-9402-4390-37782c6a7c3a@si6networks.com> <CAKD1Yr3uEx3oY2RF6617cYufUMEehjdqXtVf5yf6kD_otVgLEA@mail.gmail.com> <CAN-Dau1zv7q3qcN=gHi2dxnbFZKW3az6+juWi0W=cTevpcFUCA@mail.gmail.com> <a1b918b6-9219-03c1-aec6-2020a7aac2e4@si6networks.com> <CAN-Dau0kDhsRDVjCX=znSKDfT5-NrQ42DOHMchBw+fG2QRXfhw@mail.gmail.com>
In-Reply-To: <CAN-Dau0kDhsRDVjCX=znSKDfT5-NrQ42DOHMchBw+fG2QRXfhw@mail.gmail.com>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rDOXcMOeYgn-nmv0aDzmlhlNlYM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Jun 2017 19:30:58 -0000

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer

>> I don't see anything in BCP204 where /64 is a MUST or even RECOMMENDED.
>
> It's not in the normative language, but it is part of the RFCs
> recommendations section, see below.

> Second paragraph, second and third sentences of section 8;

   This can be achieved either by allowing the host
   to form new addresses autonomously (e.g., via SLAAC) or by providing
   the host with a dedicated /64 prefix.  The prefix MAY be provided
   using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

I keep reading less into this supposedly mandatory 64-bit boundary than some others seem to, especially for the future.

RFC 2464 (IPv6 over Ethernet) is short, sweet, and due for a -bis version. The rationale for 64-bit IIDs is simply obsolete. Use of EUI-64 has been deprecated.

   The Interface Identifier [AARCH] for an Ethernet interface is based
   on the EUI-64 identifier [EUI64] derived from the interface's built-
   in 48-bit IEEE 802 address.

I see a lot of "64-bit IIDs mandatory" hinging on this one sentence, and its premise no longer holds. At the very least, 48-bit IIDs should be feasible over Ethernet, and you'd lose no randomness, compared with EUI-64. If not many other possibilities.

And RFC 4862 (SLAAC) is quite agnostic on this matter, requiring use of a link local address IID and RA-supplied prefix, and the total number of bits must <= 128.

   3.  If the length of the interface identifier is N bits, the right-
       most N bits of the address are replaced by the interface
       identifier.

   If the sum of the link-local prefix length and N is larger than 128,
   autoconfiguration fails and manual configuration is required.

So what's left? How LLAs are formed. LLAs are formed using a well-known prefix and EUI-64. Same old story, LLAs also hinge on an obsolescent RFC 2464. This can all change, with RFC 2464-bis. RFC 4862 wouldn't even need to change, if an RFC 2464-bis were to redefine how IPv6-over-Ethernet IIDs are formed.

Every inflexible supposed "rule" about 64-bit IIDs seems to hinge on an obsolete notion, which can, should, and probably will be revised in due course. In my view, we should be allowing for an easy transition after RFC 2464-bis, with this new draft, instead of cementing this 64-bit boundary.

Bert

v2.23.0 | Report a Bug | By Email