Right now, dhcpv6_pd_min_len is zero, meaning any request would be
accepted (as long as it fits what we have available).
That means that with a /56 (a common residential scenario), a downstream
router can request a /57 and gobble up 1/2 of the available address
space. Even a default dhcpv6_pd_min_len value of 60 means that we'd
support 15 PDs in total.
So let's err on the side of caution and set /62 as the default, people
who want larger allocations can easily override the default.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/357
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The current limit of [1,62] doesn't really seem to be justified. With
things like RFC9762 (DHCPv6-PD preferred), it isn't unlikely that we'll
see more DHCPv6-PD requests in the future, and not just from actual
routers.
The smallest realistic PD that can be allocated is a /64, so make that
the minimum.
Also, fix a bug in the logic (note that the PD_MIN_LEN_MAX actually
isn't enforced).
Closes: #352
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/357
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
A "folder" is a Windows concept, rename the cfg option from "piofolder"
to "piodir", which will also make it more consistent with other cfg
options.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/333
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This is inspired by @Kasoo's work in PR #234, but slightly different.
The "ip" option now takes "ignore" as a value , but it'll only disable
DHCPv4 for a matching client.
Similarly, the "hostid" option now also understands "ignore", which will
disable DHCPv6 for a matching client.
Of course, this is all based on client-reported MAC
addresses/DUIDs/client IDs/etc, so it's not actually a security feature.
Closes: https://github.com/openwrt/odhcpd/pull/234
Closes: https://github.com/openwrt/odhcpd/issues/198
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/303
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
With this change, the "hostsfile" option is changed to a "hostsdir"
option. If set, per-interface hosts files will be written to the
directory (this requires some changes to the UCI defaults in the OpenWrt
repo). This prevents the hostnames from one interface "leaking" into
other interfaces, which might not be desirable e.g. when running several
instances of dnsmasq.
dnsmasq already supports reading several hosts files from a directory
(via the "--hostsdir=" option), so some changes to dnsmasq's init script
will also be necessary (depending on whether the user wants dnsmasq to
support resolution of all hosts or just the host on a given interface).
Making hosts files (rather than odhcpd's state file) the primary
interface for dnsmasq to be made aware of active leases/hostnames is
also an important first step towards making the statefile properly
private (the other important consumer is LuCI, via its rpcd plugin),
which is necessary if we want to support persisting leases across
restarts of odhcpd (or even reboots, if writing to flash is deemed
acceptable) in the future (since I want to extend the state file to
capture the full state of leases so that they can be properly
reconstructed).
In addition, the use of "--hostsdir=" in dnsmasq would make the
"leasetrigger" unnecessary, since it just restarts dnsmasq to make it
aware of the changes to the hostsfile. That still leaves the case when
dnsmasq uses multiple instances and only wants to read a specific
hostsfile (which, AFAIK, doesn't support automatic detection of when
that specific file changes).
Closes: https://github.com/openwrt/odhcpd/issues/237
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/302
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The RFC defines the P flag for use within PIOs, and defines its meaning
as "purely a positive indicator, telling nodes that DHCPv6 PD is
available and the network prefers that nodes use it".
The RFC abstract lays out:
The (P) flag is used to indicate that the network prefers that clients
use the deployment model in RFC 9663 instead of using individual
addresses in the on-link prefix assigned using SLAAC, or DHCPv6 address
assignment.
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Link: https://github.com/openwrt/odhcpd/pull/301
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
LuCI has already been updated so that the "dhcpv4" option is exposed in
the UI and the option also gets set when the user clicks the "Set up
DHCP Server" button in the "DHCP Server" tab in the interfaces view.
Furthermore, there are instructions in the UI to enable the DHCPv4
server on a per-interface basis.
Finally, the odhcp defaults script (in the openwrt repo) also sets the dhcpv4
option, as necessary.
People who don't use LuCI but prefer the cmdline should presumably be able to
figure out that the dhcpv4 option needs to be set (if it isn't already), so
remove the "legacy" option.
This supersedes this PR:
https://github.com/openwrt/odhcpd/pull/275
Note that the "maindhcp" option is used by both dnsmasq and odhcpd to control
which of them handles DHCPv4, and is now exposed in the LuCI UI as well, so it
cannot be removed.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/294
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
I'm not 100% sure about whether this option will get automagically set e.g. by
the data that is returned from the netifd ubus call, but this documentation is
better than nothing.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/294
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Might see little practical use in the field, but the option is there, so let's
document it. Also align the documentation for the "ra_slaac" option.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/294
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The option is marked as deprecated since 2019 in the odhcpd code base.
It has been superseded by the "ra_flags" and "ra_slaac" options, which provide
more fine-grained control, and having several different configuration options
controlling the same thing is a potential source of confusion.
The option is, and has always been, undocumented.
Furthermore, I've grepped through the LuCI source tree, and it contains logic
to control "ra_flags" and "ra_slaac", but no references to "ra_management" at
all.
The only references in the openwrt tree is inside the dnsmasq init script, but
that is a dnsmasq-internal thing and, again, the option cannot be set from
LuCI, meaning I think we can assume that it has limited usage.
So, remove it.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/294
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
As noted in the previous commit, Homenet is defunct.
The only users of these two options are Homenet/hnetd, so remove the options,
which results in a nice cleanup to src/dhcpv6-ia.c.
We also need to update the Makefile in the main OpenWrt repo.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/294
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The "filter_class" option was first introduced as part of the effort to support
the Homenet Control Protocol (HNCP, RFC7368, RFC7788). At first it was
hardcoded to filter out the user class "HOMENET", and later it was made
configurable, but there appears to be no other use-cases than Homenet. There's
also legacy comments in the odhcpd code pointing at filtering out homenet user
classes (the comments are misleading since "filter_class" is not set by
default).
Homenet is effectively dead. The "hnetd" daemon last saw any code changes in
2018, doesn't compile with current versions of GCC, and was removed from
OpenWrt altogether in 2025 [1].
The OpenWrt wiki also notes [2] that HNCP is effectively dead, and that the
upstream website [3] is gone.
Searching for the Homenet Control Protocol mostly returns results pointing
either:
a) at the standards
b) at the OpenWrt/hnetd project
c) at various posts stating that it is dead
The IETF working group for Homenet is no more, and Éric Vyncke (Area Director
for the Internet Area of the IETF) mentioned wanting to avoid Homenet pitfalls
[4] (page 11) in the future of IPv6 autoconfig.
The current implementation is also contrary to the spirit of the RFCs
introducing the option (RFC3004 - DHCPv4; RFC8415, §21.15 - DHCPv6) where it is
described (example from RFC8415) as follows:
The information contained in the data area of this option is
contained in one or more opaque fields that represent the user class
or classes of which the client is a member. A server selects
configuration information for the client based on the classes
identified in this option. For example, the User Class option can be
used to configure all clients of people in the accounting department
with a different printer than clients of people in the marketing
department.
I.e., it's meant to be used in a manner similar to "tags" in dnsmasq.
Finally, the option has been undocumented for the whole existance of odhcpd.
So, remove this option.
[1] 85b868b341
[2] https://openwrt.org/docs/guide-user/network/zeroconfig/hncp_configuration
[3] https://web.archive.org/web/20180831161552/http://homewrt.org/start
[4] https://ripe87.ripe.net/wp-content/uploads/presentations/102-20231130-RIPE-87-IPv6-from-IETF.pdf
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/294
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
I did a quick dig through the source, and these are all the options that are
supported but which do not have any corresponding documentation. Subsequent
patches will go through the options one by one.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/294
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Allow the use of a (stable) globally configured DUID as the server identifier.
Currently, odhcpd generates a per-interface DUID-LL, meaning that the DUID is
not stable across interfaces and will change if/when hardware changes.
Supporting a stable DUID brings odhcpd's behaviour in line with RFC8415, §11:
...The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server. That is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change as a result of a change in
the device's network hardware or changes to virtual interfaces...
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/274
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This implements RFC4833 - supplying timezone information to clients that
request them. Both forms are possible, when timezone is configured in
the uci system settings (the luci GUI saves both forms to the config).
e.g.
```
config system
option zonename 'America/Puerto Rico'
option timezone 'AST4'
```
There is also an odhcpd flag to disable their use, set in uci dhcp.
```
config odhcpd 'odhcpd'
option enable_tzdb '0'
```
Once enabled, the options, when requested, are sent:
NEW_POSIX_TIMEZONE 41 // 'AST4'
NEW_TZDB_TIMEZONE 42 // 'America/Puerto_Rico'
Wireshark disassemble of options sent to client:
```
...
Time Zone Database
Option: Time Zone Database (42)
Length: 19
TZ-database: America/Puerto_Rico
Time Zone
Option: Time Zone (41)
Length: 4
Time-zone: AST4
```
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Link: https://github.com/openwrt/odhcpd/pull/284
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This patch allows for multiple per-client DHCPv6 DUIDs. One use-case for
multiple DUIDs is dual-boot hosts, where e.g. Windows creates it's own DUID and
Linux (say, systemd-networkd) creates it's own DUID, and the two cannot be
synced in a simple manner. This also makes DUIDs similar to multiple per-host
MAC addresses (which is already supported by dnsmasq for DHCPv4 leases).
Note that the "old" behaviour is still kept, in other words, where a
simple DUID (as opposed to a "DUID%IAID") static association is defined,
the address will be given out on a first-come-first-serve basis.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/255
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Extend the string format for duids to alternatively support
"<duid>%<iaid>", which makes it possible to define separate static
leases, e.g. for a client which is connected to the same network with
more than one interface (which will both have the same DUID, as it is a
per-host identifier, but different IAIDs).
Note that this only wires up the new format, actually using it to make
DHCPv6-IA decisions will be implemented in subsequent patches.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/255
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
I guess this might be subject to change (for example, we probably want to
also broadcast events for DHCPv6 leases in the future, and I guess the
ack/release/expire events that are currently broadcast might benefit from
being renamed to something that makes it clearer that they are DHCPv4
specific events), but this is the current ubus interface.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/270
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
macOS ignores NDP packets that don't originate from link-local addresses,
causing IPv6 connectivity issues with odhcpd. This change ensures NDP
packets (Neighbor Advertisements and ICMP Echo Requests) are sent using
link-local source addresses for RFC 4861 compliance.
Changes:
* Add ndp_from_link_local configuration flag (defaults to true)
* Add odhcpd_send_with_src() to allow explicit source address control
* Add odhcpd_try_send_with_src() helper to eliminate code duplication
* Add odhcpd_get_interface_linklocal_addr() with caching for performance
* Update send_na() and ping6() to use link-local source addresses when
enabled
* Add RFC 4861, §4.2 comments explaining the mandated behavior
* Maintain backward compatibility with fallback behavior
Fixes: openwrt/openwrt#7561 #202
Signed-off-by: Stephen Groat <stephengroat@gmail.com>
Link: https://github.com/openwrt/odhcpd/pull/242
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Convert the README file to GitHub style markdown. I don't think it affects the
readability of the plain text file much (or not at all, rather). But it makes
it much easier to read for people looking at the GitHub repo.
I've intentionally kept the fancy markup at a minimum and also haven't changed
any help text messages in order to not get bogged down in how each help message
should read. That is something which can be addressed later.
Signed-off-by: David Härdeman <david@hardeman.nu>
Link: https://github.com/openwrt/odhcpd/pull/263
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
