>>>>> On Mon, 01 Mar 2004 22:34:47 +0200,
>>>>> Mika Liljeberg <[EMAIL PROTECTED]> said:
>> Okay, I'm happy to reach the consensus, too.
> Futile though it may be, I would like to register disagreement.
I think it is not necessarily futile, though in my understanding (I
must admit it may be biased) many people have agreed on the proposed
change.
> If the intention truly was to simplify the specification, we would be
> going to pure DIID. As it is, removing mention of DIID seems like a
> gratuitous change at best. As an author of one of those DIID
> implementations, I find this somewhat unfortunate.
Please check the proposed change posted to this list the other day
(attached below). This is basically "removing mention of DIID" on
which you seem to be able to agree. Actually, we'd need to change
"DAD MUST take place on all unicast addresses" to "DAD SHOULD take
place on all unicast addresses" in a literal sense of what you said,
but I'm personally fine with the change as already stated.
> Also, there is the problem of DAD storms occurring whenever a new prefix
> appears on a link. Will the revision be introducing a random delay
> before a node begins the DAD procedure for each new address, or will
> that make the specification too complex?
Valid point. I've already filed this as a separate issue, and I admit
this may affect the decision of this particular issue. So far, I
personally believe we will not have to change the decision here
regardless of the conclusion of the other problem. But I'm sure we'll
need further discission on the other one.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> 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
--------------------------------------------------------------------
--- End Message ---
