IETF Logo Mail Archive

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

Mark Smith <markzzzsmith@gmail.com> Wed, 20 March 2024 16:43 UTC

Return-Path: <markzzzsmith@gmail.com>
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 A0735C151710 for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 09:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.com
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 1jrwYFVEHkMl for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 09:43:34 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 1A5E4C151701 for <v6ops@ietf.org>; Wed, 20 Mar 2024 09:43:34 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-563c403719cso8595128a12.2 for <v6ops@ietf.org>; Wed, 20 Mar 2024 09:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710953012; x=1711557812; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R3D47bJ9Lg5h5E4y3HrMhoYdbLxqCcoQ40EhBYS2cE8=; b=cD+sJyR4wiKhuiROPempMCpGeyn1KiNr7Dy7W30Nnt2qjnVfG1rw4Pl/+qcyA7BzFa N5kkBJbJ559l/RrNdOxCDgZVmDY82RIbeg3f0mIZEJfnzF7q0QpDQUIKmiK+not+4Ook Ah2HSTgCXng3X5naPWi9EWz+enXuWZHgTmpjCfnp78GhoZYt0efnpEcTtun/gIrROCMg BTM3Yjt2iqxfdIytW6z8BaJisCpiw74s1116JBOEB0twAr8zdh1ighKeqlAlxWd8+omf gC17UODwypY8YiYFR8nHWj88UlVRaFjKLVFiUqXIGTKnVXbMI4u6eAcokQe4fqEyx1xl W6/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710953012; x=1711557812; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R3D47bJ9Lg5h5E4y3HrMhoYdbLxqCcoQ40EhBYS2cE8=; b=k2L88eYbIrcdZPw77dZ4KljNFD+1Ahv1PjUBDy2DFyeYJiV86/eskWYQHhYDT+dt3c j3WTREgLKriNvyfYCVzFXGsND3QjNKJr2fKukaMnKbUfROb29vq3y2jlGGortBAiR8jO Kt/Gts753ZIQJgyuQdafh2KZyTB5CXZW6fHBC4yxX0lfz8+VbbBL+J4O0DeXA9H77gFN XLOEFsDc8ZGQIE6M8A/ygmeHtPxaLGnXbdiGN+1qFKnK2CnXWj5xLnhEbYn0t4Cy/uN0 m2E3pX2pIkILswKedeyyVRP9OhTNSzDPyO7+rp5t4W5dtXSbJk8NfhuE3MAbnfPOa+gc EMUg==
X-Forwarded-Encrypted: i=1; AJvYcCWZoZ+vrDg3t0I1lw7kgN3Lko2bndCzG2Sx4Rt0dPcPIJLVabMUtyzBI4HNAXWqYeT+fxTK2Z/mrZvAw8mRBQ==
X-Gm-Message-State: AOJu0YwNZRnXfnV793hK8+ds0iVWuYfoRj5T9G99oSx+SMAcGl/JfXFg Q+sIoJfWBlYdWGSNnFf2RxwWLqv/5rujgbMfDvyOHw56+5/p3FW2Q1lXmkSDVrgMdz7VY4mBV8v n+Wj0tHtr+5r7BHQtOwQnOSGexNkUO0ue
X-Google-Smtp-Source: AGHT+IFC4nLHqp9w38OuN0DIa0EADiEFsbWhMQjzwgayG7mygyN2AQh95Hz3DZ6dmSO7zfykdUDTONtwmuPD00ozgBA=
X-Received: by 2002:a05:6402:3981:b0:567:2cf:1ecc with SMTP id fk1-20020a056402398100b0056702cf1eccmr14821467edb.30.1710953012167; Wed, 20 Mar 2024 09:43:32 -0700 (PDT)
MIME-Version: 1.0
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> <A0C407DD-9BC3-4D4A-B842-7505223AAFAD@employees.org>
In-Reply-To: <A0C407DD-9BC3-4D4A-B842-7505223AAFAD@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 21 Mar 2024 02:43:22 +1000
Message-ID: <CAO42Z2zC95-EexW78GPOir=fSOxh_EBOnHQwReo4fS6PRLeAMQ@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: "jordi.palet@consulintel.es" <jordi.palet=40consulintel.es@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000848f1406141a4aef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/HpP8vDh34IStlGWY_l-eidjTh9k>
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:43:34 -0000

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

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