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

[Lorenzo Colitti <[e-mail]>]

On Fri, Nov 13, 2015 at 11:36 AM, 神明達哉 <[e-mail]> wrote:

> I think I understand what you are trying to say, and I tend to agree
> that it would be quite unlikely that someone else than node 'N' is
> using address 'A' in the WAN link in practice in this scenario.
> However, I think it's dangerous to just jump to the conclusion that
> DAD is not necessary in this case in some kind of standard document.
> In my understanding, DAD is designed to cover "quite unlikely
> scenarios" including cases with some broken implementations/operation.
> In this particular scenario, I would say that the original intent of
> DAD covers an "unlikely" case where the remote (or some other,
> depending the type of link) node of the WAN link is broken or some
> invalid operation and is actually using address "A".
>

RFC 4862 is says:   Duplicate Address Detection MUST be performed on all
unicast addresses prior to assigning them to an interface.

That is true in almost all cases, including DHCPv6 PD. For example, if a
device gets a /64 via DHCPv6 PD, and shares that /64 via a wifi hotspot,
then any address that the device itself forms out of that /64 MUST perform
DAD so that other devices connected to the wifi hotspot do not use the same
address.

At most we could slightly amend this to ..."MUST be performed on all
unicast addresses prior to assigning them to an interface except a loopback
interface". Even node-internal interfaces are not necessarily safe to omit
DAD on. For example, in a mobile device the application processor and
baseband processor might both be on the same link, and because they are two
separate processors running two separate network stacks, they need to do
DAD.