UHCP (micro host configuration protocol) is a RIOT-proprietary protocol
that was developed back in 2016 [1] to have a simple drop-in replacement
for DHCPv6 prefix delegation (which was not implemented yet back then).
Basically it just requests a prefix for a downstream interface from a
server by sending a multicast UDP packet to a known address upstream. It
is how the `examples/gnrc_border_router` application gets its prefix
configured in default mode, but you can use `USE_DHCPV6=1` in the
environment to switch to DHCPv6 prefix delegation (for which a client
implementation was created in the mean time [2]).
UHCP (micro host configuration protocol) is a RIOT-proprietary protocol
that was developed back in 2016 [1]
that begs the question of why it's still default.
There's been some discussion on IRC on 2020-10-20 that concluded that
the remaining advantage is that the UHCP server can be host-built
everywhere.
I half expected dnsmasq to be used as a DHCPv6 server, but that seems
not to be the case; instead, dist/tools/dhcpv6-pd_ia has been added
recently (2020-03).
Could, with some updates to the border router example setup scripts,
that or dnsmasq fill the gap?
KR
chrysn
PS. The DHCPv6 client is working really smooth; except for some numbers
that needed increasing and one hack to prefer routable over ULAs, the
DHCPv6 version of the border router example works quite straightforward
with OpenWRT routers -- plug it in, install the missing CDC-ECM kernel
module from the GUI, assign usb0 to your LAN and off you go with real v6
addresses being assigned to your devices!
Exactly, and there are no root privileges required to run it on a restricted port (which of course can be reconfigured). Also, when using the border router with the testbed [1] UHCP is currently the simplest way to get a prefix to a node, due to its easy provisioning and small footprint (on the A8 nodes, I don’t believe a DHCPv6 server can be easily deployed). To my knowledge and last time I checked dnsmasq did not support server-side prefix delegation, if that is wrong: great, let’s use it. dist/tools/dhcpv6-pd_ia is not a DHCPv6 server on its own, but a dispatcher script that installs and runs a DHCPv6 server, using the operating systems installation services (like APT or pacman). Currently, Kea [2] is used for that, again last time I checked, is the only open source DHCPv6 server, that supports prefix delegation. It has however the distinct disadvantage, that some configuration paths, like the pidfile are configured at compile time, and thus it requires root, even when a non-restricted port is used (main reason why UHCP still exists in my book). I think the simplest solution to get rid of UHCP could be, to have a very simple DHCPv6 server that just provides Prefix Delegation at hand, that could be compiled (if it is not a script) as fast as UHCPD can be and allows for easy non-root deployment. Cheers, Martine [1] [2]
To my knowledge and last time I checked dnsmasq did not support
server-side prefix delegation, if that is wrong: great, let's use it.
`dist/tools/dhcpv6-pd_ia` is not a DHCPv6 server on its own, but a
dispatcher script that installs and runs a DHCPv6 server, using the
operating systems installation services (like APT or pacman).
Currently, Kea [2] is used for that, again last time I checked, is the
only open source DHCPv6 server, that supports prefix delegation. It
has however the distinct disadvantage,
"it" doesn't mean Kea but the way Kea is installed?
I think the simplest solution to get rid of UHCP could be, to have a
very simple DHCPv6 server that just provides Prefix Delegation at
hand, that could be compiled (if it is not a script) as fast as UHCPD
can be and allows for easy non-root deployment.
To my knowledge and last time I checked dnsmasq did not support
server-side prefix delegation, if that is wrong: great, let's use it.
`dist/tools/dhcpv6-pd_ia` is not a DHCPv6 server on its own, but a
dispatcher script that installs and runs a DHCPv6 server, using the
operating systems installation services (like APT or pacman).
Currently, Kea [2] is used for that, again last time I checked, is the
only open source DHCPv6 server, that supports prefix delegation. It
has however the distinct disadvantage,
"it" doesn't mean Kea but the way Kea is installed?
Yes, if you compile from source yourself, that problem does not exist of
course.
I think the simplest solution to get rid of UHCP could be, to have a
very simple DHCPv6 server that just provides Prefix Delegation at
hand, that could be compiled (if it is not a script) as fast as UHCPD
can be and allows for easy non-root deployment.
I remember looking at it back when I was searching servers, but do not
remember why I decided against it (maybe back then it did not support PD
yet or did not seem very stable back then?) A python-based DHCPv6 server
would be of course perfect for our use case: Easy to set-up and platform
independent (though in dhcpy6d's README they curiously leave out Windows
in their listing, but not that important for us, I guess). I agree it's
worth a look! If I find some time today, I will have a go at it.
UHCP (micro host configuration protocol) is a RIOT-proprietary protocol
that was developed back in 2016 [1] to have a simple drop-in replacement
for DHCPv6 prefix delegation (which was not implemented yet back then).
thanks for the explanation. Now that I read it I actually remember it.
Would you mind to just copy-paste this explanation into the doxygen
documentation?
There are currently some caveats to dhcpy6 that I identified to run it as non-root user / use it as drop-in DHCPv6 server: - It can’t be installed via the usual python methods, as it expects a UNIX file structure at the installation path and dumps directories like usr/bin/ and etc/ there [1]; i.e. it can only be installed as root and sensibly used. - Setting the port to a non-standard port was removed in March [2] because there seemed to be no apparent use for it [3]. However, the dhcpy6 people seem open to the idea, to make the server runnable as non-root user, so it would be a small effort on our part (compared to writing a simple DHCPv6 server ourselves) to help them negate those caveats. Cheers, Martine [1] [2] [3]
While running the daemon as non-root for security reasons makes sense,
without root, how does the daemon install the route for the delegated prefix?
(I hate the <1024 port restriction. It's dumb for VMs and containers,
and it's weird that it's not sysctl'able on Linux. There is a capability
though.)
for that we have setup scripts that an admin could run (they might be fine setting some routes, but not running a DHCPv6 server). Alternatively, (if the admin is brave enough) ip could be made sudo-able for any user or the capabilities set accordingly.