Subject: To DAD or not to DAD?

From: Erik Nordmark <[email-masked]>
Date: Wed, 18 Feb 2015 11:46:34 -0800

Hello,

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
2. Only send and receive DAD for manually configured addresses
3. Improve DAD
  3a. Better at detecting duplicates (partition-join, etc)
  3b. Less network and host impact (allow sleep schedule)
4. Do nothing a. aka go to the beach ;-)

The 3a vs. 3b implicitly refers to the list of issues in 
draft-yourtchenko-6man-dad-issues.

Given that the beach is kind of cold this time of year, we can remove 
the 4th choice from the list.
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?

Regards,
     Erik

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 18 Feb 2015 22:40:20 +0100

Thanks for starting this discussion. 

> (https://datatracker.ietf.org/doc/draft-yourtchenko-6man-dad-issues/)

I also agree with all issues explained in the above  draft. I guess these
issues are more tangible in networks of constrained devices unless the
networks consists of many nodes. But there is a question here that might be
good to cover when decide about to do DAD or not to do (or worth to think
about it) is that whether the large enterprises with large networks and
large number of nodes would prefer to (or already) use fully manageable
networks (such as stateful DHCP) or they would prefer to use less or no
manageable mechanisms such as NDP, stateless DHCPv6. 

> Would it be helpful to present draft-yourtchenko-6man-dad-issues in
Dallas?

Yes, I think it is really worth to discuss.

Thanks,
Best,
Hosnieh

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 19 Feb 2015 10:35:22 +1100

Hi Erik,

It’s been a while! 

>4. Do nothing a. aka go to the beach ;-)

=> Personally, I think some of the inefficiencies mentioned are more
theoretical than practical. I think in all large wireless system
(cellular) the DAD issue is basically solved because they’re point to
point links. As for delays before using an address, optimistic DAD solves
this issue as well.

So IMHO yes collisions should be rare but I just don’t see DAD as this
major cost given the tools we have in various scenarios. So go to the
beach! It’s warm here so the beach is fine in the southern hemisphere :)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2015 13:43:26 +1300

On 19/02/2015 08:46, Erik Nordmark wrote:
> 
> Hello,
> 
> 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.
> 

A true story about buses in Geneva. It's an IPv4 story, but never mind.
Some of those buses have multiple independent TV screens with info
about the next stop. Once or twice a month, when I was a daily user
of those buses, I would see the Windows warning box about duplicate
IP addresses on one or two of the screens in the bus.

I don't live there any more, and they may have fixed it, but my point is
that options 1 and 2 are simply not OK, considering that we are talking
about billions of installations over the next century or more. Murphy's
law really does apply.

> 4. Do nothing a. aka go to the beach ;-)

We can certainly discuss whether the problem is serious enough
to justify the work. But where I live, the beach is quite OK
right now.

    Brian

> 
> The 3a vs. 3b implicitly refers to the list of issues in draft-yourtchenko-6man-dad-issues.
> 
> Given that the beach is kind of cold this time of year, we can remove the 4th choice from the list.
> 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?
> 
> Regards,
>     Erik
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 19 Feb 2015 05:16:57 +0000 (UTC)

I'd prefer to keep DAD. I don't have fond memories of early 1990s pre-IPv4 DAD when 5 programmers decided to copy their PCs' TCP/IP configuration's onto each of their workstations and I had to troubleshoot 5 different devices with the same IP address.
I think improving it would be good i.e., option 3.
One recent problem I've seen is that in a transport network at my most recent employer, sometimes layer 2 loops were left in place "within a link" after testing.
The router operators at both end would see the link as up. If the operators verified that they definitely had different addresses on either end via the phone, the failed IPv6 DAD check would be the obvious give away that there is a layer 2 loop in the link somewhere.
As IPv4 DAD is optional, and unlikely to be implemented on routers, capturing and looking at packets on the interface is the only other option for layer 2 loops that impact IPv4 traffic, and on higher end routers that isn't necessarily as easy or quick as it sounds.
Hmm, on a slight tangent, I wonder if it might be be useful to enhance the DAD process to perform further IPv6 link validation, similar to what routing protocol Hellos do e.g., a MTU check and perhaps a two way check on point-to-point links. 
      From: Erik Nordmark <[email-masked]>
 To: "[email-masked]" <[email-masked]> 
 Sent: Thursday, 19 February 2015, 6:46
 Subject: To DAD or not to DAD?

Hello,

Regards,
    Erik

---

From: Alejandro Acosta <[email-masked]>
Date: Thu, 19 Feb 2015 00:51:36 -0430

+1 to Mark ZZZ's comment.
I would agree to keep DAD and try to improve it as it was mentioned in
option 3.

Alejandro,

El 2/19/2015 a las 12:46 AM, Mark ZZZ Smith escribió:
> I'd prefer to keep DAD. I don't have fond memories of early 1990s
> pre-IPv4 DAD when 5 programmers decided to copy their PCs' TCP/IP
> configuration's onto each of their workstations and I had to
> troubleshoot 5 different devices with the same IP address.
>
> One recent problem I've seen is that in a transport network at my most
> recent employer, sometimes layer 2 loops were left in place "within a
> link" after testing.
>
> The router operators at both end would see the link as up. If the
> operators verified that they definitely had different addresses on
> either end via the phone, the failed IPv6 DAD check would be the
> obvious give away that there is a layer 2 loop in the link somewhere.
>
> As IPv4 DAD is optional, and unlikely to be implemented on routers,
> capturing and looking at packets on the interface is the only other
> option for layer 2 loops that impact IPv4 traffic, and on higher end
> routers that isn't necessarily as easy or quick as it sounds.
>
> Hmm, on a slight tangent, I wonder if it might be be useful to enhance
> the DAD process to perform further IPv6 link validation, similar to
> what routing protocol Hellos do e.g., a MTU check and perhaps a two
> way check on point-to-point links. 
>
> ------------------------------------------------------------------------
> *From:* Erik Nordmark <[email-masked]>
> *To:* "[email-masked]" <[email-masked]>
> *Sent:* Thursday, 19 February 2015, 6:46
> *Subject:* To DAD or not to DAD?
>
>
> Hello,
>
> [email-masked] <mailto:[email-masked]>

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Feb 2015 09:49:01 +0100

