> From: Thomas Narten <[EMAIL PROTECTED]> > > Note: one thing we could all be better about is defining just what > "DAD vs. DIID" means.
I had my implementation before the term "DIID" was coined. I suppose, in the effect, if I have the "id defense mode" turned on, it is very close. The main fact is that my version is just an implementation based on the autoconfigure RFC, taking the allowed DAD optimization (= do DAD on link-local, combine id with announced prefixes without doing DAD on those combinations). Some want to disallow the DAD optimization. I would like to present another proposal: ******************************************** leave autoconfigure basicly RFC as it is now ******************************************** Autoconfigururation deals only with an ID that is assigned to host and is combined with announced prefixes (A=1). If host does this, it must do DAD on link-local and doing DAD other addresses based on same ID is not required. I think autoconfiguration should be the normal mode how IPv6 nodes get their addresses. Anything else is to be treated *exceptional*, and such other mechanisms have to define their own ways of avoiding address collisions. For example, - if address is not link local, they could do DAD on corresponding link local, or - they could assign the ID from a range that is not used by the autoconfigure (put asides id range 1-1024 or somesuch for the purpose). - they guarantee that the prefix part of the address is never announced on the link with A=1 (this also guarantees that address never going to collide with autoconfigured addresses). - just hope you are lucky - etc. I have explained in other messages, that the "Do DAD on every combined address" has some unpleasant features, caused by the "delayed fail mode". This adds complexity, compared to the "optimized DAD", where you do it once, and if passed, you don't have to worry about it. Choosing this does not require a change in any stacks that do DAD on all addresses (KAME, Microsoft). It only affects abnormal address configurations. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
