Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

JORDI PALET MARTINEZ <> Wed, 30 October 2019 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CBF312081A for <>; Wed, 30 Oct 2019 06:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8TJyBJTDzhrT for <>; Wed, 30 Oct 2019 06:33:16 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB17F1200DE for <>; Wed, 30 Oct 2019 06:33:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; s=MDaemon; t=1572442392; x=1573047192;; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=fuLyO7Et+4evJLorD/REq0 lgzBvixKBPt2+hsd0JLvQ=; b=Q4B17m5Wp/AWn0TrWxXq0uKaNPTH8G6gT5Tl89 /cwBnI0nHb6iQDiaHSscC63+VBtpBu5racgxTqht4uVsNvssW487G/sKj3JAw4G2 F4yRZiW493YXLtlJM8lP7H5x5Bza1MGMb30N8fEcpQqnhAzzK1wVczoYst1i5or+ 41uFo=
X-MDAV-Result: clean
X-MDAV-Processed:, Wed, 30 Oct 2019 14:33:12 +0100
X-Spam-Processed:, Wed, 30 Oct 2019 14:33:10 +0100
Received: from [] by (MDaemon PRO v16.5.2) with ESMTPA id md50006446627.msg for <>; Wed, 30 Oct 2019 14:33:09 +0100
X-MDRemoteIP: 2001:470:1f09:495:81e7:1e88:3063:7d60
X-MDHelo: []
X-MDArrival-Date: Wed, 30 Oct 2019 14:33:09 +0100
User-Agent: Microsoft-MacOutlook/10.10.f.191014
Date: Wed, 30 Oct 2019 14:33:08 +0100
To: "Bernie Volz (volz)" <>, Ted Lemon <>, Timothy Winters <>
CC: IPv6 Operations <>
Message-ID: <>
Thread-Topic: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
References: <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3655290788_72956351"
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2019 13:33:19 -0000

Hi Bernie,


I think RFC4649, option 37, provides that option.








El 30/10/19 14:25, "v6ops en nombre de Bernie Volz (volz)" < en nombre de> escribió:


While I haven’t followed this discussion in detail, I do wonder if the SP DHCP server could provide some assistance to CPEs that don’t have storage …


When a CPE boots and does a Solicit / Request, it could include a new option that tells the DHCP server that it has no storage and therefore no knowledge of any “past” leases. The DHCP server in this case could include any “old” leases it still has a record of (i.e., that have not expired but are no longer “valid” in terms of the configuration because of renumbering or other conditions) with 0 lifetimes. That would allow a rebooting CPE to learn old delegated prefixes that it might have advertised to its clients and initiate deprecation of these prefixes (and any addresses generated from them).


This would improve the situation when the CPE has no storage and reboots (whether customer or SP initiated).


Note: There could be conditions in which this would fail (such as if SP removed all configuration related to the older prefixes from the DHCP server), but in many cases it would allow for clean renumbering. Of course, it requires updating the DHCP software (on the SP servers and in the CPEs), but it probably easier to accomplish than requiring use of storage on the CPE device.


Be a relative easy draft to write up (at least in theory).


-          Bernie


From: v6ops <> on behalf of Ted Lemon <>
Date: Wednesday, October 30, 2019 at 9:00 AM
To: Timothy Winters <>
Cc: "" <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds


On Oct 30, 2019, at 8:40 AM, Timothy Winters <> wrote: 

We check both, the handling of the IA_PD and the error message.


And to be clear, you mean that if the CPE asks for a prefix delegation and doesn’t get the prefix it previously had, it deprecates it as described in L-14?  When this deprecation happens, what ways are being tested for it to happen?


E.g., is it the case that the client sends an IA PD containing an IA Prefix option, is the server returning the IA Prefix option containing the same prefix, with a status code encapsulated in it?   What status code?   Or is it returning an IA Prefix option with a different prefix?   Or is it doing both?


_______________________________________________ v6ops mailing list 

IPv4 is over
Are you ready for the new Internet ?
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.