In your previous mail you wrote: Here I have to raise a hand. I wrote implementation that actually followed the allowed optimization: do DAD only on link-local, and then freely combine that ID with announced prefixes WITHOUT doing a separate DAD for EACH prefix*ID combination. => so you have implemented DIID.
This is still fully allowed by current RFC's, => you can't say this is *fully* allowed by current RFCs. In fact IMHO this is both allowed and forbiden so RFCs are not sound... and I still believe this is GOOD, and should not be changed. => there are two points: - RFCs don't clearly specify DAD or DIID. I believe you agree there is a real problem to fix ASAP. - we have to choose between DAD and DIID: as almost everybody implemented DAD the rough consensus is DAD. As a consequence, and observing that others may not have chosen this tactics, the code also defends plain ID, that is: if it sees a DAD for address which contains one of my ID's, it will reply to the DAD as if I had the address. => this is a good idea but is not specified at all in RFCs: you've just shown your DIID choice is not directly compatible with the common DAD choice, so something (in RFCs, not in your implementation) has to be fixed! I don't see any catastrophic failures resulting from it. => only some hundreds of junk mails in the mobile ip mailing list... Regards [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
