Re: To DAD or not to DAD?

And a bit more evidence that things that shouldn't be copied can mistakenly be, sometimes on a very large scale.

Tens of thousands of home routers at risk with duplicate SSH keys

http://www.networkworld.com/article/2886433/security/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html?null#tk.rss_all

If a secret key value used in the RFC7217 SLAAC Opaque IDs method suffered the same fate,  DAD would sort it out.

________________________________
From: James Woodyatt <jhw@nestlabs.com>
To: Erik Nordmark <nordmark@acm.org> 
Cc: "6man@ietf.org" <6man@ietf.org> 
Sent: Friday, 20 February 2015, 10:15
Subject: Re: To DAD or not to DAD?

On Wed, Feb 18, 2015 at 11:46 AM, Erik Nordmark <nordmark@acm.org> wrote:

>Back in November the efficient-nd design team presented slides (http://www.ietf.org/proceedings/91/slides/slides-91-6man-11.pdf)
>and a document was produced on the DAD problems (https://datatracker.ietf.org/doc/draft-yourtchenko-6man-dad-issues/)
>
>The key questions in the design team report was what to do about DAD. But we haven't had any discussion on this on the list and I'd like to get some feedback from the WG to we can move forward.
>
>The slides offered these options:
>1. Deprecate DAD - it is expensive and duplicates are not common
>

I wish I had a euro for every second I've spent chasing problems caused by expected MAC/IPv6-IID address collisions, which had the root causes of either A) MAC address cloning, or B) some network sleep proxy protocol misbehaving somewhere. I would go live on a nice beach in Italy, and I would never wear shoes again.

I've also yet to work for an employer who didn't have to deal with the problem that the factory shipped a pile of machines into the market with duplicate MAC addresses, and now we can't rely on them being unique hardware identifiers anymore. The EUI-48 and EUI-64 specifications don't actually require that, you know.

Go ahead. Say "duplicates are not common" again. I double-dog dare you. Shorter james: I would vigorously oppose deprecating DAD.

2. Only send and receive DAD for manually configured addresses
>

I've never seen a collision of this type in the wild. Doesn't mean I don't believe they happen, but my hunch is they're actually not as common as we might be assuming.

3. Improve DAD
> 3a. Better at detecting duplicates (partition-join, etc)
> 3b. Less network and host impact (allow sleep schedule) 
The 3a vs. 3b implicitly refers to the list of issues in draft-yourtchenko-6man-dad-issues.

I'm okay with improving DAD, so long as we don't break any DAD proxies. That way lies madness and calamity.

4. Do nothing a. aka go to the beach ;-)
>Given that the beach is kind of cold this time of year, we can remove the 4th choice from the list.
>

Maybe in your hemisphere it's cold.  I want to live in a world where the Endless Summer option is never removed from a list like this for any reason. 

More seriously, the WG needs to decide how to move forward with DAD.
>Would it be helpful to present draft-yourtchenko-6man-dad-issues in Dallas? Or can we have an email discussion without/prior to such a presentation?
>
 That draft needs to say something about network sleep proxies.

-- 

james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------