[dhcwg] Re: Request for review: draft-drew-dhc-v4-routed-p refix-00
Christian Giese <[email protected]>
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <CACrksOc3GJnXpaW36kdWAat+M8LN7KkRWnVvPoiRxiQsaLgoRA@mail.gmail.com> |
Hi Brendon, Thank you for putting this draft together. I really like the idea and completely agree that this addresses a valid use case for broadband access. This specific domain is always a bit tricky to navigate within the IETF since it touches multiple working groups, and there isn't an explicit WG dedicated to broadband. I had a similar experience with my own draft ( https://datatracker.ietf.org/doc/draft-giese-dhcp-rate-signaling/01/), which will now find its home in the INTAREA (Internet Area) working group, as is the case for many other broadband-related topics. The draft looks good overall, but I noticed one critical topic is currently missing: routing loop prevention. Assigning routes statelessly can cause dangerous routing loops. It is great that the draft already requires this option to only be sent if the client explicitly signals support via the Parameter Request List (PRL). However, there is no mechanism for the client to signal back to the network if its LAN interface goes down or if the address fails to install for some reason. If that happens, the client could end up bouncing traffic destined for that prefix back to the upstream router via its default route, creating a loop. To mitigate this, I suggest adding language that mandates clients supporting this option MUST install a discard (null) route for each received prefix. This acts as a safety net in addition to installing the prefix on a LAN link or loopback interface. This is also crucial if a client only expects one prefix but receives multiple; it must safely discard traffic to those unexpected addresses and never send it back. A couple of other suggestions for the draft: - Alternatives: Consider explicitly mentioning TR-069 (ACS) as one of the existing alternatives used in the industry today for this specific use case. - BNG / DHCP Relay Use Case: It would be highly beneficial to address the common scenario where a Broadband Network Gateway (BNG) acts as a DHCP relay agent. In this setup, the BNG could learn these delegated prefixes and install the necessary routes downstream toward the client. Looking forward to seeing how this draft progresses! Best regards, Christian Giese On Wed, Aug 12, 2026 at 9:58 AM Brendon Drew <brendon= [email protected]> wrote: > > Hi all, > > I've recently submitted an individual Internet-Draft, draft-drew-dhc-v4-routed-prefix-00, defining a DHCPv4 option for communicating IPv4 prefixes that are routed toward the requesting router. > > The draft is here: https://datatracker.ietf.org/doc/draft-drew-dhc-v4-routed-prefix/ > > The motivating use case is an ISP subscriber connection where the CPE receives an ordinary attachment address, potentially from the CGNAT shared address space, while one or more separate public IPv4 prefixes are routed toward that subscriber. > > The intention is to provide a generic way for the DHCP server to communicate, in effect, "this prefix is routed toward you", without requiring the routed prefix to be treated as an on-link subnet or used as the DHCP-assigned interface address. > > I would particularly appreciate feedback on: > > Whether there is existing DHCP functionality or prior work that already addresses this use case. > Whether the proposed option encoding is appropriate. > The proposed client and server behaviour. > Any operational, interoperability, or security issues I have overlooked. > Whether this work is appropriate for discussion within DHC, or would be better handled elsewhere within the IETF. > > This is my first Internet-Draft, so I am very much treating -00 as the start of the discussion rather than a finished proposal. > > Thanks in advance for any review or comments. > > Regards, > > Brendon Drew > > _______________________________________________ > dhcwg mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ dhcwg mailing list -- [email protected] To unsubscribe send an email to [email protected]