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

Nick Hilliard <> Mon, 13 November 2017 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4A83127843; Mon, 13 Nov 2017 07:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F6CMLrlJ6oMT; Mon, 13 Nov 2017 07:48:20 -0800 (PST)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9F1D1205F1; Mon, 13 Nov 2017 07:48:19 -0800 (PST)
Received: from cupcake.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id vADEm6ec024500 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2017 14:48:07 GMT (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be cupcake.local
Message-ID: <>
Date: Mon, 13 Nov 2017 15:48:15 +0000
From: Nick Hilliard <>
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Lorenzo Colitti <>
CC: "" <>, " WG" <>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
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, 13 Nov 2017 15:48:22 -0000

Lorenzo Colitti wrote:
> Actually, IIRC the thread you started a couple of months ago reaffirmed
> that consensus. (The document does not state that DHCPv6 address
> assignment is not recommended, it only states that networks that *only*
> use DHCPv6 address assignment are not recommended.)

1. draft-ietf-v6ops-unique-ipv6-prefix-per-host says nothing one way or
another about networks that *only* use DHCPv6 address assignment, so RFC
7934 is not relevant in this case, even by your own arguments.

2. 7934 does not state that networks that *only* use DHCPv6 address
assignment are not recommended.  There was no WG consensus for your
interpretation, and your interpretation is in direct conflict with the
reality that DHCPv6 can be used to provide multiple IP addresses to a
host, as 7934 recommends, and as was proven with working examples during
that thread and others.  Either way, this is outside the scope of
draft-ietf-v6ops-unique-ipv6-prefix-per-host and it's not helpful to
have another rehash of this argument here.

3. you are now arguing that an option to implement
draft-ietf-v6ops-unique-ipv6-prefix-per-host with DHCPv6 shouldn't be
considered because of rfc7934.  In other words, you're arguing that we
shouldn't introduce the option for hosts to be able to get multiple ipv6
addresses via dhcpv6, because according to you, rfc7934 recommends
against using dhcpv6-only because it lacks the ability to provide
multiple ipv6 addresses for hosts.  I.e. circular reasoning.

These arguments are untenable.  In fact, they're completely ridiculous.