Brian,

> about billions of installations over the next century or more. Murphy's

I think it is invalid to use IPv4 as an example.
(IPv4 ACD provides better collision detection than IPv6 btw).

if my math (or wikipedia's is correct), you need 6 million devices on a link to get a one in a million chance of a collision.
http://www.wolframalpha.com/input/?i=sqrt%282*2%5E64ln%281%2F1-0.000001%29%29

please help me understand why that is a problem?
noting that on wireless there is a significant probability that DAD will _not_ detect a duplicate anyway.

> to justify the work. But where I live, the beach is quite OK

cheers,
Ole

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 19 Feb 2015 22:50:39 +1100

>
>if my math (or wikipedia's is correct), you need 6 million devices on a
>link to get a one in a million chance of a collision.

=> Is that assuming everyone is using a good RNG and people are not
manually configuring addresses?

Hesham

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Feb 2015 13:05:55 +0100

Hesham,

> manually configuring addresses?

clearly.

what has been discussed a few times is to do DAD only for addresses likely to collide. e.g. manually configured addresses.

cheers,
Ole

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 19 Feb 2015 23:46:42 +1100

-----Original Message-----
From: Ole Troan <[email-masked]>
Date: Thursday, 19 February 2015 11:05 pm
To: Hesham Soliman <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, Erik Nordmark
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: To DAD or not to DAD?

>>>http://www.wolframalpha.com/input/?i=sqrt%282*2%5E64ln%281%2F1-0.000001%
>>>29
>>> %29
>> 
>what has been discussed a few times is to do DAD only for addresses
>likely to collide. e.g. manually configured addresses.

=> Thanks, yes I saw that. I guess my point of the rhetorical question,
which I should’ve included, is that if we’re going to keep it and add more
branches on when it should be used, we’re just adding more complexity
when, at least to me, the cost of just leaving it as it is today is zero.
So, if we’re keeping it for special cases then lets just keep it as is.
Maybe I missed some of the discussion but the inefficiency claims I saw in
draft and on the list don’t justify removing it.

It would be good to see some real data from deployed networks which show
that there is a real-world problem. To me claims such as energy
inefficiency are not relevant for the large cellular networks but maybe
for others like sensor networks something special should be done (I
haven’t kept up with the 6lowpan work, which might’ve fixed it). Other
claims like handling fragmented links should be irrelevant because it was
never the intention of DAD. Delays before using an address are solved by
optimistic DAD. Finally, if there are faulty implementations then point it
out to them and they should be fixed.

Hesham

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Feb 2015 14:07:26 +0100

Hesman,

> out to them and they should be fixed.

point to point links isn't the target for this work.

see:
http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01
http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01
https://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-06
https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-00

cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 19 Feb 2015 15:22:32 +0000

My take-away from https://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01 was that the contribution of DAD to the multicast chatter on a network is nothing compared to the contribution of UPnP SSDP and DNS SD/mDNS. And I see these latter as continuing to increase much more than DAD. So doing something to limit DAD really does nothing to solve the broader "multicast" problem.

I would like to see a more holistic approach to solving the problem of vast quantities of multicast traffic, rather than just going after DAD.
Barbara

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Feb 2015 08:43:03 -0800

On 2/18/15 3:35 PM, Hesham Soliman wrote:
> point links. As for delays before using an address, optimistic DAD 
> solves this issue as well.

Hesham,

Might make sense to read draft-yourtchenko-6man-dad-issues. Of the 11+ 
issues/sections I think there are only two that are about efficiency.

For instance, if we depend on DAD it would make sense for it to have 
better tolerance against partions/join on the link.

One of the potential solutions might to treat large wireless systems 
(WiFi ;-) as point-to-point links.
But before getting into solutions I think it would be good for the WG to 
look over the set of issues with DAD.

    Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2015 17:58:20 +0100

> Dallas? Or can we have an email discussion without/prior to such a

Recenlty there are a number of new ways of generating IID and addresses 
subsequently.  I suspect the initial implementations will be subject to 
collisions, and DAD would detect them.

There are some new devices on the market with MAC addresses that only 
have the corporate id, but not the individual identifier.  These risk 
clashing during SLAAC.

As for help in network partition/join: in some of these networks one may 
appreciate less chatter, i.e. avoid long additional useless DAD.  Maybe 
an exchange of RAs would be sufficient to safely assume duplicates dont 
exist, in addition to their other roles; only if RA identifies 
duplicates then run full DAD (3 NSs); but dont systematically run DAD by 
principle.  In some cases only.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Feb 2015 09:05:29 -0800

> I think improving it would be good i.e., option 3.

Next step would be to look over raft-yourtchenko-6man-dad-issues to see 
if some issues (that have not yet been solved) are more important to 
solve than others. The slides had two choices under 3 trying to 
summarize this
  3a. Better at detecting duplicates (partition-join, etc)
  3b. Less network and host impact (allow sleep schedule)

> obvious give away that there is a layer 2 loop in the link somewhere.

For that one we already have a fix on the books; the enhanced-dad draft 
uses random nonce to be able to detect DAD probes that are looped back.

> way check on point-to-point links.

I don't know if we want to go that far. Routing protocol hellos already 
do this. So might BFD.

    Erik

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 Feb 2015 13:03:43 -0800

Erik,

With no hats on.

> On Feb 18, 2015, at 11:46 AM, Erik Nordmark <[email-masked]> wrote:
> 
> 
> Hello,
> 
> 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.
> 

I think we know that duplicates are not common with IEEE EUI based IIDs.  In the case of duplicates at the L2 on a LAN, there is a bigger problem for the network operator to solve.  I don’t think DAD brings very much in this case.

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

I note we are in the process of moving away from IEEE EUI based IIDs to software generated pseudorandom numbers.  Lots of good reasons to do that, but I don’t think we know how well this new software will work in regard to duplicates.  It should work fine, but there will be bugs and possibly increased duplicates if different algorithms are chosen.  For this reason, I think that we should continue using DAD for software generated IIDs, at least until we get more operational experience.

> More seriously, the WG needs to decide how to move forward with DAD.

I agree.

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

Yes, for both.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Feb 2015 10:07:46 +1300

> what has been discussed a few times is to do DAD only for addresses likely to collide. e.g. manually configured addresses.

So, you are absolutely certain that over the next hundred years or so,
nobody anywhere will screw up their technology in such a way, for example,
that a DHCPv6 server assigns the same IID to more than one host?
Or that a pseudo-random number generator is erroneously run twice with
the same seed? We're talking about billions, not millions, of deployments.
If it can go wrong, it will.

And I think IPv4 is a perfectly valid comparison. I don't know how the
system I was referring to was set up, but I bet the intention was that
each host got a unique address. It went wrong.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Feb 2015 22:25:15 +0100

Brian,

> If it can go wrong, it will.

sure, and if you read the DAD issues draft you will see that DAD is not solving many of those corner cases.

> each host got a unique address. It went wrong.

let me bring an example as well then.
two IETFs ago I tried configuring a duplicate address on the IETF WIFI. that worked just 'fine'. that is DAD didn't detect the duplicate. DAD requires two multicast messages, and on a busy IETF WIFI the probability of getting multicast through is low enough that DAD failing to detect a collision is not uncommon.

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Feb 2015 14:09:42 -0800

> I would like to see a more holistic approach to solving the problem of vast quantities of multicast traffic, rather than just going after DAD.

The design team has collected a bunch of information around the 
multicast traffic. Ole sent some of the specific drafts in an email 
today. (And elsewhere in the IETF folks are looking at mDNS proxies.) In 
addition to those drafts (and earlier ones from about a year ago) the 
design team has discussed summarizing the space by creating report in an 
Internet Draft.

However, the DAD question is somewhat separate. It came up as a side 
effect of asking the question "is DAD inefficient for hosts that want to 
sleep".
That question resulted in other ways that DAD might need to be improved 
- see the list in the draft. Note that all but two of those items are 
*not* about efficiency but about DAD's ability to detect duplicates when 
they exist on the network.

Regards,
    Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 19 Feb 2015 23:35:39 +0100

In your previous mail you wrote:

>  => Is that assuming everyone is using a good RNG

=> make it a bit harder: a good RNG at boot time on a cheap device
without stable memory (:-).

=> and people are not manually configuring addresses?

=> or manually copying configurations including manual addresses
and of course without changing them? (BTW the first DAD report
I saw (and perhaps the first in the IPv6 history) was exactly
this case: a copy from a router to another one. Since that day
(that: it was > 15 years ago) I has believed in DAD...)

Regards

[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Thu, 19 Feb 2015 22:51:28 +0000

Hi Francis, 

I would like to support your point.

I am still getting queries from IPv6 deployers (primarily those with responsibility for servers rather than networks), who ask if they can manually assign a "meaningful" address.

Regardless of our specifications for address allocation policy, human allocation of addressing will occur and has a higher chance of collision. Therefore DAD is still required.

Unfortunately, these people can also now configure their MAC addresses in many circumstances, so there is a chance of MAC collision too (e.g. 01:fe:ed:ab:ba:01). Including information in the DAD challenges which a host could use to track their previous requests may be a good way to distinguish between looped and IPv6 Addr(+MAC?) duplicate packets.

Sincerely,  

Greg Daley
Solutions Architect
Logicalis Australia Pty Ltd
m +61 401 772 770

> From: ipv6 [mailto:[email-masked]] On Behalf Of Francis Dupont
> Sent: Friday, 20 February 2015 9:36 AM
> To: Hesham Soliman
> Cc: Erik Nordmark; [email-masked]
> => make it a bit harder: a good RNG at boot time on a cheap device without
> stable memory (:-).
> 
> => or manually copying configurations including manual addresses and of
> course without changing them? (BTW the first DAD report I saw (and perhaps
> the first in the IPv6 history) was exactly this case: a copy from a router to
> another one. Since that day

---

From: James Woodyatt <[email-masked]>
Date: Thu, 19 Feb 2015 15:15:26 -0800

On Wed, Feb 18, 2015 at 11:46 AM, Erik Nordmark <[email-masked]> 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.
>

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.

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

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

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

> Dallas? Or can we have an email discussion without/prior to such a

That draft needs to say something about network sleep proxies.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Feb 2015 15:57:57 -0800

On 2/19/15 3:15 PM, James Woodyatt wrote:
> 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.
>
> 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.

James,

FWIW I don't believe we should deprecate it either. Put it on the slides 
to wake folks up. That seems to work better on the mailing list than it 
did in the meeting room in Honolulu ;-)
> That draft needs to say something about network sleep proxies.

Is there any detailed descriptions of what sleep proxies do with ND? 
I've just seem a wikipedia article which didn't have any detail.

    Erik

>
>
> -- 
> james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 20 Feb 2015 11:22:08 +1100

>issues/sections I think there are only two that are about efficiency.

=> That’s right, I did read it before opening my mouth :). I only
commented on efficiencies because it stuck in my head after looking at
your slides. I think I made more comments on other issues in another email
to Ole.  
I see those issues falling into 4 categories:
1. Increasing the scope of DAD’s support (e.g. supporting
partitions/joins, multi-link subnets ..etc), which were known “out of
scope” features before.
2. Problems which are not true because we have documented solutions for
them (e.g. delays before using an address)
3. Strange link layer behaviour. There is only one issue that struck me
there related to link layers that appear to be up but are not really up
because they’re running STP (issue 3), which strikes me as a misleading
“link up” indication, which can cause more problems than just DAD.
4. Implementation bugs (issue 5 only)

I guess as always YMMV on whether a valid problem is worth solving (i.e.
category 1 above) and the group decides that based on experiences. I only
commented on the ones that I didn’t agree with as problems.

DISCLAIMER: Ole sent a few links in addition to the draft, which I haven’t
read yet. 

>better tolerance against partions/join on the link.

=> Right, that falls under category 1. For me that depends on data showing
how serious a problem this is. Personally I don’t know.

>look over the set of issues with DAD.

=> Agreed. We need to be on the same wavelength when it comes to the
actual problems. 

Hesham

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 20 Feb 2015 02:02:09 +0000 (UTC)

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 <[email-masked]>
To: Erik Nordmark <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, 20 February 2015, 10:15
Subject: Re: To DAD or not to DAD?

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

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

I'm okay with improving DAD, so long as we don't break any DAD proxies. That way lies madness and calamity.
 
>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. 

--

---

From: t.petch <[email-masked]>
Date: Fri, 20 Feb 2015 10:01:46 +0000

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Ole Troan" <[email-masked]>; "Hesham Soliman"
<[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>
Sent: Thursday, February 19, 2015 9:07 PM

Brian

I have seen the same Microsoft error message displayed when I was trying
to find which bus to catch at a Portuguese bus station.

I have also seen it in a less public context when the users of the
configuration manual of a well know router supplier did not understand
that the examples in the manual were examples, not meant to be
transcribed literally to the production boxes (which, of course, some of
the values in the examples must be:-).

Where human nature is concerned, forget probability and statistics.

Tom Petch

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Feb 2015 12:48:19 +0100

Le 19/02/2015 23:51, Greg Daley a écrit :
[...]
> Unfortunately, these people can also now configure their MAC
> addresses in many circumstances, so there is a chance of MAC
> collision too (e.g. 01:fe:ed:ab:ba:01)

I think these feed abba matters deserve collecting in one dictionary.

It's useful for network planners who need addresses to assign on 
devices, to address scanners defence, to trainers, DHCP and automatic 
collision avoidance.

- IPv6 words in several languages made of 1..4 letters A-F, 0-9 and to
   some extent substitutes 0(O), 1(i), 2(Z), 5(S), 6(G), 8(H), C(K).
   (e.g. :abba:, fade, fed:c0de, def1:g0d, ac1d:cafe, deaf:d06,

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2015 16:02:13 +0100

In your previous mail you wrote:

> I am still getting queries from IPv6 deployers (primarily those with
> responsibility for servers rather than networks), who ask if they
> can manually assign a "meaningful" address.

=> for me it was more an address (or IID) I can easily remember.
Note when you tried it has many advantages (e.g., transparent
upgrade of the hardware) you want to do it again, even after
DAD showed the disadvantage (:-)...

> Regardless of our specifications for address allocation policy,
> human allocation of addressing will occur and has a higher chance of
> collision. Therefore DAD is still required.

=> it was my argument. Note I was (am?) lucky enough to have never
got a duplicate MAC address (the worst I found is a vendor applying
the "one address per device" with device ==  box in place of the
usual device = NIC). You have plugable NICs too but by definition
one can be plugged only at one place so could not raise DAD errors.

> addresses in many circumstances

=> in fact there is an obscure IBM ethernet NIC without a MAC address
changing feature (for security reasons).

> so there is a chance of MAC collision too (e.g. 01:fe:ed:ab:ba:01).

=> never got this (and changed a MAC address once per decade).

> Including information in the DAD challenges which a host could use
> to track their previous requests may be a good way to distinguish
> between looped and IPv6 Addr(+MAC?) duplicate packets.

=> yes, adding a transaction ID (or a nonce if security is involved)
to DAD should improve it.

Thanks

PS: to summary I don't want the 1 (deprecate DAD).

---

From: Warren Kumari <[email-masked]>
Date: Fri, 20 Feb 2015 15:49:44 -0500

On Fri, Feb 20, 2015 at 6:48 AM, Alexandru Petrescu
<[email-masked]> wrote:
> It's useful for network planners who need addresses to assign on devices, to
> address scanners defence, to trainers, DHCP and automatic collision
> avoidance.
>

Depends on how 1337 your leetspeak is, but:
cat  /usr/share/dict/words | grep -E '^[abcdefABCDEFolzs]+$' | tr
'olzs' '0125' | strings -6
does a passable job. e.g:
wkumari-macbookpro1:dict wkumari$ cat  /usr/share/dict/words | grep -E
'^[abcdefABCDEFolzs]+$' | tr 'olzs' '0125' | strings -6 | grep c0ffee
c0ffee
c0ffee1eaf

You do get some valid, but obscure ones, like: Ba5e11aceae -
Basellaceae, a family of flowering plants[0]...

W

[0]: Let's pretend that I knew that, and didn't use wikipedia...

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Feb 2015 14:27:12 -0800

Hesham,

Part of the question for the WG is whether some of those have become 
more important in the last 20 years; the network might have changed.
We set the requirements in the hallways at the IETF in Stockholm 1995. 
At the time we saw some incidence of duplicate Ethernet addresses (due 
to manufacturing issues),  we knew that static assignment could have 
issues. But we didn't have any temporary addresses, not even DHCPv6, and 
WiFi didn't exist. I recall we also made the assumption that getting a 
log/console message in the case of a duplicate was sufficient; the user 
at the desktop would notice fix and it.

With recommendations to default to randomly generated IID, and with lots 
of L2 technology with different packet drop characterstics (radio with 
inherent more drops, 802.11 with multicast a lot less reliable than 
unicast, and also the initial outage below in #3), plus IoT having lots 
of "unmanned" devices, it might make sense to revisit things.

That is why I'm asking the WG.

> them (e.g. delays before using an address)

RFC4429 on Optimistic DAD makes some notes about causing TCP RST when 
there is a duplicate. Don't know if all application protocols (on 
unmanned devices) will always retry in such a case.

> “link up” indication, which can cause more problems than just DAD.

The Ethernet behavior is just something we need to live with whether we 
like it or not.
The fact that the 802 link is up means that 802.1X can start, but it 
doesn't mean that the port is forwarding. We also have modems for e.g., 
DSL and cable which might operate in bridge mode, resulting in the same 
type of initial outage when the link comes up.

FWIW 6man has developed ways to deal with this for some parts - I'm 
thinking of resilient-RS. But DAD remains useless in when the initial 
packets are dropped.

IMHO these L2 behaviors shouldn't cause problems because we are supposed 
to develop robust protocols using things like retransmissions.
DAD isn't one of those.

> 4. Implementation bugs (issue 5 only)

Did you mean 5.  Interaction with looped interfaces
That isn't an implementation bug AFAIK; but we do have a solution for it 
already.
> commented on the ones that I didn’t agree with as problems.

I don't know in which of the above 4 items you categorized the following:
     4.  Behavior on links with unreliable multicast
     8.  Behavior on collision
     10.  Wake-up and L2 events

Those are issues which make DAD less able to detect duplicates when they 
do exist.

In my mind most of the issues are around that robustness of DAD, under 
different network and deployment conditions, then I think we have a 
problem. If we don't want to fix it, then it probably makes sense 
documenting the conditions under which it would fail.

My 2 cents,
     Erik

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 21 Feb 2015 02:58:43 +0000

> With recommendations to default to randomly generated IID, and with lots of L2 technology with different packet drop characterstics (radio with inherent [ > more drops, 802.11 with multicast a lot less reliable than unicast, and also the initial outage below in #3), plus IoT having lots of "unmanned" devices, it  >might  make sense to revisit things.

 >That is why I'm asking the WG.

[SC>] We have discussed the importance of adding *optional*  IPv6 ND behavior  during 
https://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-nd/ adoption call.

The chatty behavior of ND, doing DAD, multicast messages cause penalties in networks that are not traditional Ethernet IP subnets.
The practical  options are 1) not to adopt IPv6 ND or 2) modify its behavior in different SDO accordingly. Another example: some of the wireless phone vendors optimize device ND behavior ( does not respond to DAD when sleepy)  in order to fit to the power  requirements.

While we can of course adjust the constant values and tweak small changes with RA and RS etc. to achieve a bit of optimization for relatively small devices, perhaps the question is to the community:

 If 6man WG charter and folks would like to deal with the IoT or constrained device type wireless IPv6 networks or these type of  IPv6 related work would be best done in constrained node related workgroups?

-Samita

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 21 Feb 2015 21:29:22 +1100

>That is why I'm asking the WG.

=> Thanks for the detailed background. I want to make sure that I’m clear
that I’m not at all against revisiting things. Increasing the capability
of DAD due to changing environment is a valid argument. The one thing I’m
against was the option to remove/deprecate DAD. So when I categorised the
“new scope” issues I didn’t do that in an attempt to dismiss them.

>unmanned devices) will always retry in such a case.

=> OK, perhaps this could be highlighted in the issue/draft itself. I.e.
that we know of one approach to fix this but we’re concerned about it’s
side effect in the aforementioned case.

>type of initial outage when the link comes up.

=> Oh yes that happens in cable/DSL modems now, but that usually means you
have no external access at all, but on-link communication is possible in
V6. What I don’t quite understand about this scenario is whether it’s
sufficient to not show that linkup to upper layers or have a more
sophisticated way of showing it (e.g. Link pending, or coming up) because
it seems to be an issue for general communication from any node. I mean,
it’s bigger than DAD. If the link is not ready for communication, then the
host hasn’t even got a prefix yet. The only way it can have an address is
either because it had one already or it was manually configured with one.
In both of those cases all communication will fail.

>to develop robust protocols using things like retransmissions.

=> OK, thanks for the reference to resilient RS.

>That isn't an implementation bug AFAIK; but we do have a solution for it

=> I think the draft says that it could be an implementation bug in some
devices. It does also mention that we have a solution for it in 4862 but
it “guesses” that it might be an implementation error.

>     10.  Wake-up and L2 events

=> to me 4 and 10 look like new features. Perhaps 8 is a bug in the old
approach that should be addressed.

>Those are issues which make DAD less able to detect duplicates when they

=> Agreed. 

>documenting the conditions under which it would fail.

=> Agree with the approach. I’m in no way against expanding the feature
set as long as we don’t remove DAD.
I would hope though, if we expand the feature set that it doesn’t disrupt
current deployments of course and has no impact on interoperability, which
can be done I’m sure. Also, I like to start from where things ended up to
make sure that we learnt from past work. So it would be good to consider
efforts like opti DAD ..etc so we don’t start from scratch.

Thanks,
Hesham

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Feb 2015 15:49:36 +0000

I'd go with option 3 and see which issues from draft-yourtchenko-6man-dad-issues could be addressed.   I already like what Erik has highlighted in bold for DAD issues in http://www.ietf.org/proceedings/91/slides/slides-91-6man-11.pdf.  The issues in bold are:

Behavior on links with unreliable multicast
Energy efficiency
Wake-up and L2 events

One adds complexity to the host to special-case using DAD for manually configured IPv6 address vs. a DHCPv6- or SLAAC- acquired address.  Also, as others have said, DAD is needed to detect duplicates in many networks.  

Regards,

Hemant 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Wednesday, February 18, 2015 2:47 PM
To: [email-masked]
Subject: To DAD or not to DAD?

Hello,

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 2. Only send and receive DAD for manually configured addresses 3. Improve DAD
  3a. Better at detecting duplicates (partition-join, etc)
  3b. Less network and host impact (allow sleep schedule) 4. Do nothing a. aka go to the beach ;-)

Regards,
     Erik

---

From: Fernando Gont <[email-masked]>
Date: Tue, 24 Feb 2015 19:01:08 -0300

Hi, Erik,

> 4. Do nothing a. aka go to the beach ;-)

I'm all for option 3.

> Dallas? Or can we have an email discussion without/prior to such a

I'd suggest to start email discussion prior to the f2f meeting such that
we can probably frame the discussion and then mke more progress during
the f2f meeting.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Feb 2015 13:22:45 +0000

Hello Erik;

Same here, option 3, both a and b. The scenarios that demand it are out
there already.

And now is not a good time for the beach anyway. So let's do real progress
before summer!

I'd note that 3a and 3b are largely different in appearance, but maybe not
in the solution space.
It sounds really bad in a split-join scenario to have all devices chat at
the same time to figure out what's going on.
Which boils down to some degree of centralization/reflection which in turn
could allow 3b quite naturally...

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: mardi 24 février 2015 23:01
> To: Erik Nordmark; [email-masked]
> > 1. Deprecate DAD - it is expensive and duplicates are not common 2.
> > Only send and receive DAD for manually configured addresses 3. Improve
> > DAD  3a. Better at detecting duplicates (partition-join, etc)  3b.
> > Less network and host impact (allow sleep schedule) 4. Do nothing a.
> > aka go to the beach ;-)
> 
> I'm all for option 3.
> 
> 
we can
> probably frame the discussion and then mke more progress during the f2f
> meeting.
> 
> Thanks,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
>

