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

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 14 Nov 2015 00:54:45 +0000

+1 to Jinmei's comments.  I am also ccing to the 6man mailer where the topic to change anything in RFC4862 should be discussed.   

I do agree that on certain links, a lo interface should not perform DAD.   If  yes, what else should this interface not perform such as ND address resolution,  any redirects, issue any NA or NS and not join the all-nodes and the solicited-node multicast addresses.  DAD and IPv6 ND address resolution are twins.  If one is disabled then the other is as well because one does not perform DAD or ND resolution in a different routed domain.  I have also cced to WesB who is a good subject matter expert with whom I discuss such issues.

Thanks,

Hemant

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, November 12, 2015 9:36 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

At Mon, 9 Nov 2015 19:59:30 +0000,
"Templin, Fred L" <[email-masked]> 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 
> FLT>>> as unnecessary for a given interface. In this case, the address 
> FLT>>> A is not matched by a prefix in the Prefix List for the WAN 
> FLT>>> interface and it is known that the prefix will never never be 
> FLT>>> added to the Prefix List for the WAN interface by node N nor any 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

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Sat, 14 Nov 2015 12:53:50 +0100

In your letter dated Sat, 14 Nov 2015 00:54:45 +0000 you wrote:
>+1 to Jinmei's comments.  I am also ccing to the 6man mailer where the topic t
>o change anything in RFC4862 should be discussed.   
>
>I do agree that on certain links, a lo interface should not perform DAD.   If 
> yes, what else should this interface not perform such as ND address resolutio
>n,  any redirects, issue any NA or NS and not join the all-nodes and the solic
>ited-node multicast addresses.  DAD and IPv6 ND address resolution are twins. 
> If one is disabled then the other is as well because one does not perform DAD
> or ND resolution in a different routed domain.  I have also cced to WesB who 
>is a good subject matter expert with whom I discuss such issues.

I'm completely confused about the case where DAD would be needed on the
loopback interface.

In my opinion, if a host uses a source address from interface A, it should
originate the packet from interface A. Everything else is just asking for
trouble. Just fix implementations that break this. :-)

Now suppose a host that doesn't do that. Say a host will take address a_eth0
from interface eth0 and then originate the packet from interface eth1 because
the destination is onlink on eth1.

In that case, the host will not perform DAD for a_eth0 on eth1. If will only
perform DAD on eth0.

So it seems to me that if a host assigns address a_lo0 to lo0, it should do the
same. It can do DAD on lo0, which a no-op. In my preferred strict model,
that address would only be usable within the host it self.

In a weaker model, the host can originate packets with source address a_lo0
on any other interface, but it will only perform (fake) DAD on the lo0 
interface.