Re: [Ntp] Antw: [EXT] Re: Public NTP servers already responds to NTPv5

Hal Murray <hmurray@megapathdsl.net> Tue, 01 December 2020 21:45 UTC

Return-Path: <hmurray@megapathdsl.net>
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 539163A14E7 for <ntp@ietfa.amsl.com>; Tue, 1 Dec 2020 13:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 CyYooqLjfYmA for <ntp@ietfa.amsl.com>; Tue, 1 Dec 2020 13:45:46 -0800 (PST)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1053A14E5 for <ntp@ietf.org>; Tue, 1 Dec 2020 13:45:44 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id AABF440605C; Tue, 1 Dec 2020 13:45:34 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: ntp@ietf.org
cc: hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> of "Tue, 01 Dec 2020 08:36:16 +0100." <5FC5F270020000A10003D2DB@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 01 Dec 2020 13:45:34 -0800
Message-Id: <20201201214534.AABF440605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/x-Z4by43MtWeK_uRrBtdDUlO7g8>
Subject: Re: [Ntp] Antw: [EXT] Re: Public NTP servers already responds to NTPv5
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 01 Dec 2020 21:45:47 -0000

Ulrich.Windl@rz.uni-regensburg.de said:
> IMHO a v4 server should _never_ answer a packet version it does not know
> about. I know you cannot change the past, however.

If a v4 server gets a v5 request, it could respond with a v4 reply.  That's 
the best it can do.  That might simplify the transition.  A client doesn't 
have to know if the server it is going to talk to is v5 or v4.

The first assumption is that the mode and version fields stay in the same 
place so a server can figure out that it is a v5 request.  It also assumes 
that the v4 servers planned ahead for something like that.  For the pool where 
most systems are reasonably well attended it may be possible to retrofit v4 
servers that don't get updated to v5.  Or we could split the pool into v4 and 
v5.

If a v5 client gets a v4 response, it could process it.  That's assuming there 
is enough overlap between v4 and v5 fundamental concepts so that the old 
response has enough data to be useful.

If the v4 packet format is different from v5, the above requires extra code.  
If the packet format is very close, the extra code could be small.  At worst 
it is 2x.  The server side is only a page or two so 2x isn't unreasonable.  I 
think the client side is similar but I haven't looked as carefully

30% of the traffic to a pool server is v3.


-- 
These are my opinions.  I hate spam.