> I'm trying to understand what the following text means and > implies in Section 3.3 of RFC 3041: > > "Note: because multiple temporary addresses are generated from the > same associated randomized interface identifier, there is little > benefit in running DAD on every temporary address. This document > recommends that DAD be run on the first address generated from a > given randomized identifier, but that DAD be skipped on all > subsequent addresses generated from the same randomized interface > identifier." > > Does this refer to multiple addresses when the link has > multiple prefixes? Or when multiple temporary addresses are > generated in sequence? It says "addresses generated from the > given randomized identifier" so one might assume it means the > multiple prefix case. But on the other hand the randomized > identifier is also fed as history to the generation of new > addresses, so it might mean the sequence also.
I think it means the multiple addresses when the link has multiple prefixes. > Additionally, I'm wondering how DAD works with RFC 3041. > The scheme appears to rely on the order in which addresses > are generated. On a network with two prefixes A and B two > nodes might not generate and test the addresses in the same > order. For instance, node 1 could test A::<random> and node 2 > could test B::<random> first. If the random values collide, > the collision apparently isn't detected and both nodes > proceed to use both A::<random> and B::<random>. Or did I > miss something? Yes, this is a known bug in the spec. I think you should either run DAD on all your temporary addresses or none of them (if you trust your RNG). > Also, it wasn't clear to me whether link-local addresses are > generated for every new IID or not. If they are, RFC 2462 > rules in Section 5.4 apply and the collision problem may be > solved that way. (Or does it -- where does it say that > "first" in 3041 refers to the link-local address?) You do not generate link-local addresses for the new IIDs. And not site-local either. Just global addresses. Rich -------------------------------------------------------------------- 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] --------------------------------------------------------------------
