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

[Brendon Drew <[e-mail]>]

Hi Christian,

Thanks very much for taking the time to read through the draft and provide such detailed feedback.

I agree that the potential routing loop is a real issue. If a client accepts a routed prefix but does not have a valid local or downstream route for it, traffic could fall back to the default route and be sent straight back towards the provider. Requiring a discard route covering the received prefix, with valid local or more-specific routes taking precedence, seems like a sensible safeguard. I'll incorporate that into the next revision.

Your point about the BNG acting as the DHCP relay is also particularly interesting.

My intention has been to leave the mechanism by which the DHCP server determines which routed prefixes belong to a subscriber out of scope. That information could come from RADIUS, static provisioning, an OSS/BSS, or another provider-specific mechanism.

However, I can see value in documenting that a BNG acting as the relay may observe the Routed Prefix option in the server response and associate the returned prefix with the relevant subscriber attachment. An implementation could potentially use that information when installing subscriber forwarding state, while leaving the actual route installation and provisioning mechanism outside the scope of the DHCP option itself.

I also agree that TR-069/ACS should be mentioned as an existing way of achieving automatic configuration. I think there is an important distinction, though, in that TR-069 requires a management relationship between the provider and the CPE and depends on the required configuration being exposed through the device's management model.

That may be entirely appropriate for provider-managed CPE, but it is not always available or desirable, particularly with customer-owned or otherwise unmanaged equipment.

The intent of the Routed Prefix option is instead to provide a narrowly scoped standards-based capability. The provider communicates the network state — essentially, "this prefix is routed toward you" — without requiring a general management interface into the CPE. A device can selectively implement this DHCP capability without granting the provider broader management access.

Manual configuration, TR-069, and other provisioning methods would remain completely valid. The purpose of the option is simply to provide an interoperable mechanism for automatically communicating the routed-prefix information where both sides support it.

I'll work these points into -01.

Thanks again for the review. 

Regards,

Brendon Drew

---

From: Christian Giese <christian=[e-mail]>
Sent: Wednesday, August 12, 2026 7:21:45 pm
To: Brendon Drew <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [dhcwg] Request for review: draft-drew-dhc-v4-routed-prefix-00

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/" rel="nofollow">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/" rel="nofollow">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]