---

From: James Woodyatt <[email-masked]>
Date: Wed, 25 Feb 2015 11:43:35 -0800

Well, there's the ECMA-393 standard, which was mostly written from the
perspective of sleep proxies integrated with network interface peripheral
devices, but it's not hard to see that what those sleep proxies inside the
NIC are doing could be extended to work with a network sleep proxy like
what Apple shipped in OS X hosts, the Apple TV and the AirPort base station
product line: when a host goes to sleep, it registers its services with a
sleep proxy, which acts as a ND and ARP proxy for the sleeping host,
answers mDNS-SD service requests for it, and sends wake-on-LAN packets to
the sleeping host when a TCP SYN, or initial UDP packet, or what have you
arrives at the sleep proxy host.  When the sleeping host awakens, it sends
ARP and ND advertisements to invalidate cache entries on the network that
previously pointed to the sleep proxy.

On Thu, Feb 19, 2015 at 3:57 PM, Erik Nordmark <[email-masked]> wrote:

>> 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
> to wake folks up. That seems to work better on the mailing list than it did
> in the meeting room in Honolulu ;-)
>
> Is there any detailed descriptions of what sleep proxies do with ND? I've
> just seem a wikipedia article which didn't have any detail.
>
>    Erik
>
>
>>
>> --

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 26 Feb 2015 13:34:47 +0000

