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

From: Dan Lanciani <[email-masked]>
Date: Mon, 12 Jul 2004 16:36:32 -0400 (EDT)

JINMEI Tatuya <[email-masked]> 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
|appreciated.

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
				ddl@danlan.*com

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 15 Jul 2004 01:08:48 +0900

>>>>> On Mon, 12 Jul 2004 16:36:32 -0400 (EDT), 
>>>>> Dan Lanciani <[email-masked]> said:

(snip)

> make a change like this and for all I know it was suggested before and rejected

I'm afraid I'm not the appropriate person to make a response to this
comment since this appendix has been in the spec since RFC1971...but
anyway:

As indicated by the fact this appendix has long been in the spec, the
issue has been well understood.  Unfortunately, we, as an implementor,
have not seen a magic to solve the issue completely and in a portable
manner, so workaround has always been
driver/firmware/hardware-specific.  In fact, our own implementation
also has this level of workaround.  It's a weird thing, but has been a
fact we need to face since RFC1971.

Now, what can we do for this in rfc2462bis?

Clearly, we cannot take any specific action just from a general
comment like "it is a mistake for DAD to depend on the low-level
characteristics".  It is also pretty clear that the scope/goal of
rfc2462bis will not allow to include a new option (or something
similar) to carry the random identifier even if we agree on the
approach itself (i.e., it should be specified in a new separate
document).

I slightly recall discussions on the idea of the random identifier,
but I don't even remember if it was rejected.  Could someone show us a
pointer?  If it was not actually rejected, one possibility in
rfc2462bis would be to mention that kind of option as a future
possible extension (and as a beyond-the-scope thing).

If the idea was actually rejected in the past and no one can provide
further information on this issue, then I regret to say this but I
must say I cannot do anything on this in rfc2462bis, especially
considering this is an old issue and we have been dealing with it
anyway (in a dirty manner).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

p.s. I'll file the original message from you at the issue tracker for
the record.

p.p.s. I don't think "keeping a packet count" is problematic in the
sense you pointed out:

> Keeping

Layer 2 typically always works on a best effort basis, so DAD always
may or may not work as designed in this sense, regardless of whether
we have the "loopback" issue or not.  Except for the reliability
issue, I believe keeping the count can be a reasonable workaround when
you are sure that the driver/platform/firmware/whatever provides
loopback (just in the same level that we can live with DAD on a
platform that does not have the loopback issue under the reliability
that the L2 can provide).  In my understanding, the problematic case
can happen when a separate entity (like IPv4 stack or applications)
temporarily suppresses/enables the loopback feature while DAD is
performed.

---

From: Tim Hartrick <[email-masked]>
Date: 14 Jul 2004 15:48:08 -0700

Jinmei, Dan,

> anyway (in a dirty manner).

My memory of the discussions regarding this issue are that the problem
was asserted to be not enough of a problem to worry about.  That is, an
unofficial poll of the implementors on hand indicated that it wasn't a
problem for their driver infrastructure.  I am pretty certain that this
discussion took place at an interim working group meeting in Washington
at ISI, or possibly at LBL in the Bay area, and possibly continued on to
one or more subsequent IETFs.  Sorry I don't recall all the chronology
and I don't have any pointers to records of the discussions.

This issue has come up from time to time for us when using some
hardware, drivers and OS's.  We have worked around it but the methods
have been unsatisfying.  I agree that we are too far down the road to
attempt an elaborate corrective like an identifier option for inclusion
in RFC2462bis.  I believe such a corrective, if done as a separate
document, would have utility if it could be done in a way that was
backward compatible with existing DAD implementations.

Tim Hartrick
Mentat Inc.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 15 Jul 2004 14:45:08 +0900

>>>>> On 14 Jul 2004 15:48:08 -0700, 
>>>>> Tim Hartrick <[email-masked]> said:

> and I don't have any pointers to records of the discussions.

Thanks for the information.  I'll listen to others for further
information for now, but right now there seems nothing we can do for
this particular issue in rfc2462bis.

					JINMEI, Tatuya