Replace deprecated ISC dhcp-relay (EOL) with something else
Open, WishlistPublicFEATURE REQUEST
Actions

Assigned To

None

Authored By

	Apachez
	Sat, Apr 20, 9:40 AM

Description

TLDR: I think it could be good to start looking at possible replacement of the ISC DHCP-relay agent (dhcrelay) used by VyOS since its EOL.

Longer:

It turns out that the ISC DHCP-relay agent (dhcrelay) used in VyOS have been deprecated for some time even if its still available in Debian repositories:

https://packages.debian.org/bookworm/isc-dhcp-relay

ISC has decided to stop maintaining the client and relay parts of isc-dhcp, and they will be removed after the 4.4.3 release, keeping only the server component. Please, consider using an alternative for isc-dhcp-relay (dhcrelay).

More information can be found in the ISC official announcement: https://www.isc.org/blogs/dhcp-client-relay-eom/

The above blog-post (last updated January 2022) states that:

There are forks of the ISC client and relay included in operating system packages, and there are also alternative client and relay implementations available. For example:

* Roy Marples offers a dhcpcd client.
* OpenBSD distributes a DHCP client apparently based on the ISC DHCP client, that has been updated by Henning Brauer. FreeBSD also packages that client.
* BusyBox distributes a very small client, suitable for embedded applications.
* OpenDHCP reportedly includes a relay. OpenWRT packages that and a DHCP forwarder maintained by Scott Logan.
* Dibbler, which is also no longer maintained, includes a client and relay as well as a server.
* ISC is also considering developing a new relay based on Kea DHCP code.

So far (April 2024) it seems that ISC have not created any DHCP-relay agent based on the KEA DHCP code.

Another option to evaluate (except for the list from the blog-post) would be to use dnsmasq for this task:

https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

--dhcp-relay=<local address>[,<server address>[#<server port>]][,<interface]
Configure dnsmasq to do DHCP relay. The local address is an address allocated to an interface on the host running dnsmasq. All DHCP requests arriving on that interface will we relayed to a remote DHCP server at the server address. It is possible to relay from a single local address to multiple remote servers by using multiple --dhcp-relay configs with the same local address and different server addresses. A server address must be an IP literal address, not a domain name. If the server address is omitted, the request will be forwarded by broadcast (IPv4) or multicast (IPv6). In this case the interface must be given and not be wildcard. The server address may specify a non-standard port to relay to. If this is used then --dhcp-proxy should likely also be set, otherwise parts of the DHCP conversation which do not pass through the relay will be delivered to the wrong port.
Access control for DHCP clients has the same rules as for the DHCP server, see --interface, --except-interface, etc. The optional interface name in the --dhcp-relay config has a different function: it controls on which interface DHCP replies from the server will be accepted. This is intended for configurations which have three interfaces: one being relayed from, a second connecting the DHCP server, and a third untrusted network, typically the wider internet. It avoids the possibility of spoof replies arriving via this third interface.

It is allowed to have dnsmasq act as a DHCP server on one set of interfaces and relay from a disjoint set of interfaces. Note that whilst it is quite possible to write configurations which appear to act as a server and a relay on the same interface, this is not supported: the relay function will take precedence.

Both DHCPv4 and DHCPv6 relay is supported. It's not possible to relay DHCPv4 to a DHCPv6 server or vice-versa.

The DHCP relay function for IPv6 includes the ability to snoop prefix-delegation from relayed DHCP transactions. See --dhcp-script for details.

Otherwise out of the box it would probably be a good thing if the OpenBSD fork can be used by VyOS (even if VyOS is linuxbased).

Details

Difficulty level: Unknown (require assessment)
Version: -
Why the issue appeared?: Will be filled on close
Is it a breaking change?: Unspecified (possibly destroys the router)
Issue type: Internal change (not visible to end users)

Event Timeline

Apachez created this task.Sat, Apr 20, 9:40 AM

Depending on how BSD dependent the OpenBSD one is, that might be the easiest drop-in replacement.
Otherwise I would suggest going for dnsmasq, since it is quiet small and well maintained. (not saying the other projects aren't being maintained, but I don't know about them)

When evaluating proper replacement (other than choosing the best one for the task) another thing to consider is, if possible, to select something that not everybody else uses in terms of if/when a vuln is found in that softrware then not ALL vendors are affected at once.

On the other hand a larger userbase should be able to find anomalies quicker than a software with a much smaller userbase.

A workaround for that might of course be to have the "package" being selectable through config but that would add additional work for the VyOS team to support multiple DHCP-relay agent solutions.

While I do somewhat agree on that, having more than one to choose from, for everything, is going to be a maintenance nightmare.
If you have just 5 things with 2 packages to choose from, you already have 32 different combinations to support.
Having something else than everyone else sounds great, but again, people are not going to switch due to a vuln being found - they are going to push for a fix for it instead.

So the better tested option should win (in my opinion)

Here is a post from an OPNsense forum administrator in august 2023 (dunno if the below is still valid for OPNsense):

https://forum.opnsense.org/index.php?topic=35207.msg170739#msg170739

The plan is to replace the current dhcrelay with a MVC/API equivalent but since isc-dhcp is EoL we re going to look for a different upstream provider. Since we haven't decided on one the actual "feature scope" for the future is a bit unclear. But I think this will be worked on for 24.1. Best to make a new feature request and we will see what we can do about it.

They switched to the OpenBSD fork of dhcrelay (I still have a router running OPNsense to test some stuff) 🙂

Perhaps Im missing something here but where is Option82 information included (injected into the DCHP-request reaching the DHCP-server)?

By the DHCP-snooping or the DHCP-relay?

If the OpenBSD dhcrelay have support for that but not Dnsmasq I would say we probably have a winner.

pasik added a subscriber: pasik.Sun, Apr 21, 8:25 PM

Viacheslav triaged this task as Wishlist priority.Mon, Apr 22, 9:05 AM

I just did a quick search - it doesn't seem like dnsmasq supports option 82 when acting like a relay.

I sent a question to ISC regarding https://www.isc.org/blogs/dhcp-client-relay-eom/ and:

ISC is also considering developing a new relay based on Kea DHCP code.

I received a reply today:

At the moment, we have no sponsorship for developing a relay, and no spare engineers to assign to it.  I did just recently get a request for a relay, and I am corresponding with a guy whose organization might fund initial development. (that’s why I delayed answering you)

I am not sure his application is particularly mainstream, however.  I explained that there were two approaches: one that would add this to Kea, and one that would create a standalone relay, that might be simpler and smaller.  He hasn’t responded about whether they are actually serious about funding development yet, and I consider this to be sort of a longshot. They are a commercial software company and although they use open source in their products, they may not be willing to fund open source. 

Anyway, if you have any specific requirements, I invite you to add them to this issue in our Gitlab:

https://gitlab.isc.org/isc-projects/kea/-/issues/1869

So most likely we will have to find another implementation.

Now the question is - can dnsmasq be used (I haven't tested it), or should we look in the same direction as OPNsense?

Replace deprecated ISC dhcp-relay (EOL) with something elseOpen, WishlistPublicFEATURE REQUESTActions

Description

Details

Event Timeline

Replace deprecated ISC dhcp-relay (EOL) with something else
Open, WishlistPublicFEATURE REQUEST
Actions