Hi Markku, Sorry for the delay. Please see in line below against "<hs>".
-----Original Message----- From: Markku Savela [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 26, 2007 10:39 AM To: [email protected]; [EMAIL PROTECTED]; Fred Baker (fred) Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08 Related to this topic, long time ago when the choices of a) DAD only on link local, and not on other addresses derived from the same id (legal on original RFC) b) do DAD indivially on each address were discussed, I preferred (a) (and still do), and proposed an additional logic on hosts using (a): - if they see DAD probe on any address using the ID part of the assigned link local address, the host would reply as if the probed address was configured ("defend ID patch"). That solves the case where one tries to manually configure global address to some other host using the same ID part. The attempt will fail as DAD collision. It does not solve merging of two local links into one, but nothing solves that mess anyway, if there are multiple users of same ID and addresses. <hs> Please see Host1 and Host2 in the scenario we described in Section 2, bullet 4 of our I-D. Since this email, we also have a newer -01 version. Please grab that copy. In our scenario, Host1 comes online first while Host2 is powered down. Then, Host2 comes online. In this case, your "defend ID patch" doesn't work (since Host2 doesn't see Host1's DAD using MAC2). However, our solution of "not skipping DAD for any acquired unicast address" will work because if Host2 performs DAD for GUA with MAC2, then Host1 will catch this NS(DAD) and respond with an NA. I still question the sanity of "do DAD on all addresses" approach: - when router advertises a list of global prefixes, *each* and *every* node will now send DAD on each address at same time => instant DAD storm. And a host can have mulpiple id's in use... - now, if we talk about rogue hosts, one could do continous stream of RA's with 40 random prefixes, and see how the hosts behave... <hs> Let's appreciate the fact that 2462bis has already changed to say "newer implementations MUST perform DAD for every acquired unicast address". We don't have a DAD storm problem (as described above) because DAD's are initiated with a randomized delay. See section 5.4.2 of 2462bis -08 I-D, third and fourth paragraph. - Hemant and Wes -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
