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

Owen DeLong <> Thu, 24 October 2019 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CC8A120100 for <>; Thu, 24 Oct 2019 09:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Status: No, score=-6.999 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 Y1xLhlyteEVB for <>; Thu, 24 Oct 2019 09:52:32 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 6F5D21200DB for <>; Thu, 24 Oct 2019 09:52:32 -0700 (PDT)
Received: from ( [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x9OGqVmU000380 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Oct 2019 09:52:31 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 x9OGqVmU000380
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1571935952; bh=g2SHeCCgoyAHGklgQzg+uocBDb/VndFkf07i1z80Crc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=p1n75PqjoIrMjZxZX/EM5xXNDTnhFMcvt/Q0+wO6E46JzSTbfxPqtiPra+A2ZAljp HKddEzWyh6ZlzysAUIVCM2UeQi4Ty04j9R6sGbUu3js0p7UeH8Gk0L1ikHAzZ6pQc8 WSF1KZeoJsKtgmdkcwlpG3CTNjkv4zJj0EmnY51U=
From: Owen DeLong <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BBA4E4E1-A862-425B-8B3B-07C74BE29715"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 24 Oct 2019 09:52:31 -0700
In-Reply-To: <>
Cc: Philip Homburg <>,
To: Fernando Gont <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( [IPv6:2620:0:930:0:0:0:200:2]); Thu, 24 Oct 2019 09:52:32 -0700 (PDT)
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 16:52:35 -0000

>> I'm also not convinced
>> that there are sensible values for these lifetimes that are robust enough 
>> and at the same time responsive enough to deal with the issue at hand.
>> Reducing the lifetimes would help against build up of stale prefixes. If
>> they are set to a couple of hours.
> I do agree that this is not a complete solution, but, as you correctly
> note, would help against build up of stale prefixes.

I do agree that 7 and 30 days, respectively are absurd timer default values.

I think we can take some lessons from IPv4 and DHCP here. A fairly common
lease time in the DHCP world is 3600 seconds (1 hour). This seems like a
reasonable default preferred lifetime and I would propose that 1 day (86400)
seconds may well be a reasonable default valid lifetime.

It is worth noting that these values are tunable by the administrator and the
RFC suggested defaults should never be a hard-coded value.

With the following exception, I don’t advocate modifying this on the client
	+	Section 5.5.3 of RFC4862 should be amended to specifically
		allow the immediate deprecation of a prefix by sending a valid
		lifetime of 0 seconds. Hosts should be required to honor
		this as a signal that the prefix is no longer valid.

I do think that generally speaking, your proposed modifications to CPE and
router behavior should be standardized and implemented.

> 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.

In the crash scenarios you describe, you’re assuming a single router on the network or
at least only one router announcing the prefix(es) in question with no persistent
memory of the prefixes it was announcing across a reboot. In such a scenario,
it seems to me that the following are also likely valid assumptions:

	+	The network has significant excess bandwidth compared to demand.
	+	The small overhead of frequent RAs and short lifetimes is probably
		an acceptable tradeoff in this environment.

However, there are lots of other scenarios in the world where those assumptions
won’t hold true and we should not seek to solve this problem (which is generally
applicable to residential and SMB environments) at the expense of all of those
other professionally administered environments.


For the busy wifi scenario, the preferred lifetime of zero for the old PIO should be
sent many times and should be maintained in the configuration for at least
OldPreferredLifetime seconds. At the end of OldPreferredLifetime seconds,
if a host hasn’t seen the new RA, it will no longer matter as the last RA it saw
will have expired. It’s not ideal, but there really aren’t a lot of good options here
other than getting WiFi vendors to improve multicast reliability.

In your automated configuration management scenario, IMHO, the people
driving the automation have erred. The related case is, IMHO, a variant
of the exact same case and represents the same error. It is still operator
error regardless of whether the operator is driving an automation system,
or is directly configuring a router. At a certain point, we need to accept that
there is a limit to the acceptable gymnastics for the prevention of operator
error. The best colloquialism here is “If you make something completely
idiot proof, the world will invent a better idiot.”

In section 3.2.1, you advocate setting the A and L bits to their previous values
for prefixes which are being deprecated. IMHO, this is incorrect and the
announcements calling for immediate deprecation should also indicate that
the prefix should no longer be auto-configured and should no longer be
considered on-link.

Is there some unfortunate widely deployed behavior that interacts poorly
with setting A and L to 0 for these previously valid prefixes?

Finally, An editorial note… In Section 3, you state “Finally, Section 2.5 analyzes…”
I believe this is intended to be a reference to section 3.2.2.