RE: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis

"Manfredi, Albert E" <> Thu, 09 March 2017 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51F8F1296B1 for <>; Thu, 9 Mar 2017 11:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 98BBosBZe3tb for <>; Thu, 9 Mar 2017 11:28:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD3931293E1 for <>; Thu, 9 Mar 2017 11:28:51 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v29JSoOc051883; Thu, 9 Mar 2017 12:28:51 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v29JSmVV051875 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 9 Mar 2017 12:28:49 -0700
Received: from (2002:8988:efdc::8988:efdc) by (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 9 Mar 2017 11:28:48 -0800
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Thu, 9 Mar 2017 11:28:48 -0800
From: "Manfredi, Albert E" <>
To: Philip Homburg <>, "" <>
Subject: RE: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
Thread-Topic: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
Thread-Index: AQHSmMa1fYJCK+RzH0+zdQWkR+y1LqGM4iAg
Date: Thu, 9 Mar 2017 19:28:48 +0000
Message-ID: <>
References: Your message of "Thu, 9 Mar 2017 00:19:21 -0800 ." <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
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: Thu, 09 Mar 2017 19:28:53 -0000

-----Original Message-----
From: ipv6 [] On Behalf Of Philip Homburg

> The first interface identifier concept is that for any prefix of
> length n, the length of the interface identifier is 128-n. Let me
> call this prefix-iid.
> The second iid concept is in auto configuration of addresses. I'll
> call this slaac-iid.
> The way I see it, any slaac-iid that is based on (pseudo)-random
> number has to be at least 64 bits. I don't see any reason for more
> than 64 so exactly 64 sounds about right.

If you want random, a PRNG can create any length of IID. A 48-bit IID would be just as reasonable, and it could be formed from a randomly changing link layer address.

I would stay away, at this point, from any mention of 64 as a constant. We are (I think) beyond that, even for a particular 2000::/3 subset of globally unique unicast addresses.

Secondly, RFC 4862 states:

      Note that a future revision of the address architecture [RFC4291]
      and a future link-type-specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers. 

Which is where we are today, in fact.

> In theory, a link that has hardware MAC addresses with less than 64
> bits could define a slaac-iid that is shorter, however that precludes
> the use of pseudo-random slaac-iids.

I don't think it does.