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

[Miroslav Lichvar <[e-mail]>]

On Thu, Aug 11, 2022 at 03:43:54AM -0700, Harlan Stenn wrote:
> The design is that the base packet for a given NTP protocol stays the same
> for future protocol versions.  If new info is wanted, it is APPENDED to the
> packet.  The easiest way to get new stuff there might be to use EFs, rather
> than by changing the base packet format and size.

Maybe that was the original intention, but if it's not specified
anywhere I don't think we should be prevented from making incompatible
changes in the protocol.

> If v5 comes along and makes the base packet larger, it should do so by
> appending the new data after the v4 base packet boundary.  Looking at A.5.3
> (fast_xmit()) in 5905, a v5 server would respond to a v5 client request with
> a v5 packet that is the expected size.  But a v4 (or v3) server would
> respond with a v5 version number in the header area with a base packet
> length of (to use the above example) 40 bytes.  The originating system would
> see it got a v5 response with a short length. That packet should be
> perfectly usable (as a v4 response).

If you look at A.5.1 in RFC5905, you will see

	if (r->version > VERSION /* or format error */)
		return;                 /* format error */

That is, an NTPv4 server is supposed to drop an NTPv5/6/7 request.

-- 
Miroslav Lichvar