Currrently we started deploying IPv6 all around our campus. Usually we rely on Slaac, but in certain usecases, we give out IPv6-addresses via DHCPv6.
We rely on DHCPv6-relays that support Option79 for cases where the supplied DUUID does not correspond to the clients mac-address.
I noticed that mac-based host-declarations on our central ISC-DCHP do not work, when the DHCPv6-relay-agent is a mikrotik device. After some digging I found the reason why:
When a client is using a DUUID not based on the mac-address, i.e the DHCP-server has to rely on Option79 to make an assignment, it fails.
Option79 is standardized in RFC6939 and allows a dhcp-relay to include the clients link-layer-address (read as in mac-address) in the relayed packet. (See https://datatracker.ietf.org/doc/html/rfc6939#section-4.
Usually the relay-agent would set the ethertype to 01 and then include the clients mac-address right afterwards.
However, RouterOS does not seem to do this (see the attached screenshot). RouterOS dhcp-relay seems to cut the last 48 bits of the link-local address and pass them in option79.
This is problematic since the last 48bits of the link-local address are in almost no cases representative of the clients link-layer/mac-address. However RFC6939 cleary states that the link-layer address shall be used. The highlighted area in the screenshot show the nibbles
Code: Select all
da c7 21 39 ed 93
My mac-address in this example is completely different from what RouterOS includes.
This should be fixed to allow people to properly use option79
Edit: Additional Info:
Version number: 7.1.3
Router's model: CCR1036
Steps to reproduce the issue: Create a DHCPv6-relay and look into option79.
Configuration export:
Relevant part:
Code: Select all
/ipv6 dhcp-relay
add dhcp-server=xxxx:3100::9 interface=uulm-welcome link-address=xxxx::1 name=welcome-dhcpv6