IPv6 not working on ether1

I just bought two BaseBox5 (RB912UAG-5HPnD) devices which is also my first contact with MikroTik devices. I am running the latest ROS 6.10. I have networking experiences with other vendors, the MikroTik hardware and software looks pretty nice, so I wanted to give it a try. Basically I could sucessfully setup (almost) everything I need but I encounter major problems when I try to add the device to my existing IPv6 infrastructure. I just cannot get IPv6 working on the ether1 interface. wlan1 works without any problems. On ether1 I am unable to ping the ipv6 address of my device itself nor can I ping any other ipv6 address in my network. A packet capture shows no outgoing icmp6 packets on ether1. IPv4 works. So this looks like the IPv6 stack on ether1 would be down. Are there still known issues with IPv6? I found some older topic regardings IPv6 where disabling and enabling the interfaces helped. But it doesn’t work here.

I can reproduce this issue by just adding some IPv6 addresses to the interfaces:

/ipv6 address
add address=2001:db8::1 advertise=no interface=ether1-local
add address=2001:db8:1::1 advertise=no interface=wlan1-gateway

Now I would expect to be able to ping 2001:db8::1 as well as 2001:db8:1::1.
Actually I can ping the IPv6 address on the wlan1 interface but not on the ether1 interface.

[admin@BaseBox5-AP] > ping 2001:db8::1
HOST                                     SIZE TTL TIME  STATUS
2001:db8::1                                             timeout
    sent=1 received=0 packet-loss=100%

[admin@BaseBox5-AP] > ping 2001:db8:1::1
HOST                                     SIZE TTL TIME  STATUS
2001:db8:1::1                              56  64 1ms   echo reply
    sent=1 received=1 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=1ms

IPv6 addresses and routing table looks fine so far. Everything is up and as expected.

[admin@BaseBox5-AP] > ipv6 address print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
 #    ADDRESS                                     FROM-POOL INTERFACE                                   ADVERTISE
 0  G 2001:db8::1/64                                        ether1-local                                no
 1 DL fe80::4e5e:cff:feXX:XXXX/64                           wlan1-gateway                               no
 2 DL fe80::4e5e:cff:feXX:XXXX/64                           ether1-local                                no
 3  G 2001:db8:1::1/64                                      wlan1-gateway                               no

It is not only the ping to my own address, I cannot communicate with IPv6 on ether1 at all.

Does anybody have an idea, or maybe already had similiar issues and can provide me with a solution? Or maybe some hints on how to debug this any further to find the root cause.

I have also attached a full configuration (export) where I only masked personal or sensitive data.
Thanks for any assistance in advance.
rb912-config.txt (4.56 KB)

Please post the results of ‘ipv6 route print’

Hi,
unfortunately I missed to gather the output of the ipv6 routing table during the broken configuration.
However, in the meantime I was actually able to fix this issue by myself.

In my first configuration attempt, I started with the default configuration shipped on the RB912 and performed my intended changes based upon this template.

Now in my next attempt, I started with a complete erased / empty configuration. Then I applied the statements I actually wanted. And just out of a sudden, the IPv6 worked instantly without any problems.

I have attached the configuration that now works.
From my point of view I can only spot one relevant difference between the old and the new config.

In the old config there was such a statement.

/interface ethernet
set [ find default-name=ether1 ] name=ether1-local

And later on everything (e.g. IPv4 and IPv6 addresses) are assigned to “ether1-local”.

In my new configuration this statement is missing and all further commands are referencing “ether1”.

So I guess in my first attempt the real ether1 device was renamed into ether1-local and the IPv6 stack (for some reason) seemed to have problems with such renamed devices.

I myself am absolutely fine with the real name ether1 so there is no need to rename it. This was just done because the default config template contained it. So I will simply use ether1 - and be happy. I did several reboots etc. and with the new configuration the IPv6 stack was rock solid.

Maybe somebody else might also run into this particular problem - and then find this topic helpful.
rb912-config-new.txt (4.23 KB)

Hello,
unfortunately the problem arised again after a few days.
The IPv6 stack is currently broken although I am using regular interface names.

Here is my complete running configuration:

/certificate
[...]
/ip neighbor discovery
set ether1 discover=no
/interface wireless channels
[...]
/interface wireless
set [ find default-name=wlan1 ] band=5ghz-onlyn channel-width=20/40mhz-ht-above country=germany disabled=no \
    frequency=ch100 frequency-mode=superchannel ht-supported-mcs=\
    mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,mcs-9,mcs-10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15 \
    l2mtu=2290 mode=ap-bridge nv2-cell-radius=10 nv2-preshared-key=XXX nv2-security=enabled scan-list=\
    outdoor ssid=BaseBox5 tx-power=14 tx-power-mode=all-rates-fixed wireless-protocol=802.11
/ip neighbor discovery
set wlan1 discover=no
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik \
    wpa-pre-shared-key=XXX wpa2-pre-shared-key=XXX
