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
> -----Original Message-----
> From: Thomas Narten [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 01, 2001 1:47 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: DAD
>
>
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
