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 > --------------------------------------------------------------------
- Next Steps on DAD Improvements Bob Hinden
- Re: Next Steps on DAD Improvements James Woodyatt
- Re: Next Steps on DAD Improvements Brian E Carpenter
- Re: Next Steps on DAD Improvements Lorenzo Colitti
- Re: Next Steps on DAD Improvements Pascal Thubert (pthubert)
- Re: Next Steps on DAD Improvements Lorenzo Colitti
- Re: Next Steps on DAD Improvements Brian E Carpenter
- RE: Next Steps on DAD Improvements JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
- RE: Next Steps on DAD Improvements Greg Daley
- Re: Next Steps on DAD Improvements Lorenzo Colitti
- Re: Next Steps on DAD Improvements Ole Troan
- RE: Next Steps on DAD Improvements Greg Daley
- Re: Next Steps on DAD Improvements Lorenzo Colitti
- Re: Next Steps on DAD Improvements Ole Troan
- Re: Next Steps on DAD Improvements Lorenzo Colitti
- Re: Next Steps on DAD Improvements Ole Troan
- Re: Next Steps on DAD Improvements Lorenzo Colitti
- Re: Next Steps on DAD Improvements Tim Chown
- Re: Next Steps on DAD Improvements Lorenzo Colitti
- Re: Next Steps on DAD Improvements Tim Chown
- RE: Next Steps on DAD Improvements Hemant Singh (shemant)
- Re: Next Steps on DAD Improvements Mark ZZZ Smith
- Re: Next Steps on DAD Improvements 神明達哉
- Re: Next Steps on DAD Improvements Erik Nordmark
- Re: Next Steps on DAD Improvements Erik Nordmark
- RE: Next Steps on DAD Improvements Pascal Thubert (pthubert)
- Re: Next Steps on DAD Improvements Sowmini Varadhan
- RE: Next Steps on DAD Improvements Samita Chakrabarti
- Re: Next Steps on DAD Improvements Bob Hinden