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

james woodyatt <> Wed, 18 January 2017 18:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5754912945C for <>; Wed, 18 Jan 2017 10:50:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 pg7mviov88Fk for <>; Wed, 18 Jan 2017 10:50:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F01312943E for <>; Wed, 18 Jan 2017 10:50:54 -0800 (PST)
Received: by with SMTP id e4so6281091pfg.1 for <>; Wed, 18 Jan 2017 10:50:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=kV3twzg0JnGe2h7sZkkJnq1+k70hGvJf0tKip14YUfg=; b=u5vSWIhQMeuTLY4YogdsmeX/wRH6d4187E8meLSsS1PTWehKKTV5piDGAkyBRpc2rD 4bZMxnmnVp5uLPTT4a8Eh4Bw1JZoqGYPFVID+ldzBTl2HWytU2xK/OSl1Y6wJEh98M9Y 7zhMdH3u/Q6RYgB+4wXTfju2NWcnZdqaVJ42h969z4WCjGupj7in/lLCaRgIfK9pNye7 3zl1PMDR4Esw+qqHUGBoKrYehE9HZKyqIZHZBaJYOGpRlCnlMSnqMIopezIZGpTx/1Iv Bf3MBR9d6DLAr+ff0Mfo+WCjAxRfNTAbWHVoIMyJBDpo1wtRzIpIS/7BZm6s1cEzkZRK vyMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=kV3twzg0JnGe2h7sZkkJnq1+k70hGvJf0tKip14YUfg=; b=hVHVykhCOlv6ACm+mqa18WlEpzUzYsw5rNxT35fPE9mwf8Ym1ohYW/krxkN6gw643K Vt7iDVWB6OrofTJKp1vbMQnRDZCRMhB1Hjtn1cD6+O8+j0Wd83iLQyIWheZWs+meNYbP 74eNhHCykHFaDz44nWDPtZNwkV38A+stqGywvr9RZilNWlzDXw3lZG8ymUYfgQ9HqVG+ /EbxJqGIE2AKQoUrglv9E2W5dSdAxigsi5ydSmr7IQsCuO945Ya/nnKZpG1IR51hsipj RdK4P7RHwpcODkND+HLCRTRL0fzbPocowNKr0rHgj7BD2/3NR67KQidVPdGD5XUHUMqi aIlQ==
X-Gm-Message-State: AIkVDXKLd9iTdBja12BlhP13AZeXFLomJEFmDNeSqiRIISKxq2z5xlHGmUI6E0jdB9lOJm2j
X-Received: by with SMTP id 7mr5449720pfd.9.1484765453387; Wed, 18 Jan 2017 10:50:53 -0800 (PST)
Received: from ([]) by with ESMTPSA id a8sm2533366pfa.19.2017. for <> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 Jan 2017 10:50:52 -0800 (PST)
From: james woodyatt <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_26BF2336-682A-4F79-88E7-7CE3628D493D"
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
Date: Wed, 18 Jan 2017 10:50:51 -0800
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <>
To: 6man <>
In-Reply-To: <>
X-Mailer: Apple Mail (2.3124)
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: Wed, 18 Jan 2017 18:50:55 -0000

On Jan 16, 2017, at 18:36, Erik Kline <> wrote:
> Actually, I think the NEW text is pretty reasonable if we could
> restore the word "required" for the currently allocated unicast status
> quo:
> From:
>   ... For all currently
>   allocated unicast addresses, except those that start with the binary
>   value 000, that length is 64 bits.
> To:
>   ...  For all currently
>   allocated unicast addresses, except those that start with the binary
>   value 000, that length is required to be 64 bits.
> We can always produce a document that updates 4291bis for 4::/3 or
> whatever we want, and the new text states so explicitly.
> But I'm not convinced we should change to text that could be read to
> weaken the current situation.

I fully agree.

My apologies if I’m coming into the discussion with a point everyone has already dismissed, but it seems to me there is a procedural matter regarding the fact that RFC 4941 doesn’t actually describe how to generate temporary addresses with IID length other than 64 bits.

In the first paragraph of Section 1, RFC 4941 says "Note that an IPv6 identifier does not necessarily have to be 64 bits in length, but the algorithm specified in this document is targeted towards 64-bit interface identifiers.” And nothing else about it appears elsewhere in the text. It doesn’t seem like a host receiving a RA Message containing a PIO option with A=1 is permitted to generate temporary addresses by SLAAC unless the prefix length is 64 bits.

This seems important to me because the text Erik proposes here provides a guarantee to sub-IPv6 link protocol developers that RFC 4941 is an available as a standard for generating temporary addresses using SLAAC for every currently allocated globally-unique prefix. If that requirement disappears in RFC 4291bis, then those of us involved in the development of new sub-IPv6 link layers will not have that guarantee, which may force some of us to develop link-layer alternatives (possibly involving address translation) in order to provide comparable address privacy properties on subnets with globally-unique prefixes longer than 64 bits.

I don’t want to see 6MAN place this possible new requirement on link-layer developers by removing it from IPv6.

--james woodyatt < <>>