Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04

Fernando Gont <> Wed, 21 October 2020 00:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F7213A0C10; Tue, 20 Oct 2020 17:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iz1iGiYlJ02k; Tue, 20 Oct 2020 17:37:16 -0700 (PDT)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 866423A0C01; Tue, 20 Oct 2020 17:37:15 -0700 (PDT)
Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5225A283A8B; Wed, 21 Oct 2020 00:37:12 +0000 (UTC)
To: Ted Lemon <>
Cc:,, v6ops list <>,
References: <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Tue, 20 Oct 2020 20:24:55 -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: 8bit
Archived-At: <>
Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04
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: Wed, 21 Oct 2020 00:37:21 -0000

Hello, Ted,

On 20/10/20 19:23, Ted Lemon wrote:
> On Oct 20, 2020, at 3:51 PM, Fernando Gont < 
> <>> wrote:
>>> This is relevant because some IoT deployments make use of sleepy 
>>> devices that may only wake up once per day or even less frequently. 
>>> The suggested parameters would be inappropriate for such a device.
>> Just me double-checking: Do you mean it would be to short for them?
>> Please note that the default router lifetime is 1800 seconds. So a host
>> that sleeps for longer than that will presumably not have a default 
>> router when it wakes up, and would need to do a "refresh" procedure 
>> (RS/RA exchange) before it would be able to send a packet, anyway.
> Right, in a situation like this, where the network is pretty stable, it 
> would make sense to use longer lifetimes. Also bear in mind that the 
> communication on this network might be between two hosts on the same 
> link—one a data collector and one a reporting device. So the router 
> lifetime might not be an issue. If the communication is going 
> off-network, a longer router lifetime would be required.

(food for thought) It would seem to me that from a robustness principle, 
the nodes should be able to deal with this type of scenarios gracefully. 
That said, if you're communicating on the local link, you'd employ 
link-locals (and hence don't care about the RAs and associated 
parameters). And if you do mean to communicate off-link, thenthe first 
concern would be the Router Lifetime, rather than the prefix lifetimes.

>>> At the same time such a device likely is not relying on RA, since it
>>> would not be awake for periodic refreshes. Nevertheless the 
>>> operational mitigations section could use some additional verbiage 
>>> about applicability so that readers do not assume that the advice 
>>> given there is universally applicable.
>> Please clarify the above, and based on that, we could craft some text if
>> necessary.
> What I’m suggesting is simply that you mention that the defaults you are 
> recommending are really most applicable in home networks, and may not be 
> applicable in various commercial networks, including the IoT deployment 
> I used as an example.  IOW, make it clear that these defaults are not 
> universally applicable. There’s no text right now that says that (unless 
> I missed it).

I'd argue that they are applicable to most general cases, not just home 
networks. e.g., I know of several enterprise deployments that employ 
"shorter than RFC4861" RAs. e.g., radvd employs 4 hours/1 day for the 
PL/VL.  An operator may always manually override these values, anyway.

In any case, how about adding this to the "Notes" in Section 3.2:

--- cut here ----
The aforementioned values for AdvPreferredLifetime and AdvValidLifetime 
are expected to be appropriate for most general network scenarios. 
However, operators should analyze what specific values for these 
configuration variables would better suit their specific network scenarios.
---- cut here ----

...or the like?


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