Re: To DAD or not to DAD?

[James Woodyatt <[e-mail]>]

On Wed, Feb 18, 2015 at 11:46 AM, Erik Nordmark <[e-mail]> 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 <[e-mail]>
Nest Labs, Communications Engineering