Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Hi Miroslav,

I do not think that it would add a lot of complexity if we would change the packet header format. 

Can you explain why you want to keep the 48 bytes length? Why is that so important? What would happen if the new v5 packet format would have, let's say, 56 bytes?

Any implementation that wants to be v4/v5 compatible can easily deal with two different packet header formats IMHO. Handling this in the right way will not remotely add as much complexity as all the other v5 changes will cause. Think about the added complexity when someone has to implement the RefID handling as described in that draft, compared to just having an additional field in the packet that indicates there is a leap second smear going on, or there is a specific ID that you want clients to use when they refer to your server in their RefID field. 

Please do not get me wrong, I do not want to change the NTP packet format at any cost (or for the sake of change or to make it as hard as possible for implementors), I just want to avoid that we all try to stick with the current format (that arguably has some shortcomings, as illustrated by the presented drafts) just because we want to avoid that someone implementing NTPv5 has to add a second packet header structure to their code and, upon receiving or sending a packet, has to select which of the two formats to work with. 

This *exactly* is why there is a version field in the header, and it is placed very close to the start of the packet to make it efficient and secure for implementations to support multiple NTP versions. 

Again, lets change the NTP packet format for v5 to make things easier and less complex for future implementations. And do not stick with the format just because you want to avoid changing your own code too much, protect bad/faulty implementations or save firewall admins from having to touch their configuration. 

That said, I would be happy to start working on v5, maybe by collecting a list of all the issues and problems that we all see in v4 and the features we would like to see added. But maybe we should open another email thread for this. 

Best Regards,
    Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 heiko.gerstung@meinberg.de 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

On 28.08.19, 12:39 "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ietf.org im Auftrag von mlichvar@redhat.com> wrote:

    On Wed, Aug 28, 2019 at 12:07:53PM +0200, Heiko Gerstung wrote:
    > Regarding backwards compatibility of NTPv5: I think it would be no problem to change the NTP packet format if there are requirements we want to meet that can be fulfilled more efficiently with a changed packet header. Any implementation that ignores the version field deserves whatever happens to it and, since a client mode packet contains the version number, an NTP server would most probably have to reply to a v4 client request with a v4 server response anyway. Only if an implementation sends a request with version=5 and then tries to decode the response based on a v4 packet format there will be a problem. And again, implementations doing this should go down in flames anyway IMHO. 

    I think a good reason to keep v5 mostly compatible with v4, similarly
    to how previous versions were compatible with one another, would be
    avoiding extra complexity in both server and client implementations.

    My suggestion would be to keep the NTP header 48 octets long and
    change only two fields: the refid and reference timestamp. They are
    ignored by current servers and most clients. That gives us 12 octets
    of contiguous space in the header to work with. That's plenty for the
    timescale negotiation and other metadata. Longer fields should be in
    extension fields. No MACs allowed.

    FWIW, I'm willing to help with the NTPv5 specification if people are
    considering to start working on that.

    -- 
    Miroslav Lichvar

    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp