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

Philip Homburg <pch-v6ops-3@u-1.phicoh.com> Tue, 03 November 2015 23:07 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45EA1A883E for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 15:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jEzYgC2Wdso for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 15:07:09 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA831B3587 for <v6ops@ietf.org>; Tue, 3 Nov 2015 15:07:08 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZtkfP-0000FVC; Wed, 4 Nov 2015 00:07:03 +0100
Message-Id: <m1ZtkfP-0000FVC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.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> <56392B6D.8030703@gmail.com>
In-reply-to: Your message of "Wed, 4 Nov 2015 10:47:25 +1300 ." <56392B6D.8030703@gmail.com>
Date: Wed, 04 Nov 2015 00:06:53 +0100
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/uJ0XRFO-zACC900pZ1VlpvaNcVI>
Subject: Re: [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 23:07:11 -0000

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

There are a few things something I don't understand in this discussion.

Suppose we have a router with one upstream ethernet interface and a
couple of downstream interfaces.

The upstream interface does not have any addresses assigned other than
link local. The router receives a prefix through DHCPv6 and assigns
a number of /64 prefixes to the downstream interfaces.

Two things should be obvious:
- the router is not going to perform DAD on addresses used by hosts on 
  its downstream interfaces
- other routers on the upstream interface are not going to use ND on
  addresses covered by the prefix, they will use the link local address
  of the router instead.

No we replace the router by a host. The host receives a prefix using DHCPv6 PD
and starts using it. Why would the host perform DAD on addresses covered
by the delegated prefix when a router would not do this?
Why would routers try to perform ND on addresses covered by the prefix 
instead sending traffic to the link local address?

There might be a problem though. Routers take part in a routing protocol.
So it should be obvious to all routers how to forward traffic to a
delegated prefix.

When prefix delegation happens over a point-to-point link then, 'the other
side' is also clearly defined. So a host could receive a prefix and it
would work.

In the case of ethernet, if a host receives a prefix over DHCPv6 PD, then a
router connected to the host has to create a routing entry that forwards
the prefix to link local address of the host (as found in the DHCPv6 requests).

How is the delegating router supposed to know this? If we have special
treatment for hosts, then another option would be to logically assign the
addresses to the ethernet interface, perform DAD and have other nodes
perform ND.

But I have no idea how that should be signalled. Manual configuration
on the delegating router? 

Consistency with CPE behavior suggests that hosts should never assign
addresses to the (upstream) link and therefor not perform DAD on those
addresses.