Since we have a discussion about optimistic DAD, this is probably a
good chance to start a related discussion for rfc2462bis.
As you know, there have been many discussions on DAD, including
- whether omitting/optimizing DAD is a good idea
- (if yes) in which case we can omit DAD
- DAD vs DIID
- ...
without getting any convergence (particularly about DAD
omission/optimization or DIID), unfortunately.
Through the past discussion and by considering the purpose of
rfc2462bis, I believe rfc2462bis is NOT the place where DAD
optimization or DAD omission or DIID should be specified (even if we
agree on introducing some of them). And I believe we agree on this as
a base line.
Meanwhile, one source of the confusion is an unclear wording of
RFC2462. It says in Section 5.4 that
- Each individual unicast address SHOULD be tested for uniqueness.
and then says
... In such cases, the link-local address MUST be tested for
uniqueness, and if no duplicate address is detected, an
implementation MAY choose to skip Duplicate Address Detection
for additional addresses derived from the same interface
identifier.
I do not necessarily think this is inconsistent (whereas the issue
title contains "inconsistencies"), but the "MAY" following the
"SHOULD" has surely tempted people to cause the DAD related
discussions and to propose DAD omission/optimization or DIID.
In my understanding, we have basically agreed in the passed discussion
that we should honor the sense of the "SHOULD" rather than the "MAY".
(but I may be wrong here, in which case please correct me)
Having considered these points, possible resolutions *for rfc2462bis*
that I can think of are:
1. harden the requirement: Each individual unicast address MUST be
tested for uniqueness. No MAY for omitting the rule (i.e., remove
it). We can use SHOULD instead of MUST if we need compromise.
2. MUST run DAD on all addresses for which the interface identifier is
NOT globally unique (such as non EUI-64 ID). This is a proposal by
Thomas Narten in June 2001. (see the issue tracker for more
background information)
3. do nothing for this in rfc2462bis; leave Section 5.4 as is, do not
add any text.
4. no change in the protocol specification, but add an appendix (or
something) to discuss the issue on the effect of
omitting/optimizing DAD.
I personally prefer option 1, because this makes the intention very
clear, avoiding further similar discussions and waste of energy.
"MUST" may be too strong for compatibility with existing
implementations, and if so, we can use "SHOULD". (And this does even
not conflict with the proposed "optimistic DAD")
I would not take option 2, though this makes the specification a bit
clearer, since even EUI-64 IDs can collide (due to manufacturer error,
etc).
We could live with option 3. After all, current RFC2462 does not have
an "error" on this point. This option may be a bit irresponsible,
though, since the unclear text has caused diverging discussions
without success.
We could also live with option 4, although I do not have a concrete
idea on what should be written in the appendix.
Even though I have my own preference, I'm quite open to other
opinions. I'd really like to make a consensus on this quickly and
move forward.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
