> From: Robert Elz <[EMAIL PROTECTED]>
>
> But can you test what happens if you configure an address on some other
> node (using a different implementation), that happens to be one that yor
> node will assign, without doing DAD on it explicitly, and then start
> your node after that.
I think the first discussion should be about the most common normal
case: autoconfiguring using the "globally unique" EUI64 ID (or if not
global, then at least ID which is supposed to be normally unique on
the link).
Ok, first definitions:
- Node A, has "globally unigue" id = AI, implements "link local"
optimization (does DAD only on fe80::AI).
- Node B is the evil one :-). It has its own "globally unique" id = BI
for it's link local
- Prefix "P1::/64" is advertised on the link by the router.
Events in order of occurrence:
1. Node B is manually configured with address "P1::AI"
2. Node B does DAD on "P1::AI" and assigns address, because node A is
not yet connected.
3. Node A comes online on the link
4. Node A does DAD on "fe80::AI", and succeeds.
5. Router send RA with P1::/64
6. Node A uses P1::AI without doing DAD (and probably both A and B
cannot communicate properly with this address).
Some observations:
- if before (6.), A did DAD on "P1::AI", it would fail and leave A
without any global address to use. It's options would be
a) accept the situation and be isolated
b) generate temporary AIn and use "P1::AIn" (repeat until DAD
succeeds) (can also redo fe80::AIn).
- it seems that this is a configuration error on the node B, that
should be detected and fixed.
- situation does not occur in the normal autoconfiguration, where node
needs to have a link local address first.
The whole issue comes from the introduction of "privacy" and generated
addresses. To me this is a special case, and it should solve it's own
problems, and not break the normal case. And one solution is that,
whatever address "Prefix::Id" you configure, you always do the DAD on
linklocal "fe80::Id" (you don't need to actually generate this
address, if you are not going to use it, just handle DAD as if you had
it).
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