Erik

Thanks for posting this to the list, more feedbacks/ideas then during the
WG meeting (where the beach was nearby).

From the emails on the list, it appears to me that DAD really needs to be
improved

-éric (who lost hours to spot why DAD was detecting a duplicate... Cloned
laptops had different MAC addresses but the same DUID...)

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 28 Feb 2015 00:35:19 -0800

> “new scope” issues I didn’t do that in an attempt to dismiss them.

OK
> side effect in the aforementioned case.
We'll add a note about this to the draft.

> In both of those cases all communication will fail.

Protocols are supposed to be robust against packet loss. The fact that a 
modem or the spanning tree protocol can cause outages for an tens of 
seconds should just be a particular loss pattern meaning that things 
should recover after the connectivity is back.

RS didn't do that, but now we have resilient-rs.

But I don't think it is useful to have some more fine-grained view of 
different flavors of "link up" means. Do do that one would need to add 
something to the IEEE 802 set of protocols, get the Ethernet device 
drivers to implement that new thing, and then make the DAD code use it.
Still, after that effort, it would only handle the STP case and not the 
modem case (AFAICT). In the modem case the local link in the house is 
up. But that Ethernet doesn't know that it is being bridged over a modem 
to some other devices; that bridging logic is layered on top of the 
Ethernet port behavior.

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 28 Feb 2015 11:59:30 +0000

