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

Miroslav Lichvar <> Tue, 09 August 2022 09:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7900AC15C539 for <>; Tue, 9 Aug 2022 02:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SxST4CcojeVK for <>; Tue, 9 Aug 2022 02:49:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D305AC15C532 for <>; Tue, 9 Aug 2022 02:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1660038540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=z/+JonJMefgh19uWaxYJYu7/ZjpzDFE7cQnI7DultzY=; b=M74ZzPQXu5C35W252MHB7z188KBppq5Ed04BOCNoKHCZqZsgE3UuuT9xa5z2clH0ZO/V+K uFyqWwnoiFe1NY8pp6thY9iW+JZsZGXvhzTJ9TP/HW58wEc8zKSE3qpCEDfjk4PPNb67Ks N3Vb+g18X3yNMvsfuY5FkZUgu1AD/5I=
Received: from ( []) by with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-351-O62u4ZWOPAuaMjRWCOO3yw-1; Tue, 09 Aug 2022 05:48:57 -0400
X-MC-Unique: O62u4ZWOPAuaMjRWCOO3yw-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C6EA3C0E23A; Tue, 9 Aug 2022 09:48:56 +0000 (UTC)
Received: from localhost (unknown []) by (Postfix) with ESMTPS id 07B1C40C1288; Tue, 9 Aug 2022 09:48:55 +0000 (UTC)
Date: Tue, 9 Aug 2022 11:48:54 +0200
From: Miroslav Lichvar <>
To: Harlan Stenn <>
Cc: Hal Murray <>, "" <>
Message-ID: <YvIthoUI7HtKpD9E@localhost>
References: <> <> <YvIXDS2EkxzI0nTh@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.84 on
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] =?utf-8?q?Antw=3A_=5BEXT=5D_Re=3A_Quick_review_of_WGLC_for?= =?utf-8?b?IHN0YXR1cyBjaGFuZ2UgZm9yIGRyYWZ04oCRaWV0ZuKAkW50cOKAkXVwZGF0?= =?utf-8?q?e=E2=80=91registries?=
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Aug 2022 09:49:02 -0000

On Tue, Aug 09, 2022 at 02:22:32AM -0700, Harlan Stenn wrote:
> 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.

Because ntpd kept the NTPv3 support when it added NTPv4. The NTPv3
support is broken in some ways, e.g. it accepts Autokey extension
fields which is not possible in NTPv3.

Some client implementations support NTPv4 only and don't accept an
NTPv3 response.

> > 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.

That is not possible if we want to make incompatible changes in NTPv5.

> > > 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?

It's not written anywhere. It will save us a lot of work if we can
reuse the existing EFs (e.g. NTS) as they are specified for NTPv4.

> 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.

As I understand it, ntpd doesn't support 7822 yet. It is still
responding to unknown extension fields with a crypto NAK.

Miroslav Lichvar