Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

Tim Chown <> Tue, 17 January 2017 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56100129470 for <>; Tue, 17 Jan 2017 06:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zpF3gphkSJbW for <>; Tue, 17 Jan 2017 06:58:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0134512942F for <>; Tue, 17 Jan 2017 06:58:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x3PfUSewppc/5sQ2IegEiJT8T/7jJegt2i1I6BcAqb4=; b=Q2r3fwrC5FENGafHgABS6f0VVf+srdjfxERhmRQEqjehbyRiNu4gK8L99maFXdrnRcR9iaLgz8d8PTqwHqAvxyvGWBd9wVmr74v2DqgQyoEqQHgY7J223TgLefh01OKMIqMQr8ZXT7iS2wDo+MfQXbMLexWpzhlrpi9zajItTdI=
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-26-K4SXe8myMu-WM9QK8gItyA-1; Tue, 17 Jan 2017 14:57:55 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 14:57:54 +0000
Received: from ([fe80::5989:a034:d099:8480]) by ([fe80::5989:a034:d099:8480%15]) with mapi id 15.01.0860.008; Tue, 17 Jan 2017 14:57:54 +0000
From: Tim Chown <>
To: David Farmer <>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
Thread-Topic: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
Date: Tue, 17 Jan 2017 14:57:54 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: cc25a759-dd43-4959-c952-08d43ee93764
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1140;
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:QIzyrp+ACEn/2dk2zl9renbAAKHTBPjQqIJAfWRZaM63mzPNwnwgkSWhsRNYHLVhYYVEy1sY3PsxDlpaovD+Q9o68CY6fvwgiu+8bgONcVPy/mU2c/JM5nPwwAWkdx36lqEjNvaiM32mk+dVmAfAo+FxLBUeW7vx/PRTkYL0oMPjsDqzgxl/cSbCzFcbc48RY2dLM3k3UYJ4cYT/zFMN9F48HJiV3Zc/UeT0jlMg94Pu7zwXFz9d40gJHQY0as1kl5Qtqmu5xu6ZHvcQ+prWqJUYVJ/lB5jrW2iSyCdM83548wWxjdrEDjFQCAX1J6zXumM4mHT/Ft54KNpuKaPkP6xt8MfaWS7oIuAVp1zA0ciO7oqmsOeUYCxgMJkPPEbo/owVpq3S63qh5j/ec5bZkOt2yw0lE8WoxDGYUNVwovrIzH/Jb3ejoiS+ivmLm1YPSYuVBfU6DKMwpwbCzu/CrQ==; 20:cREVtqZCIzImAEk834KZ0tBCeUvGikKmwTgL5UizErZusyBS5tpr0vLb+ekfI76HXzbicM3lwVX67EN2l5QK0epT5WU4a3XmlDizJgv0XMyXatzwu7nITNjM3ceN6Arp0erM3jAFl5UJSeJ7ri8v3soFdU1Vkxo3u9tkjioFjWY=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(20558992708506)(8104003914727);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140;
x-forefront-prvs: 01901B3451
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(24454002)(86362001)(8936002)(8676002)(83716003)(81166006)(74482002)(81156014)(68736007)(6306002)(99286003)(54896002)(54906002)(2171001)(3280700002)(50226002)(33656002)(2906002)(6436002)(6506006)(2900100001)(6116002)(6486002)(229853002)(3846002)(102836003)(4326007)(38730400001)(36756003)(5250100002)(106356001)(106116001)(230783001)(92566002)(5660300001)(82746002)(7736002)(105586002)(93886004)(189998001)(66066001)(76176999)(110136003)(6916009)(50986999)(236005)(3660700001)(101416001)(42882006)(6512007)(97736004)(30001)(57306001)(2950100002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 14:57:54.2642 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140
X-MC-Unique: K4SXe8myMu-WM9QK8gItyA-1
Content-Type: multipart/alternative; boundary="_000_7024EF45953E4C5B90698B61B7AADCD1jiscacuk_"
Archived-At: <>
Cc: Erik Kline <>, 6man WG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jan 2017 14:58:05 -0000


On 17 Jan 2017, at 14:30, David Farmer <<>> wrote:

On Tue, Jan 17, 2017 at 4:00 AM, <<>> wrote:
> What breaks if all IIDs in global unicast are not 64 bits?  Especially other than SLACC?  I would hope such a REQUIREMENT has a better motivation that "we said so".  Citing the "rest of the specifications" was simply my shorthand for I don't see what else breaks.

RFC7421, section 4.2.

There's also a set of political considerations, where one tries to achieve balance between the provider's desire to have effective aggregation and the end-users desire to have enough address space. We specifically want to avoid provider's charging by the address.


Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it does not say to me "IIDs MUST be 64 bits", this is a subtle but important difference.  Furthermore, RFC7421, section 4.3.2, also say there is operational use of IID other than 64 bits, which to me disproves the statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 bits.”

Well, when we wrote that document, the aim was to highlight the problems you may encounter if you did go off piste in terms of IID length.  It’s just an informational document, so those “SHOULDs” are purely implicit.

Section 4.3.2 is purely noting comments made on the 6man list during discussion of the Why /64 draft about some rather rare deployments in the wild.  We specifically asked, iirc, about known non /64 host-based subnetting, and this section reports on the responses.

So lets be clear, I'm not saying that we should RECOMMEND other than 64 bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC 2119.

So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to the in my opinion the more proper "IIDs SHOULD be 64 bits".

So, I would prefer:

  ...  For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length should be 64 bits.

But, I'm willing to live with what Brian proposed:

   ... For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is 64 bits.

This seems fine.


But, I can not accept what Eric proposed:

   ...  For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is required to be 64 bits.

David Farmer     <>
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
IETF IPv6 working group mailing list<>
Administrative Requests: