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

Lorenzo Colitti <lorenzo@google.com> Wed, 12 August 2015 01:59 UTC

Return-Path: <lorenzo@google.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 0D7FD1A1BE7 for <dhcwg@ietfa.amsl.com>; Tue, 11 Aug 2015 18:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 O6ORmp1X-Hdt for <dhcwg@ietfa.amsl.com>; Tue, 11 Aug 2015 18:59:02 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 DF79B1A1BC8 for <dhcwg@ietf.org>; Tue, 11 Aug 2015 18:59:01 -0700 (PDT)
Received: by ykdt205 with SMTP id t205so2906707ykd.1 for <dhcwg@ietf.org>; Tue, 11 Aug 2015 18:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=9G3q2alnX8vpXezBMkd8NRd7ExJRd9Xsm8Z4us1P3AM=; b=LwPAQ6wktrkKG5KmKHrkm0BX4hRYWR1NypqXBqWVvRDYN2m8C6Rogj9B0lA9i1mzv+ NdzMcjCTXzM70Qg6TNKRkTUCpnhnCfgyje1ccHLx/sMCEmlu5IleCJqqgsaw9pRvvx39 0DjF7vG0V5rzw/A+D57B8yqsnRfm53+3enbedkh+ZBOLvU1z7O0ltjktTSiwpRW9Pkik bAK4Xv3tNTQvXfjTmt6XlPqa34Z9ztXnZfwruWpp6nHZo1RmFCPp50wz5CiT/Rf/WgI8 fFTVRMmYvVkWgrgxfZ61g9IYZjkc94xqTbNG0d02IcxxoBQQKjc0UHEg5suWXG+noYyU byUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=9G3q2alnX8vpXezBMkd8NRd7ExJRd9Xsm8Z4us1P3AM=; b=ZJlB1dwJ+0MsvJIZqJhBwFGCDnNs0btVaSE3I8BzXsPcxpbKfp5ShhWEJ2+BpygmuV 0ZhkUWNV1YvMjVp971mCBCwB6L+WTMadT2EhalQeu1hgmLy7M15Givgbh6GBcfKTxBAT KBYviGodrKBSKNP8NFr1bnsh3u98P16PU5HZd0Vw+/bwUZtZvNoTwpTZhR3ABuL/3Kx3 syNjr0L6sV4Wtp7lzch8/eBPo1Wn8GJWX7yL3/ACOeplFaEvPYl9kGDbomZd6O6Pr8xe 1Nkq3SVJHnHFjzIVYrRkain2ZJUaa39Smryy5GAUhiXfiXAwBd+55i331dwd8HZ4bhy6 5quA==
X-Gm-Message-State: ALoCoQklks0vr5QOzOUW4oKkXWfVgjUvREZX19uGINpX5VI/Q0qKHFdwHPilOpdEMIxrmVtyoOu/
X-Received: by 10.13.255.2 with SMTP id p2mr30815328ywf.149.1439344740955; Tue, 11 Aug 2015 18:59:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.116.147 with HTTP; Tue, 11 Aug 2015 18:58:41 -0700 (PDT)
In-Reply-To: <20150811141557.GG23262@angus.ind.WPI.EDU>
References: <489D13FBFA9B3E41812EA89F188F018E1CB90384@xmb-rcd-x04.cisco.com> <20150811141557.GG23262@angus.ind.WPI.EDU>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 12 Aug 2015 10:58:41 +0900
Message-ID: <CAKD1Yr0wkAsZbM6wcWmFMnB8TLmF4Fmy=xbJB6dx8dW2wgiZZg@mail.gmail.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c0888f6fed177051d138f21
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/wfpCAY_yZ_AdVbLnzKUIbU-MkbI>
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: Wed, 12 Aug 2015 01:59:03 -0000

On Tue, Aug 11, 2015 at 11:15 PM, Chuck Anderson <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.