Re: To DAD or not to DAD?

Ole Troan <otroan@employees.org> Thu, 19 February 2015 13:07 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1DD1A8ADD for <ipv6@ietfa.amsl.com>; Thu, 19 Feb 2015 05:07:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4q_7g1LN2Nf for <ipv6@ietfa.amsl.com>; Thu, 19 Feb 2015 05:07:32 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0F61A9041 for <6man@ietf.org>; Thu, 19 Feb 2015 05:07:32 -0800 (PST)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id A8650627A; Thu, 19 Feb 2015 05:07:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=St9LK9BctWfmTL47zwpEARYMsmw=; b= I0xX7/HRem3X164e8pgvRgfh03xnmdoNl0vhHxMiR/GHtaaJvW/JtwRLDXkIAeRs UZFKtacBAdVxHjY/5IKVwsxHJOAE/JKV3wtR2XdN0tJyTFM5kHdcnJSR2hv6WIcT imfrekSsXa4WsIMD/r0zJFOrYSlHstAWer2sS64DnXM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=fm1ODphfrbMDwrFwmvgSVq254c aSUGrR2Wy4mMGkmhRtRL6HJIaNn/4A+45jurZppZR5fLwUHqxYiM94agaRUplzKV VTno5LfDowdrMpssvuCfefRRF5u3LQoPmEl7fxdZb24Cn2vMcNU1Occy5N9d2hUU XHZ6vOr7CWHQX/978=
Received: from gomlefisk.localdomain (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 2B13361F7; Thu, 19 Feb 2015 05:07:29 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id EFDA03EFF262; Thu, 19 Feb 2015 14:07:26 +0100 (CET)
Subject: Re: To DAD or not to DAD?
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_847E986E-D70A-4C9C-8D9D-52A249D83426"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b5
From: Ole Troan <otroan@employees.org>
In-Reply-To: <D10C237E.5B466%hesham@elevatemobile.com>
Date: Thu, 19 Feb 2015 14:07:26 +0100
Message-Id: <958B43FE-81BC-4F86-B979-7881667C716D@employees.org>
References: <54E4EC1A.3080303@acm.org> <54E531AE.9080603@gmail.com> <C82C46A6-450F-4BB9-9BFF-12299A87DFAD@employees.org> <D10C1907.5B45D%hesham@elevatemobile.com> <66AC3D9F-CE39-424B-A071-B5FE65809416@employees.org> <D10C237E.5B466%hesham@elevatemobile.com>
To: Hesham Soliman <hesham@elevatemobile.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/ov8ipsUGPJ8fJx6rTRzDJgu3fGk>
Cc: Erik Nordmark <nordmark@acm.org>, "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 13:07:34 -0000

Hesman,

>>>> if my math (or wikipedia's is correct), you need 6 million devices on a
>>>> link to get a one in a million chance of a collision.
>>>> 
>>>> http://www.wolframalpha.com/input/?i=sqrt%282*2%5E64ln%281%2F1-0.000001%
>>>> 29
>>>> %29
>>> 
>>> => Is that assuming everyone is using a good RNG and people are not
>>> manually configuring addresses?
>> 
>> clearly.
>> 
>> what has been discussed a few times is to do DAD only for addresses
>> likely to collide. e.g. manually configured addresses.
> 
> => Thanks, yes I saw that. I guess my point of the rhetorical question,
> which I should’ve included, is that if we’re going to keep it and add more
> branches on when it should be used, we’re just adding more complexity
> when, at least to me, the cost of just leaving it as it is today is zero.
> So, if we’re keeping it for special cases then lets just keep it as is.
> Maybe I missed some of the discussion but the inefficiency claims I saw in
> draft and on the list don’t justify removing it.
> 
> It would be good to see some real data from deployed networks which show
> that there is a real-world problem. To me claims such as energy
> inefficiency are not relevant for the large cellular networks but maybe
> for others like sensor networks something special should be done (I
> haven’t kept up with the 6lowpan work, which might’ve fixed it). Other
> claims like handling fragmented links should be irrelevant because it was
> never the intention of DAD. Delays before using an address are solved by
> optimistic DAD. Finally, if there are faulty implementations then point it
> out to them and they should be fixed.

point to point links isn't the target for this work.

see:
http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01
http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01
https://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-06
https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-00

cheers,
Ole