[v6ops] Re: Correction: Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd

Timothy Winters <tim@qacafe.com> Mon, 12 August 2024 20:15 UTC

Return-Path: <tim@qacafe.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 B309EC1D4CCC for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2024 13:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=qacafe.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 jV4V-44Sqpga for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2024 13:15:36 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 8D181C1D4CCA for <v6ops@ietf.org>; Mon, 12 Aug 2024 13:15:36 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-70eb0ae23e4so3485389b3a.0 for <v6ops@ietf.org>; Mon, 12 Aug 2024 13:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; t=1723493736; x=1724098536; 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=zgS6mG85lHY/ZvSpbrACyBaApko9g24XE7GoR0EBRSI=; b=DcVDGV06boFHd2b47M6BJhtfvKgyg+7aYx5BtaWJH5W35AYBTHp5AB8etF2KwTpqZJ 8GoH/CpONMkCFBX/87cGw82ceogrLiZYM+NRi0x+CtQXlR/X/yR4GF+plEqg5h1Qiw0a YmfHwmM5wAlYQYXYzB4Zu7CovA2HbZ+9DHh4o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723493736; x=1724098536; 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=zgS6mG85lHY/ZvSpbrACyBaApko9g24XE7GoR0EBRSI=; b=eBVxlk7V6QgsKiXn3bnpkpJ2AUdUcmJXFj98TNfrBGFp4U8Mn/dbEgMnmfzMxgZAm3 z8xHU8cQAqObUodcLnFnfqxxsbtenTKty43fW60Trutax9xkMsrNIxocGxrrHR1Qs2Zy PlfIomLWbOavluP6f1wiDP/KOfWi3voBIDbjeUQ0m/Pv+9rz+b0GwOdHupb5zbzcrZa2 WcYMXZ+B4L4TJpHhYIjm9novpaxDLXElMYWhtQT1jndmSDQtc8FNc1816+BXHr4AQ2CO xbXJKuQ0k/L2to7C0cLxpfxMCWziZaCj65hVQAGJELiSrNdeY8oh/DRdChXVaHdYSzjX YSng==
X-Forwarded-Encrypted: i=1; AJvYcCVUlm0JQr3VVHIOGvrldlpgHMDzOx2+YO5bhUQxq6uRN5BpX7ZtF5hZxdf9hPa1teh2gYzpUPORVfo1hS1bUg==
X-Gm-Message-State: AOJu0Yyvwt4oZ0Sa3HPzY7hjgxc5bVBHAPQGDA/YZEPGTA2IDx+hXX1Q vUPckmQ6+9+EhE6MNxFB4c9/M5lrKGr3ILmXvRZm3K7hvvxcFq2PPHJkhFfkMbR0yNM2h4NEqzd LDlUPHMj15JTfvS5hwGUrI3vc+VPNKJB50DNeXQ==
X-Google-Smtp-Source: AGHT+IFMOJIHEOwqELW2LM1r9gIsMXj81vBK8pdzj4M9GNOw2SjI5HTOlnjaGGVkvmebqVuIljHULnPKLGpv5pgkcYw=
X-Received: by 2002:a05:6a00:138b:b0:710:5825:5ba0 with SMTP id d2e1a72fcca58-712550cdef5mr1710008b3a.3.1723493735844; Mon, 12 Aug 2024 13:15:35 -0700 (PDT)
MIME-Version: 1.0
References: <CACMsEX_x0ORZZ+nYeUQ5Lf83W9GZPwZOfcWpfq5gDtuY7oqk9w@mail.gmail.com> <11d52d74-b53a-4176-8128-5d2aa80320ca@gmail.com> <DB9PR07MB7771A90163C51552F8BCE28CD6B82@DB9PR07MB7771.eurprd07.prod.outlook.com> <CAJgLMKtS=yD=PjamVAjW88ZtvNpGqV6QgqPNfPPgfTVBE_wCEw@mail.gmail.com> <DB9PR07MB7771DC1F7FB03FD2B9BEF1EBD6B92@DB9PR07MB7771.eurprd07.prod.outlook.com> <CAJgLMKuQ_SNNNt3s4ps=JOgx=P33bkxpVxaDLZ8NQgdx2ub3UA@mail.gmail.com> <CAPt1N1kc99ntYzvkrYqTDPUH-WSLpR1zcbX1J5Oxs5GVAfqPqQ@mail.gmail.com> <CAJgLMKtb9HB48s7UkALqYjBhnDgr+h3y_Or2WO9sxnT=_TmrQA@mail.gmail.com> <CAFU7BARTioScMuprHTkJvFu_h835znqpcnKKJL8MyG66hJ5HSg@mail.gmail.com> <CAPt1N1nr+xZ_sJ5LmkeXLSh3bcSycV6Yomchhk7kH=-W=RypTA@mail.gmail.com>
In-Reply-To: <CAPt1N1nr+xZ_sJ5LmkeXLSh3bcSycV6Yomchhk7kH=-W=RypTA@mail.gmail.com>
From: Timothy Winters <tim@qacafe.com>
Date: Mon, 12 Aug 2024 16:15:24 -0400
Message-ID: <CAJgLMKtsj52bNkRJKA7QnjXB9xV3Y=Ew6CFi85tuP2qYaiV7qg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="000000000000e5e715061f822732"
Message-ID-Hash: R2S7VCC2HNOF5YFCDOUQYT6MMJWITMGC
X-Message-ID-Hash: R2S7VCC2HNOF5YFCDOUQYT6MMJWITMGC
X-MailFrom: tim@qacafe.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Tim Chown <Tim.Chown@jisc.ac.uk>, IPv6 Operations <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Correction: Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/55rEp5BTYCpAr2XXTFIJS-4rzaE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

