>>>>> On Mon, 23 Feb 2004 22:21:49 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Since we have a discussion about optimistic DAD, this is probably a
> good chance to start a related discussion for rfc2462bis.
(...snip...)
> 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.
> 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")
So far, I've not seen an objection to Option 1, and two people
(Francis and Jari) seem to agree on this approach.
So, I'd now like to propose a concrete change. The simplest way to
implement the option would be to remove the second exception shown in
Section 5.4 of RFC2462. That is, the revised text would be:
5.4 Duplicate Address Detection
Duplicate Address Detection is performed on unicast addresses prior
to assigning them to an interface whose DupAddrDetectTransmits
variable is greater than zero. Duplicate Address Detection MUST take
place on all unicast addresses, regardless of whether they are
obtained through stateful, stateless or manual configuration. On the
other hand, Duplicate Address Detection MUST NOT be performed on
anycast addresses.
The procedure for detecting duplicate addresses uses Neighbor
Solicitation and Advertisement messages as described below...
Can we live with this simple resolution?
If yes, is the requirement of "DAD **MUST** take place" acceptable? I
believe this is acceptable in essence, but I'd like to know this does
not cause a severe compatibility issue with existing implementations
that conform to RFC2462.
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
--------------------------------------------------------------------
