Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.txt

"Nick 'Sharkey' Moore" <sharkey@zoic.org> Thu, 27 January 2005 09:56 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09164 for <ipv6-web-archive@ietf.org>; Thu, 27 Jan 2005 04:56:20 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu6f5-0005Po-OB for ipv6-web-archive@ietf.org; Thu, 27 Jan 2005 05:14:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6JT-0006Zh-V2; Thu, 27 Jan 2005 04:51:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu6BT-0005MC-71 for ipv6@megatron.ietf.org; Thu, 27 Jan 2005 04:43:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07601 for <ipv6@ietf.org>; Thu, 27 Jan 2005 04:43:22 -0500 (EST)
Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu6SW-000503-Dx for ipv6@ietf.org; Thu, 27 Jan 2005 05:01:05 -0500
Received: by anchovy.zoic.org (Postfix, from userid 1000) id 68D79701A9E; Thu, 27 Jan 2005 20:43:11 +1100 (EST)
Date: Thu, 27 Jan 2005 20:43:11 +1100
From: Nick 'Sharkey' Moore <sharkey@zoic.org>
To: Pekka Savola <pekkas@netcore.fi>
Message-ID: <20050127094311.GA16361@zoic.org>
Mail-Followup-To: Pekka Savola <pekkas@netcore.fi>, ipv6@ietf.org
References: <24382B78-6024-11D9-856F-000D93330CAA@innovationslab.net> <4A05FBE6-6BC8-11D9-955E-000D93330CAA@innovationslab.net> <Pine.LNX.4.61.0501271049500.8633@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0501271049500.8633@netcore.fi>
User-Agent: Mutt/1.3.28i
X-URL: http://zoic.org/sharkey/
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: ipv6@ietf.org
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------