On 2005-01-27, Pekka Savola wrote:
>
> 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.
G'day Pekka,
Thanks for looking at the draft ... looks like there's still
I few things I missed, dang!
> Sorry that I did not catch this earlier, but I think the analysis in
> Appendix A on collision probability is not quite accurate.
Ah, Appendix A is new. And you're right, I should have made it
much clearer that I was talking about 3041 addresses. My main
reason for including the text in Appendix A was to provide a
permanent home for the work done by Soto et al.
Ethernet-derived addresses are indeed also an issue, but they're
hypothetically unique ... so we're back to estimating the
inestimable ... are they less likely to collide than 3041 because
of this supposed uniqueness, or more likely to collide because
of the possibility of human error?
> 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.
I'm open to suggestions ... I can just do the analysis with
N=2^48 in parallel with N=2^62 if that seems useful ... but the
non-random distribution of Ethernet addresses I think negates
that point. I should definitely mention it.
Would it be sufficient to change the first para of Appendix A to:
| In assessing the usefulness of Duplicate Address Detection, the
| probability of collision must be considered. Various mechanisms,
| such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee
| uniqueness of the address, but they add complexity to address
| configuration and may introduce a risk of collision due to
| misconfiguration.
|
| Privacy Extensions to SLAAC [RFC3041] avoid this issue by
| picking an Interface Identifier (IID) at random from 2^62 possible
| 64-bit IIDs (allowing for the reserved U and G bits). No
| attempt is made to guarantee uniqueness, but as the following
| discussion shows, probability is exceedingly unlikely.
... or do I need to be even clearer?
> semi-substantial
> ----------------
> [...]
> editorial
> ---------
> [...]
I agree on all of these, and will fix them immediately.
Thanks heaps for your scrutiny!
-----Nick
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
