Re: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)

Fernando Gont <> Tue, 19 May 2020 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85B353A0AB8 for <>; Tue, 19 May 2020 09:08:50 -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 lLN2fKDaYgNi for <>; Tue, 19 May 2020 09:08:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 857443A0A84 for <>; Tue, 19 May 2020 09:08:46 -0700 (PDT)
Received: from [IPv6:2800:810:464:11f:ddb1:8740:ceee:11b0] (unknown [IPv6:2800:810:464:11f:ddb1:8740:ceee:11b0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 092CE28380C; Tue, 19 May 2020 16:08:43 +0000 (UTC)
Subject: Re: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)
To: Philip Homburg <>,
References: <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Tue, 19 May 2020 13:06:28 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2020 16:08:57 -0000

On 19/5/20 12:24, Philip Homburg wrote:
> In your letter dated Tue, 19 May 2020 03:38:18 -0300 you wrote:
> I disagree with Section 4.1.2. Host should not try to second-guess routers.
> So host should keep preferred and valid lifetimes unchanged.

[This is responded below]

> In Section 4.5, I think it is bad to hardcode knowledge about ULAs
> in detecting stale prefixes. In my opinion that shows that the
> algorithm is fragile. And note that this applies to all hosts.

Not sure what you mean. Could you please elaborate?
Unfolding th processing of ULA vs. non-ULA is simply 
fine-tuning/optimization: So if, say, you had a globally-reachable 
address, and now the router ceases to advertise the globally-reachable 
addresses, but starts advertising the ULA, you keep both.

One might was well not do this optimization, but it's certainly better 
this way.

WHy do you think about the algorithm being fragile?

> So there might be other circumstances where some prefixes are special. A
> site may have multiple ULA prefixes that have different meaning. The
> same applies to regular global unicast.

The logic here is:

When a prefix is missing, that's an indication that the prefix has 
become stale. Now, you might process the RAs irrelevant of ULA nad 
non-ULA, and it would also be fine.

But the logic here is that it is better to have one stale address of 
each type, than no address of that type. If you want, this is the 
algorithm being more conservative.

> So in my opinion the best way forward is to only expire prefixes quickly
> if the host knows that the router sends all information in one RA.
> Hosts can easily detect if a router uses one RA or multiple RAs.

Two things:

1) network config split into multiple RAs do not happen in practice -- 
as reported by Time Winters

2) Irrelevant from #2, from a theoretical there's no way in which a host 
can positively know whether information is split into multiple RAs or 
not. You may try to "sample" the router. But if you don't get split 
information that might simply be the result of packet loss. 
Additionally, the fact that at time T information is sent in a single 
RA, doesn't mean that that will be the case at time T+t.

The point of the algorithm is simple:
The algorithm doesn't deprecate prefixes at once. So if information is 
split into multiple RAs, then since you don't act on RAs at once, the 
algorithm will handle the split information gracefully.

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