IETF Logo Mail Archive

[Ntp] Antw: Re: Antw: [EXT] Re: Quick review of WGLC for status change for draft‑ietf‑ntp‑update‑registries

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Tue, 09 August 2022 11:01 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9025C13CCE5 for <ntp@ietfa.amsl.com>; Tue, 9 Aug 2022 04:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3z7R-juE1KU for <ntp@ietfa.amsl.com>; Tue, 9 Aug 2022 04:01:41 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [194.94.157.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636EFC15A737 for <ntp@ietf.org>; Tue, 9 Aug 2022 04:01:35 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16B576000059 for <ntp@ietf.org>; Tue, 9 Aug 2022 13:01:32 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id EAD0F6000053 for <ntp@ietf.org>; Tue, 9 Aug 2022 13:01:31 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 09 Aug 2022 13:01:32 +0200
Message-Id: <62F23E8A020000A10004C393@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.0
Date: Tue, 09 Aug 2022 13:01:30 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: martin.burnicki=40meinberg.de@dmarc.ietf.org, "ntp@ietf.org" <ntp@ietf.org>
Cc: stenn@nwtime.org, halmurray@sonic.net
References: <20220809030711.F00DC28C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <7eef9a6f-a115-b009-24e5-2b96a8bc02ae@meinberg.de>
In-Reply-To: <7eef9a6f-a115-b009-24e5-2b96a8bc02ae@meinberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/i_khH5uk-9VlGL8Zz7V3skJmH6U>
Subject: [Ntp] Antw: Re: Antw: [EXT] Re: Quick review of WGLC for status change for draft‑ietf‑ntp‑update‑registries
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2022 11:01:42 -0000

>>> Martin Burnicki <martin.burnicki=40meinberg.de@dmarc.ietf.org> schrieb am
09.08.2022 um 12:17 in Nachricht
<7eef9a6f-a115-b009-24e5-2b96a8bc02ae@meinberg.de>:

...
> 
> As far as I know, the original ntpd copies the version number of the 
> client request to the version number of the response packet, except if 
> the client version is higher than the real server version.
> 
> That means:
> 
> - if a v4 server gets v3 request, it should respond with v3
> - if a v4 server gets v4 request, it should respond with v4
> - if a v4 server gets v5 request, it should respond with v4

...or discard the packet: At the time when NTPv4 wad defined there was no NTPv5. So it would be valid to discard any "unknown version". However I see that NTPv5 will have an easier start then, specifically as the protocol will "auto-upgrade" once the remote party supports v5.

Maybe NTPv5 should (be able to) indicate the minimum and maximum versions supported in the packet. Obviously the maximum will be v5 then, but it would help for any future version (meaning: the then "old" v5 servers would indicate that they don't understand v6 yet).

> 
> The latter should only work if a v5 base packet is compatible with a v4 
> base packet. Otherwise a v4 server wouldn't even recognize and accept a 
> request from a v5 client.

See above, the silent assumption that an older server will understand a newer packet or a newer server will understand an older packet will break some day, and it's better to be prepared. Maybe even the version number will be relocated in the future.

...

Regards,
Ulrich

v2.23.0 | Report a Bug | By Email