[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reminder: IPv6 WG Last Call:draft-ietf-ipv6-rfc2462bis-02.txt

JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> wrote:

|Reminder: the following wg last call will end tomorrow (July 13th).
|So far, I've only seen one comment in response to the last call (the
|one from itojun about "disabling interface" on DAD failure).
|I'm afraid wg members are too busy for processing a rush of new I-Ds
|or for writing/updating their own drafts, but if anyone of you could
|review the document by the end of the last call, it would really be

I (unfortunately) had never really looked at DAD closely before and the
comment I'm going to make probably isn't suitable for a last call (it
goes too deep) but I'll make it anyway...

I was contacted yesterday about a problem with DAD over a packet driver
shim I provide for Windows.  The problem stems from the fact that the
Windows NDIS3+ driver model has a policy of letting you hear anything on
the wire that your requested filter would allow, even if you are the sender.
This results in "loopback" (if necessary) of multicast packets.  I was
surprised to learn that DAD does not tolerate hearing its own packets very
well.  Having looked at appendix A of RFC2462bis I see that the problem is
understood, but the suggested solutions are inadequate.  There is no standard
way of controlling the "loopback" behavior in many APIs.  For NDIS3+ there
are two different flags that may or may not work depending on the specific
platform, but there are some platforms on which no flag works.  Even if
there were, there is no way to express the desired state of loopback through
other APIs (like the packet driver API).  Whether or not you hear your own
packets has historically been rather hit or miss on most other platforms,
depending on the whims of the driver, firmware, and hardware builders.  Keeping
a packet count is also problematic since platforms that do provide loopback
still may do it only on a "best effort" basis.

I believe it is a mistake for DAD to depend so strongly on the low-level
characteristics of the network interface, especially when those characteristics
vary so much from interface to interface.  It isn't clear to me why DAD
packets could not carry a (hopefully) unique random (or even non-random if
some other kind of serial number is available) identifier to allow a host to
identify its own packets.  Of course, I realize that it's far too late to
make a change like this and for all I know it was suggested before and rejected
for other reasons. :(

				Dan Lanciani

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6