Julian, When this idea was suggested at the Interim Meeting, several people expressed concern about needing to have a link-local address for every interface identifier you might be using. A node may want to have a large number of global addresses, for example, and the overhead of requiring that it keep a corresponding link-local address for each might be prohibitive. I think I'd prefer to just perfom DAD on all the global addresses instead. It's the same amount of DADing going on, and you don't need to keep all those link-local addresses around. --Brian > -----Original Message----- > From: Sellers, Julian P [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 05 June, 2001 14:04 > To: 'Thomas Narten' > Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Subject: RE: DAD > > > Thomas, > > Is there a problem with requiring nodes to perform DAD on the > link-local address generated from a given interface > identifier, even if they only want to use the site-local or > the global address? That's what I thought the following > sentences from 5.4 of RFC 2462 required: > > Thus, for a set of addresses formed from the same > interface identifier, it is sufficient to check that the link- > local address generated from the identifier is unique on the > link. In such cases, the link-local address MUST be tested for > uniqueness, and if no duplicate address is detected, an > implementation MAY choose to skip Duplicate Address Detection > for additional addresses derived from the same interface > identifier. > > It's not clear to me what the qualifier "In such cases" > refers to. Maybe this paragraph just needs to state clearly that > > - If a node has successfully performed DAD on a > link-local address, the node has the > right to all addresses on the same link that contain > the same interface identifier. > - If a node has not performed DAD on the link-local > address, or if the link-local > address has failed DAD, the node must not use any > address on that link generated with > the same interface identifier. > > Julian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
