Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

Brian E Carpenter <> Tue, 03 November 2015 02:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E48441ACDFB for <>; Mon, 2 Nov 2015 18:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eydUbsrRocBP for <>; Mon, 2 Nov 2015 18:54:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85C851ACD69 for <>; Mon, 2 Nov 2015 18:54:37 -0800 (PST)
Received: by pasz6 with SMTP id z6so4493167pas.2 for <>; Mon, 02 Nov 2015 18:54:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Vkp3gl/yzkrExPkqIq5VAbJQb/7FNRmxeK6EdJ1RCoo=; b=OLKzC5iJ5BedOY8aVBwNp1jLPAa+KVtrk/jSS/WKeaAm9QE5yzFqlDycKfmL8imecR gBr9y9LfjaD5sjMqW0gZpNkKy6W9upZmbRuu4nQReuHexvwOJIpemUm58grFD+zMxWfF apFtqHZ64ng7i1k8nsRROEoWy+w5vTDwx1n3ZLOTKktf9U1AX8lSszTYlZD67vQQkvog 99YvYuUsWFRPzcnYZL29ygCFYwHG/UaGwFu4J3jl9YpuSXR8Qgv8qQQSiuhb8izMwq5j MGjfUxMUMZMJo52+o7c1UiOBPJHfc0PqNO81ljAFSi5F19o+XXyeLLQPQT3hLmlcCWB4 bnGQ==
X-Received: by with SMTP id pj6mr31351771pac.104.1446519277241; Mon, 02 Nov 2015 18:54:37 -0800 (PST)
Received: from ?IPv6:2406:e007:4394:1:28cc:dc4c:9703:6781? ([2406:e007:4394:1:28cc:dc4c:9703:6781]) by with ESMTPSA id ia3sm26561043pbb.5.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 18:54:36 -0800 (PST)
To: "Templin, Fred L" <>, Lorenzo Colitti <>
References: <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 3 Nov 2015 15:54:35 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Nov 2015 02:54:40 -0000

Hi Fred,
On 03/11/2015 14:59, Templin, Fred L wrote:
> Hi Brian,
>> -----Original Message-----
>> From: Brian E Carpenter []
>> Sent: Monday, November 02, 2015 5:46 PM
>> To: Templin, Fred L; Lorenzo Colitti
>> Cc:
>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>> On 03/11/2015 14:31, Templin, Fred L wrote:
>>> Bumping up one level – is it clear to everyone that it is OK to assign addresses
>>> taken from a DHCPv6 delegated prefix to the interface over which the prefix
>>> was received?
>> If it was legitimately received, I can't see why it wouldn't be OK.
> OK. When the DHCPv6 server grants a prefix delegation to the client,
> the server is asserting that that prefix is unique and is now the sole
> property of the client. So, when you say legitimately received I
> agree and that is actually a core requirement of DHCPv6 PD.
> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the
> routing system would become hopelessly corrupted and address
> duplication would be the least of our worries.
>>> And, that DAD is not required for those addresses?
>> How is that safe? What is to stop a host running SLAAC once it
>> sees that prefix in an RA, and hitting the same IID by chance?
>> At least you need to specify that the A bit must not be set.
> I am talking about DAD on interface "A" being the interface over
> which the client receives the prefix delegation. No other node on
> interface "A" may use the delegated prefix, and no router on
> interface "A" may advertise the prefix in an RA. The prefix is the
> sole property of the client that received the PD, so the client is
> free to assign addresses without needing DAD.

That usage of "may" might confuse some people, so let's pretend
you used a "MUST NOT" construct instead. I could still construct
a host stack that would ignore the issue: its logic would be
"I sent an RS and got no RA/PIO with A=1; but I see traffic from
prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix."

>> Come to that, a manual address might collide.
> The client itself is the only node that is permitted to assign addresses
> from the delegated prefix to an interface, so there is no risk of
> collision unless the client itself is somehow corrupt.

Or another client on the same LAN gets too clever.


> Thanks - Fred
>>     Brian
>>> Thanks - Fred
>>> From: v6ops [] On Behalf Of Templin, Fred L
>>> Sent: Monday, November 02, 2015 5:24 PM
>>> To: Lorenzo Colitti
>>> Cc:
>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>> Hi Lorenzo,
>>> Responses below in “green”:
>>> From: Lorenzo Colitti []
>>> Sent: Monday, November 02, 2015 5:04 PM
>>> To: Templin, Fred L
>>> Cc: Fred Baker (fred);<>
>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <<>> wrote:
>>> I have one text addition suggestion and one question. On P. 7, in Table 1,
>>> suggest adding a new final row as follows:
>>>   requires DAD               Yes                  Yes                   No                 N/A
>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA
>>> must use DAD to check for duplicates on the link they were obtained. In a
>>> multi-addressing environment where millions of addresses are required,
>>> this could amount to a substantial amount of DAD multicast traffic. On the
>>> other hand, DAD is not needed for DHCPv6 PD because the network has
>>> unambiguously delegated the prefix for the node's exclusive use.
>>> I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD with
>> any other devices on that /64 (e.g., tethered devices, VMs, etc.).
>>> I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure we could
>> come up with lots of things we could add to the table that aren't there at the moment. My main concern is that if we add something to
>> the table it needs to be correct.
>>> What I mean is “Requires DAD on the interface over which the prefix was received”,
>>> but that was too long to fit in the table. Let’s call the interface “A”. If the node gets
>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface “A”, then it needs
>>> to do DAD on interface “A” for each such address. If the node gets a DHCPv6 PD
>>> over interface “A”, however, it does not need to do DAD over interface “A” at all.
>>> If the node assigns the delegated prefix to interface “B”, then you are right that
>>> that DAD will be required among all tethered devices, VMs, etc. on interface “B”.
>>> But, there will still be no need for DAD on interface “A”. Does that clarify?
>>> I have a question also on table 1. Under ""Unlimited" endpoints", why does
>>> it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a prefix
>>> obtained by DHCPv6 PD can be used to configure an unlimited number of
>>> addresses on the link over which the prefix was received.
>>> The table is written from the perspective of the network assigning addresses to devices that connect to it. Therefore, it says "no"
>> because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to however many
>> /64s you have available.
>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to assign to
>> clients. Of course, that's only true in theory. In practice, there's going to be a limit due to scaling reasons.
>>> I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used
>>> to assign an unlimited number of addresses to interface “A”. But, so can DHCPv6
>>> PD. When the node receives the delegated prefix (e.g., a /64), it can assign as
>>> many unique IPv6 addresses as it likes to interface “A”. And again, it need not
>>> do DAD for any of them.
>>> _______________________________________________
>>> v6ops mailing list