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

[Harlan Stenn <[e-mail]>]

On 8/9/2022 1:13 AM, Miroslav Lichvar wrote:
> On Mon, Aug 08, 2022 at 10:33:12PM -0700, Harlan Stenn wrote:
>>> NIST servers respond to NTPV4 requests with NTPv3.
>>
>> which works perfectly with V4 clients, and it works because of the way the
>> protocol was designed and has worked for ntp V1-V4.
> 
> It works only with clients that support NTPv3. Not all clients do
> that. And v1 is not compatible with v2-v4. There is no mode field yet.

I don't understand "clients that support NTPv3".  I know that ntpd 
(which has been v4 for nearly 25 years' time) talks with NIST just fine.

I haven't seen any v1 clients in ages.  For that matter, I don't think 
I've ever seen a v1 client request come in (OK, nobody has reported that 
they could not sync a v1 client with a v3 or a v4 server).

I similarly don't know about v2.  And again, nobody has reported that 
they could not sync a v2 client to a v3 or a v4 server.

I guess I just don't understand what you're trying to accomplish here.

> Responding with NTPv3 to an NTPv4 request is ok when you know that the
> NTPv4 header is compatible with NTPv3.

Is the NTPv3 base packet compatible with an NTPv4 base packet?

Is an NTPv4 base packet compatible with an NTp3 base packet?

> The bigger issue is that the NIST servers are responding with NTPv3
> even to NTPv5 requests, which is not specified yet. There is nothing
> in RFC1305 or RFC5905 that would guarantee future compatibility.

I submit that the answer to this depends strongly on the format of a v5 
packet.

> NTPv5 needs to be designed in such a way that if it is misinterpreted
> as NTPv3 or NTPv4, it will produce an invalid response that will be
> ignored by the client. The current proposal has that property.

I submit better behavior would be for a v3 or v4 client to be able to 
*use* a v5 response.

>> It sure looks to me like the NTPv5 work will be breaking this.
> 
> Well, if NTPv5 is expected to have incompatible changes like shorter
> extension fields, it cannot be compabile with NTPv4. If it was
> compatible with NTPv4, it wouldn't have to change to NTPv5.

Where is it written that a v4 EF must be compatible with a v5 packet?

And if one requires 7822 header lengths for compatibility, great.

The reference implementation supports both, but we do not require 7822 
minimum lengths because they are demonstrably not needed.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!