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

[神明達哉]

At Mon, 17 Jul 2017 08:58:18 +1200,

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

[Ole Troan]

Post by 神明達哉
At Mon, 17 Jul 2017 08:58:18 +1200,

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).

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

[Erik Kline]

Post by 神明達哉
At Mon, 17 Jul 2017 08:58:18 +1200,
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).
It's a tradeoff between how long it takes before the address is usable.
I wasn't aware tgat 4429 was more robust.
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

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

[Erik Nordmark]

Post by 神明達哉
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,

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