[Ntp] Re: NTPv5: Operational use case for server/node identification

[Harlan Stenn <[e-mail]>]

On 7/20/2026 5:01 AM, Miroslav Lichvar wrote:
> On Mon, Jul 20, 2026 at 04:30:07AM -0700, Hal Murray wrote:
>> I think we should continue the no-amplification in size policy.
> 
> +1

No-amplification should be a SHOULD, not a MUST.

H
--
> The document says the request EF length is 0, which is not a valid
> length in NTPv4/v5 as it must cover also the EF header.
> 
>> One way to do that is for the client's request to have unused space.
>>
>> Next, we need to know how much space the server needs and/or if the answer
>> fit in the space allocated.
>>
>> How about using the first byte of the answer as a size?  0 on the client
>> size means empty.  n on the server size tells you the actual length if it
>> is <= than the size of the field, or the actual size if the answer has
>> been truncated to fit.
> 
> If it needs to work in both NTPv4 and NTPv5, yes, that would make
> sense to me, assuming 255 bytes as the maximum length is sufficient.
> 
> If it was only for NTPv5 (which allows EF lengths not divisible by 4)
> the additional length field wouldn't be necessary. The client would
> know it got everything when the EF in the response is shorter than in
> the request.
> 
>> I think we should keep the overall packet size the same even if that
>> leaves empty space in the answer slot.  The idea is to avoid timing
>> asymmetry due to different packet lengths on the wire between request and
>> response..
> 
> In NTPv5 the padding EF could be used instead, but for NTPv4 with its
> special restrictions on EF lengths that wouldn't work.
> 

-- 
Harlan Stenn <[e-mail]>
NTP Project Lead.  The NTP Project is part of:
https://www.nwtime.org/ - be a member!