IETF Logo Mail Archive

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

Mark Smith <markzzzsmith@gmail.com> Wed, 20 March 2024 20:11 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 8A375C14F6F1 for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 13:11:21 -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 p56DEVcJchM7 for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 13:11:20 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 E3A65C14F6EE for <v6ops@ietf.org>; Wed, 20 Mar 2024 13:11:20 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-513e134f73aso353908e87.2 for <v6ops@ietf.org>; Wed, 20 Mar 2024 13:11:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710965479; x=1711570279; 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=cHAJ5AtqARo2BBlNceZevz7LGjT5ImOICybZnG1SlFU=; b=e+HwZRHfiLWLwYUXAHaMcQE2X5amRF8VU3dUAQojKHCx2PZ7qw5fJvjVuuObtlZoaR Y0wZHRnw2lzKdCzRlgEUB3PXE2KktFZqSfzbFJQ9yCMM+6jdnR88ILPNggH62CTRhJYu k5drTjBdli3lpfWQYhIC+lIrILTpFreedKeJ2ToV9+LT3+OjWpafZSTBR5KfEU/lotIl WPpUSgR0vXzxEE7XC+k1bgZ96dy6Y59FVOmljxW+Wo7XdW3S5ttP+h0Glr0ZnBndPBNW se3w70bKgF0z/zcXQkn2IrGnikR2h7otaahaNWJrqorHBiAHR78t+oFXUJNVeWtVkDC2 m5kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710965479; x=1711570279; 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=cHAJ5AtqARo2BBlNceZevz7LGjT5ImOICybZnG1SlFU=; b=kU8Dt3dDRM6oS+Em4B02fll+2rgmi/sLh1YBE4jGgY57fW5Mhxambh1LS0vqSFl7WY XclEZVhZwhhes677lGltAzweKEotuIBCbzmeZry7A0K0zMt/1OWphlkWZPIIPvCNeTbT VxKvrOYhDQ2ywCQRfhrkroZOUVh61yaaeaxeTN+DYEeTwNXBAs/pOSi0ALuqMiPGhO/y Bfd7erzyy5fzBpkvxcS9sVtg9wbnUsovV23tUC7qPyhKNf0/Tsj5JE1rojkvxOqBhBGo GmOMdgrqow119YCo7X96z3bgvydI1ULLe4UH/1LS8+ITUCRiJcoQTLQcNe2rP3um2aeg azSA==
X-Forwarded-Encrypted: i=1; AJvYcCWDvlLP2kTs2Zar2njfSHyRJWLOLt10ZNccW+wW+Ca4Vn3r0OZl72Joc6dqqnXXXUrvD/RQa+FsG7fhiEoKjA==
X-Gm-Message-State: AOJu0YzbqRVSowQbvvRhIDubbrTVytmy1yYBpo2lSHC5FNhOCKQsFDmv 2iRIYPpWybnUSUBhAQx4FrRYZ+m6CNvZQ6Zu3LegOSBv+Ixb/BRGyL+lYpGG2+pvjk0eqyBALhY sDs8Qp3nHiLWNNAI/rODsPbDQ+tE=
X-Google-Smtp-Source: AGHT+IE2U5OryljFCG8WkPZhijlbSAYUY5WblgKyJWgdfCbU+JI+/BLQ2SYLb5OxQL//VjenQG/H+uFAGYI8q1QAQu8=
X-Received: by 2002:a19:e00f:0:b0:513:c54d:7bd1 with SMTP id x15-20020a19e00f000000b00513c54d7bd1mr5007147lfg.35.1710965478835; Wed, 20 Mar 2024 13:11:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAO42Z2zC95-EexW78GPOir=fSOxh_EBOnHQwReo4fS6PRLeAMQ@mail.gmail.com> <29DEFFD9-2CFC-4BC9-8DCC-CD46A6895E3C@employees.org>
In-Reply-To: <29DEFFD9-2CFC-4BC9-8DCC-CD46A6895E3C@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 21 Mar 2024 06:11:09 +1000
Message-ID: <CAO42Z2yZgTd74WQbvC3+w-QPOO+1v70D0chW9Y4QhgWkYbRCCA@mail.gmail.com>
To: Ole Trøan <otroan@employees.org>
Cc: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000096cf3406141d31ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IMfXllrRS-H4JNweV4yqwVRi-OA>
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 20:11:21 -0000

On Thu, 21 Mar 2024, 02:56 Ole Trøan, <otroan@employees.org> wrote:

>
>
> 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
>>
>> 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…”
>


Residential customers' hosts are provided with and use DNS resolvers and
IPv6 address space via PD uncritically, which I think would far more
dangerous than any other service parameters the customers' hosts ask for
via DHCP that could be provided by the SP.

Residential customers trust their SP to provide a working and useful
service. Customers wouldn't use or pay an SP for a service if that trust
didn't exist.

Of the parties that could provide DHCPv6 option values to a customers'
devices on the CE LAN side, directly or indirectly, those parties being the
customer's SP, the IETF via spec or the CE vendor via implementation, the
SP is the most accountable because the customer calls them first for any
service faults (including faults the SP isn't responsible for or is able to
fix, like SVOD service faults).


Regards,
Mark.


> 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