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

Philip Homburg <> Thu, 24 October 2019 07:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ECB3120877 for <>; Thu, 24 Oct 2019 00:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kaVP14-hXGhI for <>; Thu, 24 Oct 2019 00:43:02 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 949DD120814 for <>; Thu, 24 Oct 2019 00:43:01 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iNXlr-0000GGC; Thu, 24 Oct 2019 09:42:59 +0200
Message-Id: <>
Cc: Fernando Gont <>
From: Philip Homburg <>
References: <> <>
In-reply-to: Your message of "Wed, 23 Oct 2019 11:07:20 -0500 ." <>
Date: Thu, 24 Oct 2019 09:42:58 +0200
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: Thu, 24 Oct 2019 07:43:05 -0000

>A better mitigation is to affect the preferred and possibly the valid
>lifetimes in response to consecutive RAs from the same router that lack
>the original (stale) prefix. e.g., after two consecutive RAs that do not
>contain the existing prefix, reduce the preferred lifetime. After two
>additional RAs, reduce the valid lifetime.

I think that to avoid confusion it is probably best to have 3 documents:
- one that describes host behavior. I think that what you describe above would
  fit in such a document. There is a lot we can do to make hosts more robust.
- one that describes CPE behavior. If the CPE explicitly deprecates old
  prefixes then that solves the problem with CPE reboots. Having
  more sensible lifetimes fits in such a document, but I don't think it
  provides a solution. It just reduces some secondary effects such as
  stale prefix build up.
- Finally, a document for ISPs describing how to best provide prefixes 
  using DHCPv6-PD. 

I think all 3 approaches are needed:
- a host doesn't want to rely on a cheap CPE doing its job.
- a quality CPE can provide better support for hosts today. There will always
  be ISPs that do flash renumbering
- finally a quality ISP may have a need to renumber customers and would like
  to do so without breaking things.