Subject: Re: rationale for the default of DupAddrDetectTransmits

From: 神明達哉 <[email-masked]>
Date: Mon, 17 Jul 2017 11:40:19 -0700

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

> > 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".
[...]
> > (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).

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

Perhaps I unintentionally confused others by saying I wouldn't be
opposed to increasing the default of DupAddrDetectTransmits, but I
guess we are basically on the same page.  My main point in my previous
message was that, in a response to earlier messages saying as if the
current default (1) were *the* problem and changing it is the
solution, RFC4862-version of DAD wasn't expected to be robust that
much anyway and blaming the current default or tweaking that parameter
as a kind of solution would be misdirected.

I understand the failure mode you mentioned above, and I agree just
increasing DupAddrDetectTransmits wouldn't make DAD more robust.
Isn't it consistent with my main point?

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Jul 2017 22:33:48 +0200

> Isn't it consistent with my main point?
Yes, we're on the same page.

Regards,
    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jul 2017 11:10:03 +1200

> Yes, we're on the same page.

Fair enough. My original point was that having DAD be less reliable
than basic ND, under adverse conditions such as an overloaded
802.11 network, is IMHO a real problem. Yes, duplicates should
be extremely rare but they can also be extremely harmful.

     Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jul 2017 09:42:12 +1000

> be extremely rare but they can also be extremely harmful.

So it makes me wonder if DAD was supposed to be to detect an error
that is considered fatal or just to issue a warning about what might
be a tolerable situation.

This text from RFC4862 reads like it is to detect an error considered
fatal, so it should be reliable in most cases except perhaps when the
link is beyond its designed capacity (and therefore other link
capacity related failures are likely to occur too.)

"A tentative address that is determined to be a duplicate as described
   above MUST NOT be assigned to an interface, and the node SHOULD log a
   system management error."

In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on
a link before IPv4 DAD (and DHCPv4) became available. I'd much rather
reliable DAD and failure of DAD to be considered fatal.

Regards,
Mark.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 19 Jul 2017 09:55:19 +0100

> reliable DAD and failure of DAD to be considered fatal.

Yes, address duplicates are "interesting" aren't they - especially if it's the default router address :-(

At the risk of opening another tin or worms, shouldn't DAD be an ongoing process ? Ie, rather than a simple "fire off a packet, if you get nothing back then use the address", it should do that initially, but keep looking out for evidence that the address is in use and discontinue use if it detects a conflict ?

Introduces another means of DoS - but I think if any node is in a position to trigger such an ongoing DAD collision event, then it's already in a position to cause problems (such as by firing off unsolicited ND packets ?)

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 19 Jul 2017 09:04:03 +0000

should do that initially, but keep looking out for evidence that the address is in use and discontinue use if it detects a conflict ?

Nope. :) if every node performs the check and uses the assumed address only if check passed, then no conflict afterwards.

Cheers,
Rajiv

On Jul 19, 2017, at 10:55 AM, Simon Hobson <[email-masked]<mailto:[email-masked]>> wrote:

Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Jul 2017 19:18:19 +1000

On 19 July 2017 at 18:55, Simon Hobson <[email-masked]> wrote:
> At the risk of opening another tin or worms, shouldn't DAD be an ongoing process ?
> Ie, rather than a simple "fire off a packet, if you get nothing back then use the address", it should do that initially, but keep looking out for evidence that the address is in use and discontinue use if it detects a conflict ?
>

It shouldn't be necessary.

The normal state is no duplicates, so why have all devices that have
known unique addresses continually check to see if duplicates have
occurred?

A duplicate can only occur when a node tries to bring up a new address
on the link, and that is the time for that node to check to see if the
new address is a duplicate. If the new address is a duplicate of an
existing address, the existing address user gets to keep using it, and
the new node has to pick another address.

Ongoing DAD by existing nodes could overcome the reliability issues
being discussed, however it is really better to have the new entrant
try harder. It's a once off period of checking to ensure and get the
set of addresses to being unique verses an ongoing period of checking
that has no value once the set of addresses are unique.

