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

[Timothy Winters <[e-mail]>]

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