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

Nick Hilliard <nick@foobar.org> Sun, 24 January 2021 17:55 UTC

Return-Path: <nick@foobar.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE1A3A0EF2 for <ipv6@ietfa.amsl.com>; Sun, 24 Jan 2021 09:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk483mpkORNt for <ipv6@ietfa.amsl.com>; Sun, 24 Jan 2021 09:55:48 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2AD3A0EF1 for <ipv6@ietf.org>; Sun, 24 Jan 2021 09:55:47 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 10OHtgVV092693 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2021 17:55:42 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Subject: Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds
To: Isaac <isaactheogaraj@gmail.com>
Cc: ipv6@ietf.org
References: <CAGeZV=RLrZwLgTusStv73gEuppxs40ijNXvGOWABH3U_Pqz-4Q@mail.gmail.com> <3e9138db-2b62-b145-a7d0-86d22fb1eea0@foobar.org> <CAGeZV=Sv8TwA7X3tzh_ZSjKGK1EdUhbWo+nj31bUfy8DhhHg-Q@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <3ecb187d-dc26-4135-23eb-edeff952f4f2@foobar.org>
Date: Sun, 24 Jan 2021 17:55:40 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.45
MIME-Version: 1.0
In-Reply-To: <CAGeZV=Sv8TwA7X3tzh_ZSjKGK1EdUhbWo+nj31bUfy8DhhHg-Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fbCLtL027MGDxt95nTkOF9cereY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2021 17:55:51 -0000

Isaac wrote on 24/01/2021 16:07:
> 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.

RA lifetime = 0 means that the route specified in the RA should not be 
used as a default route.

RA reachable time is the time in milliseconds that the issuing router 
should be considered reachable from the point of view of NUD.

The tuple { ra_lifetime = 0, ra_reachable = 10000 } is valid.  As 
described in the RFC, it might be emitted from a device which was 
providing prefix information for the l2 domain, and nothing else; for 
example, specifying a non-routed ULA prefix for the local l2 domain.

> 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.

I'm not sure who "we" refers to here.

Obviously, if you're writing an ipv6 stack, it's your choice as to what 
goes into your implementation.  There doesn't seem to be any ambiguity 
in the rfc, however.  From a more general point of view, the IETF's 
position on communication protocols is to be liberal in what you expect 
and conservative in what you send, so if you decline to support 
something like this, it would open up questions as to whether your 
implementation conformed with the rfc.

Whether or not it should be part of the IPv6 Forum's certification spec 
is an issue for them, not the ietf.

Nick