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

Owen DeLong <> Thu, 31 October 2019 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0789A1209D9 for <>; Thu, 31 Oct 2019 12:27:39 -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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 Sy5sxzQi4Lcg for <>; Thu, 31 Oct 2019 12:27:36 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 9DE0912097C for <>; Thu, 31 Oct 2019 12:27:32 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x9VJRVkF021473 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 12:27:31 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 x9VJRVkF021473
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1572550052; bh=tQeKh/rNwYgT1e/jvMxMIfJ7B4MZ3KOjy0yhN1GiZXg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=GtELwLZd2GcNvox5/EVKjE4oU79XsmXa9EOrbDPS83G0aWpyVoGHZeMuY9yQ1LmT3 PXZhLCEWpXkFWorNc89+L+r/qJCM6idzFtfvJj6BnXRD9itIm7KTCsLrP8Og5fT2qy T1uuYgoevR8LtVrFOLIf/ztXvZgkUDeXOB2OmQrw=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Thu, 31 Oct 2019 12:27:30 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Thu, 31 Oct 2019 12:27: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, 31 Oct 2019 19:27:45 -0000

> On Oct 31, 2019, at 12:13 PM, Fernando Gont <> wrote:
> On 27/10/19 01:48, Owen DeLong wrote:
>>>> 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
>>>> side:
>>>> +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.
>>> Could you please elaborate on this one?
>> I’m not sure what I could do to elaborate. The addition of a specific
>> call-out that
>> even if the current behavior of ≤2 hours = 2 hours is to be preserved,
>> there should
>> be a special case for “0 seconds” which causes the prefix to be immediately
>> deprecated with extreme prejudice.
>> Hosts should be required to treat an RA containing a prefix with a 0 second
>> valid lifetime as an invalid prefix and immediately deprecate it from
>> the interface
>> if it is in use.
> OK, so you do agree with the proposed change? (in
> draft-gont-6man-slaac-renum, not in *this* document)

From the context of my thinking at the time of writing the original reply,
“this document” referred to draft-gont-6man-slaac-renum. Apolgies
for my lack of clarity as you have apparently interpreted it differently.

>>>> 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.
>>> Even with the default RA frequency, if you were to unprefer a prefix
>>> upon, say, second RA that doesn't advertise it, and say, remove the
>>> prefix after many other RAs are received, that would be a *big*
>>> improvement to what we have now.
>> I don’t like this idea because I can think of some scenarios where you
>> may receive multiple RAs from router A not containing the prefix in the
>> same time frame that router B has not sent an additional RA containing
>> the prefix, but it will do so in its next RA.
> Maybe it wasn't clear in the I-D, but the basic idea is:
> If you receive multiple RAs from router A that do not advertise the
> prefix, then you disassociate such prefix with router A. If nobody else
> is advertising the prefix, you'd deprecate it. If other routers are
> advertising it, this would not change the status quo of the prefix wrt
> such other routers.

That’s definitely not how I interpreted the I-D and I would strongly encourage
you to review and update the I-D for clarity in this area. I’m actually still not
100% convinced that this is correct behavior. It also places additional burdens
on hosts to track all routers associated with a given prefix rather than merely
tracking candidate default gateways, RIO data, and one set of prefix timers
utilizing the most recently received timer refreshes.

>> There is no requirement for all routers on the same link to provide the
>> same set of PIOs, nor are they required to use the same advertisement
>> timers.
> Agreed. Please see above.

With the above clarification, I think it can be done and is less likely to break
things. However, it does place a significant additional tracking burden on the
host which I’m not entirely convinced is a desirable situation. Especially in the
case of a resource-constrained host which is using SLAAC to avoid the overhead
of DHCP.

>>>> 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.
>>> Not sure I follow. Could you please elaborate?
>> Sure… In section 3.2.1 of your document, you advocate that if the previously
>> valid PIOs were set A=1 and/or L=1, then those values of the A and L bits
>> should be preserved in the RAs sent to deprecate them.
>> My argument is that since you are attempting to make this a prefix that
>> hosts
>> will no longer autoconfigure (A) and will no longer consider on-link
>> (L), that
>> in reality, regardless of the previous state of the A and L bits in the RAs
>> announcing the prefix in a valid PIO, the new RAs since the prefix has been
>> deprecated should be sent with A=0, L=0 in order to signal the host
>> that this prefix should not be auto configured and should no longer be
>> considered on-link.
> You really make a good point. I will go through RFC4861 and see what's
> the current expected behaviour in such case.