>> Don't do that. For autoconfigured addresses it will probably work
>> (probably) but for assigned addresses, things will break badly.
>> There's no reason that on a link with prefixes A::/64 abd B::/64
>> I can't assign A::1 and B::2 to node X, and A::2 and B::1 to node Y.
>
>Yes, I was talking about autoconfigured addresses. I did have in mind
>allowing the full addresses being configured as an option.
>
>But, it does raise a question: if you configure "A::1", and then some
>host happens to autoconfigure "fe80::1" and performs DAD on this
>(ADDRCONF specially mentions that you can do DAD on link-local, as id
>should be unique, and can freely assume that A::1 is also usable. You
>don't need to do DAD on every combination!).
I suggest you to rnu DAD for every address you have (so run DAD for
A::1). the following fragment is from RFC2462 5.4. I believe it works
only if all the neighbors are using autoconfigured address only.
as we are not sure about how the neighbors would behave, it is safer
to run DAD for eveyr addresses you have.
in the past, KAME omitted DAD for A::id, when A::id is autoconfigured
from fe80::id. with the latest code we run DAD for A::id as well.
itojun
- Each individual unicast address SHOULD be tested for uniqueness.
However, when stateless address autoconfiguration is used,
address uniqueness is determined solely by the interface
identifier, assuming that subnet prefixes are assigned correctly
(i.e., if all of an interface's addresses are generated from the
same identifier, either all addresses or none of them will be
duplicates). 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.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
