Re: Next Steps on DAD Improvements

Erik Nordmark <nordmark@acm.org> Thu, 09 July 2015 16:47 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 4BC721B2A53 for <ipv6@ietfa.amsl.com>; Thu, 9 Jul 2015 09:47:19 -0700 (PDT)
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 y0KFQi9BPexO for <ipv6@ietfa.amsl.com>; Thu, 9 Jul 2015 09:47:18 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1232A1AC408 for <ipv6@ietf.org>; Thu, 9 Jul 2015 09:47:18 -0700 (PDT)
Received: from [192.168.10.21] ([78.197.168.57]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t69Gl7FU008455 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Jul 2015 09:47:09 -0700
Subject: Re: Next Steps on DAD Improvements
To: Lorenzo Colitti <lorenzo@google.com>, Ole Troan <otroan@employees.org>
References: <8CD12D24-FFB3-4F92-9E13-B4D9A40F3B3A@gmail.com> <CAKD1Yr1Z+Q=XELmEOzsw0D=PcuDXSmGtDTTdaMGbbtPqPbQHPA@mail.gmail.com> <7FE19EE0-EB14-4C1E-9B29-4C859D363DC2@cisco.com> <CAKD1Yr3ONe6cSUddjEh0eO2e8K8-qxMT6L0NCE7Jjh5t=csGLA@mail.gmail.com> <72381AF1F18BAE4F890A0813768D99282DA8A2E9@sdcexchms.au.logicalis.com> <CAKD1Yr0DNjtCcS++uF9m9Asy4+4nEh4o=gMX0pQf-ndJ0P9H4Q@mail.gmail.com> <3E3182A4-01F7-4520-8167-DD678B79E8AF@employees.org> <CAKD1Yr0oLbBNyB8EyVU=npUfjH7Ny_bYWCRo2oFoAattqPsx5w@mail.gmail.com> <C40203E5-D350-4DCE-B01A-3748A33672BC@employees.org> <CAKD1Yr0-HpcSvwSGC9HstVxD+XCNuadK+uOxhPJT9E2m+yYfug@mail.gmail.com> <F02F75A4-039A-416B-8D3B-725ECC1DF67F@employees.org> <CAKD1Yr2ZECY8-1wX6xg2jFghTecBj7n-MkW59FCu7XSeTXpVPg@mail.gmail.com>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <559EA584.1030804@acm.org>
Date: Thu, 09 Jul 2015 18:47:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr2ZECY8-1wX6xg2jFghTecBj7n-MkW59FCu7XSeTXpVPg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sonic-CAuth: UmFuZG9tSVaRf155FUVNzLWUrkG7QUWOSw0MyhcHe6zi2v8ZMZVHY1nkJW8vpzAlv2S48y8NTtrY563uaB9s24IFNgIflKyb
X-Sonic-ID: C;4sLLIlom5RG2ZYM848vClw== M;sJGcI1om5RG2ZYM848vClw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/AEoqjowREu-_Oyi286xVuPPxwCs>
Cc: Bob Hinden <bob.hinden@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, 6man WG <ipv6@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: <https://mailarchive.ietf.org/arch/browse/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, 09 Jul 2015 16:47:19 -0000

On 6/10/15 10:44 AM, Lorenzo Colitti wrote:
> On Wed, Jun 10, 2015 at 5:27 PM, Ole Troan <otroan@employees.org 
> <mailto:otroan@employees.org>> wrote:
>
>     > How is that different from the network telling the host that an address can no longer be used?
>
>     that might be one way the hosts figures out an address no longer
>     works.
>     but I don’t think we can assume the network would necessarily know
>     in all cases.
>
>     please let’s not make too many assumptions about solutions at this
>     stage.
>
>
> I'm not talking about solutions, I'm talking about scope.

Sorry for having ignored this thread for so long - too much opinions and 
noise for my taste ;-)

If you read draft-yourtchenko-6man-dad-issues you'll see that one of the 
issues is Partition-join tolerance. An implication of that is that at 
the point that an address is configured the link might be partitioned. 
And no authoritative entity on the link can help here since two 
different nodes might attempt to configure the same address while the 
link is partitioned (unless the authority is using quorums and disables 
the nodes that are not connected to a quorum, which sounds like a 
treatment worse than the disease).

This implies that the only way to can be sufficiently robust is by doing 
on-going duplicate detection; something RFC 5227 does for IPv4.

So please please read at least dad-issues since that contains the scope. 
If we want to discuss possible solution approaches I'd say that AFAICT 
an authority isn't a useful solution to get robustness.

    Erik




> Duplicate address detection is a well-defined concept. It deals with 
> detecting duplicates on a given link. On the other hand, saying that 
> an address "works" is a completely undefined concept. You might be 
> able to say that an address is unique on link at a given point in 
> time, or that it's not unique, or that it can be used to reach some 
> set of off-node (on-link or off-link) destinations.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------