>>>>> On Mon, 12 Jul 2004 16:36:32 -0400 (EDT),
>>>>> Dan Lanciani <[EMAIL PROTECTED]> said:
(snip)
> 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. :(
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 PROTECTED]
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
> a packet count is also problematic since platforms that do provide loopback
> still may do it only on a "best effort" basis.
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
