[v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 03 November 2015 21:47 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1D5B31B2A1F for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 13:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GcY258FxIq1V for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 13:47:26 -0800 (PST)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790031B2A22 for <v6ops@ietf.org>; Tue, 3 Nov 2015 13:47:26 -0800 (PST)
Received: by pacdm15 with SMTP id dm15so5423171pac.3 for <v6ops@ietf.org>; Tue, 03 Nov 2015 13:47:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=vf04O4XRhnp2M/w+zkeawoqXo+t2IDxryRYYAhUV3zk=; b=ncpVCXPIPtoRy3mtqqwTGv/lDy4RkkFTKE93f+/pNbupNoo9bRcgoHelQXPs2Z7AdQ PdnfFbKgCoYAfILKvdamG7HBuBQRhYmuJlwUe3ImD+idCLEeyc3qP3qHY0KQoySZL/oS IpNpcIVwhuGMmnTC5SvjYNWT/mzJn3K1CM2cutpP/08dMI0dcU+IMRCDZBGygjObqUAu uLzj8okxA53COL/M7GNrb574v4Zwz5e4tujRWC2OwzvBwtEVmRVEOt2a+2M3RgpFQihx 0R8OtAB3M7dyJQc6ZvfVnd77Nx8OxsP1zHG0XmjspIZsa4GIGehgn1RbZ5rwlf+WoUw+ l1xw==
X-Received: by with SMTP id gp8mr37226485pac.154.1446587246129; Tue, 03 Nov 2015 13:47:26 -0800 (PST)
Received: from ?IPv6:2406:e007:4a67:1:28cc:dc4c:9703:6781? ([2406:e007:4a67:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id rm10sm31191993pbc.96.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 13:47:24 -0800 (PST)
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Lorenzo Colitti <lorenzo@google.com>
References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <CAKD1Yr15C-uoxUw0kgWO-d=LmUK8qWGLS7vt+22W+k8xXtDY+g@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <56392B6D.8030703@gmail.com>
Date: Wed, 4 Nov 2015 10:47:25 +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: <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ZNdBk-lxu7bGLm9lrVlfpBmKdo0>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 21:47:29 -0000

Hello Fred,

On 03/11/2015 20:10, Templin, Fred L wrote:
> Hi Brian,
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: Monday, November 02, 2015 6:55 PM
>> To: Templin, Fred L; Lorenzo Colitti
>> Cc: v6ops@ietf.org
>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>> Hi Fred,
>> On 03/11/2015 14:59, Templin, Fred L wrote:
>>> Hi Brian,
>>>> -----Original Message-----
>>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>>>> Sent: Monday, November 02, 2015 5:46 PM
>>>> To: Templin, Fred L; Lorenzo Colitti
>>>> Cc: v6ops@ietf.org
>>>> 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."
> The malicious (or otherwise broken) host 'A' could configure any number
> of addresses it likes, but it would do so in a vacuum because ingress
> filtering will prevent a packet with a source address from a prefix
> belonging to host B from being accepted. So, node B has no reason
> to fear address duplication by node A.

I'm not sure how an ingress filter somewhere upstream would know that
the packet came from the "wrong" host. But I don't think that's enough;
a duplicate address on the LAN is already a problem in itself.

> Also, what if node B in fact did do DAD and A heard it? What is to stop
> A from configuring a duplicate address and trying to use it just to mess
> up the legitimate operation of node B?

Nothing. That, I think, is why the RFCs make DAD mandatory.

> What you are describing is a broken implementation that could only
> be employed by a malicious host, and not something that honors
> the standards. 

I don't think it's malicious; it's just trying to get IPv6 connectivity
in the face of what it sees as a broken router that isn't responding
to RS. But that isn't really my point - my point is that whatever we
do, it's impossible to assert that a duplicate address will never arise.

> Doing DAD is not going to guard against malicious
> hosts.

No, but it might allow you to detect the resulting anomaly.


> Thanks - Fred
> fred.l.templin@beoing.com 
>>>> 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.
>>    Brian
>>> Thanks - Fred
>>> fred.l.templin@boeing.com
>>>>     Brian
>>>>> Thanks - Fred
>>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
>>>>> Sent: Monday, November 02, 2015 5:24 PM
>>>>> To: Lorenzo Colitti
>>>>> Cc: v6ops@ietf.org
>>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>> Hi Lorenzo,
>>>>> Responses below in “green”:
>>>>> From: Lorenzo Colitti [mailto:lorenzo@google.com]
>>>>> Sent: Monday, November 02, 2015 5:04 PM
>>>>> To: Templin, Fred L
>>>>> Cc: Fred Baker (fred); v6ops@ietf.org<mailto:v6ops@ietf.org>
>>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> 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
>>>>> v6ops@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/v6ops