This Last Call ended yesterday with no comments. At a minimum, I would like to hear from those people who commented previously whether or not this version satisfies their concerns.
Hi,
I took a quick look at -03, with comments below. I think the main oDAD functionality is OK, but the draft likely needs a revision to make a few textual corrections.
substantial -----------
Sorry that I did not catch this earlier, but I think the analysis in Appendix A on collision probability is not quite accurate.
[SOTO] describes the collision of a random interface identifier. For that, looking at 62 bits is OK.
What we are mostly concerned with are: - manual configuration - stateless address autoconfiguration - RFC3041 addresses
Now, we cannot really analyze manual configuration mismatches, but we can analyze the probability of collision of SLAAC addresses. For RFC3041, the current calculations would apply, but we should calculate the maximal feasible probability as it is larger with SLAAC addresses.
And for that, you'll have to use a different instead of 2^62; you could take for example Ethernet, and analyze 2^48. Text also needs to be massaged a bit to state which probability you are actually calculating. (Unfortunately, as the L2 address lengths are variable, you can't do much better calculations than this..)
I don't think this changes the results in any meaningful way (the probabilities are about 16K larger), but this should probably still be changed.
semi-substantial ----------------
* Nodes implementing Optimistic DAD SHOULD additionally implement
Secure Neighbor Discovery [SEND].==> I agree with Jinmei's concern. SEND should be a normative reference if it's a SHOULD.
* (modifies 5.5) A host MAY choose to configure a new address as an
Optimistic Address. A host which does not know the SLLAO of its
router SHOULD NOT configure a new address as Optimistic. A
router MUST NOT configure an Optimistic Address.==> Why MUST NOT for routers? It seems too strong. Sooner or later (if not already) folks deploying Mobile Routers (for example) are going to want to use this for their upstream interface, at least.
Either you should justify clearly somewhere why it's technically unfeasible to use oDAD on routers, or weaken the text a bit, e.g., to a SHOULD NOT.
editorial ---------
The existing IPv6 address configuration mechanisms provide adequate collision detection mechanisms for the static hosts they were designed for.
==> s/static/fixed/ ?
SAA - Stateless Address Autoconfiguration. The process described in
[RFC2462]==> "SAA" is ambiguous, because it could as well be Stateful AA. I suggest using either SLAC or SLAAC (both have been used).
4.2 Collision case
==> this section does not explicitly state at which point the ON unconfigures the address. Should it say that?
When considering collision probability, the Birthday Paradox is generally mentioned. When randomly selecting k values from n possiblities, the probability of two values being the same is:
==> s/possib/possibi/
When considering the effect of collisions on a individual nodes, we
==> "a invididual nodes" ?
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
