>We have two solutions to solve this issue:
> - the first one is to affirm that DAD is not a DIIDD:
> * removal of the uniqueness of IIDs in address architecture
> (only link-local addresses must be unique)
> * removal of the "same interface identifier" considerations in RFC 2462
> * DAD becomes mandatory (i.e. SHOULD -> MUST in 5.4) for unicast addresses
> Implementation changes are:
> - for stateless configuration or stateless configuration-like mechanisms
> the only difference is the removal of the MAY in 5.4.
> - for other mechanisms the DAD detection for the address itself doesn't
> change but this choice makes clear the associated link-local address
> should not be object of a DAD.
> This is the simpler fix but IMHO not the best.
i vote for this (DAD is DAD, not DIIDD). this is future-proven even
if we have other address architecture (which does not use /64).
itojun
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
