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

[Danny Mayer <[e-mail]>]

On 12/1/20 4:45 PM, Hal Murray wrote:
> [e-mail] 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.
>
That's because the clients making the queries haven't been upgraded in 
decades. That's not surprising because once NTP is set up you don't 
really need to change anything, what I call a set-and-forget 
application. There are routers and switches and all sorts of hardware 
out there which have been running for years and as long as they are 
working they don't get upgraded or replaced.

Noone is going to be bothering to update a NTPv4 client to deal with a 
server returning V5 packets. See above. The only way to support V4 
clients is to make the V5 packet a V4 packet plus extra stuff. It's 
unlikely that anything else would work.

It's essential that any NTPv5 document deal with interoperability with 
NTPv4 clients and servers. NTPv5 will fail without it.

Danny