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

Fernando Gont <> Fri, 01 November 2019 03:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33CF01200F9 for <>; Thu, 31 Oct 2019 20:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1DsgTu7k764G for <>; Thu, 31 Oct 2019 20:07:28 -0700 (PDT)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE37412006D for <>; Thu, 31 Oct 2019 20:07:27 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D3A03869AA; Fri, 1 Nov 2019 04:07:23 +0100 (CET)
To: Owen DeLong <>
References: <> <> <> <> <> <> <>
From: Fernando Gont <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Thu, 31 Oct 2019 23:04:47 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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: Fri, 01 Nov 2019 03:07:30 -0000

Hello, Owen,

On 31/10/19 16:27, Owen DeLong wrote:
>>> 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.

Ok. BUt, double-checking: DO you agree with the proposed behaviour?

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

Thanks for the feedback! I will definitely clarify the text. FWIW, in
the context of RFC8028, you already need to keep prefixes associated
with routers....

>>> 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 the context of RFC8028, you don't have much of an option -- otherwise
you run the risk of being egress filtered.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492