> > It'll be faster, though it'll run the risk of breaking this node's own
> > communication and another node's communication when things
> > go bad. If this risk was only affecting the node using this
"optimization",
> > we could say it's this node's choice (i.e., a tradeoff). But when this
> > "aggressive" behavior costs some other innocent node its connectivity,
> > then a node's individual decision won't be sufficient. Maybe it should
> > be network operator's decision, by allowing/disallowing all nodes use
> > this optimization at the expense of risking other on-link nodes??
>
> >From the half-baked idea department:
>
> Perhaps it would be better to explore "router/agent assisted DAD"
> than optimistic DAD. In the assisted DAD case there would be an agent
> which would somehow reliably know the IP addresses and link-layer
> address of everybody on the link. Then it could send an "ok to use it"
> response to DAD queries if the address isn't in its table or
> if it is in the table with the same link-layer address.
>
> The trick is how to reliably have the agent build the tables.
> One way would be to add a new RA option "please periodically send a packet
> to X" where X is the address of the agent, which would cause all hosts
> to send a packet with a given period.
> This requires changes in all hosts on the link, and it causes additional
> background traffic for the benefit of shortening the DAD query.
Actually I have a draft in the works along this line. The basic idea is
to turn distributed (i.e., peer2peer) address resolution process into
a centralized one. First hop routers keep track of all of the hosts
on link, effectively turning their neighbor cache into a neighbor table
(NT),
and hosts consulting routers for neighbor solicitations and duplicate
address detection (now can be called duplicate address check - DAC).
There is obviously neighbor table maintenance with neighbor advertisements
with lifetimes.
The benefits of this scheme is not limited to DAD only. The DoS attack
I had identified in section 3.8 of draft-kempf-ipng-netaccess-threats-02.txt
can also be solved by relying on this mechanism. Even when it's not an
attack, awakening of dormant nodes and delays caused by a ND when
an entry may or may not be in the "cache" of a router are other issues that
can benefit from NT approach. Delays get more significant and bandwidth
gets more precious in cellular environments. Also a multicast message likely
to cause one unicast per each host.
alper