Subject: [Efficientnd-dt] "DAD issues" draft

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 15 Oct 2014 22:07:17 +0200

Hi all,

finally I got to sit down and do the first rough pass on dad issues draft.

Looking forward to your feedback.

--a

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Oct 2014 16:27:42 -0700

On 10/15/14 1:07 PM, Andrew Yourtchenko wrote:
> 3.  Interaction with Spanning Tree Protocol
>
>     When a port on an STP-enabled switch comes up, it goes through three
>     phases of Listening then Learning then Forwarding.  The default is to
>     keep it for 15 seconds in Listening and 15 seconds in Learning
>     states.  During this time no user traffic is forwarded by the switch
>     from and to this port.  Therefore, if a DAD process happens during
>     this period it is guaranteed to not detect any duplicates.  This
>     results in DAD being ineffective for link-local and otherwise pre
>     configured addresses.

STP is one instance of a somewhat predictable outage.
If a link uses some modems (e.g., DSL and cable modems whose up/down 
status is not visible to the IP stack) we could also have outages that 
last for tens of seconds making DAD be ineffective. Thus it might make 
sense to add a sentence about this being a more general issue than only STP.

> 7.  Partition-join tolerance
>
>     [RFC4862] explicitly mentions this problem: "Note that the method for
>     detecting duplicates is not completely reliable, and it is possible
>     that duplicate addresses will still exist (e.g., if the link was
>     partitioned while Duplicate Address Detection was performed)."
It might make sense to add a reference to ACD (RFC 5227) as an example 
of a way to detect duplicates in IPv4/ARP - at the cost of broadcast ARP 
responses.

    Erik

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Oct 2014 07:42:53 +0000

Hi Andrew,
   Went through the draft. Looks good. Couple of more quick items to add 
in bullet form.

* DupAddrDetectTransmits can be configured to zero.
* Anycast addresses. DAD is not done for them
* Legacy 2462 clients that do DAD only once per IID (and not per address).
* Presence of DAD proxy (RFC6957)

Thanks
Suresh

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 27 Oct 2014 14:26:22 +0100

Erik,

On Thu, 23 Oct 2014, Erik Nordmark wrote:

> If a link uses some modems (e.g., DSL and cable modems whose up/down status 
> is not visible to the IP stack) we could also have outages that last for tens 
> of seconds making DAD be ineffective. Thus it might make sense to add a 
> sentence about this being a more general issue than only STP.

Thanks - reworded to generalize.

> It might make sense to add a reference to ACD (RFC 5227) as an example of a 
> way to detect duplicates in IPv4/ARP - at the cost of broadcast ARP 
> responses.

Added a reference. we can discuss the better wording later.

Thanks a lot for the comments!

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 27 Oct 2014 14:29:22 +0100

Hi Suresh,

thanks for the review and comments, some replies inline...

> * DupAddrDetectTransmits can be configured to zero.

Why would that be a problem ? An ability to turn the feature off 
(since this is the explicit purpose in the original standard) seems to be 
an important feature, rather than a bug, so I've omitted this point for 
now - we can discuss later of course and add it into next rev if I 
misunderstood something.

> * Anycast addresses. DAD is not done for them

Added.

> * Legacy 2462 clients that do DAD only once per IID (and not per address).

Added.

> * Presence of DAD proxy (RFC6957)

Added in a form of generic item that the DAD, if changed, must remain 
backwards compatible and not break DAD proxies.

--a