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 28FE1C14F71E for ; Wed, 14 Aug 2024 07:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 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_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 uhRzxoukAoF4 for ; Wed, 14 Aug 2024 07:51:44 -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 C37A2C14F6EF for ; Wed, 14 Aug 2024 07:51:44 -0700 (PDT) Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-268a9645e72so4640022fac.1 for ; Wed, 14 Aug 2024 07:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1723647103; x=1724251903; 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=wI0FQ7Sn2kzx2CsCOYGNNLqh5XSIC7p5vmo0UaULqEE=; b=FD/S1slUQcf3w0NtWmStfA/j3TIS4kJGvbaMljV1DYmcO1pkm2wU/eXzkcyDAqJ6qF 2Eq8cf1elzTj5DV3pecxYfN7gYe0/+OCz8ruDAfBMGqRQBcG0wOZdPX6LJds/wUCmejH t+R/lh44qzztz08xrFHNqBY99B7cmgt8qR1dVl8KVCy3IrDzhqCgoM/SKUQQNkpF8Lge vaXUzWQXw1d6eywq+oq2eH3/scFZhDmIRip2V1wQbXqDFqwz5N2Nny2tdLO3tykoYzJL rTF6jXwHROaejPsCTYaQHJbL3uz3mVdzjADw8xtECBbg+fgKyPls1Wq40CGXrcHwesFS zwbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723647103; x=1724251903; 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=wI0FQ7Sn2kzx2CsCOYGNNLqh5XSIC7p5vmo0UaULqEE=; b=JYXl8zW3g93P/44ggUh6+IX/tAYv42QdjVPrqLRSYm9YanH5ff2mptpVBAkQqtxe46 gOKdQrdkIPwGN1QAB9isn/N4+YJJiEAAXLDSc6aiiUe6LnMQRpvP/iitIPlLbx3uyQjW Ol0yZeh9rs3ss6zr4VtwpIhqI1BLKI4GwyrCcGR7Syo5Si/CeacaEU4UgVnAhs8NysfY qfnev3xNG1hqmkz738xGocCuRRcQnJQTnxQ2wh7jn8hvzwmcSVAtiH6XFGiqlJYxK3Zb I2wwrHbvzKih7ttnroIZO2vJB/L2L/47GSd/kU1jqxum32X5xEeaiIyycT+O9/HC4FHz dMaw== X-Forwarded-Encrypted: i=1; AJvYcCXN9GU+7L562nc4zZQ3l/tWqQyYAr3xHkF9CDtSWsiCeU5oCH1NhBo6stlfZIdc9MUR8MiblEm0NwzEk3s0YA== X-Gm-Message-State: AOJu0Yyizrw5n63yFBqGbkWVHtvq2jlpbnA2MuVRg80SOf6CwV8+5ZNK uMNt83l0kh7/iyrVsVrtjlXFYDDowx4kjVUjo0EP1X+WJmEK8iS8iaDL0e2l0MKmIPEvzTCZcbF SVwVB9tn/BuYEsTWSzihTP7xw4xOCSifrqBwHoA== X-Google-Smtp-Source: AGHT+IFoL2zzemp/dEGtGiyfbotMpgnodTXOlq2mlpOgkaDfro4ea2TOX3uUq7TadP/m2XUF5EfYiDUezsCNz0+eMj8= X-Received: by 2002:a05:6870:55c9:b0:260:eb3a:1bc with SMTP id 586e51a60fabf-26fe5c288damr3711114fac.41.1723647103347; Wed, 14 Aug 2024 07:51:43 -0700 (PDT) MIME-Version: 1.0 References: <172306305735.252.5586801355147827297@dt-datatracker-6df4c9dcf5-t2x2k> In-Reply-To: From: Ted Lemon Date: Wed, 14 Aug 2024 10:51:32 -0400 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary="000000000000504e98061fa5ddf2" Message-ID-Hash: POPASNFB3EXXWCE5NLAXMP23KF6ZC6AN X-Message-ID-Hash: POPASNFB3EXXWCE5NLAXMP23KF6ZC6AN 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 list 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: --000000000000504e98061fa5ddf2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right. We can=E2=80=99t necessarily control what the isp does, unless as I suggested in another thread we have the router not actually turn on IPv6 if a satisfactory prefix isn=E2=80=99t offered. Op wo 14 aug 2024 om 01:42 schreef Mark Smith > Hi Ted, > > On Wed, 14 Aug 2024, 00:32 Ted Lemon, wrote: > >> That seems needlessly complicated though. The presence of two IAIDs in >> the request is an indication that one is enough. >> > > Okay, so that's a binary sign that the CPE doesn't have enough prefixes. > > Requiring the server to do math on the set of requests it=E2=80=99s not b= een able >> to satisfy seems like it doesn=E2=80=99t add anything. >> > > I'm looking at the refusal to provide a /48 even if asked for by a RFC > 7084 CE as a policy decision by the network operator, rather than the > DHCPv6 server running out of address space to assign. > > In other words, the DHCPv6 server would be configured to hand out e.g. PD > /60s to all residential customers regardless of the Perfix Hint value (an= d > perhaps some other common standard size to SOHO business customers). > > I agree about the maths. I was thinking that by asking for a "just big > enough" prefix it would provide data to the network operator how many /64 > prefixes they need to additionally provide so they could resize their > default sized prefix to something bigger. > > However, I think it would be better and simpler to just ask for another > prefix of the same size as originally supplied. The DHCPv6 server would > provide another prefix of that default or standard size out of the > available PD pool. > > If an ISP thinks 2 * default PD prefix (or n * default PD prefix) is to= o > much space to give to a customer, then they could shrink their default PD > prefix size. > > Regards, > Mark. > > > > > > > > >> >> Op di 13 aug 2024 om 05:36 schreef Mark Smith >> >>> Hi Tim, Ted, >>> >>> Great to say to send another PD request with a new IAID when there are >>> no prefixes left. >>> >>> I've realised we might be talking past each other a bit regarding >>> requesting a /48. >>> >>> Here's what I was thinking for the sequence of events that would >>> signal to an ISP that they're both not providing enough prefixes and >>> also signalling how many additional prefixes they would need to >>> provide: >>> >>> 1. At initialisation, CPE makes an initial IA_PD request with no >>> Prefix-Length hint value (I assume this is where /48 has been >>> suggested). >>> 2. ISP hands out a small PD prefix for the customer e.g. a /60. >>> 3. Customer's network runs out of /64s because of e.g. too many links, >>> or too many PD-per-host hosts. >>> 4. Customer's CPE knows it needs another 6 /64s (as an example) and >>> then sends a new IAID with a Prefix-Length hint rounded up to the next >>> prefix bit boundary of a /61. >>> 5. The ISP provides an additional suitably sized prefix to satisfy the >>> 4. prefix hint request. >>> >>> At 4., it could be simpler for the CPE to instead send a Prefix-Length >>> hint of the same size as supplied at 2 i.e. request another /60. >>> >>> The size of the prefix hint at step 4 would provide to the ISP >>> evidence that they're both not providing enough initial address space, >>> and also an indication of how much additional space they need to >>> provide, if their view is to only provide "enough" prefixes for what >>> they think the customer needs rather than a simpler and assured >>> "always enough" of a /48. >>> >>> Regards, >>> Mark. >>> >>> >>> >>> >>> >>> >>> On Fri, 9 Aug 2024 at 22:57, Timothy Winters wrote: >>> > >>> > Agree. >>> > On Fri, Aug 9, 2024 at 8:56=E2=80=AFAM Ted Lemon w= rote: >>> >> >>> >> It would also make sense to send a new IAID whenever we get a new pd >>> request and have no remaining prefixes to provide. >>> >> >>> >> >>> >> Op vr 9 aug 2024 om 08:53 schreef Timothy Winters >>> >>> >>> >>> Hi Mark and Ted, >>> >>> >>> >>> I'll add a line asking for a second IA_PD with a unique IAID when >>> sending Renew/Rebind messages. >>> >>> >>> >>> ~Tim >>> >>> >>> >>> On Fri, Aug 9, 2024 at 7:33=E2=80=AFAM Ted Lemon = wrote: >>> >>>> >>> >>>> The point of always asking for a /48 isn=E2=80=99t to signal somet= hing to >>> the isp other than =E2=80=9Cgive me the biggest prefix you are willing = to >>> provide.=E2=80=9D If we don=E2=80=99t ask for a /48, we won=E2=80=99t = get one. >>> >>>> >>> >>>> If we ask for additional prefixes, the customer may just never see >>> a problem, so I=E2=80=99m not sure how useful a signal this is, but cer= tainly it >>> will tell the isp if there is demand for narrower prefixes, and that is= n=E2=80=99t >>> a bad thing. >>> >>>> >>> >>>> Op vr 9 aug 2024 om 03:30 schreef Mark Smith < >>> markzzzsmith@gmail.com> >>> >>>>> >>> >>>>> Hi, >>> >>>>> >>> >>>>> On Fri, 9 Aug 2024, 12:20 Ted Lemon, wrote: >>> >>>>>> >>> >>>>>> What=E2=80=99s the downside? :) >>> >>>>> >>> >>>>> >>> >>>>> The concern I have is that I've seen obscure individual customer >>> faults float around inside residential help desks for a number of weeks >>> being looked at by different people, rather than being escalated to net= work >>> engineering as soon as they should be. Eventually it might get escalate= d, >>> or the customer leaves through frustration. >>> >>>>> >>> >>>>> For ISPs that aren't willing to give out large prefixes e.g., >>> /60s, having the CPE ask for additional PD space when it runs out would= at >>> least show up in DHCPv6 PD server logs. That network engineering can >>> directly look for that, and it would be absolute evidence of what probl= em >>> the individual customer is suffering from. It would also be direct evid= ence >>> to the ISP that they're not handing out big enough prefixes to customer= s. >>> >>>>> >>> >>>>> If an ISP isn't going to honor an IA_PD request for a /48, which = I >>> think would be unlikely for ISPs who aren't already handing out /48s, t= hen >>> I don't think this ID specifying to always ask for /48s is going to ach= ieve >>> anything. It won't signal to network engineering that customers are run= ning >>> out of address space because it will hide that customers are running ou= t. >>> >>>>> >>> >>>>> Regards, >>> >>>>> Mark. >>> >>>>> >>> >>>>> >>> >>>>>> >>> >>>>>> Op do 8 aug 2024 om 14:36 schreef Timothy Winters >> > >>> >>>>>>> >>> >>>>>>> Ted, >>> >>>>>>> >>> >>>>>>> On Thu, Aug 8, 2024 at 2:28=E2=80=AFPM Ted Lemon >>> wrote: >>> >>>>>>>> >>> >>>>>>>> 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 differen= t >>> 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. >>> >>>>>>> >>> >>>>>>> I was toying with that idea as well. Just asking for /48. >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> On Thu, Aug 8, 2024 at 2:23=E2=80=AFPM Timothy Winters >>> wrote: >>> >>>>>>>>> >>> >>>>>>>>> Hi Mark, >>> >>>>>>>>> >>> >>>>>>>>> On Wed, Aug 7, 2024 at 7:06=E2=80=AFPM Mark Smith < >>> markzzzsmith@gmail.com> wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> Hi, >>> >>>>>>>>>> >>> >>>>>>>>>> Apologies for the late comments, I seem to be missing IETF I= D >>> >>>>>>>>>> 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 belo= w >>> >>>>>>>>>> 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 loo= k >>> 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 hav= e >>> 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 o= r >>> 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 i= s >>> 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/NETCON= F >>> 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 additiona= l >>> >>>>>>>>>> prefixes, rounded up to the next shortest prefix length bit >>> boundary, >>> >>>>>>>>>> via an additional IA_PD option through the Prefix-Length Hin= t >>> >>>>>>>>>> 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 additiona= l >>> 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 th= e >>> 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 RFC >>> >>>>>>>>>> > 7084. >>> >>>>>>>>>> > >>> >>>>>>>>>> > The IETF datatracker status page for this Internet-Draft i= s: >>> >>>>>>>>>> > >>> 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 >>> >> --000000000000504e98061fa5ddf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right. We can=E2=80=99t necessarily control what the isp = does, unless as I suggested in another thread we have the router not actual= ly turn on IPv6 if a satisfactory prefix isn=E2=80=99t offered.=C2=A0
=

