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

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Tue, 13 June 2017 02:22 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 B0AA2129480 for <ipv6@ietfa.amsl.com>; Mon, 12 Jun 2017 19:22:14 -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 rPeoqTxofCo4 for <ipv6@ietfa.amsl.com>; Mon, 12 Jun 2017 19:22:13 -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 021E5128D3E for <ipv6@ietf.org>; Mon, 12 Jun 2017 19:22:12 -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 v5D2MBYe059652; Mon, 12 Jun 2017 19:22:12 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5D2M6eN059548 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 12 Jun 2017 19:22:06 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 19:22:05 -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; Mon, 12 Jun 2017 19:22:05 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: draft-bourbaki-6man-classless-ipv6-00
Thread-Topic: draft-bourbaki-6man-classless-ipv6-00
Thread-Index: AQHS4kKOngy9O72egk+O0dQc6kfgF6IexPVggACVDgCAARhCgIAAbSKAgAGcDQD//5E4sA==
Date: Tue, 13 Jun 2017 02:22:04 +0000
Message-ID: <f2ac9e0a467b4015a0a78d549c0fbbf0@XCH15-06-11.nw.nos.boeing.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170604093119.nt733rb3ymmjssww@Vurt.local> <m1dHTLx-0000DcC@stereo.hq.phicoh.net> <CAKD1Yr0ZZwRar6D-2bkXBKPYehqqW99+BMtDOjyovR8WDXKzxw@mail.gmail.com> <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> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <6e03e25e-fd6a-6311-390e-4834281a76f7@si6networks.com> <1B580CBB-B29D-4860-9EC8-BECD1D5E0006@employees.org> <4b2f5200-86a1-7711-e5ff-7436572be467@gmail.com> <E02C4C99-155A-4358-A845-F00F8BB071C1@employees.org> <b3ca5271-21b1-ab33-2dff-82735ebe9128@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <FA3032F9-F44B-45B4-9AFF-01EBC84F1448@employees.org> <b1c5c13d-ef69-ef30-546c-9178a2655caf@si6networks.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com>
In-Reply-To: <391c730c-fa75-7596-bb6b-383ea6583131@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="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/blWTN4q8MXt304WPkEzddec4sxs>
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: Tue, 13 Jun 2017 02:22:15 -0000

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter

>> there's no reason why the IID should be link-type dependent.
>
> I believe that is simply false unless you want to go back to the
> era of DIP switches with instructions to users to
> a) choose an IID length for their new subnet
> b) set the DIP switches on every device to select that length
> c) then plug and play.
>
> Otherwise LL addresses cannot be formed consistently on the
> whole link.

Why so, Brian? I've already described one easy technique: the host can create IIDs of any length, based on an algorithm that we might just be debating for a long time, but fundamentally can be quite straightforward. And then the host chooses the correct IID to use for SLAAC, based on the RA it just received.

> OK, that is caricature, but without a substantial reworking of
> RFC4862 I believe that is essentially what we would need, in
> an automated version, before SLAAC can start.

1. Host can create, in real time, IIDs of length 128 to 0 bits. To do this, for SLAAC, it SHOULD not be difficult IMO. One possibility: create random 128-bit value, then use a simple truncation algorithm to reduce the number of bits to the required value, at the appropriate time.

2. Host waits for RA.

3. Host determines prefix length after receiving RA, using the equation:

IID length = 128 - prefix length

4. Host generates 128-bit SLAAC address. If we started with the 128-bit random number, just truncate as needed.

5. Perform DAD, as already prescribed.

> Anway, all this is empty talk as long as the addressing
> architecture *requires* 64 bits rather than *recommending* 64
> bits.

True, but anything that *requires* something, based on a premise that has all but been discarded, doesn't hold much credibility anymore. The fallout from having deprecated that premise needs to be considered. A better future can result, as in this case (IMO). I think there's something in philosophy that addresses just this sort of situation. Where the general consensus of an argument can change 180 degrees, if more information on the underlying premises is presented.

Bert