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

Lorenzo Colitti <> Mon, 13 November 2017 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B3FF129B14 for <>; Mon, 13 Nov 2017 09:09:15 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NLLU2gUxfgZR for <>; Mon, 13 Nov 2017 09:09:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42068126BFD for <>; Mon, 13 Nov 2017 09:09:13 -0800 (PST)
Received: by with SMTP id 134so21388269ioo.0 for <>; Mon, 13 Nov 2017 09:09:13 -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=tLpgKLpiDdNoXm6HNltwUYjXAKfssFOEDjOTz6nssqs=; b=YRueMl+2v3w5zGAR0ZDfAAzbzsnEpeP1IlNFEuFQtPBh3d2tyk19HzFWN9CfxXTldc e9mtKwr8e6J57yzCzHpHeek5PXqsHs5as8Snvl1Y8bJsQdAnkL1DYRIxiH87DOJ/KBTX ca9z1lvGVlaQnq8HWKl4EnY1nZgtkOX6kETqCl2BId6t1cHy7frBAVO/Tl2ATSrLSd1T /HBY4vbh0VApGrCfJ882CBu/oE6slIt7+KqAr6uWapKsmfN40QPGDlgmgeUH6LsRx2em bOytA4dn18VarBdo4khiVejuulWD/vuroP+R/ZBqpUPIR5Fc2u/W6wtDohKsVmr9AvpA Jziw==
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=tLpgKLpiDdNoXm6HNltwUYjXAKfssFOEDjOTz6nssqs=; b=fERXr8htGoV69AraFZERyWdPCos5yFnA+avBX6VdGhzc19x4sqagLKR3QCTRjSZrpZ lc5w2mPqpgkJLLZb79aUrXW6oc4LENNIO/k7dYe2lnUSt7s4l1es7ELMly0mYINgOwR3 Ujl7LCcGsssBqvH/vtZV0b9a9r7lSNN+7goW1PhM/r1xKV9ETkR8Ahe4XZeiXxv4ZmWe Ab65gWENjjl9f8cX29kChhPxXTKAX9otiqZ/lh1YFe+ylq59MaFi/YQpg5cJ1EjJcIM5 m7p8t4qjODeJH/39jzE9Rif+YMSuz5/V3iy6jZMSb4nZ9py//bCoJCuczmLrlM6vOvKI VhZg==
X-Gm-Message-State: AJaThX6t4lM4/NVlCO2PzcSYjgoISi6bIg7B86Ne8NtToxIlznU/zh55 eE0tNaOUuQ7xMa2fS0sIMnqnI6TTZhQgEvXAx0jUMvSo
X-Google-Smtp-Source: AGs4zMYJaC04jqTSwmNSt42JXnsPSU/aer4sdH3aW/7hDIz3Y6Eo4l/KS11Tg86R+2iDeO9TGlt0LeUEFOhvavlZoPA=
X-Received: by with SMTP id n75mr10315238ioo.43.1510592952149; Mon, 13 Nov 2017 09:09:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Nov 2017 09:08:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Tue, 14 Nov 2017 02:08:51 +0900
Message-ID: <>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Nick Hilliard <>
Cc: "" <>, " WG" <>
Content-Type: multipart/alternative; boundary="001a11445e9e50e808055de05403"
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 17:09:15 -0000

On Tue, Nov 14, 2017 at 12:48 AM, Nick Hilliard <> wrote:

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

Agreed. It is relevant only in that there were comments on this thread that
roughly said "why not use DHCPv6 instead".

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

The 7934 recommendation that can't be met by networks that only use DHCPv6
address assignment is not "provide hosts with multiple addresses" - it's
"allow hosts to form new addresses without explicit requests to the
network". But I agree it's not useful to repeat that 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.

I don't think you understood me. If you're saying that a unique prefix per
host can be assigned using DHCPv6 PD, then of course that's true. Given
that DHCPv6 PD is not widely supported by hosts, it's not a fit for the
goals of this document, which are to support as many hosts as possible. But
it would work.

RFC 7934 only recommends against a network that exclusively uses DHCPv6
*address* assignment. Using DHCPv6 PD to assign a /64 *prefix* to each host
is fine (and in fact, cited as an example).