> To be more specific, if I understand your concern correctly, the problem is
> that the host is required by this to send packets to the router at a time
> when it does not have the router's link address?

Somewhat different. From an implementation perspective, one needs
access to information (e.g., whether the router's link-layer address
is in the cache) at a place in the implementation where that
information is not necessarily readily availbale.

But, looking back over the document again, I think I've convinced
myself that this may not be a big issue after all.

However, thinking and rereading leads me to two more thoughts:

In off-list mail:

Jari Arkko <[EMAIL PROTECTED]> writes:

> >    * Optimistic DAD SHOULD NOT be used to configure addresses unless the
> >         probability of collision is exceedingly small.


> I find it very hard to implement this. More guidance would be
> needed. Did you mean "... SHOULD NOT when addresses have
> been configured manually"?

I tend to agree.

Actually, I wonder if what is needed is more of an applicability
statement saying what types of addresses it is appropriate to use this
procedure for, and where not. For example, can optimistic DAD be used
for the LL address?  It took me some thinking to decide whether it
could or not. The answer I believe is yes, but that is not immediately
obvious, I would assert.

But this all depends on having the link-layer address of a router in
the cache (as had been discussed already).

The second thought I have is that the security considerations section
needs some more text, something along the following lines:

  Optimistic DAD takes steps to ensure that if another node is already
  using an address, the proper link-layer address in existing Neighbor
  Cache Entries is not replaced with the link-layer address of the
  Optimistic node. However, there are still scenarios where incorrect
  entries may be created, if only temporarily.  For example, if a
  router (while forwarding a packet) sends out a Neighbor Solicitation
  for an address, the optimistic node may respond first, and if the
  router has no pre-existing link-layer address for that IP address,
  it will accept the response and (incorrectly) forward any queued
  packets to the optimistic node. The optimistic node may then respond
  in an incorrect manner (e.g., sending a TCP RST in response to an
  unknown TCP connection). Such transient conditions should be
  short-lived, in most cases.

  Likewise, an Optimistic node can still inject IP packets into the
  Internet that will in effect be "spoofed" packets appearing to come
  from the legitimate node. In some cases, those packets may lead to
  errors or other operational problems, though one would expect that
  upper layer protocols would generally treat such packets robustly,
  in the same way they must treat old and other duplicate packets.

Thomas  

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to