IPv6 routes with no gateway

RouterOS General
1

Since configuring a DHCPv6 client in RouterOS 7.1.5 (and later), I’ve noticed the following routes:

/ipv6/route> print
Flags: D - DYNAMIC; A - ACTIVE; c, s, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS               GATEWAY                           DISTANCE
0  As ::/0                      fe80::4e12:65ff:fe6e:7e30%ether1         1
  DAc blah:blah:blah:119e::/64  BASE_VLAN                                0
  D d blah:blah:blah:119e::/64                                           1
  D d blah:blah:blah:119f::/64                                           1
  DAc blah:blah:blah:119f::/64  COMMON_VLAN                              0
  (…)

The DHCPv6 clients are only requesting a prefix and are not using peer DNS. The addresses are being advertised.

/ipv6/address> print
Flags: D - DYNAMIC; G, L - LINK-LOCAL
Columns: ADDRESS, INTERFACE, ADVERTISE
 #    ADDRESS                                     INTERFACE    ADVERTISE
 0 DL fe80::258:9a1e:ed82:b0e8/64                 homevpn      no       
 1  G blah:blah:blah:119f:4a8f:5aff:fe6a:4767/64  COMMON_VLAN  yes      
 (…)
 6 DL fe80::4a8f:5aff:fe6a:4767/64                BASE_VLAN    no       
 7 DL fe80::4a8f:5aff:fe6a:4767/64                COMMON_VLAN  no       
10  G blah:blah:blah:119e:4a8f:5aff:fe6a:4767/64  BASE_VLAN    yes

I understand these routes were added by the DHCPv6 client (hence the lowercase “d”), but shouldn’t they have a gateway?

2

DHCPv6 has no mechanism to obtain or provide a default gateway. The Mikrotik DHCPv6 client add-default-route=yes is a hacky bodge, it uses the address of the DHCPv6 server from which the address/prefix/other information was received - this works if the DHCPv6 server and the default gateway are the same host, but otherwise fails.

The correct method is to set add-default-route=no and use received router advertisments (RA) which unfortunately are not displayed by RouterOS as discussed in other forum posts. The default IPv6 settings include forward=yes and accept-router-advertisements=yes-if-forwarding-disabled, so as you are forwarding you need to set accept-router-advertisements=yes. Ideally Mikrotik should implement accepting RAs per-interface rather than globally, plus other features as described in RFC7084.

If you look at the routing table on an IPv6-capable device downstream of your Mikrotik it will have learnt fe80::4a8f:5aff:fe6a:4767%someinterfacename as its default gateway using the RAs from the Mikrotik.

3

So, I actually had add-default-route set to “no”:

/ipv6/dhcp-client> print detail 
Flags: D - dynamic; X - disabled, I - invalid 
 0    interface=ether1 status=bound duid="0x00030001488f5a6a4766" dhcp-server-v6=fe80::4e12:65ff:fe6e:7e30 request=prefix add-default-route=no use-peer-dns=no dhcp-options="" pool-name="COMMON_POOL" pool-prefix-length=64 prefix-hint=::/64 dhcp-options="" 
      prefix=blah:blah:blah:119f::/64, 33m8s 

 1    interface=ether3 status=bound duid="0x00030001488f5a6a4766" dhcp-server-v6=fe80::4e12:65ff:fe6e:7e30 request=prefix add-default-route=no use-peer-dns=no dhcp-options="" pool-name="BASE_POOL" pool-prefix-length=64 prefix-hint=::/64 dhcp-options="" 
      prefix=blah:blah:blah:119e::/64, 33m56s

However, the rest of your explanation likely tells me why my other MikroTik devices are not adding IPv6 addresses per the RAs from the hEX S. They all have forwarding disabled and accept-router-advertisements set to “yes-if-forwarding-disabled”. However, the hEX S has forwarding enabled and is therefore not accepting router advertisements. It gets its IPv6 prefixes from an AT&T gateway via DHCPv6 clients (one per interface because AT&T won’t hand out blocks larger than /64 unless you’re an enterprise customer).

4

So do you have a switch or multiple network cables connecting your main Mikrotik with the AT&T gateway? IIRC there are forum threads which discuss abusing VRRP interfaces to effectively provide multiple MAC addresses on an interface allowing a request to be made from each. I do wish providers would actually implement IPv6 sensibly after reading https://www.ripe.net/publications/docs/ripe-690 or similar.

For info IPv6 RA was broken in some of the earlier v7 releases so you couldn’t make IPv6 work at all for some setups, again IIRC there are forum threads which mention this.

5

Currently, ether1 and ether3 (which do not share a bridge) are connected directly to the AT&T Gateway. Each interface has a DHCPv6 client, and the gateway gave each a different /64 prefix.

  • The prefix ether1 pulled is being advertised on COMMON_VLAN, and all devices on that VLAN are getting the prefix as expected.
  • The prefix ether3 pulled is being advertised on BASE_VLAN, which is only occupied by MikroTik devices (a hAP ac³, a CRS112-8P-4S-IN, and a hEX). The hEX and the hAP ac³ are connected to the CRS112 on trunk ports, and ultimately everything has to go through the CRS112 to get to the hEX S.

The way I’ve set this up, I can get one /64 prefix per available interface on the AT&T gateway for a maximum of 4. I could probably get around this by bypassing the gateway altogether (per http://forum.mikrotik.com/t/bypassing-at-t-residential-gateways-with-mikrotik/135563/1), but I don’t have enough VLANs to make the full /60 necessary.

I’ll look around the forum some more, but the RAs not being taken up on the downstream devices is likely something silly I’ve done with VLAN routing. I was more interested in why I had routes with no gateway, and I think the answer is this implementation is a bit kludgey.