Hi Ted,



On Mon, Aug 12, 2024 at 11:15 AM Ted Lemon <mellon@fugue.com> wrote:

> Mow that you mention is, it does seem like a gap not to specify how the
> isp lifetime and dependent router lifetime interact.
>
> For example, it’s probably worth making sure we don’t get into a Xeno’s
> paradox situation with the downstream lease, because the remaining lifetime
> isn’t constant and hence the lifetime of the downstream lease could always
> be shorter than the lifetime of the prefix provided by the ISP. However,
> specifying that would complexify the document a bit.
>
> But the main point is that I can think of several ways to choose the
> lifetime of the downstream lease based on the current text, and that’s not
> good. :)
>
Ted, one idea is we can borrow this text from the CPE Renumbering draft
with a twist.

LPD-X: IPv6 CE routers MUST NOT advertise prefixes via delegate prefixes
via DHCPv6 on the LAN side using lifetimes that exceed the remaining
lifetimes of the corresponding prefixes learned on the WAN side via
DHCPv6-PD. For more details, see 9096 Section 3.3
<https://datatracker.ietf.org/doc/html/rfc9096#section-3.3>.


> Op ma 12 aug 2024 om 10:29 schreef Jen Linkova <furry13@gmail.com>
>
>> Hi Tim,
>>
>> Sorry, coming late to the party (..again...;( )
>>
>> On Fri, Aug 9, 2024 at 4:36 AM Timothy Winters <tim@qacafe.com> wrote:
>> > LPD-7:
>> > The IPv6 CE Router MUST provision IA_PD prefixes with a prefix-length
>> of 64 unless configured to different prefix-length by the user. The prefix
>> length of 64 is used as that is the current prefix length supported by
>> SLAAC.
>>
>> While I do not have a strong opinion on that, I think that maybe
>> saying smth like 'MUST provision....a prefix length suitable for SLAAC
>> (currently /64)' would be better...
>>
>> I read the text you have in -04 as 'the router MUST provide /64 (btw
>> we chose that number because it's the current value for SLAAC)', so
>> the value is still hardcoded, so if we ever change the SLAAC prefix
>> length, this document would still require an update.
>>
>> What do you think?
>>
>> A few more comments:
>>
>> 1) shall the draft say anything about a flash renumbering/the change
>> of the delegated prefix?
>> LPD-3 allows the onlink prefix change if the topology or config
>> changes, but what about the pool? Would it be too much to ask for a
>> reconfigure message to be sent?
>> 2) is it assumed that T1/T2 values are consistent with T1/T2 received
>> from the ISP?
>> 3) It's been mentioned already, I believe, that the draft updates 7084
>> but there is no update text. In particular, I think, it needs to
>> update  WPD-5 to include packets to delegated prefixes.
>>
>>
>> > On Thu, Aug 8, 2024 at 2:15 PM Ted Lemon <mellon@fugue.com> wrote:
>> >>
>> >> What happened to the updates we talked about earlier (e.g., MUST, and
>> explaining what "by default" means)? :)
>> >>
>> >> I'm otherwise okay with this text though.
>> >>
>> >> On Thu, Aug 8, 2024 at 2:04 PM Timothy Winters <tim@qacafe.com> wrote:
>> >>>
>> >>> Hi Tim,
>> >>>
>> >>> I can get on board with that.
>> >>>
>> >>> OLD:
>> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
>> prefixes with a prefix-length of 64.
>> >>>
>> >>> New:
>> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
>> prefixes with a prefix-length of 64. The prefix length of 64 is
>> >>>    used as that is the current prefix length supported by SLAAC.
>> >>>
>> >>> ~Tim
>> >>>
>> >>> On Thu, Aug 8, 2024 at 4:22 AM Tim Chown <Tim.Chown@jisc.ac.uk>
>> wrote:
>> >>>>
>> >>>> Hi Tim,
>> >>>>
>> >>>>
>> >>>>
>> >>>> From: Timothy Winters <tim@qacafe.com>
>> >>>> Date: Wednesday, 7 August 2024 at 20:09
>> >>>> To: Tim Chown <Tim.Chown@jisc.ac.uk>
>> >>>> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Nick Buraglio <
>> buraglio@forwardingplane.net>, IPv6 Operations <v6ops@ietf.org>
>> >>>> Subject: Re: [v6ops] Re: Correction: Re: Working group Last call:
>> draft-ietf-v6ops-cpe-lan-pd
>> >>>>
>> >>>> Hi Tim,
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, Aug 7, 2024 at 7:24 AM Tim Chown <Tim.Chown=
>> 40jisc.ac.uk@dmarc.ietf.org> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>>
>> >>>>
>> >>>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> >>>> Date: Tuesday, 6 August 2024 at 21:53
>> >>>> To: Nick Buraglio <buraglio@forwardingplane.net>, IPv6 Operations <
>> v6ops@ietf.org>
>> >>>> Subject: [v6ops] Correction: Re: Working group Last call:
>> draft-ietf-v6ops-cpe-lan-pd
>> >>>>
>> >>>> I support the draft going forward.
>> >>>>
>> >>>> I do have one comment on the scope of the document. I believe that
>> it should also cover use of PD for a locally assigned ULA prefix. Please
>> don't turn this into another endless ULA thread - but if the CE has
>> assigned a ULA prefix, and supports PD for a GUA prefix, it should also
>> support PD for the ULA prefix.
>> >>>>
>> >>>>
>> >>>>
>> >>>> This seems reasonable.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Should /64 be hard coded in the document, or should it refer to a
>> prefix of the length required to support SLAAC as currently defined?
>> >>>>
>> >>>> I'm concerned this will cause confusion amongst the CE Router
>> community if I don't put an actual number.  If you really want we can 64 is
>> based on the prefix length of SLAAC as currently defined.  How strong do
>> you feel about this?
>> >>>>
>> >>>>
>> >>>>
>> >>>> Not strongly, but the WG has of late been trying not to
>> unnecessarily hard code the 64 into documents. If 64 is used, then a short
>> statement as to why would be good.
>> >>>>
>> >>>>
>> >>>>
>> >>>> The pd-per-device draft uses /64 in an example and says “Note that
>> the prefix lengths used in the example are /64 because that is the prefix
>> length currently supported by SLAAC and is not otherwise required by the
>> proposed deployment model” and says a little more on /64 in section 8 which
>> also refers to RFC 7084, and in section 11. The 64 isn’t “hard coded” in
>> there, in that its use in the example is clearly explained.
>> >>>>
>> >>>> Minor nit – the “addresses” at the end of para 1 of the intro should
>> probably say “prefixes”.
>> >>>>
>> >>>> thanks, fixed in -03.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Best wishes,
>> >>>>
>> >>>> Tim
>> >>>>
>> >>>>
>> >>>>
>> >>>> Tim
>> >>>>
>> >>>>
>> >>>>
>> >>>> (There are several grammatical nits in the Introduction. I'll send
>> them to the author off-list.)
>> >>>>
>> >>>> Regards
>> >>>>      Brian Carpenter
>> >>>>
>> >>>> On 07-Aug-24 03:18, Nick Buraglio wrote:
>> >>>> > All,
>> >>>> >
>> >>>> > This message begins the working group last call for
>> draft-ietf-v6ops-cpe-lan-pd. Please read the draft and send your comments
>> in response to this email.
>> >>>> >
>> >>>> > The draft can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/ <
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/>
>> >>>> >
>> >>>> > nb
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > v6ops mailing list -- v6ops@ietf.org
>> >>>> > To unsubscribe send an email to v6ops-leave@ietf.org
>> >>>>
>> >>>> _______________________________________________
>> >>>> v6ops mailing list -- v6ops@ietf.org
>> >>>> To unsubscribe send an email to v6ops-leave@ietf.org
>> >>>>
>> >>>> _______________________________________________
>> >>>> v6ops mailing list -- v6ops@ietf.org
>> >>>> To unsubscribe send an email to v6ops-leave@ietf.org
>> >>>
>> >>> _______________________________________________
>> >>> v6ops mailing list -- v6ops@ietf.org
>> >>> To unsubscribe send an email to v6ops-leave@ietf.org
>> >
>> > _______________________________________________
>> > v6ops mailing list -- v6ops@ietf.org
>> > To unsubscribe send an email to v6ops-leave@ietf.org
>>
>>
>>
>> --
>> Cheers, Jen Linkova
>>
>