Re: Updated IID length text

Brian E Carpenter <> Thu, 19 January 2017 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8355812943B for <>; Thu, 19 Jan 2017 11:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 evNVEY9ITnj1 for <>; Thu, 19 Jan 2017 11:41:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7BD712951E for <>; Thu, 19 Jan 2017 11:41:21 -0800 (PST)
Received: by with SMTP id f144so15788093pfa.2 for <>; Thu, 19 Jan 2017 11:41:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YC6jcr80Y3K5HvnbkDEIJ+qXslzoBxdp/Brlhw0RCqc=; b=NhQp+TCLro4PcQTNy/M1OHsyd4xBecX8e5YTgItWMuAi3oJhOCLIPr2Li7ZaddPjM6 9AdcrMtDMAk9bB8Q9BNdS1oXJZ8EuKli9Kf3Yt1Gl9Xjyb5PIfdt+vkLNAfTAPEey20+ YVNv33/KmVM9aOF5xMRnPFKIO+272aO0j8mBBWEGLcTpuuRmfu60W7xGEdMwrC/WKitR KOWg+w8pw6R0N9g9l2S5JHt/AiO6VY7rAH5cGO/pOZ1EPCb9EB4kCkd6M5iYIlV3cFOZ jaFEVv3sKZqX7xpjDMl5CAZkRpsM8Mi9ZiF8IitidXW3iHXOFM0DvvLgdyMHn12K85bj SZig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=YC6jcr80Y3K5HvnbkDEIJ+qXslzoBxdp/Brlhw0RCqc=; b=Ed0RZC/v1UaBIzsyMV1wxZ8yqxnBp3ZvRFOCOnIlTvqtR7q2gAoKezXgXnY7bF8tFS SkPJXG8oaQd6LnZpNpTPHz2guvHkgj42D7Edc22Ew3xzHo3Rf2KhUTOZFzD8LPuPkfaQ Jr0fFn3JeBo6KrR+0+jgwvgHkhE87k7s2ISkL7Sk50FBPvQqR6cMSkgqeUnCi1iOw3IQ FHgMWCAdlVDOoaZwFuU/7tyWWgAf54/Bv94rPIyOkMp3B3emv7S0BxujF9yehbbfPbrf 6mbKnf7bzvuoxnxe2D8E/ppQ814cs4ccrAowmkAa+WY3fzfwxCHNE/V9L7LTJYo0rHFN 6YWw==
X-Gm-Message-State: AIkVDXJwws54MW8EpXg4ejUihAxJHaQLwT8xs3A+GNPD6dPOerKGIdLlH+XEXyZVMJ2UuA==
X-Received: by with SMTP id l2mr12374575pgn.116.1484854881329; Thu, 19 Jan 2017 11:41:21 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id q2sm10863275pga.8.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 11:41:20 -0800 (PST)
Subject: Re: Updated IID length text
To: "Manfredi, Albert E" <>, 6man <>
References: <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 20 Jan 2017 08:41:25 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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, 19 Jan 2017 19:41:42 -0000

On 19/01/2017 16:23, Brian E Carpenter wrote:
> On 19/01/2017 15:55, Manfredi, Albert E wrote:
> ...
>>> I don't think that SLAAC *must* require a single standard IID length, so
>>> that's why I added the word "robust." Now that we have moved away from using
>>> the MAC address for SLAAC, it's not clear to me why a host cannot wait for a
>>> RA, and then decide on how many IID bits to use, based on the prefix
>>> length(s) advertised by the router.
> Not if you want to form a link-local address first. Which you always do,
> because perhaps there *is* no router when you come up after a power cut.
> (In the Anima WG, we are very interested in the behaviour of nodes
> that have absolutely no external information when they come up, because
> it's their job to bootstrap the network out of nowhere.)

I should have added that in the context of promoting the document to
full Standard, we can't introduce new behaviour. But I don't object to the word
'robust'.  I don't think it makes sense to use the word 'standard' inside a
standard, however. And using 'consistent' twice is ugly. So I get to

   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, 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, 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. Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

Any speculation about deviations from /64 is out of scope, IMHO, for
a draft being proposed for full Standard, given that 4291 requires /64.