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

Fernando Gont <> Fri, 01 November 2019 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 643A4120847 for <>; Fri, 1 Nov 2019 03:40:15 -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 WxvU2qCTOzJI for <>; Fri, 1 Nov 2019 03:40:13 -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 58F87120821 for <>; Fri, 1 Nov 2019 03:40:13 -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 E0DC086ABF; Fri, 1 Nov 2019 11:40:10 +0100 (CET)
To: Ted Lemon <>
Cc: v6ops list <>
References: <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Fri, 1 Nov 2019 07:39:52 -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 10:40:20 -0000

On 1/11/19 07:11, Ted Lemon wrote:
> On Nov 1, 2019, at 5:45 AM, Fernando Gont <
> <>> wrote:
>>> So why aren’t they doing that?   What’s the obstacle?
>> Are you referring to the CPE case, or to the rest?
> I’m specifically referring to the ISP case, although I think referring
> to it as “the CPE case” is limiting your options! :)

At least one ISP reported issues with their provisioning system. I will
ask another, and come back to you.

>> If you assume all routers employ the same values for the valid/preferred
>> lifetimes, then what you propose is the equivalent to "prefer the last
>> advertised prefix". In which case, in the presence of multiple RAs the
>> src address of new sessions will deterministically flap. That doesn't
>> seem nice from a troubleshooting perspective.
> No, I’m saying that if you have two prefixes, one with a preferred
> lifetime of zero, and another with a preferred lifetime that is not
> zero, you should choose the second one.   Can you explain in a little
> more detail when this would cause a “deterministic flap”?

I misunderstoof you. What I was assuming that you were describing is this:

* CPE no longer advertises OLDPREFIX

* CPE now advertises NEWPREFIX

* If hosts always prefer the prefix with the larger Preferred Lifetime
(or the latest advertised Prefix), then you have "solved the problem"

However, in a scenario where you have two routers, Router_A that
advertises PREFIX_A, and Router_B that Advertises Prefix_B, then, upon
receipt of an RA from Router_A, Prefix_A would become preferred. But
then, when an RA from Router_B is received, Prefix_B will become
preferred. Then, upon receipt of an RA from Router_A, Prefix_A will
become preferred again.

In the case you discribe, all is fine. However, the key is: what caused
the Preferred Lifetime to become 0? (and RA from the CPE trying to
deprecate a previous prefix?)

>>> As for previous comments about source address selection, I think that if
>>> you have two prefixes that are otherwise equivalent (a tie), and one has
>>> a preferred lifetime of zero, while the other has a preferred lifetime
>>> of not-zero, it would be dysfunctional to choose the one with the
>>> preferred lifetime of zero.  What on earth is the purpose of preferred
>>> and valid lifetimes if SAS isn’t taking them into account?
>> The timers are only supposed to be of use if they go off. Given the
>> default values the use (one month, and one week), they never go off.
>> The valid lifetime would trigger garbage collection for stale prefixes.
>> The preferred lifetime would keep a fresh and working address as the
>> preferred address for new flows. -- if only they went of in a timelier
>> manner.
>> So, I'd rather ask the question: what on earth is the purpose of setting
>> a timer that will never go off in a meaningful situation and period of
>> time?
> Possibly we are talking past each other.   A prefix with a preferred
> lifetime of zero always has a preferred lifetime of zero.   There’s no
> timer to go off.   How the preferred lifetime /got/ to be zero is of
> course an important question, and there I think that what you are
> getting at is important: a 30 day expiry time is way too long.

Yep, then we were talking past each other :-)

> What if the user does want to release the prefix, e.g. for privacy reasons?
>> Not that I oppose to that. But I just note that there's no reason for ot
>> trusting a router that advertises PIO,VL=0, because your trust model is
>> that you do trust the router (if not your whole local network).
>>> If I get an RA that’s not signed by the same key as a route in my
>>> routing table that’s working, I don’t let it override what is currently
>>> in my routing table and working.
>> But that's not the current deployed reality. IN current deployments, RAs
>> are not signed. So why wuld you be skeptical to PIO, VL=0?
> Right, we have a problem there.   SEND didn’t solve it.   I don’t think
> RA Guard solves it for the home case.   So, there is work to do… :)

Improvements in this area would certainly be nice. However, my point is
that it should be quite acceptable for one to update RFC4861 such that
PIO, VL=0 be honored, since the trust model is that you do trust
routers... and, in terms of DoS, there are already pletny of other
vectors for an attacker to exploint.

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