IPv6 propagate address to clients behind router

Savanture · Sat Nov 02, 2024 2:17 pm

Hi, dear community!
I'm using RB5009 with ROS 7.16.1.
1. Recently I've changed my ISP and it appears that my new ISP supports IPv6. Using IPv6 DHCP client I've got the following (addresses are masked, XXXX and YYYY everywhere in the post below are the same):

Prefix: XXXX:YYYY:84f0:2c00::/56
Address: XXXX:YYYY:a04:479e::1

DHCP client was created with the following parameters:

/ipv6 dhcp-client add interface=ether1 request=prefix,address pool-name=ipv6-pool add-default-route=yes

Received IPv6 address was automatically assigned to interface ether1. From the router I can successfully ping Google's DNS adddress:
2001:4860:4860::8888
2. IPv6 pool was successfully created with prefix

XXXX:YYYY:84f0:2c00::/64

3. As mentioned in https://wiki.mikrotik.com/Manual:IPv6/DHCP_Client I've assigned IPv6 address to bridge with advertise=yes parameter using command

ipv6 address add address=::1/64 from-pool=ipv6-pool interface=bridge advertise=yes

and after adding the address was automatically changed to the first address from pool: XXXX:YYYY:84f0

:/64

However, no one of my internal devices behind the router didn't receive any IPv6 address from the pool, only channel local addresses like fe80: are assigned.
I've already allowed in IPv6 firewall any UDP in chain input from internal network. By the messages on this forum it looks like IPv6 DHCP server on my router is capable to transfer IPv6 prefixes only (to another routers) and is not used to deliver addresses to clients. From my PC I can successfully ping router's link-local address of bridge.

What should I do make my MT propagate IPv6 addresses to clients?

sindy · Sat Nov 02, 2024 3:22 pm

What should I do make my MT propagate IPv6 addresses to clients?

Strictly speaking nothing as MT does not propagate them. It just reveals its own address upon request, which is enough for the host to create its own address, combining the prefix provided by the router and locally provided suffix - see https://ru.wikipedia.org/wiki/IPv6?sect ... %94_SLAAC) for details. So what does /ipv6 firewall export show? I can imagine the firewall to block the ND multicast ICMPv6 messages, preventing the router from responding the ND requests from the LAN hosts.

Also, I hate to say that but at more than one occasion, I had to reboot the router after configuring IPv6 for the first time.

Savanture · Sat Nov 02, 2024 4:14 pm

Hi, sindy!
I've got all the default IPv6 rules except ipsec rules (deleted by me) and default address-list bad_ipv6:

/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" limit=5,5:packet protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 limit=5,5:packet protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=accept chain=input in-interface-list=LAN protocol=udp
add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" limit=10,5:packet protocol=icmpv6
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN

The only rule I've added was
add action=accept chain=input in-interface-list=LAN protocol=udp
to accept UDP coming from LAN.
UPD: since IPv6 setup router was rebooted twice.

sindy · Sat Nov 02, 2024 6:06 pm

The only rule I've added was
add action=accept chain=input in-interface-list=LAN protocol=udp
to accept UDP coming from LAN.

Since the default behavior of the firewall filter in Mikrotik is accept, your rule will not change the overall behavior of the filter, as the "drop everything else" rule in chain input matches on in-interface=!LAN, so it ignores packets arriving via LAN, which then get accepted by default.

But the above has nothing to do with your basic issue, so like in many other "mysterious" cases, I'd suggest sniffing as a way to find out whether the Mikrotik or the LAN host are the reason why SLAAC fails.

So disconnect the Ethernet cable from one of the LAN hosts, run /tool sniffer quick interface=bridge ip-protocol=icmpv6, connect the Ethernet cable back, and stop the sniffer 30 seconds later. Immediately after run /tool sniffer save file=slaac.pcap (the buffer gets purged within minutes), and then download the file and open it using Wireshark. If everything worked, you should see something similar like e.g. here: https://www.cloudshark.org/captures/042b071a3af5 . As it doesn't work, something will be missing in your case.

tdw · Sat Nov 02, 2024 6:29 pm

As IPv6 requires multicast any badly behaved or configured switches inbetween can prevent IPv6 from working, faulty implementations of DHCP or IGMP snooping are often the cause. So if you have switches between your router and end device(s) check if connecting a device directly to the router works as expected.

Savanture · Sat Nov 02, 2024 8:37 pm

sindy, thank you for pointing me on the useless rule. Deleted it.
On the MT dump I can see ONLY packets coming to router from my PC (connected by ethernet). No any packet sent from the router. Thank you for the site, posted my dump here:
https://www.cloudshark.org/captures/5d2b2e829c20
It seems like MT is not responding...
Hi, tdw! I have no any devices between MT and clients.

sindy · Sat Nov 02, 2024 9:05 pm

Please post the complete export of your configuration (minus all the passwords and usernames, public addresses etc.). If you have indeed sniffed on the bridge, not on the ethernet interface, it looks really weird, as if you had some bridge filter rule there or an IPsec policy.

Savanture · Sun Nov 03, 2024 12:15 am

sindy, attached my exported and slightly cleaned configuration. This router is also a CAPsMAN, zerotier ang wireguard client. Also I've never used IPsec. And I have no any bridge filter rules.

sindy · Sun Nov 03, 2024 1:04 am

Your export says
/ipv6 address
add from-pool=IPv6-pool interface=bridge
This means that you have set address=::, so the resulting address is a "subnet router anycast address", which I believe cannot be assigned as an individual unicast address of an interface. So try changing that to the ::1 you've shown in the OP and try again.

If this is not the issue, the only thing to come to my mind except a mere bug is that attaching the DHCPv6 server to the bridge might prevent the router from responding to the Router Solicitation requests.

Savanture · Tue Nov 05, 2024 11:39 am

I've finally found a solution, but it more about "magic", not to a real solution: in Winbox I've opened /IPv6/ND, checked "Advertise DNS" flag, applied change, then unchecked that flag back and applied changes again. After that MT started reply with Router Advertisement (RA) to the clients. It looks like ND settings were specified but not actually applied and not worked until first apply. It looks like bug workaround, not a real solution...

Kentzo · Sun Nov 10, 2024 8:43 am

In this case please report it at https://mikrotik.com/support/

IPv6 propagate address to clients behind router

IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Re: IPv6 propagate address to clients behind router

Who is online