Optimistic Duplicate Address Detection (DAD) for IPv6
RFC 4429

Note: This ballot was opened for revision 07 and is now closed.

(Margaret Cullen) Yes

(Brian Carpenter) No Objection

Comment (2005-05-23 for -)
No email
send info
Possible clarifications from review by Spencer Dawkins:

... it's confusing to new readers that "standard DAD" isn't defined - there's nothing called DAD except optimistic DAD until Section 4.4). Maybe this is OK. I wish the abbreviation was ODAD, though.

In Section 1.1, I would really like to see explicit numbers here - what is the delay before an address can be used when an IPv6 node uses ND or SLAAC, and what is the corresponding delay using optimistic DAD? I've seen enough IETF discussion of fast handoff, etc. to suspect that some people will be hoping this is the 50-ms fast handoff solution... I think I can figure the numbers out from RFC 2641, but you guys already know what you're thinking!

I'm a little confused by the text in 3.2 - up to this point, Optimistic DAD is described as safe, so why is its use SHOULD NOT "unless the probability of collision is exceedingly small"? Just a sentence or two would be good, but there's no discussion of this point until Section 4.2.

In Section 4.2, "the ON will hopefully know all it needs to know about the router from the initial RA" is really informal text, even for a non-normative section. Could you add a phrase detailing the kind of things the ON hopefully knows?

Appendix A is pretty helpful, but I didn't see any reference to it in the rest of the text. A pointer would be nice, especially somewhere near Section 4.2, which discusses collision probability concerns.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2005-05-23 for -)
No email
send info
In 4.3, I found this a bit hard to parse:
 
   Once the Optimistic Address has completed DAD, it acts exactly like a
   normal address, and so interoperation cases only arise while the
   address is Optimistic.

I assume it means that the special rules for Optimistic Addresses aren't
applicable once the Address is marked Preferred or Deprecated.  I think
that is clear enough without saying it again here, but if you do need to,
some other phrasing might be needed.

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

Comment (2005-05-24 for -)
No email
send info
Section 3.2 is titled "Modifications to RFC 2461 Neighbor Discovery".  Shouldn't this document thus be identified as updating RFC 2461?  Similar question for Section 3.3 (RFC 2462).

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) (was Discuss) No Objection

(Alex Zinin) No Objection