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

Owen DeLong <> Mon, 16 November 2015 20:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D9A6F1B315E for <>; Mon, 16 Nov 2015 12:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.685
X-Spam-Status: No, score=-6.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L4vphPnY2yI3 for <>; Mon, 16 Nov 2015 12:48:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9EA1E1B315D for <>; Mon, 16 Nov 2015 12:48:18 -0800 (PST)
Received: from (delong-dhcp29 []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id tAGKjDle026606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 12:45:14 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B720431-2620-491C-ACAB-E2E6CDA2BD16"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Mon, 16 Nov 2015 12:45:13 -0800
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <2134F8430051B64F815C691A62D9831832F4CE72@XCH-BLV-504.nw.nos.b!>
To: "Templin, Fred L" <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] DAD again [was: 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: Mon, 16 Nov 2015 20:48:21 -0000

> This is starting to diverge from the case I originally intended this discussion to
> examine. The case I am interested in is as follows:
> - Node N receives a /64 prefix delegation for prefix P over interface eth0.
> - N assigns P to the lo interface as a /64 route. This is done to black-hole
>   unused portions of P.
> - N configures address A from prefix P, and assigns it to eth0.

N inherently cannot do this because ETH0 is the interface on which it received the DHCPv6 PD
delegation of the /64 in question.

Therefore it volates:

> [the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it
> received the DHCP message from the delegating router.]

> - N need not perform DAD for A over eth0, because the delegating router
>   has made sure that the routing system will route all packets with a
>   destination address from P to node N, and not to any other node.

In any case, N should not perform DAD for A over eth0 because A is not assigned to eth0.

However, I’m not sure how one can claim that a delegating router can ensure anything
about the behavior of other routers in the routing system.

It’s unclear to me why A would assign P to eth0 anyway. Why not just have the delegating
router assign addresses to other hosts on eth0? Why would A act as a gateway leading to
the delegating router on the same subnet?

I am finding your example more confusing that perhaps is intended.


> In this way, N can function as an ordinary host according to the strong end
> system model even though it acted as a "requesting router" in procuring a
> prefix from the delegating router. No other node X on the same link as
> N can therefore configure an address from P and have the routing system
> return packets to X. In fact, any node X that configures an address from P
> can be considered an "attacker", and the use or non-use of DAD has no
> way of preventing that. In fact, the use of DAD could give X a clue as to
> which addresses from P are ripe for attacking. So, it is in fact better to
> NOT do DAD.
> Thanks - Fred
> <>
>> Hemant
> _______________________________________________
> v6ops mailing list
> <>
> <>