RE: To DAD or not to DAD?

"Hemant Singh (shemant)" <shemant@cisco.com> Sun, 01 March 2015 00:45 UTC

Return-Path: <shemant@cisco.com>
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 D336F1A00EC for <ipv6@ietfa.amsl.com>; Sat, 28 Feb 2015 16:45:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 ECQWgL_NWeCP for <ipv6@ietfa.amsl.com>; Sat, 28 Feb 2015 16:45:43 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D481A00E6 for <6man@ietf.org>; Sat, 28 Feb 2015 16:45:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3877; q=dns/txt; s=iport; t=1425170744; x=1426380344; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p5xEd68m0BcnkCAYwrJJVT4KAYCEl/VkliROxxPEZZo=; b=DfXqE4C4kcgNlm20eFO/Ba0VWaorNz/8jz7sA/pTyol5M/2rE7ll0O5V dVQLf5Gr9RBI9aEdVizG3aMjc9edSQ59yAXgWY1F04hDLINJETegvBymp KejvKgwQgg4f9hrW+dJ5TeNjsDTvSHYPO0wRNks5Atsbg9RvNn4sA6L9g A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BTBQCxYPJU/40NJK1agwJSXsIaCoRjAYEMAoEXTQEBAQEBAXyEDwEBAQMBAQEBNy8BBAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIiB8IDdRsAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLEoQ9MQcGgxGBFAWFb4oJnSEjggIcgVBvgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.09,669,1418083200"; d="scan'208";a="400044808"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 01 Mar 2015 00:45:43 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t210jg7F015733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Mar 2015 00:45:42 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Sat, 28 Feb 2015 18:45:42 -0600
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Erik Nordmark <nordmark@acm.org>, James Woodyatt <jhw@nestlabs.com>
Subject: RE: To DAD or not to DAD?
Thread-Topic: To DAD or not to DAD?
Thread-Index: AQHQS7OiTZZ4njkebUio2cP8BCSONpz5AREAgAAL4YCACSbrgIAE28cA///JTRA=
Date: Sun, 01 Mar 2015 00:45:41 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B891680F009@xmb-rcd-x06.cisco.com>
References: <54E4EC1A.3080303@acm.org> <CADhXe50phthLzQCKxEU0Rqt6GNviiTHzp=k96T5L1ZJXmbMOpQ@mail.gmail.com> <54E67885.80003@acm.org> <CADhXe50G+hOVQQLjM_k7yvp_yb=MUUhwxD_ucrGMJ=iNXoEmEA@mail.gmail.com> <54F23942.4030907@acm.org>
In-Reply-To: <54F23942.4030907@acm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.247.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/R3fopwdNJ8o9KryXTaSr2E8KvAY>
Cc: "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: Sun, 01 Mar 2015 00:45:46 -0000

The ECMA-393 standard as described bellows looks useful.  However, how is information in the proxy purged?  I replace the sleeping Apple TV node with a new one.  How does the proxy purge the old one?    What if the new one gets the same IPv6 address as the old one?  The devices do not use Modified EUI-64 format for IPv6 address generation.

Thanks,

Hemant

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Erik Nordmark
Sent: Saturday, February 28, 2015 4:55 PM
To: James Woodyatt; Erik Nordmark
Cc: 6man@ietf.org
Subject: Re: To DAD or not to DAD?

On 2/25/15 11:43 AM, James Woodyatt wrote:
> Well, there's the ECMA-393 standard, which was mostly written from the 
> perspective of sleep proxies integrated with network interface 
> peripheral devices, but it's not hard to see that what those sleep 
> proxies inside the NIC are doing could be extended to work with a 
> network sleep proxy like what Apple shipped in OS X hosts, the Apple 
> TV and the AirPort base station product line: when a host goes to 
> sleep, it registers its services with a sleep proxy, which acts as a 
> ND and ARP proxy for the sleeping host, answers mDNS-SD service 
> requests for it, and sends wake-on-LAN packets to the sleeping host 
> when a TCP SYN, or initial UDP packet, or what have you arrives at the 
> sleep proxy host.  When the sleeping host awakens, it sends ARP and ND 
> advertisements to invalidate cache entries on the network that 
> previously pointed to the sleep proxy.

Thanks - I'll at least add a reference to ECMA-393 and the wikpedia page for Bonjour sleep proxies to the draft.

    Erik


>
> On Thu, Feb 19, 2015 at 3:57 PM, Erik Nordmark <nordmark@acm.org 
> <mailto:nordmark@acm.org>> wrote:
>
>     On 2/19/15 3:15 PM, James Woodyatt wrote:
>
>
>             The slides offered these options:
>             1. Deprecate DAD - it is expensive and duplicates are not
>         common
>
>
>         I wish I had a euro for every second I've spent chasing
>         problems caused by expected MAC/IPv6-IID address collisions,
>         which had the root causes of either A) MAC address cloning, or
>         B) some network sleep proxy protocol misbehaving somewhere. I
>         would go live on a nice beach in Italy, and I would never wear
>         shoes again.
>
>         I've also yet to work for an employer who didn't have to deal
>         with the problem that the factory shipped a pile of machines
>         into the market with duplicate MAC addresses, and now we can't
>         rely on them being unique hardware identifiers anymore. The
>         EUI-48 and EUI-64 specifications don't actually require that,
>         you know.
>
>
>     James,
>
>     FWIW I don't believe we should deprecate it either. Put it on the
>     slides to wake folks up. That seems to work better on the mailing
>     list than it did in the meeting room in Honolulu ;-)
>
>         That draft needs to say something about network sleep proxies.
>
>
>     Is there any detailed descriptions of what sleep proxies do with
>     ND? I've just seem a wikipedia article which didn't have any detail.
>
>        Erik
>
>
>
>         -- 
>         james woodyatt <jhw@nestlabs.com <mailto:jhw@nestlabs.com>
>         <mailto:jhw@nestlabs.com <mailto:jhw@nestlabs.com>>>
>         Nest Labs, Communications Engineering
>
>
>
>
>
> --
> james woodyatt <jhw@nestlabs.com <mailto:jhw@nestlabs.com>> Nest Labs, 
> Communications Engineering

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