Cannot reach Router via secondary on-link IPv6 address

RouterOS General
1

On my network I have a VLAN with two IPv6 addresses assigned, one GUA and one ULA:

> /ipv6/address/export 
add address=::...:17fe eui-64=yes from-pool=global interface=vlan-main
add address=fd6f:...:17fe eui-64=yes interface=vlan-main

> /ipv6/address/print detail
0   G   address=2601:...:17fe/64 from-pool=global interface=vlan-main actual-interface=vlan-main eui-64=yes advertise=yes no-dad=no auto-link-local=yes
1   G   address=fd6f:...:17fe/64 from-pool="" interface=vlan-main actual-interface=vlan-main eui-64=yes advertise=yes no-dad=no auto-link-local=yes

The router is not reachable from hosts via the fd6f:...:17fe address, although hosts on the link can ping each other using addresses from this prefix just fine. Furthermore, :ping fd6f:...:17fe fails on the router itself.
The 2601:...:17fe address works just fine.

The firewall is permissive:

chain=input action=accept protocol=icmpv6 log=no log-prefix=""

and the route is present:

DAc   dst-address=fd6f:...::/64 routing-table=main gateway=vlan-main immediate-gw=vlan-main distance=0 scope=10 target-scope=5

In Wireshark I see that the router ignores Neighbor Solicitation requests sent by the hosts for this address.

Do you see this problem on your networks?

2

Lack of responses makes me uneasy :slight_smile: Does no one have both GUA and ULA on the same link?

3

LOL, you’re normally the one with IPv6 answers…

You seem to allow ICMP in firewall, which would have been my guess. Is it getting any hits in counter?

4

It does. I did a bit more testing and hosts on the VLAN link can access the router:

  • via on-link GUA
  • via on-link link-local address
  • via off-link ULA assigned on the bridge interface VLAN is part of
  • via off-link ULA assigned to a veth interface which is not part of any VLAN nor bridge

It does look like a bug to me and I reported it, but didn’t receive any confirmation just yet. I would appreciate if someone else could test in their lab.

5

It seems weird to me that ROS would actually be paying attention to what “class” of address is being assigned to an interface (GUA or ULA)…a client that needs to pay attention to RFCs about network class priorities, sure, but a forwarding router…? So I have a hard time believing that if this is even a bug, that it has anything to do with the fact that you are mixing GUAs and ULAs together on a single interface. To confirm this, as a test, have you tried changing the ULA address to some fake address from GUA space temporarily, and seeing if the exact same problem still happens or not?

We don’t have very many instances where we have more than a link-local + either one GUA or one ULA on a given interface. Those few cases where we do have a GUA + ULA, no, we don’t have this problem. Though to be fair, those very few cases I’m thinking of are still on 6.49. So, what version of ROS are we talking about here?

Also, your original post made no mention of the fact that the VLAN in question was also a bridge member. To be clear, do you merely mean that this is a bridge with VLAN filtering on, and the VLAN interface hangs off of that? Or do you mean the VLAN interface is literally a bridge port member, and that you have IPv6 addresses added both to the bridge itself, but also to the VLAN interface as well? If the latter, perhaps part of the problem here is that you have your IPv6 addresses added to a bridge port member, which perhaps results in undefined behavior.

6

I added an additional GUA via add **advertise=no** from-pool=global interface=vlan-main eui-64=yes and the router is reachable using this address. Still no bueno for the ULA.
I also added an ULA with advertise=no and the router is reachable via this address as well.


This.

7

I rebooted the router and now it all works. Very strange. Hopefully the support can determine the issue from the supout I sent.

8

Interesting. Again, what ROS ver#?

Was just about to respond that I found a 7.18.2 device on our network with a GUA already on the LAN bridge assigned from a pool, and added a ULA to the same interface as a test. No problems detected, and I did not have to reboot it after the add:


[admin@MikroTik] > /ipv6/address/export                          
/ipv6 address
add address=::1 from-pool=isp-pd interface=bridge
add address=fd00:1234:5678:90ab:4a8f:5aff:fe25:7240 eui-64=yes interface=bridge
[admin@MikroTik] > /ping fd00:1234:5678:90ab:4a8f:5aff:fe25:7240  
  SEQ HOST                                     SIZE TTL TIME       STATUS        
    0 fd00:1234:5678:90ab:4a8f:5aff:fe25:7240    56  64 412us      echo reply    
    1 fd00:1234:5678:90ab:4a8f:5aff:fe25:7240    56  64 477us      echo reply    
    2 fd00:1234:5678:90ab:4a8f:5aff:fe25:7240    56  64 495us      echo reply    
    3 fd00:1234:5678:90ab:4a8f:5aff:fe25:7240    56  64 522us      echo reply    
    sent=4 received=4 packet-loss=0% min-rtt=412us avg-rtt=476us max-rtt=522us 

[admin@MikroTik] >
9

7.18.2