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

Michael Richardson <[email protected]> Fri, 14 Aug 2026 14:11:10 -0400
Newsgroups	gmane.ietf.dhc
Message-ID	<[email protected]>
Brendon Drew <[email protected]> wrote:
    > 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.

Sure, moving the v4-chairs around on the v4-ship before it goes down :-)
Still, in the R&D DC that I operate, we /32 route v4 across RFC1918 assigned
links.   The v4/32 is configured as an alias on lo, and the "src" for
outgoing default route is that v4.  This maximizes v4 usage (no .0, no .255),
and lets us spread v4 out across any number of subnets/projects.

Reading the document, I see that this is a prime part of your motivation.
So that answers my initial "WHY?" in a positive way.

This process is manual right now, and I guess we could use this mechanism
instead.

I was unaware of RFC656, is it implemented anywhere?
Is there any way/reason to attempt to remediate that option?
I have not compared your option formats yet to DHCPv6-PD, but I'm
guessing/hoping that they look similiar?
Or to put it another way: if we just did DHCPv6-PD, but used v6-mapped-v4
notation, would it be equivalent?

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

At the surface, this seems reasonable, but in practice, this is 30 years too late.
I think that a better motivation is cloud/VM systems.

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

The DHC WG is the right place.
Yes, telling INTAREA is a good thing.

    > This is my first Internet-Draft, so I am very much treating -00 as the
    > start of the discussion rather than a finished proposal.

Good.

** Noting: writing an RFC does not cause it to become implemented **

So while this is a good addition, absent some interest to implement it, I
don't see the point.    My home ISP statically routes an IPv4/28 to me, and
it would be lovely to be able to use this.

I would love to see code for dnsmasq (as a server), and for NetworkManager (as a client).
You may also want to consider if you need RADIUS Attributes such that an ISP
when responding to a DSL subscriber (PPPoE) is able to communicate the extra
prefixes.


--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 487 B)