DHCPv6-relay Option 79 violates RFC6939

RouterOS General
1

Hello all,

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).
Cheese_Tue-05Jul22_16.09.png
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

 da c7 21 39 ed 93

which corresponds to the clients link-local address.
My mac-address in this example is completely different from what RouterOS includes.

This should be fixed to allow people to properly use option79 :slight_smile:


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:

/ipv6 dhcp-relay
add dhcp-server=xxxx:3100::9 interface=uulm-welcome link-address=xxxx::1 name=welcome-dhcpv6
2

Hi,

I’m also experiencing similar issues when attempting to make use of option 79 using both the current stable (7.6) and beta 7.7beta9 versions of the Cloud Hosted Router.

In my case, I have a client with a mac address of 52:54:00:b2:c5:50 and a mac-derived link-local address of fe80::5054:ff:feb2:c550. For the dhcp server, I have dnsmasq using the dhcp-host option to match the mac address of the client. Looking at the traffic passing through the relay, I can see that the mac address being sent in option 79 is actually 50:54:00:b2:c5:50 instead of 52:54:00:b2:c5:50, which reflects the same behavior that JayDi described. Since the mac address that dnsmasq sees does not match the client, it returns a “no addresses available” message.

For the sake of comparison, I set up a dhcpv6 relay using a Cisco CSR1000v image and relayed the same client and I could see that 52:54:00:b2:c5:50 was showing up correctly in the packets and dnsmasq was able to offer the client an address.

Even if we’re assuming that the link-local address is coming from the mac address, I believe the number represented by the first two digits to the right of the “fe80::” (50 in this case) needs to be XOR’d against 0x02 to return the correct value of the most significant byte of the mac address (52) - that would be a pretty easy fix that would at least support any devices deriving their link local addresses from their mac address.

I can appreciate that ipv6 + an obscure dhcp relay option is most likely not on a lot of people’s radar, but it would be cool if this can get fixed or at least looked at as an “easy win”