Subject: rationale for the default of DupAddrDetectTransmits (Re: IPv6 Routing & ND vs. Addressing)

From: 神明達哉 <[email-masked]>
Date: Mon, 17 Jul 2017 09:42:31 -0700

At Mon, 17 Jul 2017 08:58:18 +1200,
Brian E Carpenter <[email-masked]> wrote:

> > I looked up RFC4862 to find out how many DAD attempts there were,
> > because I'd assumed 3 to 4, and if so, then if that many attempts
> > failed, I'd say the link is well beyond its capacity. Something would
> > need to be done to remedy a link capacity problem in that case.
> >
> > I was surprised to find, as Ole mentioned, the number of attempts was
> > only 1 rather than 3 or 4.
>
> I'm more than surprised. I think that's a bug and IMHO it should be fixed.

Although it's probably true that at the time of RFC4862 we didn't
expect networks with much higher packet loss to be so dominantly
deployed, I don't necessarily think the current parameter of RFC4862
is a "bug".  First off, "1" is just the default of
DupAddrDetectTransmits, not a fixed constant.  Secondly, my
understanding is that DAD as defined in RFC4862 (or its predecessors)
has never been considered a very reliable duplicate detection
mechanism, so it didn't bother to make it arbitrarily less unreliable
by default (when 1 is may not be enough, there's no guarantee that 3
or 4 is enough anyway).  I also thought the "official answer" for a
high packet-loss environment is to use a more sophisticated mechanism
such as RFC4429.

(That said, I wouldn't necessarily be opposed to updating the default
value if and when we update RFC4862 so it will match the latest
deployments for leaf networks better).

--
JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Jul 2017 19:06:10 +0200

> On 17 Jul 2017, at 18:42, 神明達哉 <[email-masked]> wrote:
> 

It's a tradeoff between how long it takes before the address is usable. 

I wasn't aware tgat 4429 was more robust. 

During the efficient nd work, Erik did:
https://tools.ietf.org/html/draft-nordmark-6man-dad-approaches-02

And
https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-01

I think we essentially need ACD. 

cheers 
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Jul 2017 19:26:46 +0200

>deployments for leaf networks better).

One problem here is that the collision risk is the highest in networks
with a large number of hosts on a single link.

One common example of those are the very big wifi networks found at
conferences, etc.

However, in a big wifi network, multicast is expensive. So those networks
benefit from keeping DupAddrDetectTransmits as low as possible.

Pseudo random IIDs have the interesting property that if the IID length
is big enough and the local random number generator is of good quality,
then broken hosts on the same link cannot increase the probability of a
collision.

So if we keep IIDs at 64 bit, then we can probably argue that for
pseudo random IIDs we can ignore DAD, because any proper implementation
will never see a collision anyhow.

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Jul 2017 02:28:20 +0900

> I think we essentially need ACD.

We could recommend to do two things in concert: use optimistic
addresses and raise DAD to 3,4,5,...

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Jul 2017 20:11:20 +0200

> deployments for leaf networks better).

Jinmei,

Some of the failure modes is when the link isn't usable when the host 
configures the interface. This could be because it is on an Ethernet 
port with STP configured, and as a result all of the packets are dropped 
by the Ethernet bridge for the first 40 odd seconds. Or there is an 
dsl/cable modem bridge and the connection isn't up when the DAD packet 
is sent; it typically takes many seconds to synchronize the link.

Thus I don't think send 4 packets makes current DAD more robust.
The links that Ole pointed at has more information on this.

Regards,
    Erik