Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Fernando Gont <> Mon, 06 November 2017 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 999FF13FC3F; Mon, 6 Nov 2017 13:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eRpd5wsD8q_r; Mon, 6 Nov 2017 13:12:02 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8242613FBD5; Mon, 6 Nov 2017 13:12:02 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C30FA80EB1; Mon, 6 Nov 2017 22:11:55 +0100 (CET)
From: Fernando Gont <>
Subject: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: IPv6 Operations <>, "" <>, "" <>
Cc: "" <>,
Message-ID: <>
Date: Mon, 6 Nov 2017 18:13:50 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Nov 2017 21:12:05 -0000


These past few days I ended up reviewing the aforementioned document, as
a result of a thread on this document on the v6ops mailing-list.

I had reviewed an early version of the document, in which the benefits
of not having and on-link prefix were discussed -- which was certainly
fine (and I supported).

While reviewing this document a few days ago, I found that Section 4
(page 5) contains what is a protocol spec, rather than an operational
BCP. It contains rules regarding how to set the link-layer address (to a
unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
now remember which prefix has been "leased" to which node -- something
that seems to be way outside of the v6ops charter, and that should have
been done in 6man, instead.

Looking at diffs, it seems this additional text was incorporated very
recently, in version -09 of the I-D, published in mid September
It seems to be that this change is way beyond what the authors
originally proposed
(a bcp saying that it's great to give each host a unique prefix, without
providing details on specific mechanisms or doing protocol specs --
which was obviously within v6ops' charter), and what the wg shipped, and
also seems to be in conflict of the v6ops and 6man charters (v6ops
doesn't do protocol specs, but this document certainly contains one).

Besides what seems to be a conflict in the aforementioned charter, there
are a number of issues associated with the specified protocol:

1) The protocol spec specified in this document requires the SLAAC
router to keep state of the "leased" prefixes -- what seems a major
change to SLAAC, which now would be kind of as stateful as DHCPv6.

2) There are scenarios in which multiple nodes might receive the same
packet -- say a NIC let's the packet through because it is in
promiscuous mode -- wich could possibly lead to two nodes configuring
the same prefix.

3) What happens if the SLAAC router crashes and reboots, loosing state
of the "leased" prefixes?

4) How are prefixes selected? And, what's the minimum size of the pool
of prefixes for the selection algorithm not to break due two "prefix
collisions"? Does the selection algorithm have any specific properties?

In summary, revision -09 (most likely done to address some DISCUSS)
turned the original BCP document into a protocol spec, with a major
change to SLAAC, which should have happened in 6man, rather than in
v6ops (which is not allowed to do protocol specs). Looking at the
current document (to be published), Section 4 (page 5) looks more like a
Std Track document than a BCP.

It was suggested to me that I discuss this on the mailing-list... hence
this post.


P.S.: I wished I had caught this earlier. I just didn't.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492