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

[神明達哉 <[e-mail]>]

At Mon, 9 Nov 2015 19:59:30 +0000,
"Templin, Fred L" <[e-mail]> wrote:

> 3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN interface.
>     Again, 'N' does not do DAD on the WAN interface because (again) 'P' is not
>     assigned to that interface.
>
>
> I don't think this  is correct. DAD will be done for the WAN interface for address A irrespective of whether P is 'assigned' to it (just as DAD is performed for Link Local Addresses).
>
> FLT>>> RFC4862 says:
> FLT>>>    -  An interface whose DupAddrDetectTransmits variable is set to zero
> FLT>>>       does not perform Duplicate Address Detection.
> FLT>>> This shows that the node has latitude in when it can deem DAD as unnecessary
> FLT>>> for a given interface. In this case, the address A is not matched by a prefix in the
> FLT>>> Prefix List for the WAN interface and it is known that the prefix will never
> FLT>>> never be added to the Prefix List for the WAN interface by node N nor any
> FLT>>> node on the WAN link.

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

I would not necessarily be opposed to the idea of allowing this
particular use case to set DupAddrDetectTransmits to 0, but I don't
think we can casually say so in
draft-ietf-v6ops-host-addr-availability.  IMO, that would require a
separate standard track document that updates RFC4862 with providing
sufficient rationale of why this can be considered an exception (and
why it's that important).

--
JINMEI, Tatuya