Specifically for a cable modem, I had contacted Andrew privately.   My comment to him for draft-yourtchenko-6man-dad-issues-00 and cable modem is included below between squared braces.

[There is this text in your document

"Similarly, a DSL or cable modem whose line status is invisible to IP
   stack either within the modem or to a host connected on the Ethernet
   side, also renders the DAD ineffective - the delay before the
   connectivity is established can be much longer than any DAD wait."

Remove cable modem from the above paragraph.  Cable standards mandate each time the RF interface of the modem bounces, the modem initiates DAD; so does RFC 4862.  Also, any cable modem resets its LAN interface if the modem's RF interface bounces.  This is also mandated in cable standards.]

Hemant

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Saturday, February 28, 2015 3:35 AM
To: Hesham Soliman; Erik Nordmark; [email-masked]
Subject: Re: To DAD or not to DAD?

Protocols are supposed to be robust against packet loss. The fact that a modem or the spanning tree protocol can cause outages for an tens of seconds should just be a particular loss pattern meaning that things should recover after the connectivity is back.

But I don't think it is useful to have some more fine-grained view of different flavors of "link up" means. Do do that one would need to add something to the IEEE 802 set of protocols, get the Ethernet device drivers to implement that new thing, and then make the DAD code use it.
Still, after that effort, it would only handle the STP case and not the modem case (AFAICT). In the modem case the local link in the house is up. But that Ethernet doesn't know that it is being bridged over a modem to some other devices; that bridging logic is layered on top of the Ethernet port behavior.

    Erik

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 28 Feb 2015 23:35:23 +1100

Hemant, Erik, 

I will confess that I just don’t understand the cable modem scenario the
way you and the author understand it and that could be a flaw in my
understanding or due to different deployment models. I’ll leave the link
up indication aside, I’m not aware of cable modem deployments that act as
bridges where the upstream router (default router for every host on the
home network assuming a single link deployment), will share a prefix
across two homes for example. That is the only case where that modem’s
failure to connect to the ISP’s upstream router can cause issues when the
connection is established later.

In this simple case:

H1 <——————---->
             |   Modem <————>   ISP’s router
H2 <—————----->   

If the modem is an L2 device and it shows a link up to H1 and H2 when its
link with the ISP’s router is down, I fail to see how this will have a
negative impact on DAD if that ISP’s router is dedicating a separate
prefix for each “home”/“office” or whatever concrete container is built
around H1 and H2. 

I think I’ll just wait to see solutions or further discussion to
understand why this scenario is : 1) causing problems and 2) will be
solved by having reliable DAD.

