Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds

Ole Troan <> Sun, 24 January 2021 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 404B43A0E72 for <>; Sun, 24 Jan 2021 08:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 RfvN42xEz_fV for <>; Sun, 24 Jan 2021 08:50:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0095B3A0E71 for <>; Sun, 24 Jan 2021 08:50:50 -0800 (PST)
Received: from [IPv6:2a01:79c:cebd:9724:9875:42d7:7980:321c] (unknown [IPv6:2a01:79c:cebd:9724:9875:42d7:7980:321c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id D4D014E11AED; Sun, 24 Jan 2021 16:50:49 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-70ED1D6C-C719-4C3C-998D-0E6E01342E3A
Content-Transfer-Encoding: 7bit
From: Ole Troan <>
Mime-Version: 1.0 (1.0)
Subject: Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds
Date: Sun, 24 Jan 2021 17:50:47 +0100
Message-Id: <>
References: <>
Cc: Nick Hilliard <>,
In-Reply-To: <>
To: Isaac <>
X-Mailer: iPhone Mail (18C66)
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: Sun, 24 Jan 2021 16:50:53 -0000


The two variables are independent. 
The example you cited is perfectly fine.

the RA lifetime says: “don’t use me as a default router” and the reachable time configures hosts on the link to consider a neighbor entry in the ND cache reachable for 10s (for NUD).

Best regards,
Ole, 6man co-chair

> On 24 Jan 2021, at 17:07, Isaac <> wrote:
> Thanks Nick for the timely response!!!
> I understand your comment regarding the prerogative of IPv6 forum in this regard. Meanwhile, we need a technical answer/analysis of the combination of RA lifetime 0 and Reachable time 10s whether that makes sense or whether it was clearly envisioned in the original IPv6 design. We know that RFC puts forth a set of 'may', 'might' conditions which are deemed optional in certian corner cases (possibly). We are already having discussions with the certification body but we need to go with a clear cut technical response of whether RA lifetime 0 and reachable time 10 seconds makes sense or not. Same way, section 6.2.3 in RFC4861 puts forth a 'might' condition. RA with a lifetime 0 and with advertised prefixes might mean that there may be a second router in the LAN segment which advertises a positive lifetime. And this itself is a corner scenario we believe and common scenario would be a single router in a LAN segment who always advertises with a positive lifetime until he decides to cease to be default gatewway for clients (probably he is ging down as well). But the combination of RA lifetime 0 and reachable time 10 seconds doesn't make sense to us and we are clueless as to how that can be supported. We do not want to deisgn some throw away logic just for certfication purpose and we do think thats neither the purpose of certification bodies nor the end customers. We need a solid technical answer from the IETF IPv6 official body in this regard. Please review and respond.
> Thanks,
> Isaac.
>> On Sun, Jan 24, 2021 at 5:38 PM Nick Hilliard <> wrote:
>> Isaac wrote on 24/01/2021 11:02:
>> > At the moment, we are unable to find a scenario (real world usecase) to 
>> > support RA lifetime of 0 and RA reachable time of 10 seconds. Please 
>> > review and respond.
>> Isaac,
>> you're referring to an IPv6 Forum document, so they might be more 
>> qualified to give an answer to your question.
>> As a potential pointer, rfc4861 documents the following case in section 
>> 6.2.3:
>> >    A router might want to send Router Advertisements without advertising
>> >    itself as a default router.  For instance, a router might advertise
>> >    prefixes for stateless address autoconfiguration while not wishing to
>> >    forward packets.  Such a router sets the Router Lifetime field in
>> >    outgoing advertisements to zero.
>> Nick
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------