Hi Brian, IETF can only make recommendations to implementers, they cannot force implementers to implement anything. However, IETF is the authority on whether an implementation is compliant with an IETF specification. By making our proposed change to 2462bis, we are saying that old implementations are no longer compliant with the new 2462bis I-D. If an old implementation wishes to comply with the new 2462bis, then the software needs to be upgraded (by eliminating the "grandfathering" clause). This provides incentive for software upgrades to prevent the security problem found in our I-D.
Hemant -----Original Message----- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 10:09 AM To: Hemant Singh (shemant) Cc: JINMEI Tatuya / ????; [email protected] Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 Hemant, Your logic escapes me. Old implementations are *old* and will continue to do whatever their code does. No words in 2462bis or 2462ter or anywhere can change that. I think your proposal is a no-op. Brian On 2007-06-22 15:05, Hemant Singh (shemant) wrote: > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
