Re: [dhcwg] IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)

Fernando Gont <fgont@si6networks.com> Thu, 13 August 2015 19:47 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20E91B3A2E for <dhcwg@ietfa.amsl.com>; Thu, 13 Aug 2015 12:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 IdDyIl78Ve_q for <dhcwg@ietfa.amsl.com>; Thu, 13 Aug 2015 12:47:51 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 4D6BA1B3A38 for <dhcwg@ietf.org>; Thu, 13 Aug 2015 12:47:47 -0700 (PDT)
Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <fgont@si6networks.com>) id 1ZPyTX-0005Bp-Dz; Thu, 13 Aug 2015 21:47:43 +0200
Message-ID: <55CCF3FC.2070407@si6networks.com>
Date: Thu, 13 Aug 2015 21:46:04 +0200
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
References: <489D13FBFA9B3E41812EA89F188F018E1CB90384@xmb-rcd-x04.cisco.com> <20150811141557.GG23262@angus.ind.WPI.EDU> <CAKD1Yr0wkAsZbM6wcWmFMnB8TLmF4Fmy=xbJB6dx8dW2wgiZZg@mail.gmail.com>
In-Reply-To: <CAKD1Yr0wkAsZbM6wcWmFMnB8TLmF4Fmy=xbJB6dx8dW2wgiZZg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/nohe5sD1TCLeBfmJmK1W8opE_Kw>
Subject: Re: [dhcwg] IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2015 19:47:53 -0000

On 08/12/2015 03:58 AM, Lorenzo Colitti wrote:
> On Tue, Aug 11, 2015 at 11:15 PM, Chuck Anderson <cra@wpi.edu
> <mailto:cra@wpi.edu>> wrote:
> 
>     it offers a useful way to implement DHCPv6 Failover using a
>     calculated technique rather than state-sharing,
> 
> But it doesn't. With this scheme, if the client issues a DECLINE for any
> reason (e.g., because the address that's assigned is a duplicate, or due
> to a temporary link problem such as a looped port), there are exactly
> two options to make things work correctly:
> 
> 1. Leave that client without an IPv6 address.
> 2. Make all the DHCPv6 servers on the link record all leases and share
> all lease state, losing all the benefits of statefulness.
> 
> This is a fundamental flaw in this scheme which I believe cannot be fixed.

IMO, this is similar to saying that the automobile design is flawed
because they cannot operate on water.

This ID assumes that the address pool enough such that address
collisions are (probabilistically speaking) extremely unlikely.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492