I’m not talking about fragmented networks that are joined as a generic
case (I think that’s a clear problem in the general case), I am talking
about the above scenario because it came up several times in the
discussion. To me that link is not up and when it’s up H1 and H2 will
configure new addresses which they only need to check against each other.
Of course if that modem is a router, then it’s still the same situation
until it gets configured with a prefix.

Hesham

-----Original Message-----
From: "Hemant Singh (shemant)" <[email-masked]>
Date: Saturday, 28 February 2015 10:59 pm
To: Erik Nordmark <[email-masked]>, Hesham Soliman
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: To DAD or not to DAD?

>Specifically for a cable modem, I had contacted Andrew privately.   My
>comment to him for draft-yourtchenko-6man-dad-issues-00 and cable modem
>is included below between squared braces.
>
>Remove cable modem from the above paragraph.  Cable standards mandate
>each time the RF interface of the modem bounces, the modem initiates DAD;
>so does RFC 4862.  Also, any cable modem resets its LAN interface if the
>modem's RF interface bounces.  This is also mandated in cable standards.]
>
>Hemant
>
>modem case (AFAICT). In the modem case the local link in the house is up.
>But that Ethernet doesn't know that it is being bridged over a modem to
>some other devices; that bridging logic is layered on top of the Ethernet
>port behavior.
>
>    Erik
>
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 28 Feb 2015 13:08:57 +0000

