Hello,
I'd now like to resume the discussion on another set of outstanding
issues for rfc2462bis: DAD related ones.
Based on the past discussion, I'd like to propose the following basic
approach:
- basically, strongly recommend to perform DAD all unicast addresses
(use much stronger recommendation than in the current RFC2462)
- use consideration not to "invalidate" existing implementations
that use the "DIID-like" optimization
- (for issue 337) require to add a random delay before sending DAD
NS if the address being checked is configured by a multicasted RA
(see the long thread starting at the following message
http://www1.ietf.org/mail-archive/web/ipv6/current/msg01723.html
for the "past discussion)
A bit more detailed rationale is as follows:
First of all, my understanding of repeated discussions on DAD
optimization / DAD vs DIID / etc, in this wg is that the consensus (or
at least majority) has always been preferring DAD for all unicast
addresses. I don't see no new significant news to reverse the past
result. So, in the above proposal, I basically honor the past
consensus (or the preference of the majority).
Moreover, an important assumption on which the DIID-like optimization
depends does not necessarily hold: the assumption that all of an
interface's addresses are generated from the same identifier (and thus
it should be enough to check the uniqueness of the link-local address
only). In fact, RFC3041 temporary addresses or SEND CGA addresses
break the assumption. We've seen this could cause undetected
duplication when there are nodes that implement the DIID-like
optimization:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg01842.html
As I pointed out in this (sub)thread, actual duplication should rarely
occur and this particular case happens to be a non issue in a
practical sense. However, now that the basic assumption doesn't hold,
I believe it should be safer to require to perform DAD for all unicast
addresses, in order to prepare for the current and future such special
interface identifiers (like SEND CGA or RFC3041 IDs).
Meanwhile, we'll need to deal with a new issue pointed out in the
latest discussion that DAD NSs for addresses configured by a
multicasted RA can collide (issue 337). But I think this should be a
separate issue from whether we should strongly recommend DAD for all
addresses or should allow omitting DAD by the DIID-like optimization.
In fact, there is a class of addresses that can be created by a
multicasted RA and always require DAD (e.g., a "bis" version of
RFC3041 requires to perform DAD for all temporary addresses). Thus,
we'll need to deal with this issue anyway even if we "mandated" the
DIID-like optimization for EUI-64 based global addresses.
The easiest way to realize the strong recommendation of performing DAD
for all addresses is simply saying "MUST". However, this might be
overkilling, considering there are implementations that support the
DIID-like optimization and we basically do not want to
break/invalidate existing implementations in the rfc2462bis work. So
we need some kind of wording compromise here.
I'll soon post specific proposed text in a separate message.
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
--------------------------------------------------------------------
