IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Wed, 20 March 2024 14:05 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 7732AC14F712 for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 07:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, 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=ham 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 1o20xsCLGisL for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 07:05:20 -0700 (PDT)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [IPv6:2607:7c80:54:6::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 6E734C14F6F1 for <v6ops@ietf.org>; Wed, 20 Mar 2024 07:05:20 -0700 (PDT)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 06F50E737E; Wed, 20 Mar 2024 14:05:20 +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=vr/Gis7/ssl8OLU4 4Bz1d47AwUGnAa52MOGTxP/ND+U=; b=RqyoAsffKAYa6kBe72UygdPPFwcD7RUL bhBZSFjthzVYVq/LHeUdbyEW8AhPql6vav3LX9rmVylOEUL9NuwNB15VAnggcS+3 T8fmMIxITkKz1GmtirsvOmUNkhqoOxsgBkJ91TjLHQNpE4T47+Nl6Q6v+FEWopUC WDxciUSVTDzsmmtEBVPKxUStz9Qrv4+DAjOePc9y/Jp5AvZnaPwyUeP3p1AmIKPd Ltc+4Rf+OTLk9AB/l/AYyL6ijL3CxsJSHXjml5MwHwSsd6n+80eUaNCdBZUCgLKF B3g7+mFx2wRktHq7qMHdR7EaI9rHu7tg9wfdDMoizhrkZHOhUTgxhw==
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 D0AF9E737C; Wed, 20 Mar 2024 14:05:19 +0000 (UTC)
Received: from smtpclient.apple (ti0389q160-5480.bb.online.no [95.34.1.168]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 22C354E1379B; Wed, 20 Mar 2024 14:05:18 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAO42Z2zKyRV2bLZP2-8RNuq=JtvQQ-Yy9fOmZ34Dw-j2DQthSQ@mail.gmail.com>
Date: Wed, 20 Mar 2024 15:05:06 +0100
Cc: "jordi.palet@consulintel.es" <jordi.palet=40consulintel.es@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0C407DD-9BC3-4D4A-B842-7505223AAFAD@employees.org>
References: <7199173b-a473-4117-63b3-917687cb5766@gmail.com> <CAJgLMKu7hsRvgAaU_im8PJVOLqFcC89YZGVFRU8gxTtNFnwc8w@mail.gmail.com> <Zfqz_ZAIeqU-0iX3@Space.Net> <21B591DB-91EB-475B-9E63-415B703ED4B9@consulintel.es> <CAO42Z2zKyRV2bLZP2-8RNuq=JtvQQ-Yy9fOmZ34Dw-j2DQthSQ@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/PV7hV7B85PUu-LRUsPrJTd242Ks>
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 14:05:24 -0000

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

The CE sits on an administrative boundary. It should uncritically pass information across that boundary without some set of policy controls.
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