/ip hotspot user profile
set [ find default=yes ] idle-timeout=none keepalive-timeout=2m mac-cookie-timeout=3d
/routing bgp instance
set default as=64600 router-id=172.24.4.30
/routing ospf instance
set [ find default=yes ] router-id=172.24.4.30
/routing ospf-v3 instance
set [ find default=yes ] router-id=172.24.4.30
/ip address
add address=172.24.4.30/27 interface=ether1 network=172.24.4.0
add address=192.168.89.1/24 interface=wlan1 network=192.168.89.0
/ip dhcp-client
add dhcp-options=hostname,clientid interface=ether1
/ip dns
set allow-remote-requests=yes servers=172.24.0.244
/ip dns static
add address=192.168.88.1 name=router
/ip route
add distance=250 gateway=172.24.4.1
add distance=250 dst-address=192.168.88.0/24 gateway=192.168.89.2
/ip service
set ftp disabled=yes
set www-ssl certificate=cert disabled=no
set api disabled=yes
set winbox disabled=yes
set api-ssl certificate=cert disabled=yes
/ip upnp
set allow-disable-external-interface=no
/ipv6 address
add address=2001:db8::1 advertise=no interface=ether1
/ipv6 nd
set [ find default=yes ] disabled=yes
/routing bgp network
add network=192.168.88.0/24 synchronize=no
add network=192.168.89.0/24 synchronize=no
/routing bgp peer
add name=RouteReflector1 nexthop-choice=force-self remote-address=172.24.4.2 remote-as=64600 ttl=default
add name=RouteReflector2 nexthop-choice=force-self remote-address=172.24.4.3 remote-as=64600 ttl=default
add name=RouteReflector3 nexthop-choice=force-self remote-address=172.24.4.4 remote-as=64600 ttl=default
/routing ospf interface
add dead-interval=10s hello-interval=3s interface=ether1 network-type=broadcast priority=50
/routing ospf network
add area=backbone network=172.24.4.0/27
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=BaseBox5-AP
/system leds
set 0 interface=wlan1
/system ntp client
set enabled=yes primary-ntp=172.24.0.244
/system ntp server
set enabled=yes
/system routerboard settings
set cpu-frequency=600MHz silent-boot=yes
/tool bandwidth-server
set authenticate=no max-sessions=1

So I have assigned IPv6 address 2001:db8::1/64 to ether1.
According to various print commands everything looks fine.
But ping (v6) to my own interface does not work at all.

[admin@BaseBox5-AP] > /ipv6 address print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
 #    ADDRESS                                     FROM-POOL INTERFACE
 0  G 2001:db8::1/64                                        ether1
 1 DL fe80::4e5e:cff:fe80:xxxx/64                           wlan1
 2 DL fe80::4e5e:cff:fe80:xxxx/64                           ether1
[admin@BaseBox5-AP] > /ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 ADC  2001:db8::/64            ether1                          0
[admin@BaseBox5-AP] > /ping 2001:db8::1
HOST                                     SIZE TTL TIME  STATUS
2001:db8::1                                             timeout
2001:db8::1                                             timeout
2001:db8::1                                             timeout
    sent=3 received=0 packet-loss=100%

The ether1 interface is up and running.
Furthermore all IPv4 services are working without any problems.
So this actually looks like there still is a severe IPv6 bug in ROS.
Does anybode know what could cause this issue?
Or any hints on how to debug this any further?

I could finally find the root cause and fix it.

The IPv6 address on the MikroTik device was stuck in TENTATIVE mode, i.e. it was waiting for DAD (Duplicate Address Detection) to complete. According to RFC an IPv6 address must not be used in this state until DAD completes. The DAD works a bit like ARP in IPv4, i.e. the device with the new IPv6 address sends a neighbour solicitation message (“who has ?”). If nobody answers to this message, the device may use this address and leave tentative state.

I had another Cisco router in my backbone network which also sent a ND-SA “who has” message with the same address whenever it discovered a new device. This means whenever the MikroTik was performing DAD, the Cisco also tried to resolve this address in the very same moment. Note that the Cisco did not say “I have !”, but also “who has ?”. However this seemed to force the MikroTik to stay in tentative state - and thus it never left that state.

I am not certainly sure whose fault it actually is. On the one hand everythings works since I turned off the ND discovery on the Cisco device. On the other hand a “who has” message should not force a device to stay in tentative mode in my opinion (though I did not find a RFC statement for this).

However, @MikroTik: Could you please add an indicator in the “ipv6 address print” output which shows such tentative addresses? I think it is very important to know when an address is in this state due to DAD. Because when it is, no IPv6 communication works with that address (and this is what I noticed). Currently (ROS 6.10) I did not see anything showing me this tentative state.
My suggestion would be just to add another letter like “T” for tentative addresses in the ipv6 address output.