Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Dec 2015 18:23:36 +0000

(re-posting)

Hi Lorenzo,

I agree that “it gets messy” if you try to avoid DAD for PD prefixes while at the
same time honoring DAD for on-link prefixes (including link-local). I confess
that my angle is coming from the use case of the AERO interface, where there
are guaranteed to be no on-link prefixes other than link-local, all link-local
addresses are administratively assigned in a way that ensures uniqueness,
and everything is driven by DHCP6-PD so setting DupAddrDetectTransmits
to 0 is tenable. So assigning addresses taken from a PD prefix to the interface
while avoiding DAD and ND works fine. But in reality, the AERO interface is
an example of “an internal interface”, so using the text in your document
the AERO use case still flies (sorry for that) and hosted applications will still
observe a strong end system model.

But, it might be worth asking whether there are other interface types (such
as NBMA), or use cases for common interface types (such as multicast-capable)
where you can get away with turning off DAD and MLD. If you can do that,
you can assign addresses from a PD prefix to the interface it arrived on.

Thanks – Fred
[email-masked]<mailto:[email-masked]>

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 9:39 PM
To: Templin, Fred L
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Fri, Dec 11, 2015 at 2:04 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
RFC4862 says that DAD does not need to be performed on interfaces that have
DupAddrDetectTransmits set to 0. The document therefore shows flexibility for
determining when DAD is needed.

Perhaps, but DupAddrDetectTransmits is an "autoconfiguration-related variable to be configured by system management for each multicast-capable interface". That statement does not allow an implementation to autonomously decide to set it to 0, nor does it allow anyone (implementation or system manager) to set it to 0 for a particular prefix, bot not other prefixes, on an interface.

You could argue that it's within the remit of v6ops to publish an operational guidance document that says that implementations could or should do this, though some might argue that that's a call that only 6man can make.

If there were the possibility that the same prefix could be delegated to more than
one node, then there would be much bigger issues that could not be resolved by
DAD anyway. It would constitute a major routing issue and, again, DAD would not
be able to resolve it. So, again, there is no need for DAD.

FWIW I do agree with you. There is no technical need for DAD in such a situation. But just because there is no technical need to do DAD doesn't mean that we can state that a host can skip doing DAD, because that violates the letter of RFC4862.

In other words, my objection is not technical, but procedural. If we want to make it possible for hosts to avoid DAD in this situation, we can't just bury that statement in this draft. We need a more targeted document and perhaps 6man involvement.