IETF Logo Mail Archive

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

Martin Burnicki <martin.burnicki@meinberg.de> Tue, 09 August 2022 11:11 UTC

Return-Path: <martin.burnicki@meinberg.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 76AFCC15C52B for <ntp@ietfa.amsl.com>; Tue, 9 Aug 2022 04:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
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 Iveh2K8RE2DB for <ntp@ietfa.amsl.com>; Tue, 9 Aug 2022 04:11:29 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18455C159486 for <ntp@ietf.org>; Tue, 9 Aug 2022 04:11:29 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 5BD5C71C0065; Tue, 9 Aug 2022 13:11:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=d2021; t=1660043487; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=019V7GDiwHil0IzmB7szKWMxbLZIUhBqgZWqdMAlmgg=; b=I8hO1EuHtMMF1v4nvWISdY4ASGTyyhWXdu4yGurTlJa0djiPTxC7NQmianrY40FpA9Qi6M lXidkzUxkgRj4KnJJxlQ+mjUu2v0qsDnTs040Jg56ctSQks8GLTTCLfH3eKmLtArx1fbiq Mb9In1vVZUhdjAogGe0QwDdbyA0XEUfJZLpjUczR9HY6SQ49BGIcnT1JgZ+SQEMkwzdPUw XHf22lWdWlz3XUQYkxyHaLD4DmrpnMgN/fhq3seRaMqE6YuKqGEo5bM3ueHv0lukz5uE0K w6jQqUxftGISVfxyruLCA8/G1uY26WAn7zw6PS/1wTYRycSAGniA9Mt2y9gGJg==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Tue, 9 Aug 2022 13:11:26 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)); Tue, 9 Aug 2022 13:11:26 +0200
Message-ID: <1adca9bf-81fa-189f-ae13-47c049e02721@meinberg.de>
Date: Tue, 09 Aug 2022 13:11:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "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> <62F23E8A020000A10004C393@gwsmtp.uni-regensburg.de>
From: Martin Burnicki <martin.burnicki@meinberg.de>
Organization: Meinberg Funkuhren GmbH & Co. KG, Bad Pyrmont, Germany
In-Reply-To: <62F23E8A020000A10004C393@gwsmtp.uni-regensburg.de>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------n2uChkDStnNnhBxPfst9neSL"
X-SM-outgoing: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/nQ10WEfBh2tSlE60lvoiHDiCPxo>
Subject: Re: [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:11:34 -0000

Ulrich Windl wrote:
>>>> 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.

I used v5 in this example only to show the way this was supposed to 
work. You could easily rewrite the last line to

- if a v3 server gets v4 request, it should respond with v3

The future NTPv5 is a whole different thing if there are no plans to 
make the protocol compatible.

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

I just tried to say how it was handled in the past, and to me this 
always looked lika a good idea.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com

v2.23.0 | Report a Bug | By Email