IETF Logo Mail Archive

Re: [v6ops] LAN-side NTP in rfc7084bis?

Ole Trøan <otroan@employees.org> Wed, 20 March 2024 16:56 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46952C14F604 for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 09:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.213
X-Spam-Level:
X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr_T1FuUkHUY for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 09:56:04 -0700 (PDT)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [204.87.183.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D0FC14F5FE for <v6ops@ietf.org>; Wed, 20 Mar 2024 09:56:04 -0700 (PDT)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 1FFBCE76B6; Wed, 20 Mar 2024 16:56:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=Y5dYULZ4ZPm8W2M6 vcdsvYNRsM+Nx20OSP2kLnKuUjc=; b=HwZxlcEl+2mAMgZU+He/5tXTN63Zc0Ih ST8xEjX3boHx+VI3DdjmYQ3OAsDaeMa1EdhQ3BCk2J3PYJc8mhMxWZYX649c8bS8 XKSS3U9Q5aCltosN/b8OWaUgGljZuQsNRHbl9j4M2U22JLIfdW3pVdvNFbblVaad 7OTVURxVRuMbW5syfnwgrS2B9czY+zgjNI7gdEhaAdV+DBdfItle24eEVVW8WZjl h8CYvGsfwGiWsTTe4SYf5Y1V38wJsGf9e+AOoq+9/CL64N2eI9QqJo00S40+0CoC 7DCuGlh36Q+GV0h82YlpL7czYj0Ajdram52MLVUv/Rbr9GU6PdTAZQ==
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id 009DAE74FC; Wed, 20 Mar 2024 16:56:04 +0000 (UTC)
Received: from smtpclient.apple (unknown [IPv6:2001:4650:c3ed:37a:a855:7e61:a191:a620]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id BC9B34E1377B; Wed, 20 Mar 2024 16:56:03 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-F70D2878-73AE-445D-9D33-4AC498C1150C"
Content-Transfer-Encoding: 7bit
From: Ole Trøan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Wed, 20 Mar 2024 17:55:50 +0100
Message-Id: <29DEFFD9-2CFC-4BC9-8DCC-CD46A6895E3C@employees.org>
References: <CAO42Z2zC95-EexW78GPOir=fSOxh_EBOnHQwReo4fS6PRLeAMQ@mail.gmail.com>
Cc: jordi.palet=40consulintel.es@dmarc.ietf.org, IPv6 Operations <v6ops@ietf.org>
In-Reply-To: <CAO42Z2zC95-EexW78GPOir=fSOxh_EBOnHQwReo4fS6PRLeAMQ@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: iPhone Mail (21D61)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_mK7heOYyc4WdKIiG1NqT5953Jk>
Subject: Re: [v6ops] LAN-side NTP in rfc7084bis?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 16:56:08 -0000



On 20 Mar 2024, at 17:43, Mark Smith <markzzzsmith@gmail.com> wrote:




On Thu, 21 Mar 2024, 00:05 Ole Troan, <otroan@employees.org> wrote:
Mark,

> Yes, we should do that, not just for NTP.
>
> “Any protocol or service supported by the CE for IPv4 MUST be also supported for IPv6. The CE MAY support additional protocols or services even if not supported in IPv4"
>
>
> Even more generally, I think a CE really should be a DHCPv6 relay for options the upstream SP can provide, rather than being limited to what DHCPv6 options the CE itself can support. LAN side stateful DHCPv6 addressing can be supported by handling IA_NA and IA_TA options locally.
>
>
> IPv6 CE Device DHCPv6 Option Transparency
> https://datatracker.ietf.org/doc/html/draft-smith-v6ops-ce-dhcpv6-transparency-00" rel="noreferrer noreferrer nofollow" target="_blank">https://datatracker.ietf.org/doc/html/draft-smith-v6ops-ce-dhcpv6-transparency-00

The CE sits on an administrative boundary. It should uncritically pass information across that boundary without some set of policy controls.


That's what that draft says.

My sentence was missing an important NOT. “It should not uncritically…”

That’s my opinion of course, and there is a tussle here. E.g. PVDs are designed to allow providers to a larger degree to reach into the network and control end-user hosts directly.

O.

v2.23.0 | Report a Bug | By Email