[dhcwg] Re: Request for review: draft-drew-dhc-v4-routed-prefix-00

[Christian Giese <[e-mail]>]

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=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]