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

[Ted Lemon <[e-mail]>]

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]
>>>>>
>>>>