RE: [EXTERNAL] Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds

"Manfredi (US), Albert E" <> Mon, 25 January 2021 05:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CCF63A00D8 for <>; Sun, 24 Jan 2021 21:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.219
X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RXw9KQrNV2Xr for <>; Sun, 24 Jan 2021 21:15:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CBB53A00C4 for <>; Sun, 24 Jan 2021 21:15:42 -0800 (PST)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 10P5Fejw025851; Mon, 25 Jan 2021 00:15:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1611551741; bh=jIAVzZ+DMR1MGqwe+fH+WDKYi4oKRCqLLBf3VIk69QM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=TQ0tqQBLNixur6nrg0t74Co3thcQcJp0YS4vmyUDYv/Ku3GD3jy+V21kbsznFf74d nMtMi9M6LdAYIZivKb4ohPyJ0VCpobkJPbVtEhjk4nHYqQgYqXUqZpgTL2O1TDBvPR BjO5A3/pz0BFVEn3bagBaLFD1m0dqAnmldSqaH0o8tbCRY7yJ0IuZEVrHa4P/WQ2PY EmPRZjd9GyimxkcihmbiRhMHuqiEwZY2A2SpCmORBCHYNrLfrBIVlcBBxab0RGQ17m qEhKmfa+2UF4IeLBLbV+P1VKjJO88q32P4vD8rUd4nBtOxBVGsI8qZt7tGlXIR78o7 GBxdp7MwTbkSA==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 10P5FaV7025821 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 25 Jan 2021 00:15:36 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Sun, 24 Jan 2021 21:15:34 -0800
Received: from ([fe80::c57c:39bc:4c0a:384b]) by ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.2044.004; Sun, 24 Jan 2021 21:15:34 -0800
From: "Manfredi (US), Albert E" <>
To: Isaac <>
CC: "" <>
Subject: RE: [EXTERNAL] Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds
Thread-Topic: [EXTERNAL] Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds
Date: Mon, 25 Jan 2021 05:15:34 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: B7E2F551AF08F9A35DA428F3BFCA2DCA466D5052EB5BDAA7791D36A05B3663AA2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Mon, 25 Jan 2021 05:15:45 -0000

From: ipv6 <> On Behalf Of Isaac

> Ole/Tim Winters/IETF team,
> Yes, we understand these knobs but we wanted to understand more on the scenario/topology. More importantly we wanted to understand the real world scenario when this combination of RA lifetime 0 and reachable time 10 seconds is used and the technical merit of it for which we did not get clear response (especially in the modern global IPv6 networks context). It's surprising that the certification bodies haven't clearly mandated only common/practical (although IETF has mentioned that these paramers need to be configurable but never said explicitly that all permutation/combination of values need to be supported. Vendors (definitely want) comply to RFCs but do not want allow impractical values) use cases but have listed even the corner scenario which may never be used. We understand that there are thousand vendors who have implemented this combination. But we fear that these are extra burden for vendors considering that vendors go ahead for certification without questioning the certification body itself believing that the certification body does its job of validating the modern technical relevance. Ideally, we expect the certification body (if not IETF) to re visit all the tests periodically to understand the relevancy as time passes and modify if required (which is the purpose of the certification body we believe). Sorry to have spilled certain discussions pertaining to certification body in this forum. But we do not have much option as we want technical answer from the IETF group. Let's not stop with the high statements in RFC. The reason we approcahed IETF is to go one level deep (especially in the context of modern day global networks) to undertand the relevance of RA lifetime 0 and reachable time 10 seconds whether it makes sense to support. These are our 2 cents contribution to the community (if there is someone to listen!)

Isaac, I'm trying to understand your point. At least one scenario in which the RA lifetime is set to 0, and reachable time is set to 10 seconds, was explained a couple of times. It can be used for a router to provide the IPv6 prefix, for example for SLAAC, but for that same router NOT to be used as the default router, for the subnet in question.

Is it that this scenario seems unrealistic and unnecessary, to you?