Feature Request | DHCP-Relay Hook

RouterOS General
1

Hi,

I would like to suggest adding scripting hooks to the RouterOS DHCP Relay functionality, allowing scripts to be executed when DHCP messages are received and/or forwarded.

Current setup

We operate an access network where customer traffic reaches a CCR2004, which acts as a DHCP Relay and forwards DHCP requests to a central DHCP server.

This works very well because the relay adds the required information about the access interface/customer, allowing the DHCP server to identify where the request originated.

The basic principle in our network is:

Clients must obtain their IP address via DHCP. Statically configured IP addresses are not permitted.

There is, however, one problem that is difficult to solve reliably at the router.

A customer can manually configure an IP address that belongs to the DHCP pool. Since the DHCP server does not necessarily know that this address is already in use, it may later assign the same address to another client.

Proposed feature

It would be very useful if DHCP Relay could execute RouterOS scripts for DHCP messages passing through the relay.

Ideally there would be hooks for both directions:

  • Client -> Relay -> DHCP Server

  • DHCP Server -> Relay -> Client

The script should have access to DHCP information such as:

  • DHCP message type (DISCOVER, OFFER, REQUEST, ACK, NAK, RELEASE, RENEW, etc.)

  • Client MAC address

  • Assigned/requested IP address

  • Relay/interface information

  • Option 82 information

  • Server identifier

  • Transaction ID

  • Incoming/outgoing interface

For example, something conceptually similar to:

dhcp.message.type
dhcp.client.mac
dhcp.client.ip
dhcp.relay.interface

The most important event for us would be receiving an ACK from the DHCP server.

At this point RouterOS knows that:

IP 192.0.2.123 has legitimately been assigned to MAC AA:BB:CC:DD:EE.

A script could then automatically enforce this binding.

Example use cases

After receiving an ACK, we could dynamically create/update an IP/ARP binding so that the assigned IP address is associated with the MAC address that actually received the DHCP lease.

This would at least prevent another device using the same IP address with a different MAC address from receiving downstream traffic.

For upstream enforcement, scripting could create/update a firewall rule implementing the equivalent of:

if src.ip == 192.0.2.123 and src.mac != AA:BB:CC:DD:EE:FF -> DROP

This would allow both directions to be protected:

  • Downstream: IP -> expected MAC binding

  • Upstream: expected MAC -> IP binding

For more advanced access networks, the script could even call an API or external system to update an ACL on a downstream access switch.

Why implement this in DHCP Relay?

The DHCP Relay is in a particularly useful position because it sees both sides of the transaction.

It sees the original client request, including the access interface/customer information, and later sees the DHCP server's ACK before forwarding it back to the client.

Therefore, when processing an ACK, RouterOS has all the information required to establish an authoritative:

interface/customer + MAC address + IP address binding

The important part of this feature request is not necessarily implementing IP source guard directly in RouterOS DHCP Relay.

A generic pre-/post-processing scripting interface for DHCP Relay packets would already make it possible to implement many different policies ourselves.

Something similar to firewall/mangle processing, but exposing DHCP-specific variables to RouterOS scripting, would be extremely useful.

Possible implementation

For example, DHCP Relay could provide script properties such as:

  • on-client-message

  • on-server-message

or perhaps more generic:

  • on-receive

  • on-forward

with variables describing the DHCP packet and its direction.

It would also be useful if the script could distinguish between DISCOVER, OFFER, REQUEST, ACK, NAK, RELEASE, etc.

The script would not necessarily need to modify the DHCP packet itself. Even a read-only event hook would already enable a lot of useful functionality.

Does RouterOS already provide some mechanism that could achieve this with DHCP Relay, or would this require a new feature?

If not, I think DHCP Relay scripting hooks could be useful not only for this particular use case, but generally for subscriber/access networks where DHCP is used as the authoritative source for IP/MAC/customer bindings.

2

Those two lines were more than enough. The rest just puts off considering the first two lines.
If you want to submit the request, you need to contact support;
the programmers do not read the forum.

3

Your request is very particular to your setup and quite complicated. I would say zero chance it gets implemented.

You may know that the DHCP server itself has the capability (without scripting) to create a static ARP entry for leases it has given out. Combined with the interface-level capability of "ARP reply only" this creates a capability to only serve DHCP-assigned addresses.

The DHCP also has a capability to run a script when it assigns leases, and I suggest that you create some construct internal to your network where the DHCP server creates a static ARP entry on your CCR2004 (using some way of remote admin, i.e. API or SSH) so you have a similar function in your network.

4

Fair point, but I intentionally put the two-line summary at the very top for exactly that reason.

The additional context is there for people who actually want to understand the use case and the reasoning behind the feature request. It also makes the topic much more useful for search engines and for people finding the thread later with a similar problem.

So the structure was intentional: short summary first, detailed explanation afterwards.

Regarding support: yes, I can submit the actual feature request there as well. I still think discussing and documenting the idea publicly can be useful, especially if others have similar use cases or know of an existing RouterOS mechanism that could achieve the same thing.

5

I agree that having the DHCP server configure the appropriate rules on the requesting router (DHCP relay) via the API would be a perfectly workable and reasonable solution. That is actually how I am going to implement it for now.

There is even one advantage to doing it this way: renewals normally go directly to the DHCP server and no longer pass through the relay. Therefore, the DHCP server also has the complete lease lifecycle and can remove the corresponding static ARP entry from the CCR2004 via the API when a lease is released or expires.

A solution implemented only on the MikroTik DHCP relay itself would not have that information. It could create or update static ARP entries when it sees an ACK, but it could not reliably know when an existing entry should be removed if subsequent renewals no longer pass through the relay.

So yes, handling the binding centrally on the DHCP server and synchronizing it to the appropriate relay router via API is probably the more complete solution for this particular use case.

6

I forgot to add that I agree
and that you did the right thing by posting it publicly.
I was more focused on getting you to open the ticket,
so that this topic wouldn't go to waste.

7

Update: I have submitted this DHCP Relay scripting feature request directly to MikroTik Support as well.

Ticket ID: SUP-225437

So the request is now officially filed with MikroTik in addition to the discussion here.

8

Well, for example I have asked to have a delay implemented when an IPsec association fails. What I observe with certain ISP NAT routers inbetween a pair of MikroTik routers creating an IPsec tunnel is that the NAT and/or the "firewall" in those routers confuses the IPsec and the association forever fails to establish. When I could tell the IPsec to keep its mouth shut for a while, the NAT entry will expire and after that it succeeds.

But it was found to be too specific and I had to implement it using scripting.