Re: [Ntp] NTPv5 extension field format

[Miroslav Lichvar <[e-mail]>]

On Wed, Nov 01, 2023 at 02:23:43PM +0100, David Venhoek wrote:
> After having implemented NTPv5 in ntpd-rs, I want to again bring for
> consideration whether we should not just simply keep the NTPv4
> extension field format rather than changing it for NTPv5. The reason
> is that it turns out to be rather annoying to support both the NTPv4
> and v5 extension field formats at the same time, and I rather have
> just a single variant of that code to reduce the chance of bugs in it.

I don't see the benefit.

NTPv5 is supposed to support shorter extension field than NTPv4 (RFC
7822). That's one of the main features of NTPv5. An NTPv4+NTPv5
implementation cannot handle extension fields in the different
versions the same way, no matter if lengths indivisible by 4 are
allowed in NTPv5 or not.

It's just one extra condition for NTPv4 in addition to the RFC 7822
requirements. If you required NTPv5 to use lengths divisible by 4,
the handling of the extension fields that would otherwise use lengths
indivisible by 4 would be more difficult. It would decrease complexity
in one place, but increase complexity in multiple other places and
this number would likely grow as new extension fields are specified.
Not a good tradeoff.

>  - The draft ID, which can be solved by simply requireing the padding
> be 0 and instructing receivers to ignore any trailing 0 bytes.

This extension field is now required for the NTPv5 negotiation in
NTPv4, so this should be done anyway.

-- 
Miroslav Lichvar