O= p wo 14 aug 2024 om 01:42 schreef Mark Smith <markzzzsmith@gmail.com>
Hi Ted,

On Wed, 14 Aug 2= 024, 00:32 Ted Lemon, <mellon@fugue.com> wrote:
That seems needlessly complicated th= ough. The presence of two IAIDs in the request is an indication that one is= enough.

Okay, so that's a binary sign that the CPE doesn't have = enough prefixes.

Requiring the server to do math on the set of requests it=E2= =80=99s not been able to satisfy seems like it doesn=E2=80=99t add anything= .=C2=A0

I'm looking at the refusa= l to provide a /48 even if asked for by a RFC 7084 CE as a policy decision = by the network operator, rather than the DHCPv6 server running out of addre= ss space to assign.

In other words, the DHCPv6 ser= ver would be configured to hand out e.g. PD /60s to all residential custome= rs regardless of the Perfix Hint value (and perhaps some other common stand= ard size to SOHO business customers).

I agree abou= t the maths. I was thinking that by asking for a "just big enough"= ; prefix it would provide data to the network operator how many /64 prefixe= s they need to additionally provide so they could resize their default size= d prefix to something bigger.

However,=C2=A0 I thi= nk it would be better and simpler to just ask for another prefix of the sam= e size as originally supplied. The DHCPv6 server would provide another pref= ix of that default or standard size out of the available PD pool.
=

