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 1A73FC1519A7 for ; Thu, 8 Aug 2024 11:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (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 28ORoNbNHrih for ; Thu, 8 Aug 2024 11:28:21 -0700 (PDT) Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) (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 34225C151536 for ; Thu, 8 Aug 2024 11:28:21 -0700 (PDT) Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-261e543ef35so831859fac.3 for ; Thu, 08 Aug 2024 11:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1723141700; x=1723746500; 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=7V9+5P5akdxNRNFF0I3zM3sAcV80UQnsEk1c5pY+DIw=; b=yxgf2e7Gef/1hM/PXDrwWPpHRtfhpsBRppJ45sKO55OoonhlNHiRc1QFoGbAgLka9/ rOSbB/yaL3oBmo96gqTj5Imce6rzytzpDL+tigEt06fMTKlAqTMG8URda2kh9iDMtxoe ED60kgqXdRGiecQBwiEiwWQOsqaTp2rsbOjpg4eu+OEC32bdAaiV5bw429ZZ+H6hFM1e sj1Mcfp3OhjYr9gcmZuk5FBjyS9sCQosxVA/llxDs8uuvoNxgH/qWZl9HkG8YxwbNIg0 YxNY9aTzKrQEQVEiQmagH2rWYHyMTsZsjrmCqBp8jOEgTI1tcKDjhxqQRZzM6oD18G/3 XxEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723141700; x=1723746500; 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=7V9+5P5akdxNRNFF0I3zM3sAcV80UQnsEk1c5pY+DIw=; b=ne4Ubr4MdCV1RjyKToRLhMSrjkeC9RThPdigOZCWZiU+8SmFkdEWrLUXpwNF18dlCE RTtPhXnPrg7lutViOfabqqJgp/RcAh0c/FT0wI2f02fUbB1wHMhPnPo9SLrMNot8BbyE KfBnGrE5ouqcah+AxxSmu9dpYvROuYfRHtQ+AmgsvtG8x/+P01PeWVlTbZIy5hztakkf W+SKG6WrfW/3NJA8Yx44na+ghqnCVdnuslVMl4EF/+dGXnSzBR58tD8XOsFiwn0JM9my Kknp5bCHIygwAptanozdZ5BbVB338lgJOPDz+OxNsroqb6i6vBKWHZQazWQepVLn4V4u rQ+A== X-Forwarded-Encrypted: i=1; AJvYcCWAyAg9lDCP5qDbmJrYm601yIc01AYSSemXWDNXO+YnR3Dr7jYNkDfDwaz338KkRUillNtxMCq6lihtBN5fRw== X-Gm-Message-State: AOJu0YwJYUXF1S2lP02xWqUtEp2A9UjtRGnUDjCE1N0RRwqMMbAl5xRY 72ClBWa0GgP024IcySSbHE2LV0mkgEBMLpSsoFWj/3K/z5eAJ4JaDz2wt8wpNyDVZkHQ7+UqsBA WQLc/jbY7Oa1odz4hahuRUFFr7acWRcpAIyqHNg== X-Google-Smtp-Source: AGHT+IHfT6SPI1TsTvhGTcNlxK9ppCSCakE49SwDRlg7LW01qT6LOYbAmAECIfyCsDdZYzZH+VNO4RAI4uZIlvlcopw= X-Received: by 2002:a05:6870:3323:b0:261:1a62:a829 with SMTP id 586e51a60fabf-2692b7fd2b5mr3346253fac.46.1723141699951; Thu, 08 Aug 2024 11:28:19 -0700 (PDT) MIME-Version: 1.0 References: <172306305735.252.5586801355147827297@dt-datatracker-6df4c9dcf5-t2x2k> In-Reply-To: From: Ted Lemon Date: Thu, 8 Aug 2024 14:27:44 -0400 Message-ID: To: Timothy Winters Content-Type: multipart/alternative; boundary="000000000000ec7b66061f30303e" Message-ID-Hash: PTVSNSSW2IJZX6IXTAKRIMBKRE3LMBJT X-Message-ID-Hash: PTVSNSSW2IJZX6IXTAKRIMBKRE3LMBJT 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: v6ops@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bv6ops=5D_Re=3A_I-D_Action=3A_draft-ietf-v6ops-cpe-lan-pd-03=2Et?= =?utf-8?q?xt?= List-Id: v6ops discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000ec7b66061f30303e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it's fine to try to get more prefixes if you don't get the amount you asked for the first time, by adding IA_PDs with different IAIDs to subsequent requests. However, we should always ask for a /48. How does the CPE router know how many prefixes it will be asked to provide? If the ISP doesn't want to provide a /48, it will provide a smaller allocation, and that's perfectly fine. On Thu, Aug 8, 2024 at 2:23=E2=80=AFPM Timothy Winters wro= te: > Hi Mark, > > On Wed, Aug 7, 2024 at 7:06=E2=80=AFPM Mark Smith wrote: > >> Hi, >> >> Apologies for the late comments, I seem to be missing IETF ID >> announcements and WGLCs (I think trying to read everything out of my >> Inbox might not be working). >> >> I don't think logging a system management error for the below >> situation is good enough in a residential environment: >> >> "LPD-2: >> The IPv6 CE Router MUST assign a prefix from the delegated prefix as >> specified by L-2 [RFC7084]. If not enough addresses are available the >> IPv6 CE Router SHOULD log a system management error." >> >> Non-technical residential end-users are very unlikely to look up >> system error logs if they have a fault, they'll call their ISP's help >> desk straight away - their ISP is their first port of call for any and >> all faults that look to be Internet faults. >> > In this case I was thinking for the ISP to know that they have routers > that want to give out IA_PD > on the LAN and they aren't giving a prefix large enough. > > In my experience of residential help desk staff looking up or asking >> customers to look up system logs for error messages isn't a practice >> either - and if you look at logs of some of these devices they're very >> chatty so spotting error messages is time consuming, which is counter >> to a common helpdesk KPI of customer calls answered per hour. >> >> I also think in some cases CPE don't expose system logs - from memory, >> Google's Nest CE routers don't have a system log available. >> > I was thinking about getting system logs from CWMP/USP/NETCONF from the > ISP. > >> >> It would be better if engineering were somehow directly notified of a >> customer running out of prefixes and ideally could provide more >> prefixes automatically. The IA_PD Prefix-Length Hint mechanism would >> do that. >> > I'd had discussions with many ISPs, and only a handful of environments > with the DHCPv6 server > honor prefix hints. Most ISPs for planning purposes have a number and > that's what they send. > >> >> So I'd suggest updating LPD-2 to: >> >> "LPD-2: >> The IPv6 CE Router MUST assign a prefix from the delegated prefix as >> specified by L-2 [RFC7084]. If not enough prefixes are available the >> IPv6 CE Router MUST request the number of required additional >> prefixes, rounded up to the next shortest prefix length bit boundary, >> via an additional IA_PD option through the Prefix-Length Hint >> mechanism [RFC8168]. The second or subsequent IA_PD options are used >> to avoid a renumbering event where the initial and now too-small >> Prefix-Delegation prefix would be entirely replaced with a new and >> single larger Prefix-Delegation prefix. The IPv6 CE Router SHOULD log >> a system management error." >> > For this solution, I have some questions. > > Are you proposing that subsequent DHCPv6 messages (Renew, Rebind) ask > for additional IA_PDs, beyond what is currently leased? > > OR are you proposing that the CE Router change what it's asking DHCPv6 > Solicit or Request? > >> >> I'm not entirely convinced that "request the number of required >> additional prefixes, rounded up to the next shortest prefix length bit >> boundary" is the right amount of address space the CE should request. >> Perhaps a simpler mechanism would be to request an additional PD >> Prefix that is the same size as the initial PD prefix provided by the >> ISP. >> > I like this idea the best. I think this has the highest chance of > success, that the DHCPv6 Server is > configured to give out one size. > >> >> (I understand above is complex to provision and manage on the DHCPv6 >> server side and IPv6 addressing side, however that's the price of >> treating IPv6 address space as if it was scarce rather than abundant. >> My advice to residential ISPs is to give out /48s. APNIC had no issues >> with giving an ISP I worked for a few years ago enough address space >> for us to give all of our 500K residential customers /48s.) >> >> Regards, >> Mark. >> >> >> >> >> >> On Thu, 8 Aug 2024 at 06:39, wrote: >> > >> > Internet-Draft draft-ietf-v6ops-cpe-lan-pd-03.txt is now available. It >> is a >> > work item of the IPv6 Operations (V6OPS) WG of the IETF. >> > >> > Title: IPv6 CE Routers LAN Prefix Delegation >> > Author: Timothy Winters >> > Name: draft-ietf-v6ops-cpe-lan-pd-03.txt >> > Pages: 7 >> > Dates: 2024-08-07 >> > >> > Abstract: >> > >> > This document defines requirements for IPv6 CE Routers to support >> > DHCPv6 Prefix Delegation for redistributing any unused prefix(es) >> > that were delegated to the IPv6 CE Router. This document updates R= FC >> > 7084. >> > >> > The IETF datatracker status page for this Internet-Draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/ >> > >> > There is also an HTMLized version available at: >> > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-lan-pd-03 >> > >> > A diff from the previous version is available at: >> > >> https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-v6ops-cpe-lan-pd-= 03 >> > >> > Internet-Drafts are also available by rsync at: >> > rsync.ietf.org::internet-drafts >> > >> > >> > _______________________________________________ >> > 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 > --000000000000ec7b66061f30303e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it's fine to try to get more prefixes if you d= on't get the amount you asked for the first time, by adding IA_PDs with= different IAIDs to subsequent requests. However, we should always ask for = a /48. How does the CPE router know how many prefixes it will be asked to p= rovide? If the ISP doesn't want to provide a /48, it will provide a sma= ller allocation, and that's perfectly fine.

On Thu, Aug 8, 2024 at 2:23= =E2=80=AFPM Timothy Winters <tim@qacaf= e.com> wrote:
Hi Mark,

On Wed, Aug 7, 2024 at 7:06=E2=80=AFPM Mark Smith <markzzzsmith@gmail.c= om> wrote:
Hi,

Apologies for the late comments, I seem to be missing IETF ID
announcements and WGLCs (I think trying to read everything out of my
Inbox might not be working).

I don't think logging a system management error for the below
situation is good enough in a residential environment:

"LPD-2:
The IPv6 CE Router MUST assign a prefix from the delegated prefix as
specified by L-2 [RFC7084]. If not enough addresses are available the
IPv6 CE Router SHOULD log a system management error."

Non-technical residential end-users are very unlikely to look up
system error logs if they have a fault, they'll call their ISP's he= lp
desk straight away - their ISP is their first port of call for any and
all faults that look to be Internet faults.
In this ca= se I was thinking for the ISP to know that they have routers that want to g= ive out IA_PD=C2=A0
on the LAN and they aren't giving a prefi= x large enough.

In my experience of residential help desk staff looking up or asking
customers to look up system logs for error messages isn't a practice either - and if you look at logs of some of these devices they're very<= br> chatty so spotting error messages is time consuming, which is counter
to a common helpdesk KPI of customer calls answered per hour.

I also think in some cases CPE don't expose system logs - from memory,<= br> Google's Nest CE routers don't have a system log available.
I was thinking about getting system logs from CWMP/USP/NETCON= F from the ISP.=C2=A0

It would be better if engineering were somehow directly notified of a
customer running out of prefixes and ideally could provide more
prefixes automatically. The IA_PD Prefix-Length Hint mechanism would
do that.
I'd had discussions with many ISPs, and o= nly a handful of environments with the DHCPv6 server=C2=A0
honor = prefix hints.=C2=A0 Most ISPs for planning purposes have a number and that&= #39;s what they send.

So I'd suggest updating LPD-2 to:

"LPD-2:
The IPv6 CE Router MUST assign a prefix from the delegated prefix as
specified by L-2 [RFC7084]. If not enough prefixes are available the
IPv6 CE Router MUST request the number of required additional
prefixes, rounded up to the next shortest prefix length bit boundary,
via an additional IA_PD option through the Prefix-Length Hint
mechanism [RFC8168]. The second or subsequent IA_PD options are used
to avoid a renumbering event where the initial and now too-small
Prefix-Delegation prefix would be entirely replaced with a new and
single larger Prefix-Delegation prefix. The IPv6 CE Router SHOULD log
a system management error."
For this solution, I = have some questions.=C2=A0=C2=A0

Are you proposing= that subsequent DHCPv6 messages (Renew, Rebind) ask=C2=A0
for ad= ditional IA_PDs, beyond what is currently leased?

= OR are you proposing=C2=A0that the CE Router change what it's asking DH= CPv6 Solicit=C2=A0or Request?

I'm not entirely convinced that "request the number of required additional prefixes, rounded up to the next shortest prefix length bit
boundary" is the right amount of address space the CE should request.<= br> Perhaps a simpler mechanism would be to request an additional PD
Prefix that is the same size as the initial PD prefix provided by the
ISP.
I like this idea the best.=C2=A0 I think this has= the highest=C2=A0chance of success, that the DHCPv6 Server is=C2=A0
<= div>configured to give out one size.

(I understand above is complex to provision and manage on the DHCPv6
server side and IPv6 addressing side, however that's the price of
treating IPv6 address space as if it was scarce rather than abundant.
My advice to residential ISPs is to give out /48s. APNIC had no issues
with giving an ISP I worked for a few years ago enough address space
for us to give all of our 500K residential customers /48s.)

Regards,
Mark.





On Thu, 8 Aug 2024 at 06:39, <internet-drafts@ietf.org> wrote:
>
> Internet-Draft draft-ietf-v6ops-cpe-lan-pd-03.txt is now available. It= is a
> work item of the IPv6 Operations (V6OPS) WG of the IETF.
>
>=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0IPv6 CE Routers LAN Prefix Delegation<= br> >=C2=A0 =C2=A0 Author:=C2=A0 Timothy Winters
>=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 draft-ietf-v6ops-cpe-lan-pd-03.txt
>=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A07
>=C2=A0 =C2=A0 Dates:=C2=A0 =C2=A02024-08-07
>
> Abstract:
>
>=C2=A0 =C2=A0 This document defines requirements for IPv6 CE Routers to= support
>=C2=A0 =C2=A0 DHCPv6 Prefix Delegation for redistributing any unused pr= efix(es)
>=C2=A0 =C2=A0 that were delegated to the IPv6 CE Router.=C2=A0 This doc= ument updates RFC
>=C2=A0 =C2=A0 7084.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/d= raft-ietf-v6ops-cpe-lan-pd/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.or= g/doc/html/draft-ietf-v6ops-cpe-lan-pd-03
>
> A diff from the previous version is available at:
> https://author-tools.= ietf.org/iddiff?url2=3Ddraft-ietf-v6ops-cpe-lan-pd-03
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org

_______________________________________________
v6ops mailing list -- v= 6ops@ietf.org
To unsubscribe send an email to v6ops-leave@ietf.org
_______________________________________________
v6ops mailing list -- v= 6ops@ietf.org
To unsubscribe send an email to v6ops-leave@ietf.org
--000000000000ec7b66061f30303e--