Subject: Notification for draft-nordmark-6man-dad-approaches-00.txt

From: Erik Nordmark <[email-masked]>
Date: Fri, 06 Mar 2015 16:37:32 -0800

Some food for thought. In case the WG wants to address some of the
issues in the "DAD issues" draft, there are some possible approaches
listed in this draft.

Regards,
    Erik

-------- Forwarded Message --------
Subject: 	New Version Notification for
draft-nordmark-6man-dad-approaches-00.txt
Date: 	Fri, 06 Mar 2015 16:33:57 -0800
From: 	[email-masked]
To: 	Erik Nordmark <[email-masked]>, Erik Nordmark
<[email-masked]>

A new version of I-D, draft-nordmark-6man-dad-approaches-00.txt
has been successfully submitted by Erik Nordmark and posted to the
IETF repository.

Name:		draft-nordmark-6man-dad-approaches
Revision:	00
Title:		Possible approaches to make DAD more robust and/or efficient
Document date:	2015-03-06
Group:		Individual Submission
Pages:		8
URL:            http://www.ietf.org/internet-drafts/draft-nordmark-6man-dad-approaches-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nordmark-6man-dad-approaches/
Htmlized:       http://tools.ietf.org/html/draft-nordmark-6man-dad-approaches-00

Abstract:
    This outlines possible approaches to solve the issues around IPv6
    Duplicate Address Detection robustness and/or efficiency which are
    specified in the "DAD issues" dradft.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 06 Mar 2015 16:35:36 -0800

Regards,
    Erik

-------- Forwarded Message --------

Abstract:

The IETF Secretariat

---

From: Sowmini Varadhan <[email-masked]>
Date: Tue, 10 Mar 2015 16:10:52 -0400

> issues in the "DAD issues" draft, there are some possible approaches
The comparisons with ACD (rfc 5227) are interesting. FWIW, solaris
makes the choice of veering from the ACD draft to avoid
 sending out too many back-to-back bcast ARP /NA replies
within "too short" an interval. Insted, solaris does a periodic, rate-limited
"address announce", for published (i.e, post-DAD) addresses. There are
2 timers, one that determines the interval at which addresses
are published/defended.  Another timer is the interval
of time after a publish-event  where the same IP, hwaddr of the
sender will be sent as a unicast response. (All of this applies to
both IPv4 and IPv6)

Addresses are published as grat-ARPS for IPv4 in Solaris
(or an unsolicited NA for IPv6).
The publish timer is rate-limited (for both IPv4 and IPv6).

RFC 3927 (the precursor of rfc 5227) goes to some length to discuss
sleepy devices, network partitioning etc. The prescription there is that
the device must start ACD (DAD probes) each time it wakes up. But,
like 5227, the link-local-spec also sends all ARP messages as bcast,
which can be seen as noisy.

--Sowmini

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Mar 2015 22:27:27 -0700

> sender will be sent as a unicast response. (All of this applies to
That sounds like a better approach than the one I jotted down in the 
draft, and it would work well with sending the announce to the 
solicited-node multicast address for the IPv6 address that is being 
announced (hence any node with a duplicate address would receive the 
announce). No need to send these unsolicited NAs to all-nodes.

But it potentially leads to constant background chatter on the link if 
all hosts have to send an address announce even if they have no other 
packets to send. I wonder if a host that has been quiet, whether 
sleeping or not, for the last N minutes could safely skip sending the 
announce.

Thanks,
    Erik

---

From: Sowmini Varadhan <[email-masked]>
Date: Wed, 11 Mar 2015 06:14:19 -0400

On (03/10/15 22:27), Erik Nordmark wrote:
> 
> But it potentially leads to constant background chatter on the link
> if all hosts have to send an address announce even if they have no
> other packets to send. I wonder if a host that has been quiet,
> whether sleeping or not, for the last N minutes could safely skip
> sending the announce.

that was the rationale for rate-limiting the periodic announce
of the NAs in solaris.

Probably the harder question is how to have sleeping hosts
efficiently defend their address. If a DAD probe is sent out
for a sleeping host, then we'd need something like the ARO 
default-router/registrar defend the address. 

But IME DAD/ACD is just "detection", it doesn't actually resolve
the conflict. Anecdotal data: on 2 occassions, I have had my IPv4
address usurped by another node on the subnet. I could use macaddrs,
TCP tracing tools etc to figure out that this was virtual machine,
and what OS it was, but before I could actually go from door-to-door
(this was at the office) to tell the owner to please use another
config, the VM had shut down  (thus the danger of the problem
recurring remained).

Things like SAVI + ARO can probably help to automate some of that
recovery. So DAD is necessary, but at the right perimeter, where
it can also be fixed with some degree of fairness?

--Sowmini