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

Lorenzo Colitti <> Thu, 09 November 2017 02:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7CAD129ADF for <>; Wed, 8 Nov 2017 18:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 mK3XRwgUwVCc for <>; Wed, 8 Nov 2017 18:58:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8321D129467 for <>; Wed, 8 Nov 2017 18:58:34 -0800 (PST)
Received: by with SMTP id c3so9450075itc.3 for <>; Wed, 08 Nov 2017 18:58:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mLMKWIwUrHFcKTmKNKiwljf5/2STafD2ozRAOQZspvA=; b=F4LSPEHYkv0TuJEvPnhQhm1bonUNPr+2a0mAe9qlYjywaa7E+cF2YvzdS4b8FMNd7h DbIH7hprq6Lo+9HoHbqkGOKbwEBM7C7ilIBMJH4FoHv2XxBuiqtNxSOR4Qe4xDppj9h7 kcznn5se7cFbKrj3BoNz4s9e4Jyw15HH8Z+lzJd/MJmuQkwt3pF/HtAb2X2eccp21FRS lYyotesfsHqwNYZUxDBkOqVUUETOyUT2C3wkfdmIclgkPJvX5w3vFDF2DT7YWwqPss0O k6+qMuTv5MRDSAhsOiCBpKx5CgMXD25VvZR+KZtHVYvnXK1KqWhTRQVy/Y0kxg0XhhyI 87jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mLMKWIwUrHFcKTmKNKiwljf5/2STafD2ozRAOQZspvA=; b=icScrHkdIeaWS4HkYmgHCSQttrbH3oOFA6QwIEtzpMznSCycFE7g9yQIEjcPRo51bh HSuXVywTAKCiJWjdl9zNqdMiXcQN6J/e+XUeiMo21E9iJstdAlHH5rcNK4dZTPCaSomK YvxWCpxUICxQkQufx2IGMoRtaqgeoClJIi5VLTm5GO+Fn3oElHSf19Xw/b/nOCtl3AyZ 2KahU8S+pmk940fJ4yWmCW64Mlsh7QWJurarDLj0BcdyMIOQkjXv/P6jx2eF1D8RG30L mY2hfrPKrneE9+48Gngw6Bm47aK9ltuFb+fun/Ws5dEjTFCRK0HcHtT/GIIk3daP+q4M Vamg==
X-Gm-Message-State: AJaThX6pIuWk4cMoAqkufatVOjA+xxvnbtOvkKxZaVpxrZbM0G2h3txW sBksL7jqQS2Kor0kthjDEarMr8qvZo0m3t12QRPuU9YpIcY=
X-Google-Smtp-Source: ABhQp+TOVJ1qA/lhlyCmwjwm8qAy3XOHEhbxP2QYZWG7LgzeGN8MEIcsGJ1xD3pSLzhMhtVf12GVT26EGCiWwm3dmIo=
X-Received: by with SMTP id j73mr3563244itb.32.1510196313447; Wed, 08 Nov 2017 18:58:33 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 8 Nov 2017 18:58:12 -0800 (PST)
In-Reply-To: <>
References: <>
From: Lorenzo Colitti <>
Date: Thu, 9 Nov 2017 11:58:12 +0900
Message-ID: <>
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont <>
Cc: IPv6 Operations <>, "" <>, "" <>, "" <>,
Content-Type: multipart/alternative; boundary="001a1144b0eccea886055d83fa1e"
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: Thu, 09 Nov 2017 02:58:37 -0000

On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont <> wrote:

> 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.

I don't see how this is a protocol change. Sending RAs unicast is already
allowed by RFC 4861, so this is just an operational practice.

Looking at diffs, it seems this additional text was incorporated very
> recently, in version -09 of the I-D, published in mid September
> (<
> unique-ipv6-prefix-per-host-09.txt>).
> It seems to be that this change is way beyond what the authors
> originally proposed

The additional text did not actually change this practice at all. It simply
clarified what has always been a fundamental premise of this operational
practice: if you want to give each host its own prefix, you need to ensure
that the RA with that prefix is only received by that host.

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.

This is a bizarre claim. The first-hop router must always have fully
up-to-date state on all the prefixes it is sending RAs for, otherwise it
cannot fulfill its fundamental purpose of forwarding traffic to those
prefixes. The word "stateless" in SLAAC applies to addresses configured to
the host, not how routers route traffic.

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.

Why do you say promiscuous mode is a problem? Even in promiscuous mode,
network stacks already understand which packets are being send to the host
network stack and which are not. For example, in the linux networking
stack, well before the packet ever gets to the ICMPv6 protocol handlers
that would process incoming RAs, ipv6_rcv does:

if (skb->pkt_type == PACKET_OTHERHOST) {
return NET_RX_DROP;

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

You seem to be assuming that the router does not store the prefixes in
stable storage. It's certainly the case that if you want this scheme to
work across router crashes, then you need to ensure that the prefixes are
stored somewhere. That sort of seems self-evident, but we could add it to
the text.

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?

I see no reason why this should be in scope for this document.