If an ISP thinks 2=C2=A0 * default=C2=A0 PD prefix (or = n * default PD prefix) is too much space to give to a customer, then they c= ould shrink their default PD prefix size.

Regards,=
Mark.


=




=C2= =A0

Op di 13 aug 2024= om 05:36 schreef Mark Smith <markzzzsmith@gmail.com>
Hi Tim, Ted,

Great to say to send another PD request with a new IAID when there are
no prefixes left.

I've realised we might be talking past each other a bit regarding
requesting a /48.

Here's what I was thinking for the sequence of events that would
signal to an ISP that they're both not providing enough prefixes and also signalling how many additional prefixes they would need to
provide:

1. At initialisation, CPE makes an initial IA_PD request with no
Prefix-Length hint value (I assume this is where /48 has been
suggested).
2. ISP hands out a small PD prefix for the customer e.g. a /60.
3. Customer's network runs out of /64s because of e.g. too many links,<= br> or too many PD-per-host hosts.
4. Customer's CPE knows it needs another 6 /64s (as an example) and
then sends a new IAID with a Prefix-Length hint rounded up to the next
prefix bit boundary of a /61.
5. The ISP provides an additional suitably sized prefix to satisfy the
4. prefix hint request.

At 4., it could be simpler for the CPE to instead send a Prefix-Length
hint of the same size as supplied at 2 i.e. request another /60.

