DHCP allows the server to forcibly send options to clients, even when they aren't requested.

This is supported in ~all other DHCP servers, including ISC ("dhcp-parameter-request-list") and dnsmasq ("--dhcp-option-force").

There are a lot of use cases, including:
- Setting pxeboot and netboot parameters
- Telling Android clients to use less bandwidth ("ANDROID_METERED" via option 43)
- Setting specific routes, e.g. for client isolation, by sending Option 121
- Setting interface MTUs (for jumbo frame networks, or networks with downstream encapsulation, etc.)

This feature has been requested a few times on the forum, and is the only reason we can't currently use Mikrotik's DHCPd -- and instead have to run our own dnsmasq installation.

Would love to see it in ROS v6 or v7.

+10000

I need this feature too

+10000

I need this feature too

+100000

I need this feature too

+1 for 'Force sending of DHCP options to clients'

+1 for 'Force sending of DHCP options to clients'

Can't boot pxelinux without 209 and 210 options, but mikrotik don't force it.

+1
really need this feature.
other routers like merlin, openwrt, ddwrt etc all support this feature.
really hope mikrotik can support it too.
thanks!

+1

This feature REALLY DOES SOMETHING to my home network.
My IPTV box need to be sent the option 60 and option 125.


Big thanks!!!

+1

