Re: A common problem with SLAAC in "renumbering" scenarios

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Mon, 04 February 2019 13:47 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B2512896A for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 05:47:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 sk4agWXKBUmp for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 05:47:47 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 88F74127B4C for <ipv6@ietf.org>; Mon, 4 Feb 2019 05:47:45 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1gqeb9-0000GCC; Mon, 4 Feb 2019 14:47:43 +0100
Message-Id: <m1gqeb9-0000GCC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <62b74cf1-9cb0-bba3-b078-cb6f48e90145@foobar.org>
In-reply-to: Your message of "Mon, 4 Feb 2019 13:30:13 +0000 ." <62b74cf1-9cb0-bba3-b078-cb6f48e90145@foobar.org>
Date: Mon, 04 Feb 2019 14:47:43 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hE6OUzitaqhDMy5wDHL7pD3sgAM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 04 Feb 2019 13:47:49 -0000

>Unless I'm mistaken, Ole is saying that a dhcp6-pd lease for time period 
>X is a contract for time period X, during which the ISP should retain 
>enough state that if the CPE issues another dhcp request within time 
>period X, they will receive the same prefix.  However, when time period 
>X elapses, the ISP is fully within their rights to assign a different 
>prefix.

The way I understand DHCP leases is that for the duration of the lease, 
the party that obtained the lease has exclusive use of the address or prefix.
So it is a requirement on the DHCP server to avoid giving the lease to another
party.

As far as I know it never said anything about getting the same address or 
prefix if you do a DISCOVER.

A related point, and that's where it starts getting complicated, is that 
over time DHCP got used for access control. Initially DHCP was just a way
for making sure that everybody got a unique address, but you could just
use any address you liked at the risk of collision.

These days access routers restrict source addresses to whatever was offered in
a DHCP lease. And this is where it gets messy. 

In theory we could specify how access routers could do the right thing. And then
get CPEs to do the right thing as well.

But I think it would be more productive to make hosts more robust.