[v6ops] Re: I-D Action: draft-ietf-v6ops-cpe-lan-pd-03.txt

[Ted Lemon <[e-mail]>]

Right. We can’t 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’t offered.

Op wo 14 aug 2024 om 01:42 schreef Mark Smith <[e-mail]>

> Hi Ted,
>
> On Wed, 14 Aug 2024, 00:32 Ted Lemon, <[e-mail]> 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’s not been able
>> to satisfy seems like it doesn’t 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 (and
> 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 too
> 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 <[e-mail]>
>>
>>> 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 <[e-mail]> wrote:
>>> >
>>> > Agree.
>>> > On Fri, Aug 9, 2024 at 8:56 AM Ted Lemon <[e-mail]> 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 <[e-mail]>
>>> >>>
>>> >>> 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 AM Ted Lemon <[e-mail]> wrote:
>>> >>>>
>>> >>>> The point of always asking for a /48 isn’t to signal something to
>>> the isp other than “give me the biggest prefix you are willing to
>>> provide.”  If we don’t ask for a /48, we won’t get one.
>>> >>>>
>>> >>>> If we ask for additional prefixes, the customer may just never see
>>> a problem, so I’m not sure how useful a signal this is, but certainly it
>>> will tell the isp if there is demand for narrower prefixes, and that isn’t
>>> a bad thing.
>>> >>>>
>>> >>>> Op vr 9 aug 2024 om 03:30 schreef Mark Smith <
>>> [e-mail]>
>>> >>>>>
>>> >>>>> Hi,
>>> >>>>>
>>> >>>>> On Fri, 9 Aug 2024, 12:20 Ted Lemon, <[e-mail]> wrote:
>>> >>>>>>
>>> >>>>>> What’s 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 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 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 problem
>>> the individual customer is suffering from. It would also be direct evidence
>>> to the ISP that they're not handing out big enough prefixes to customers.
>>> >>>>>
>>> >>>>> 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, then
>>> I don't think this ID specifying to always ask for /48s is going to achieve
>>> anything. It won't signal to network engineering that customers are running
>>> out of address space because it will hide that customers are running out.
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>> Mark.
>>> >>>>>
>>> >>>>>
>>> >>>>>>
>>> >>>>>> Op do 8 aug 2024 om 14:36 schreef Timothy Winters <[e-mail]
>>> >
>>> >>>>>>>
>>> >>>>>>> Ted,
>>> >>>>>>>
>>> >>>>>>> On Thu, Aug 8, 2024 at 2:28 PM Ted Lemon <[e-mail]>
>>> 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 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.
>>> >>>>>>>
>>> >>>>>>> I was toying with that idea as well.  Just asking for /48.
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On Thu, Aug 8, 2024 at 2:23 PM Timothy Winters <[e-mail]>
>>> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>> Hi Mark,
>>> >>>>>>>>>
>>> >>>>>>>>> On Wed, Aug 7, 2024 at 7:06 PM Mark Smith <
>>> [e-mail]> 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, <[e-mail]>
>>> 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 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=draft-ietf-v6ops-cpe-lan-pd-03
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > Internet-Drafts are also available by rsync at:
>>> >>>>>>>>>> > rsync.ietf.org::internet-drafts
>>> >>>>>>>>>> >
>>> >>>>>>>>>> >
>>> >>>>>>>>>> > _______________________________________________
>>> >>>>>>>>>> > v6ops mailing list -- [e-mail]
>>> >>>>>>>>>> > To unsubscribe send an email to [e-mail]
>>> >>>>>>>>>>
>>> >>>>>>>>>> _______________________________________________
>>> >>>>>>>>>> v6ops mailing list -- [e-mail]
>>> >>>>>>>>>> To unsubscribe send an email to [e-mail]
>>> >>>>>>>>>
>>> >>>>>>>>> _______________________________________________
>>> >>>>>>>>> v6ops mailing list -- [e-mail]
>>> >>>>>>>>> To unsubscribe send an email to [e-mail]
>>>
>>