Hi Tatuya, Thanks for the quick review of section 5 in our new I-D. Your reading of section 5 is correct - we have proposed both new and old implementations to always perform DAD for any unicast address. You are also correct that the gross change we have proposed over 2462bis is that old implementations MUST also not skip DAD. We stress about old implementations because if older implementations that are already deployed continue to be deployed for say, the next 5-10 years, that's not good. A software upgrade to older implementation is certainly possible.
We have given a solid reason for our case - it's presented in Section 2, bullet 4 of our I-D. Please see if our reasoning is solid enough to convince IETF. Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 10:40 PM To: Hemant Singh (shemant) Cc: [email protected]; [EMAIL PROTECTED]; Wes Beebee (wbeebee); Ralph Droms (rdroms) Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Thu, 21 Jun 2007 12:31:58 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > Please see section 5 of our I-D for a proposed change to 2462bis-08 - > we hear this I-D is in Editor's queue and any changes to it must be > given ASAP. (with the document editor hat of 2462bis on) >From a quick look at Section 5 (and that section only), the key point of the proposed change is: skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do it (but existing ones still performing the optimization will not be accused of non-conformance) to skipping DAD is completely prohibited, and all new/old implementations MUST always perform DAD for any address. Is that correct? If so, I suspect it's too controversial to merge in 2462bis at this stage. This part was indeed a result of very heated discussions, and even though (I believe) we all knew that simply prohibiting it without exception was a cleaner resolution, we failed to reach a clear consensus on it; hence the current text as a sort of compromise. If your new draft could now perfectly convince those who opposed to prohibiting the DAD optimization before 2462bis goes to the AUTH48 state, I, for one, would be happy to include it to the final version of 2462bis. But I cannot be that optimistic. In any event, I don't think changing the phrase matters much; we already clearly state new implementations MUST NOT skip DAD, so the change only affects existing implementations. I suspect a certain amount of existing implementations that skip DAD as specified in RFC2462 will still keep the current behavior whatever the new 2462bis RFC specifies. But they'll eventually be replaced with new implementations, which, if conforming to 2462bis, won't perform DAD skipping. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