I need DHCP option 160 for Captive Portal ID (https://tools.ietf.org/html/rfc7710)

Unclear. How is this different from the already available option here?

According to what OP wrote, it differs in that this options are only sent if client explicitly requests them. And it seems there are DHCP clients in the wild that do respect some options on receive even if they don't requested them.

I do not think that forcing all options to all clients is a good idea, however conditional vendor specific options based on vendor class id (opt 60), would be nice feature to have.

It is very helpful for some iptv box in china will check the option 125 value but it do not send the option request, some dhcp server such as dnsmasq widely used in other system as merlin,openwrt,tomato also support ""force option", we hope ros can support the feature so I could no longer need another ddwrt based router to provide dhcpd as I used now.

+1 That would be a great feature for us. We need to force send the DHCP Option 43 to our CPEs, because some CPEs are not requesting it explicitly. I think it should be an optional checkmark for every DHCP option. Here the code what we are doing on our isc-dhcp:

Isn't this in general a case of "my client is broken so please fix your server"?
It would be better to send change requests to the client manufacturer to tell them to request the options they support in the reply.
(after all, that is the idea behind the protocol)

Isn't this in general a case of "my client is broken so please fix your server"?
It would be better to send change requests to the client manufacturer to tell them to request the options they support in the reply.
(after all, that is the idea behind the protocol)

When you need it , it will be really useful.
And that's the only reason why i don't use ROS as the system of my main Router.
In China millions user need to force add option-125 to activate our IPTV devices, and UBNT OpenWRT dnsmasq both support force-dhcp-options to against our ISP.
Only ROS can't do this.

Isn't this in general a case of "my client is broken so please fix your server"?
It would be better to send change requests to the client manufacturer to tell them to request the options they support in the reply.
(after all, that is the idea behind the protocol)

When you need it , it will be really useful.
And that's the only reason why i don't use ROS as the system of my main Router.
In China millions user need to force add option-125 to activate our IPTV devices, and UBNT OpenWRT dnsmasq both support force-dhcp-options to against our ISP.
Only ROS can't do this.

Yes，I am from China.
Because of the china telecom 4K IPTV devices need force option-125.
I have google "ros force dhcp option" since 2016.
Now time is 2018 , it disappointed me again .

It is very helpful for some iptv box in china will check the option 125 value but it do not send the option request, some dhcp server such as dnsmasq widely used in other system as merlin,openwrt,tomato also support ""force option", we hope ros can support the feature so I could no longer need another ddwrt based router to provide dhcpd as I used now.

agree
I use Raspberry Pi with dnsmasq to be the dhcp server.

Because of the china telecom 4K IPTV devices need force option-125.
I have google "ros force dhcp option" since 2016.
Now time is 2018 , it disappointed me again .

Ok but why don't you request china telecom to put the option 125 request in the DHCP request packet?
That would be the normal way of handling a DHCP option.
When china telecom does not honor this request in 2 years time, you can write them that you are disappointed.
But writing here that you are disappointed that MikroTik is not supporting devices that break the protocol seems a little unfounded.
(even when other manufacturers do that)

+1

Hello, I need this feature, too.
I have an Service Access Router from Nokia, this Router would discover the IP address from the dhcp server. But it need's the option 58 and 59 in the offer.
I've wiresharked the requests and don't see the options, so I added to the options in the list and make an optionset and add this to the the dhcp server configuration.
But the ROS didn't add it to the offer.
I tested it with an other option like 121 "classless", and this works. It will be offered in the response without the client didn't requested it.

Are there any hope that these functions will be available in next ROS Versions or did I some mistakes?

Many thanks!

+1;

+1
I run around 100 small Mikrotiks for just simple tasks and now I bought a bigger one where I have 100 devices connected wich need the DHCP-Options to be forced without request.
Can any developer please add this feature to DHCP-Server

Because of the china telecom 4K IPTV devices need force option-125.
I have google "ros force dhcp option" since 2016.
Now time is 2018 , it disappointed me again .

Ok but why don't you request china telecom to put the option 125 request in the DHCP request packet?
That would be the normal way of handling a DHCP option.
When china telecom does not honor this request in 2 years time, you can write them that you are disappointed.
But writing here that you are disappointed that MikroTik is not supporting devices that break the protocol seems a little unfounded.
(even when other manufacturers do that)

china telecom doesn`t want you to use your own router ,so they make the dhcp option problem .
you can use the router , which they provide and under their supervision, without the dhcp option problem.
You have limited access to their router . you only can change the Lan ip ,dhcp pool ,ssid and pw.
static pat ? no
vpn ? no
firewall ? no
qos ? no

It should be super to select wich option to FORCE in the DHCP server settings

+1

Because of the china telecom 4K IPTV devices need force option-125.
I have google "ros force dhcp option" since 2016.
Now time is 2018 , it disappointed me again .

Ok but why don't you request china telecom to put the option 125 request in the DHCP request packet?
That would be the normal way of handling a DHCP option.
When china telecom does not honor this request in 2 years time, you can write them that you are disappointed.
But writing here that you are disappointed that MikroTik is not supporting devices that break the protocol seems a little unfounded.
(even when other manufacturers do that)

china telecom doesn`t want you to use your own router ,so they make the dhcp option problem .
you can use the router , which they provide and under their supervision, without the dhcp option problem.
You have limited access to their router . you only can change the Lan ip ,dhcp pool ,ssid and pw.
static pat ? no
vpn ? no
firewall ? no
qos ? no

Not only in China, see the same behavior with Telus 4K set-top box, not sure if that apply to all set-top box or just new install in my area

+10000

Please give this option!!!

Alternatively, if Mikrotik can support dhcp option 55 which allows defining which options to send, we can work around this issue. But it is not possible either.

When there is some option that fixes your problem, you can add it. That has been possible for a long time.

It`s end of 2019 , still don`t have the force dhcp option . I don`t think it`s a difficult feature .Please add it .

Is this being planned in a feature?
Really start to need this. Hate it to have to run a separate DHCP server in the network only for forcing some options.

Now it's 2020. Does Mikrotik have any plan on this feature? without this, I have to run a separate DHCP server in my LAN to provide required feature. Really pls Mikrotik to consider this requirement.

I need to force option 252 out so that I can let the devices know to use a new or different web proxy. So anything MikroTik can do, sooner the better.

+1 - seriously needed.

Since 2 years i wait for this additional feature, I'm already waiting for forcing dhcp options.

Thank you to the development of the RouterOS-Team and Happy Eastern 2020 and keep health without Corona!

+1 feature request

+1 we need this feature as well!

The new RFC7710-Draft states this as well:

DHCP servers MAY send the Captive Portal option without any explicit request.

https://tools.ietf.org/html/draft-ietf- ... 7710bis-11

Official answer from Mikrotik-support:

Hello,
Thank you for your request. We will consider implementing such an option.
Best regards,

Fingers crossed!

I have found that quite a lot of Android clients won't request DHCP option 121, classless static routes and I am not able to push routes to them unless explicitly forced by the DHCP server. I am quite surprised this has not been implemented in RouterOS after all this years...

I am quite surprised this has not been implemented in RouterOS after all this years...

In fact you should be more surprised that the Android developers, after all those years, could not be bothered to put an option request in their DHCP request for all options that they can process. After all, that is the standard for the DHCP protocol.

I partecipated to this discussion and agree with both points of view.
a) the client device SHOULD follow the dhcp protocol correctly and ask the right option.
b) the DHCP server could force some options to fix broken clients.

I understend the view "the client is broken, please fix the server".
The reality is that a lot of manifacturers simply IGNORE the correct DHCP protocol's behaviour. For example AVM on fritzbox receives opt43 but NOT ASKS FOR IT. So we cannot provision AVM devices on a network where the mikrotik is the dhcp server, and it is really a bad situation for us. We use a separate DHCP server, or in some situations, the relay.

It would be PERFECT for a RouterOS to have the FORCE OPTION flag... and maybe a vendor specific options as a real DHCP server. It will be a wonderful move to have more and more place in the networks.

This simple feature has been requested since 2013 in this thread viewtopic.php?t=75443,
And it's almost 2021, 8 years passed, really disappointed!

I wrote to support today.
they answered me:


----------
Hello,
Thank you for your request. We will implement such feature support in one of the next RouterOS version 7 beta releases:
https://mikrotik.com/download.
Best regards,
Artūrs C.