Hesham

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Saturday, February 28, 2015 7:35 AM
To: Hemant Singh (shemant); Erik Nordmark; [email-masked]
Subject: Re: To DAD or not to DAD?

>I will confess that I just don’t understand the cable modem scenario the way you and the author understand it and that could be a flaw in my understanding or due to different deployment models. I’ll leave the link up >indication aside, I’m not aware of cable modem deployments that act as bridges where the upstream router (default router for every host on the home network assuming a single link deployment), will share a prefix >across two homes for example. That is the only case where that modem’s failure to connect to the ISP’s upstream router can cause issues when the connection is established later.

>If the modem is an L2 device and it shows a link up to H1 and H2 when its link with the ISP’s router is down, I fail to see how this will have a negative impact on DAD if that ISP’s router is dedicating a separate prefix for >each “home”/“office” or whatever concrete container is built around H1 and H2. 

A cable modem does bridge the RA from the ISP to H1 and H2 in the home.  Also a cable modem network follows the off-link model and thus the RA from the ISP router includes no PIO.   For the sake of argument in another non-cable modem network, let's say the ISP does include a PIO in the RA, then if the modem's uplink to the ISP is down and the modem shows link up to H1 and H2, we have a problem.  What if when the modem uplink is back up and the ISP has renumbered the network and a different PIO (PIO2) is sent in the RA?  The hosts didn't see any link bounce and merged the old PIO and the new PIO2.   If the ISP follows a renumbering procedure to first expire PIO, then we do not have a problem. 

