Re: To DAD or not to DAD?

Erik Nordmark <nordmark@acm.org> Thu, 19 February 2015 22:10 UTC

Return-Path: <nordmark@acm.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 8F17D1A0379 for <ipv6@ietfa.amsl.com>; Thu, 19 Feb 2015 14:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no
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 DYecxqZH3t7D for <ipv6@ietfa.amsl.com>; Thu, 19 Feb 2015 14:09:59 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EF41A036F for <6man@ietf.org>; Thu, 19 Feb 2015 14:09:59 -0800 (PST)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t1JM9hRD005475 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Feb 2015 14:09:43 -0800
Message-ID: <54E65F26.2010606@acm.org>
Date: Thu, 19 Feb 2015 14:09:42 -0800
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "STARK, BARBARA H" <bs7652@att.com>, Ole Troan <otroan@employees.org>, Hesham Soliman <hesham@elevatemobile.com>
Subject: Re: To DAD or not to DAD?
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> <958B43FE-81BC-4F86-B979-7881667C716D@employees.org> <2D09D61DDFA73D4C884805CC7865E61130F29C24@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130F29C24@GAALPA1MSGUSRBF.ITServices.sbc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/8gso2Pmd24mLy3iZICLqzM4ZbnU>
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 22:10:00 -0000

On 2/19/15 7:22 AM, STARK, BARBARA H wrote:
> My take-away from https://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01 was that the contribution of DAD to the multicast chatter on a network is nothing compared to the contribution of UPnP SSDP and DNS SD/mDNS. And I see these latter as continuing to increase much more than DAD. So doing something to limit DAD really does nothing to solve the broader "multicast" problem.
>
> I would like to see a more holistic approach to solving the problem of vast quantities of multicast traffic, rather than just going after DAD.

The design team has collected a bunch of information around the 
multicast traffic. Ole sent some of the specific drafts in an email 
today. (And elsewhere in the IETF folks are looking at mDNS proxies.) In 
addition to those drafts (and earlier ones from about a year ago) the 
design team has discussed summarizing the space by creating report in an 
Internet Draft.

However, the DAD question is somewhat separate. It came up as a side 
effect of asking the question "is DAD inefficient for hosts that want to 
sleep".
That question resulted in other ways that DAD might need to be improved 
- see the list in the draft. Note that all but two of those items are 
*not* about efficiency but about DAD's ability to detect duplicates when 
they exist on the network.


Regards,
    Erik

> Barbara
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>