> [email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Jul 2017 09:38:08 +0000

Packets get dropped or a node maybe "sleeping".

There are ongoing checks based on normal ND traffic though so no explicit DAD needed.

- Bernie (from iPhone)

On Jul 19, 2017, at 11:05 AM, Rajiv Asati (rajiva) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Rajiv

---

From: Simon Hobson <[email-masked]>
Date: Wed, 19 Jul 2017 10:49:58 +0100

> that has no value once the set of addresses are unique.

I probably didn't write that very well.

Part of this discussion arose from observations that the initial DAD could fail in a statistically significant number of cases because the packet(s) got lost - filtering/rate limiting in the wireless network, the network switch has spanning tree and the port is still not in forwarding mode, ...
So it's possible for a node to obtain/generate an address, perform initial DAD, and *NOT* detect a duplicate - so configuring an address on an interface which is already in use. It's not true to say that "A duplicate can only occur when a node tries to bring up a new address on the link". You can "try harder", but unless "try harder" means keep trying ad infinitum then you still don't have a **guarantee** on anything but a perfectly lossless/error-free network. So should "try harder" mean trying several times over a few seconds ? Or should it mean trying multiple times over at least 16 seconds (default forwarding delay is 15 seconds for spanning tree), or even longer since the network admin may have set the delay to a larger value ?

You could argue that this is a network problem, but in the real world, we do have networks which aren't 100% reliable.

When I wrote "an ongoing process" I wasn't thinking of an active process of sending discovery packets, but a passive process of monitoring for indications of another host using the same address. Eg, if the network stack sees a packet on the wire with one of it's own addresses as the source address, but that packet didn't come from this node (different hardware address for example) then that's an indication that there is a duplicate.
The problem then is which node then has the right to carry on using that address !

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jul 2017 11:58:04 +0200

Bernie,

> On 19 Jul 2017, at 11:38, Bernie Volz (volz) <[email-masked]> wrote:
> 

No, there is no collision detection as part of normal ND.

Links might merge and split. See the previous links for an enumeration of DAD failure cases. 

We need an equivalent of IPv4's ACD. 

Ole

> 
> - Bernie (from iPhone)
> 
> On Jul 19, 2017, at 11:05 AM, Rajiv Asati (rajiva) <[email-masked]> wrote:
> 
>> 
>> On Jul 19, 2017, at 10:55 AM, Simon Hobson <[email-masked]> wrote:
>>

---

From: Sowmini Varadhan <[email-masked]>
Date: Wed, 19 Jul 2017 07:38:18 -0400

This was actually brought up some IETFs ago, see
https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-01

Solaris 11 actually uses a common ACD engine for both
IPv4 and IPv6. I believe (?) Microsoft also does the same, perhaps
someone from MS can confirm.

If there's an interest in this, I'd be happy to provide more details
about the Solaris implementation.

---

From: Erik Kline <[email-masked]>
Date: Wed, 19 Jul 2017 14:06:37 +0200

> about the Solaris implementation.

If it's appropriate to share with the group, I think it'd be interesting.

---

From: Sowmini Varadhan <[email-masked]>
Date: Wed, 19 Jul 2017 08:19:40 -0400

> If it's appropriate to share with the group, I think it'd be interesting.

ok, let me dig up some of my notes about the details of this,
and I'll get back on this thread. 

--Sowmini

---

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 20 Jul 2017 07:29:13 -0400

here it is:

> From [email-masked] Thu Jul 20 07:17:24 2017
> 
> A new version of I-D, draft-varadhan-continuous-dad-00.txt
> has been successfully submitted by Sowmini Varadhan and posted to the
> IETF repository.
> 
> Name:		draft-varadhan-continuous-dad
> Revision:	00
> Title:		Continuous DAD implementation in Solaris
> Document date:	2017-07-20
> Group:		Individual Submission
> Pages:		6
> URL:            https://www.ietf.org/id/draft-varadhan-continuous-dad-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-varadhan-continuous-dad/
> Htmlized:       https://tools.ietf.org/html/draft-varadhan-continuous-dad-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-varadhan-continuous-dad-00
> 
> 
> Abstract:
>    This describes an implementation of IPv6 Duplicate Address Detection
>    (DAD) in Solaris that merges concepts from RFC 5227 to address some
>    of the known issues around DAD robustness and efficiency.
> 
> 
> 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: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 13:40:58 +0200

> be extremely rare but they can also be extremely harmful.

Where "extremely rare", according to Warren's calculator
<http://ipv6-collision-probability.appspot.com/calculate>, means:

   - 1 out of 3,689,385,709 times with 100,000 hosts per network
   - 1 out of 368,971,778,652 times with 10,000 hosts per network
   - ...

Don't we have more important problems to solve?

---

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 20 Jul 2017 17:04:17 -0400

On Thu, Jul 20, 2017 at 7:40 AM, Lorenzo Colitti <[email-masked]> wrote:
> On Tue, Jul 18, 2017 at 1:10 AM, Brian E Carpenter
> <[email-masked]> wrote:
>>
> Where "extremely rare", according to Warren's calculator, means:
>
> 1 out of 3,689,385,709 times with 100,000 hosts per network
> 1 out of 368,971,778,652 times with 10,000 hosts per network
> ...
>

Hmm, one could extend that argument to seat-belts, air-bags,
air-travel-safety-regulations, and a number of things, but I, for
one, am glad, someone spent some time trying to figure it out :-)
(even though, I'm also glad I've never had to use one of these
back-up-safety-plans). YMMV, of course.

--Sowmini

---

From: Mark Smith <[email-masked]>
Date: Fri, 21 Jul 2017 08:20:33 +1000

> back-up-safety-plans). YMMV, of course.

I had a very quick look. There's no mention of anycast addresses.
They're need to be ignored because they're specifically intended to be
duplicated.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jul 2017 16:58:37 +1200

> Don't we have more important problems to solve?

Yes. Collisions caused by human error or by malicious action.

At Three Mile Island, they assumed that nobody would forget to
turn *two* valves back on. Actually, that proved to be much
more probable that turning one of them on and forgetting
the second one.

    Brian

---

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 21 Jul 2017 01:18:47 -0400

> They're need to be ignored because they're specifically intended to be

Is the above with reference to the anycast behavior described for 4861/4862?
IIRC that should be ok? NS will go out with for the anycast target addr,
but the NA will be unicast (or am I mis-remembering?) 

But I agree that the solaris implementation (which would sometimes
solmcast the NA) would need adjustment. And if we formalize this
into a draft for other implementations to follow, then we'd need to
take that (and probably some other things, to make it generally
applicable) into account.

--Sowmini

---

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 21 Jul 2017 18:18:11 -0400

> the new node has to pick another address.

that assumes that the second node asserting the address is well-behaved,
and will politely give up the address when DAD announcment from the
first node comes through.

The usurper may not always be well-behaved.

> that has no value once the set of addresses are unique.

there are other cases of network partition and rejoin, where its not
practiical to use optimistic DAD addresses for extended periods of time.

--Sowmini