Hi Alper,
Sorry about the delayed response.
Possibly unhelpful responses below...
Alper E. YEGIN wrote:
Pekka,
2) I'm not sure if this is the right approach. Something better suited
could be found, I believe, in adding functionality to first-hop routers'
ND cache behaviour; a router could answer directly which could be
interpreted like "don't use that address, I just recently saw it used here
by another node.. but if you're really sure you want it, perform DAD as
specified in RFC2461/2".
This is the approach I've been looking at. But there is a problem.
Nodes that implement the required ND extension can explicitely
inform the router about their IP addresses. Router can learn about
others (i.e., regular DAD hosts) via listening to multicast NSs for DAD.
No problems so far...
But when a router starts with no state (a new one, or rebooting
after crash), it might never learn about regular nodes that
have already done DAD.
So, unless this problem is solved, the applicability of this
solution is limited to networks where all nodes support the
required extensions.. Any ideas?
With the mld-dad approach, the assumption is that all nodes
will do MLD on subnet-local multicast addresses, and thus
all nodes participate (to some extent) in the MLD reporting
and query mechanisms defined by the RFC2710.
Since MLD is a node requirement (good or bad) this is possible
The issue with using ND based mechansims is that there's no
generic query which all hosts (or a sufficient subset, as in MLD)
will be guaranteed to respond to. In this case, the system
cannot rebuild state from restart (nor necessarily converge to
full state in a finite length of time, unless nodes can be
prompted to send packets.
Few (all or even many nodes) multicast packets in ND can cause
a response, except for missing (lifetime 0?) router
advertisements.
In these cases, where the router lifetime is zero, or no
multicast packets are received, a node will send an RS,
although I don't know the effect on traffic from the nodes.
(Nasty Hack I know).
Greg Daley
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
