Return-Path: 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 21208C1CAE93 for ; Mon, 12 Aug 2024 11:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20230601.gappssmtp.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 bV2gkxZptxd6 for ; Mon, 12 Aug 2024 11:53:12 -0700 (PDT) Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) (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 08FC9C1CAE8C for ; Mon, 12 Aug 2024 11:53:11 -0700 (PDT) Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-260dde65a68so2976689fac.2 for ; Mon, 12 Aug 2024 11:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1723488791; x=1724093591; 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=3E4obIp/L0dADHoHl9oWkRlUusI8xSIFdY5kAaK7kVc=; b=UGO2S4PRETerQ/CafVb2B++FvqbVKtjjRVUfddUAwvkrnM7CszlqOawss3NhubjTfw 6XYclLxTvbe+eqikgIIVHkK6Qt10pJb7ywSC42lc/8n2cVNCwmKpIH5UTKbdhau/vWzC /r5VdsJNjwzsG43lW4NtqgjeN+wKjsG5S56uHcy4Ed5+g6IZjsN95RvvzVLvgpAO/Hfc vRzsiustrTWpOAPGdqPpO8QJaGu7EMe+dRtPNDU7gXafByvrAsrc/FGBs4fFtgJglYEy 9TQZy1ciUfUw368qdjkve+tApnOuoeePycb5rNBQWLCWZF7IsA0nRYBoMaOWGugYtASM irBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723488791; x=1724093591; 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=3E4obIp/L0dADHoHl9oWkRlUusI8xSIFdY5kAaK7kVc=; b=mlfH3KEDXxwlChZfs8boL4ylFMH6OfIwBaQxx3bLsoUUljVHepooD2cxR//4ec0DxN mod4OtvYczl3svsczUz/FAfO1S2Q63xuiHqHpo+04AnRSiOSfFXU+oDD+KXzeEYu9fNp UqTyTgQ1C1dHT/wE8Z6V0Cf3IM9UFlsxuRACvei74UY4a6CGgMtZhoZ2onBbXvznkEge RkN5oXR4X4wOxRwbLPwv0rRkEqRvjPSbslzYEpp5vP+BynRoWPWchumN0HlpMcbhIu7W 2D7BKTBpKr05LmTjlGz0djoVFYOsK/1Xv0K+iPdZ6RWqplm8025o0NaHoohx/1tkF15v Op1g== X-Forwarded-Encrypted: i=1; AJvYcCVSxDwhT2e1T9IPyBEkdWTKTZpe3DcqujNz6Ih6yhAkBcn/iJAbDxFckzrLpPXZF7jNDHAmowZO9fZ+jRzKKQ== X-Gm-Message-State: AOJu0YxieR5bTegTTK+9K9rOnKAsM/BBJHESF6x3DUWIaJ2+GFDIQs66 ScFhOP0uAGBRUpGujtqBGFO6M2LltqAFAy0LHFp587ZKIGHsneVz6ioVDflNskA66qScqHSQOyP rzn35hO63z4N0Ur9NXdSRLtgIq/36kc53WaxZKg== X-Google-Smtp-Source: AGHT+IEvTuKi7J/gwa8uYiqLiid1BcWV0s5NavTZ5iiW0JuxNn2dIufTOIivzBAKTB3iOrXDx4eEfsB8uWc7bcgTe4M= X-Received: by 2002:a05:6870:5693:b0:254:c7f6:3294 with SMTP id 586e51a60fabf-26fcb8c9286mr1264761fac.47.1723488791148; Mon, 12 Aug 2024 11:53:11 -0700 (PDT) MIME-Version: 1.0 References: <11d52d74-b53a-4176-8128-5d2aa80320ca@gmail.com> In-Reply-To: From: Ted Lemon Date: Mon, 12 Aug 2024 14:53:00 -0400 Message-ID: To: Timothy Winters Content-Type: multipart/alternative; boundary="0000000000002bd4bc061f810114" Message-ID-Hash: R6NLHADIFUXNTUMDJNKF7ZMAXDBSJ5B2 X-Message-ID-Hash: R6NLHADIFUXNTUMDJNKF7ZMAXDBSJ5B2 X-MailFrom: mellon@fugue.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 , IPv6 Operations X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bv6ops=5D_Re=3A_Correction=3A_Re=3A_Working_group_Last_call=3A_d?= =?utf-8?q?raft-ietf-v6ops-cpe-lan-pd?= List-Id: v6ops discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002bd4bc061f810114 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What it means to be in the rough is not that you are in the minority. It is that a technical objection has been raised that has been considered /and addressed/ by the working group, and that you don=E2=80=99t agree with the consensus. Here it is I think very clear that if you don=E2=80=99t specify a prefix wi= dth, it will not be possible to get the result we are trying to get. So you need to specify a width. A future document can change the width if necessary. Saying in parentheses =E2=80=9Ccurrently 64=E2=80=9D is really just asking = for interoperability problems. The text as previously written was more correct. Op ma 12 aug 2024 om 13:33 schreef Timothy Winters > > > On Mon, Aug 12, 2024 at 10:29=E2=80=AFAM Jen Linkova = wrote: > >> Hi Tim, >> >> Sorry, coming late to the party (..again...;( ) >> >> On Fri, Aug 9, 2024 at 4:36=E2=80=AFAM Timothy Winters = 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 pref= ix >> 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? >> >> I can live with this, I'm concerned if we don't put the actual value in > it will lead to confusion. I'm getting the feeling that I'm in the > rough, so I'll make this change.. > >> 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? >> > CE Router DHCPv6 Servers on the LAN don't support DHCP Authentication > therefore I don't think this is reasonable. > >> 2) is it assumed that T1/T2 values are consistent with T1/T2 received >> from the ISP? >> > No, not at all. > >> 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. >> > That's an interesting point, I'll work to add an update to WPD-5 for > clarification. > >> >> >> > On Thu, Aug 8, 2024 at 2:15=E2=80=AFPM Ted Lemon wr= ote: >> >> >> >> 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=E2=80=AFPM Timothy Winters 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=E2=80=AFAM Tim Chown >> wrote: >> >>>> >> >>>> Hi Tim, >> >>>> >> >>>> >> >>>> >> >>>> From: Timothy Winters >> >>>> Date: Wednesday, 7 August 2024 at 20:09 >> >>>> To: Tim Chown >> >>>> Cc: Brian E Carpenter , Nick Buraglio = < >> buraglio@forwardingplane.net>, IPv6 Operations >> >>>> 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=E2=80=AFAM Tim Chown > 40jisc.ac.uk@dmarc.ietf.org> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> >> >>>> >> >>>> From: Brian E Carpenter >> >>>> Date: Tuesday, 6 August 2024 at 21:53 >> >>>> To: Nick Buraglio , 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 sho= rt >> statement as to why would be good. >> >>>> >> >>>> >> >>>> >> >>>> The pd-per-device draft uses /64 in an example and says =E2=80=9CNo= te that >> the prefix lengths used in the example are /64 because that is the prefi= x >> length currently supported by SLAAC and is not otherwise required by the >> proposed deployment model=E2=80=9D and says a little more on /64 in sect= ion 8 which >> also refers to RFC 7084, and in section 11. The 64 isn=E2=80=99t =E2=80= =9Chard coded=E2=80=9D in >> there, in that its use in the example is clearly explained. >> >>>> >> >>>> Minor nit =E2=80=93 the =E2=80=9Caddresses=E2=80=9D at the end of p= ara 1 of the intro should >> probably say =E2=80=9Cprefixes=E2=80=9D. >> >>>> >> >>>> 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 comment= s >> 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 >> > --0000000000002bd4bc061f810114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What it means to be in the rough is not that you are in t= he minority. It is that a technical objection has been raised that has been= considered /and addressed/ by the working group, and that you don=E2=80=99= t agree with the consensus.=C2=A0

Here it is I think very clear that if you don=E2=80=99t specify a= prefix width, it will not be possible to get the result we are trying to g= et. So you need to specify a width. A future document can change the width = if necessary.=C2=A0

Sayi= ng in parentheses =E2=80=9Ccurrently 64=E2=80=9D is really just asking for = interoperability problems. The text as previously written was more correct.= =C2=A0

Op ma 12 aug 2024 om 13:33 schreef Timothy Winters <tim@qacafe.com>


On Mon, Aug 12, 2024= at 10:29=E2=80=AFAM Jen Linkova <furry13@gmail.com> wrote:
Hi Tim,

Sorry, coming late to the party (..again...;( )

On Fri, Aug 9, 2024 at 4:36=E2=80=AFAM 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 SLAA= C.

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<= br> (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.=C2=A0

What do you think?

I can live with this, I'm concerned=C2=A0if we do= n't put the actual value in it will lead to confusion.=C2=A0 I'm ge= tting the feeling that I'm in the rough,=C2=A0so I'll make=C2=A0thi= s change..=C2=A0
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?
CE Router DHCPv6 Serve= rs on the LAN don't support DHCP Authentication therefore I don't t= hink this is reasonable.
2) is it assumed that T1/T2 values are consistent with T1/T2 received
from the ISP?
No, not at all.=C2=A0 =C2=A0
3) It's been mentioned already, I believe, that the draft updates 7084<= br> but there is no update text. In particular, I think, it needs to
update=C2=A0 WPD-5 to include packets to delegated prefixes.
That's an interesting point, I'll work to add an update to W= PD-5 for clarification.


> On Thu, Aug 8, 2024 at 2:15=E2=80=AFPM 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=E2=80=AFPM Timothy Winters <tim@qacafe.com> wrote:<= br> >>>
>>> Hi Tim,
>>>
>>> I can get on board with that.
>>>
>>> OLD:
>>>=C2=A0 =C2=A0 LPD-7:=C2=A0 The IPv6 CE Router SHOULD by default= provision IA_PD IA prefixes with a prefix-length of 64.
>>>
>>> New:
>>>=C2=A0 =C2=A0 LPD-7:=C2=A0 The IPv6 CE Router SHOULD by default= provision IA_PD IA prefixes with a prefix-length of 64. The prefix length = of 64 is
>>>=C2=A0 =C2=A0 used as that is the current prefix length support= ed by SLAAC.
>>>
>>> ~Tim
>>>
>>> On Thu, Aug 8, 2024 at 4:22=E2=80=AFAM 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 Las= t call: draft-ietf-v6ops-cpe-lan-pd
>>>>
>>>> Hi Tim,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2024 at 7:24=E2=80=AFAM Tim Chown <Tim.C= hown=3D40j= isc.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 Op= erations <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 beli= eve 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 ref= er 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.=C2=A0 If you really = want we can 64 is based on the prefix length of SLAAC as currently defined.= =C2=A0 How strong do you feel about this?
>>>>
>>>>
>>>>
>>>> Not strongly, but the WG has of late been trying not to un= necessarily hard code the 64 into documents. If 64 is used, then a short st= atement as to why would be good.
>>>>
>>>>
>>>>
>>>> The pd-per-device draft uses /64 in an example and says = =E2=80=9CNote that the prefix lengths used in the example are /64 because t= hat is the prefix length currently supported by SLAAC and is not otherwise = required by the proposed deployment model=E2=80=9D and says a little more o= n /64 in section 8 which also refers to RFC 7084, and in section 11. The 64= isn=E2=80=99t =E2=80=9Chard coded=E2=80=9D in there, in that its use in th= e example is clearly explained.
>>>>
>>>> Minor nit =E2=80=93 the =E2=80=9Caddresses=E2=80=9D at the= end of para 1 of the intro should probably say =E2=80=9Cprefixes=E2=80=9D.=
>>>>
>>>> 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
>>>>=C2=A0 =C2=A0 =C2=A0 Brian Carpenter
>>>>
>>>> On 07-Aug-24 03:18, Nick Buraglio wrote:
>>>> > All,
>>>> >
>>>> > This message begins the working group last call for d= raft-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
--0000000000002bd4bc061f810114--