The size of the prefix hint at step 4 would provide to the ISP
evidence that they're both not providing enough initial address space,<= br> and also an indication of how much additional space they need to
provide, if their view is to only provide "enough" prefixes for w= hat
they think the customer needs rather than a simpler and assured
"always enough" of a /48.

Regards,
Mark.






On Fri, 9 Aug 2024 at 22:57, Timothy Winters <tim@qacafe.com> wrote:<= br> >
> Agree.
> On Fri, Aug 9, 2024 at 8:56=E2=80=AFAM Ted Lemon <mellon@fugue.com> wrote:
>>
>> It would also make sense to send a new IAID whenever we get a new = pd request and have no remaining prefixes to provide.
>>
>>
>> Op vr 9 aug 2024 om 08:53 schreef Timothy Winters <tim@qacafe.com>
>>>
>>> Hi Mark and Ted,
>>>
>>> I'll add a line asking for a second IA_PD with a unique IA= ID when sending Renew/Rebind messages.
>>>
>>> ~Tim
>>>
>>> On Fri, Aug 9, 2024 at 7:33=E2=80=AFAM Ted Lemon <mellon@fu= gue.com> wrote:
>>>>
>>>> The point of always asking for a /48 isn=E2=80=99t to sign= al something to the isp other than =E2=80=9Cgive me the biggest prefix you = are willing to provide.=E2=80=9D=C2=A0 If we don=E2=80=99t ask for a /48, w= e won=E2=80=99t get one.
>>>>
>>>> If we ask for additional prefixes, the customer may just n= ever see a problem, so I=E2=80=99m not sure how useful a signal this is, bu= t certainly it will tell the isp if there is demand for narrower prefixes, = and that isn=E2=80=99t a bad thing.
>>>>
>>>> Op vr 9 aug 2024 om 03:30 schreef Mark Smith <mar= kzzzsmith@gmail.com>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Fri, 9 Aug 2024, 12:20 Ted Lemon, <mellon@fugue.co= m> wrote:
>>>>>>
>>>>>> What=E2=80=99s the downside?=C2=A0 :)
>>>>>
>>>>>
>>>>> The concern I have is that I've seen obscure indiv= idual customer faults float around inside residential help desks for a numb= er of weeks being looked at by different people, rather than being escalate= d to network engineering as soon as they should be. Eventually it might get= escalated, or the customer leaves through frustration.
>>>>>
>>>>> For ISPs that aren't willing to give out large pre= fixes e.g., /60s, having the CPE ask for additional PD space when it runs o= ut would at least show up in DHCPv6 PD server logs. That network engineerin= g can directly look for that, and it would be absolute evidence of what pro= blem the individual customer is suffering from. It would also be direct evi= dence to the ISP that they're not handing out big enough prefixes to cu= stomers.
>>>>>
>>>>> If an ISP isn't going to honor an IA_PD request fo= r a /48, which I think would be unlikely for ISPs who aren't already ha= nding out /48s, then I don't think this ID specifying to always ask for= /48s is going to achieve anything. It won't signal to network engineer= ing that customers are running out of address space because it will hide th= at customers are running out.
>>>>>
>>>>> Regards,
>>>>> Mark.
>>>>>
>>>>>
>>>>>>
>>>>>> Op do 8 aug 2024 om 14:36 schreef Timothy Winters = <= tim@qacafe.com>
>>>>>>>
>>>>>>> Ted,
>>>>>>>
>>>>>>> On Thu, Aug 8, 2024 at 2:28=E2=80=AFPM Ted Lem= on <mellon@fugue.com> wrote:
>>>>>>>>
>>>>>>>> I think it's fine to try to get more p= refixes if you don't get the amount you asked for the first time, by ad= ding 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 wi= ll be asked to provide? If the ISP doesn't want to provide a /48, it wi= ll provide a smaller allocation, and that's perfectly fine.
>>>>>>>
>>>>>>> I was toying with that idea as well.=C2=A0 Jus= t asking for /48.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Aug 8, 2024 at 2:23=E2=80=AFPM Tim= othy Winters <tim@qacafe.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Mark,
>>>>>>>>>
>>>>>>>>> On Wed, Aug 7, 2024 at 7:06=E2=80=AFPM= Mark Smith <markzzzsmith@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Apologies for the late comments, I= seem to be missing IETF ID
>>>>>>>>>> announcements and WGLCs (I think t= rying 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 resi= dential environment:
>>>>>>>>>>
>>>>>>>>>> "LPD-2:
>>>>>>>>>> The IPv6 CE Router MUST assign a p= refix 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-user= s are very unlikely to look up
>>>>>>>>>> system error logs if they have a f= ault, 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 Interne= t faults.
>>>>>>>>>
>>>>>>>>> In this case I was thinking for the IS= P 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 he= lp desk staff looking up or asking
>>>>>>>>>> customers to look up system logs f= or error messages isn't a practice
>>>>>>>>>> either - and if you look at logs o= f some of these devices they're very
>>>>>>>>>> chatty so spotting error messages = is time consuming, which is counter
>>>>>>>>>> to a common helpdesk KPI of custom= er calls answered per hour.
>>>>>>>>>>
>>>>>>>>>> I also think in some cases CPE don= 't expose system logs - from memory,
>>>>>>>>>> Google's Nest CE routers don&#= 39;t have a system log available.
>>>>>>>>>
>>>>>>>>> I was thinking about getting system lo= gs from CWMP/USP/NETCONF from the ISP.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It would be better if engineering = were somehow directly notified of a
>>>>>>>>>> customer running out of prefixes a= nd 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.=C2=A0 Most ISPs fo= r 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 p= refix from the delegated prefix as
>>>>>>>>>> specified by L-2 [RFC7084]. If not= enough prefixes are available the
>>>>>>>>>> IPv6 CE Router MUST request the nu= mber of required additional
>>>>>>>>>> prefixes, rounded up to the next s= hortest prefix length bit boundary,
>>>>>>>>>> via an additional IA_PD option thr= ough 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 pr= efix. The IPv6 CE Router SHOULD log
>>>>>>>>>> a system management error." >>>>>>>>>
>>>>>>>>> For this solution, I have some questio= ns.
>>>>>>>>>
>>>>>>>>> Are you proposing that subsequent DHCP= v6 messages (Renew, Rebind) ask
>>>>>>>>> for additional IA_PDs, beyond what is = currently leased?
>>>>>>>>>
>>>>>>>>> OR are you proposing that the CE Route= r change what it's asking DHCPv6 Solicit or Request?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm not entirely convinced tha= t "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 th= e initial PD prefix provided by the
>>>>>>>>>> ISP.
>>>>>>>>>
>>>>>>>>> I like this idea the best.=C2=A0 I thi= nk 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 si= de, however that's the price of
>>>>>>>>>> treating IPv6 address space as if = it was scarce rather than abundant.
>>>>>>>>>> My advice to residential ISPs is t= o 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 res= idential customers /48s.)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mark.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 8 Aug 2024 at 06:39, <<= a href=3D"mailto:internet-drafts@ietf.org" rel=3D"noreferrer" target=3D"_bl= ank">internet-drafts@ietf.org> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Internet-Draft draft-ietf-v6o= ps-cpe-lan-pd-03.txt is now available. It is a
>>>>>>>>>> > work item of the IPv6 Operati= ons (V6OPS) WG of the IETF.
>>>>>>>>>> >
>>>>>>>>>> >=C2=A0 =C2=A0 Title:=C2=A0 =C2= =A0IPv6 CE Routers LAN Prefix Delegation
>>>>>>>>>> >=C2=A0 =C2=A0 Author:=C2=A0 Ti= mothy 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 de= fines requirements for IPv6 CE Routers to support
>>>>>>>>>> >=C2=A0 =C2=A0 DHCPv6 Prefix De= legation for redistributing any unused prefix(es)
>>>>>>>>>> >=C2=A0 =C2=A0 that were delega= ted to the IPv6 CE Router.=C2=A0 This document updates RFC
>>>>>>>>>> >=C2=A0 =C2=A0 7084.
>>>>>>>>>> >
>>>>>>>>>> > The IETF datatracker status p= age for this Internet-Draft is:
>>>>>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan= -pd/
>>>>>>>>>> >
>>>>>>>>>> > There is also an HTMLized ver= sion available at:
>>>>>>>>>> > https://datatracker.ietf.org/doc/html/draft-ietf-v= 6ops-cpe-lan-pd-03
>>>>>>>>>> >
>>>>>>>>>> > A diff from the previous vers= ion is available at:
>>>>>>>>>> > https://author-tools.ietf.org/iddiff?url2=3D= draft-ietf-v6ops-cpe-lan-pd-03
>>>>>>>>>> >
>>>>>>>>>> > Internet-Drafts are also avai= lable by rsync at:
>>>>>>>>>> > rsync.ietf.org::internet-draf= ts
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > _____________________________= __________________
>>>>>>>>>> > 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 v6op= s-leave@ietf.org
--000000000000504e98061fa5ddf2--