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

[Martin Burnicki <[e-mail]>]

Hal Murray wrote:
>> Really?  What % of the traffic that you see is still NTPv3?
> 
> Client requests to a pool server:
> 
> San Francisco
>    0.480%  NTPv1
> 16.376%  NTPv3
> 82.744%  NTPv4
> 
> London:
>    1.339%  NTPv1
> 17.939%  NTPv3
> 80.136%  NTPv4

Interesting. In all the years I'm working with NTP I've never seen a 
real (x)ntpd v1 in the wild.

What I've seen several times, however, are simple/dumb client 
implementations that use the NTPv3 packet format but put v1 into the 
request packets they send to servers. So these are not real v1 clients.

>> How long do you think it will be before updated NTPv4 servers are
>> "generally" deployed?
> 
> The problem is not the generally deployed, the problem is the long tail.
> 
> NIST servers respond to NTPV4 requests with NTPv3.

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

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.


Concerning the usage of extension fields:

I think it doesn't make much sense to have a client that supports the 
old ones (e.g. autokey) and the new ones.

Existing implementations may use symmetric keys, autokey, or none of 
them, but probably don't even know about the new EFs.

For *clients* that supports the new EFs, there should be no need to use 
the old EFS. They can only support the new ones.


What does make sense, IMO, is a server which can handle *both* types of 
extension fields, to be able to serve time to both old and new clients.

So the server implementation could

- check whether a request has extension fields at all
- if there are, check for plausibility of a chain of new EFs
- if check of the new EFs fails, try the old EFs
- use the new or old EF formats in responses to clients

So new server implementations can keep or drop support for old EFs, as 
appropriate for the overall time synchronization network.

Using a mixture of old and new EFs either at the client or at the server 
side would be the worst case and result in lots of confusion.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
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