Hemant

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 28 Feb 2015 13:55:14 -0800

On 2/25/15 11:43 AM, James Woodyatt wrote:
> perspective of sleep proxies integrated with network interface 
> peripheral devices, but it's not hard to see that what those sleep 
> proxies inside the NIC are doing could be extended to work with a 
> network sleep proxy like what Apple shipped in OS X hosts, the Apple 
> TV and the AirPort base station product line: when a host goes to 
> sleep, it registers its services with a sleep proxy, which acts as a 
> ND and ARP proxy for the sleeping host, answers mDNS-SD service 
> requests for it, and sends wake-on-LAN packets to the sleeping host 
> when a TCP SYN, or initial UDP packet, or what have you arrives at the 
> sleep proxy host.  When the sleeping host awakens, it sends ARP and ND 
> advertisements to invalidate cache entries on the network that 

Thanks - I'll at least add a reference to ECMA-393 and the wikpedia page 
for Bonjour sleep proxies to the draft.

    Erik

>
> On Thu, Feb 19, 2015 at 3:57 PM, Erik Nordmark <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         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.
>
>
>     James,
>
>     FWIW I don't believe we should deprecate it either. Put it on the
>     slides to wake folks up. That seems to work better on the mailing
>     list than it did in the meeting room in Honolulu ;-)
>
>     Is there any detailed descriptions of what sleep proxies do with
>     ND? I've just seem a wikipedia article which didn't have any detail.
>
>        Erik
>
>
>
>         -- 
>         james woodyatt <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 01 Mar 2015 10:16:44 +1100

>>up >indication aside, I’m not aware of cable modem deployments that act
>>as bridges where the upstream router (default router for every host on
>>the home network assuming a single link deployment), will share a prefix
>>>failure to connect to the ISP’s upstream router can cause issues when
>>>the connection is established later.
>
>>In this simple case:
>
>>H1 <——————---->
>>If the modem is an L2 device and it shows a link up to H1 and H2 when
>>its link with the ISP’s router is down, I fail to see how this will have
>>a negative impact on DAD if that ISP’s router is dedicating a separate
>>prefix for >each “home”/“office” or whatever concrete container is built
>>around H1 and H2.
>
>A cable modem does bridge the RA from the ISP to H1 and H2 in the home.
>Also a cable modem network follows the off-link model and thus the RA
>from the ISP router includes no PIO.
>   For the sake of argument in another non-cable modem network, let's say
>the ISP does include a PIO in the RA, then if the modem's uplink to the
>ISP is down and the modem shows link up to H1 and H2, we have a problem.
>What if when the modem uplink is back up and the ISP has renumbered the
>network and a different PIO (PIO2) is sent in the RA?

=> This sounds like the PIO allocated by the ISP’s to each subscriber is
done randomly everytime a link comes up and the ISP’s router doesn’t keep
track of where it sends a PIO or the lifetime of that PIO. Sounds like a
broken deployment to me. DAD is not the issue here, the issue is that the
ISP is confused about the PIO’s it sends!

>  The hosts didn't see any link bounce and merged the old PIO and the new
>PIO2.   If the ISP follows a renumbering procedure to first expire PIO,
>then we do not have a problem.

=> ISP’s don’t configure prefixes randomly and reset that everytime the
link goes down. That sounds really dangerous on several levels. I don’t
know how doing anything with DAD would fix this problem.

Hesham

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 1 Mar 2015 00:37:36 +0000

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Saturday, February 28, 2015 6:17 PM
To: Hemant Singh (shemant); Erik Nordmark; [email-masked]
Subject: Re: To DAD or not to DAD?

>=> This sounds like the PIO allocated by the ISP’s to each subscriber is done randomly everytime a link comes up and the ISP’s router doesn’t keep track of where it sends a PIO or the lifetime of that PIO. Sounds like a >broken deployment to me. DAD is not the issue here, the issue is that the ISP is confused about the PIO’s it sends!

>=> ISP’s don’t configure prefixes randomly and reset that everytime the link goes down. That sounds really dangerous on several levels. I don’t know how doing anything with DAD would fix this problem.

Agree with you.  Sorry, when I elaborated the use cases for the modem, I should have said there is no issue with DAD.   Also, it is rare when a modem is reset that the ISP router changes its prefix.   However, one reason to reset a modem is when the ISP would like the modem to acquire an DHCPV6 address using another prefix and the RA would then also advertise a different prefix to nodes behind the modem.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 1 Mar 2015 00:45:41 +0000

The ECMA-393 standard as described bellows looks useful.  However, how is information in the proxy purged?  I replace the sleeping Apple TV node with a new one.  How does the proxy purge the old one?    What if the new one gets the same IPv6 address as the old one?  The devices do not use Modified EUI-64 format for IPv6 address generation.

Thanks,

Hemant

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Saturday, February 28, 2015 4:55 PM
To: James Woodyatt; Erik Nordmark
Cc: [email-masked]
Subject: Re: To DAD or not to DAD?

> previously pointed to the sleep proxy.

Thanks - I'll at least add a reference to ECMA-393 and the wikpedia page for Bonjour sleep proxies to the draft.

    Erik

> james woodyatt <[email-masked] <mailto:[email-masked]>> Nest Labs, 
> Communications Engineering