Here is a suggestion for how to plug the main vulnerabilities that were discussed in the meeting. Problem (as I understand it): the main issue is that there are some (non-link local scope) addresses that may be assigned to an interface (e.g., manually configured, temporary addresses, DHCP assigned, etc.), but for which there is no corresponding link-local address using the same interface identifier. The stateless addrconf document (RFC 2462) says that a node can skip DAD for global (and site local) scope addresses generated from the same interface ID as the link-local address. This opens up a potential hole where a node (doing normal addrconf) has run DAD on the link-local address, but has not yet configured a global-scope address using the same interface identifier. Then, some other node (e.g., via DHCP, a temporary address etc.) chooses the same interface identifier and creates such an address, runs DAD successfully (since no other node is currently using that address), and then assigns the address to its interface. Later, the first node (which is running normal addrconf) also generates the address, but skips DAD, and now there are two nodes using the same address. Oops. Proposal: update specs to require that nodes MUST run DAD on all addresses for which the interface identifier is NOT globally unique (per the setting of the 'u' bit in interface identifier). DAD can be skipped on addresses that contain IEEE EUI-64-derived interface identifiers (and for which DAD has already been run on the corresponding link-local address). This means: still no need to run DAD on global addresses when doing normal addrconf, provided the interface identifier comes from an IEEE identifier. But one would have to run DAD for links with randomly generated identifiers (e.g., some PPP links). One would also still need to run DAD for temporary addresses. For DHCP addresses, we'd need to make sure that the server sets the 'u' bit properly, and clients would need to run DAD if the 'u' bit indicated locally unique only. Does this solve the underlying problem in an acceptable fashion? Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
