Possible Bug with DHCPv6 in RouterOS 7.8?

Hi everyone,
I like playing around with IPv6 and noticed a behavior in RouterOS (currently 7.8 ) which seams to be a bug. But I’m not yet very familiar with RouterOS and no Networking expert, therefore this could be due to a misconfiguration.
This is my DHCPv6 config:

[admin@CRS326] /ipv6> export
/ipv6 dhcp-client
add add-default-route=yes interface=10_Mgmt request=address use-interface-duid=yes

The device pulls an IPv6 address as it should but the resulting routing table looks a bit off:

[admin@CRS326] /ipv6> route print
Flags: D - DYNAMIC; A - ACTIVE; c, s, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS                    GATEWAY                           DISTANCE
  DAd ::/0                           fe80::2e0:67ff:fe21:ce09%10_Mgmt         1
  DAc 2003:aaaa:bbbb:cc10::cc10:41/128  10_Mgmt                                  0
  DAc fe80::%bridge/64               bridge                                   0
  DAc fe80::%10_Mgmt/64              10_Mgmt                                  0
  DAc fe80::%20_Home/64              20_Home                                  0
  DAc fe80::%30_IoT/64               30_IoT                                   0
  DAc fe80::%40_Public/64            40_Public                                0

That means, that even if the device communicates within the same subnet (e.g. to 2003:aaaa:bbbb:cc10::cc10:10), it tries to reach the other device via the Gateway. On all my Linux devices a get another standard route that basically says: If you are communicating within the same subnet, just communicate directly via the interface (and not via the gateway).
I was able to work around this with this script within the DHCPv6 config:

/ipv6 route remove [find gateway="10_Mgmt" and dst-address~"/64" and dst-address~"2003"];
:local ip6 [:toip6 $"na-address"]
:local mask6 FFFF:FFFF:FFFF:FFFF::;
:local ip61 ($ip6&$mask6);
/ipv6 route add disabled=no distance=1 dst-address="$ip61/64" gateway=10_Mgmt routing-table=main vrf-interface=10_Mgmt;

Resulting routing table:

[admin@CRS326] /ipv6> route print
Flags: D - DYNAMIC; A - ACTIVE; c, s, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS                    GATEWAY                           DISTANCE
  DAd ::/0                           fe80::2e0:67ff:fe21:ce09%10_Mgmt         1
0  As 2003:aaaa:bbbb:cc10::/64          10_Mgmt                                  1   ### <- that is the important line
  DAc 2003:aaaa:bbbb:cc10::cc10:41/128  10_Mgmt                                  0
  DAc fe80::%bridge/64               bridge                                   0
  DAc fe80::%10_Mgmt/64              10_Mgmt                                  0
  DAc fe80::%20_Home/64              20_Home                                  0
  DAc fe80::%30_IoT/64               30_IoT                                   0
  DAc fe80::%40_Public/64            40_Public                                0

After this, communication within the same subnet is no issue at all.

Question: Why is this rule not added by default? Is my DHCPv6 config just wrong? Is this a bug?

Thank you!

It isn’t a bug. DHCPv6 has no mechanism to distribute a default gateway, the gateway and subnet prefix are obtained from Router Advertisments (RA).

I don’t know why Mikrotik have an add-default-route option in the DHCPv6 client, it is a hacky bodge which adds the DHCPv6 server as the default gateway. This works in some situations, but not all. Also note that IPv6 has a much clearer distinction between endpoints and routers than IPv4, the default IPv6 settings on a Mikrotik are set to ignore RAs if routing.

This seams to make sense. But what I don’t understand: What is a clean way to get a route to communicate within the same subnet without involving the gateway?
As I wrote in Linux that is some kind of standard mechanism (based on the RAs?) that takes care of it. My current script within the DHCP-Clientconfig seams to be a hack…

There has to be something on the network sending RAs, and a device has to accept them.

See https://blog.ipspace.net/2012/11/ipv6-router-advertisements-deep-dive.html and https://www.arin.net/blog/2018/06/25/common-mistake-dhcpv6/ - from the first “DHCPv6 does not carry prefix length information, so a prefix information option with L=1 is the only way a host may acquire an on-link route.”

My Router (pfSense) is definitely sending RAs. I can confirm this on another machine in the same subnet with rdisc6. The announced prefix is as expected. The only “specific” thing I do on pfSense is, that I deactivated SLACC by setting the “Router Mode” to “managed” (RA Flags “managed” and "other stateful; Prefix flags “onlink” and “router”).

I simply don’t understand why every device on my net is behaving as expected, but Mikrotik devices not.

As @tdw hinted: Mikrotik default config is essentially not to accept RAs. You need them accepted, so configure your Mikrotik to do it:

/ipv6 settings set accept-router-advertisements=yes

Note that up to and including 7.7 routes, accepted by RAs, were not shown under /ipv6 route.

Thank you very much, this setting seams to have fixed the issue. Even though I’m on 7.8 I still can’t see the “RA-route” but it works. Strange…
I also set IPv6 forwarding to “no” without even knowing, what this does :wink: The documentation is not really explicit enough so that I would be able to under stand the effects. But I’m happy as long as everything works :slight_smile: Thanks again!

/ipv6 settings
set accept-router-advertisements=yes forward=no

IPv6 setting forwarding defines whether device will act as IPv6 router or not. If you use device as AP or as switch (or as combination of both), then it’s fine to set this setting to no. If device should forward traffic between different L3 interfaces, then this setting has to be set to yes.

Thank you very much!

  • Solvable without Router Advertisements
  • Specific use case is IPv4 IPv6 routing firewall
  • Comcast Xfinity near Hayward, California, USA

IPv6 connection state:

# MikroTik hAP ax3 - RouterOS 7.10.2 - Model C53UiG+5HPaxD2HPaxD
#
[admin@...] > /ipv6 dhcp-client print
Columns: INTERFACE, STATUS, REQUEST, PREFIX, ADDRESS
# INTERFACE  STATUS  REQUEST  PREFIX                              ADDRESS
0 ifname0    bound   address  2601:642:eeee:ffff::/60, 17h50m29s  2001:558:6045:76:aaaa:bbbb:cccc:dddd, 17h50m29s
                     prefix
#
[admin@...] > /ipv6 address print
Flags: D - DYNAMIC; G, L - LINK-LOCAL
Columns: ADDRESS, INTERFACE, ADVERTISE
 #    ADDRESS                                   INTERFACE  ADVERTISE
 0 DG 2001:558:6045:76:aaaa:bbbb:cccc:dddd/128  ifname0    no

Static default gateway solution:

/ipv6 dhcp-client set [ find where interface=ifname0 ] add-default-route=no
/ipv6 route add dst-address=::/0 gateway=ifname0

I disable “Rapid Commit” but observed prefix delegation works either way.

Default IPv6 firewall rule impacts recent Comcast Xfinity change.
http://forum.mikrotik.com/t/xfinity-comcast-dhcpv6-configuration-change/156031/7 is worth reading.