Dear reconnecting IOTlers,
I just came across the following page in the RIOT documentation: https://riot-os.org/api/group__net__uhcp.html
Could anybody explain what UHCP is and how it works? The documentation page is a bit minimalistic and I couldn't find an RFC or similar.
Cheers Oleg
Hi Oleg,
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]).
Cheers, Martine
[1] https://github.com/RIOT-OS/RIOT/pull/4725 [2] https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_border_router#requirements
Hi,
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.
anybody any experiences with https://github.com/HenriWahl/dhcpy6d (they claim prefix delegation support)
cheers matthias
Hi Matthias,
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.
anybody any experiences with https://github.com/HenriWahl/dhcpy6d (they claim prefix delegation support)
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.
Best regards, Martine
Hi Martine,
Hi Oleg,
Hi Martine,
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?
https://github.com/RIOT-OS/RIOT/pull/15408 I did not copy-paste it verbatim, but kept the spirit ;-).
Cheers, Martine
Hi,
some preliminary report on dhcpy6:
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.)
So I don't get it.
Hi Michael,
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.
Best, Martine
