Re: Updated IID length text

Bob Hinden <> Fri, 20 January 2017 23:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36BCD1295FE for <>; Fri, 20 Jan 2017 15:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p7kHJFSRvyaK for <>; Fri, 20 Jan 2017 15:53:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 949491295B1 for <>; Fri, 20 Jan 2017 15:53:03 -0800 (PST)
Received: by with SMTP id q20so9569926ioi.3 for <>; Fri, 20 Jan 2017 15:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qff75dr2N793umcAERMZLQ+pMrex0rThwhqVzaQAHtQ=; b=VR4mJ+I1rlmahQUtyYMmdz/MFcJYGPE8In62qua+nrU32a49RYyGq/8JWYS2IyRCAA PPmqPonjiz9Es3taS5uC9lYkJ8qki/EE3JoEcBA75pgvEddNMv4IYYGGCa9ZjmYtzyKR cHMOhtUkpOgxlevvJZ/8t9bslLdTQJ6clwItP4yKbCmHAix2UiXYbz2v4U63/p3iSNUT DqpZwcIGxcEfb9Et3BPhut6tgwpSDrFGy0dkEDROm0qQo+W0cX6Aakx8wrRr/hG8oQC5 gdgP4F7oNzEps6ikxdshAmACb7ft8IwCjzes8ZHOvpsZ1nLCR+LyMFhmn2ARZZVYpm5B WO8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qff75dr2N793umcAERMZLQ+pMrex0rThwhqVzaQAHtQ=; b=H0tdafsN6axA67zv6sPozsYFgAT64I/lR1+Nfhr2WNZ/1aVwGDVI3SnICAjLRLi/Iy hZNKhfPprxJTtPrBOYcEP2RnxYI2uL26jV4UdRfvLSVJG/dfU8+4RvDOBu91dVgmWz1c HO70+atzTCwfqtZA3Mc5sOYJ97RMd6RL1bSscdF7upCG/6U/V/RCA1Cd8+I5CdXZe88g 7pvkdvLGedpKBl+Juf2WcoL2EpYuPMDRX3Zj28eoXncYWbrB0dKhsRNzgJrHteuFT1xF QTEI4Ynk7z9SBJDGUhiGYs5REGBkOqkcDDq/C2kRTtcV8eZxIH/zc5wdGPVOV2t7Gzhp mVDg==
X-Gm-Message-State: AIkVDXIswXKsnHnZuvqZDqXCCvGmzPdWohjcVh4GIwroQt5W1HDq4NGWQpmWnXHh15ZawQ==
X-Received: by with SMTP id w92mr18184694ioe.136.1484956382764; Fri, 20 Jan 2017 15:53:02 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id j79sm1918755itb.0.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 15:53:01 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Updated IID length text
From: Bob Hinden <>
In-Reply-To: <>
Date: Fri, 20 Jan 2017 15:53:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <> <>
To: Brian Carpenter <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: IPv6 List <>, Bob Hinden <>
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: Fri, 20 Jan 2017 23:53:05 -0000


> On Jan 19, 2017, at 10:11 PM, Brian E Carpenter <> wrote:
> On 20/01/2017 17:38, Lorenzo Colitti wrote:
>> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <
>>> wrote:
>>> 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,
>> I object to the text "for this reason", because SLAAC is not the only
>> reason. There are many reasons, many of which are written in 7421, and two
>> sentences in this paragraph are not sufficient to describe them. I propose
>> the following alternative, which I believe to be normatively identical:
>>   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, 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. The rationale for the 64 bit boundary in IPv6 addresses can be found in
>>   [RFC7421].
> Yes, I'll buy 'however’.

I am generally OK with the text above, but wanted to point out that Section 2.4. "Unicast Addresses” there is more than one place where 64 IIDs are mentioned.  This discusion has been about the forth paragraph in 2.4.1. "Interface Identifiers”.  It is also mentioned in the second paragraph of 2.4.4. "Global Unicast Addresses”.  I assume this would have to be modified if the w.g. decides to adopt this text.

As Ole pointed out there is text that discusses future changes:

2.3.  Address Type Identification
   Future specifications may redefine one or more sub-ranges of the
   Global Unicast space for other purposes, but unless and until that
   happens, implementations must treat all addresses that do not start
   with any of the above-listed prefixes as Global Unicast addresses.

2.4.  Unicast Addresses
   There are several types of unicast addresses in IPv6, in particular,
   Global Unicast, Local unicast, and Link-Local unicast.  There are
   also some special-purpose subtypes of Global Unicast, such as IPv6
   addresses with embedded IPv4 addresses.  Additional address types or
   subtypes can be defined in the future.

I think that this makes it clear that things are allowed to change in the future.  I don’t think we have to capture this in the single paragraph in 2.4.1, and there could be other kind of changes as well.