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

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 05 February 2019 10:31 UTC

Return-Path: <swmike@swm.pp.se>
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 C0832130F2A for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 02:31:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 4QZObjkOeZUl for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 02:31:04 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 3F7A0130F24 for <ipv6@ietf.org>; Tue, 5 Feb 2019 02:31:03 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id C5DF4B5; Tue, 5 Feb 2019 11:31:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1549362660; bh=By6X3YiHUPXT5DIHpLkiqe02z5+oR3vYOhr9+3h3Av0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CvuVD6lPs8Yyzlk3AHL5xuNj3b/7ceOH+85mOKpc7yZgq7MSmdcdogXkKYJy6A7xm tfBHNMOsWvnpDxdlrnjbsysztg/FjZVy2WJRIi+Q1CNXGPKphD+iRoT8UZP+KIMjhi Sjj6TA6S4x4JA06nhDaTrzhnjrnsOcApx3wGiQZw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C3A27B1; Tue, 5 Feb 2019 11:31:00 +0100 (CET)
Date: Tue, 05 Feb 2019 11:31:00 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Richard Patterson <richard@helix.net.nz>
cc: Fernando Gont <fgont@si6networks.com>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
In-Reply-To: <CAHL_VyDdHuEAc9UdeiRp9f+c0tdzyoLwPY1rJbZmbWAuq96Uuw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1902051127510.23912@uplift.swm.pp.se>
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> <77ecf321-b46e-4f25-7f68-05b15714a99e@si6networks.com> <CAHL_VyDdHuEAc9UdeiRp9f+c0tdzyoLwPY1rJbZmbWAuq96Uuw@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6lY-gqeDaxRxrKUKV_b6J2htpm8>
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: Tue, 05 Feb 2019 10:31:07 -0000

On Tue, 5 Feb 2019, Richard Patterson wrote:

> The lease state is stored on the BNG/DHCP server.  If the CPE uses a 
> stable DUID, hasn't sent a Release, and returns within the valid 
> lifetime, then it should receive the same PD.  Some BNG vendors also 
> track an additional lease lifetime longer than the valid lifetime, to 
> keep old leases in a reserved/held state allowing a CPE to retain the 
> same PD even after the valid lifetime has expired.

There are also DHCP servers that can be configured to always find the 
oldest expired lease and hand that out if there are no never-used 
resources. If a device shows up 2 months after the lease expired with the 
same DUID and nobody has used that lease in between, then they get the 
same PD again that they had 2 months prior.

If the device has permanent storage then it could ask for the previous PD 
it had, and if that's free then it'd get it. So as discussed earlier in 
the thread, having the HGW just store the last PD it had could be helpful 
even if it never updates it with information as long as it's the same.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se