I found an issue with forwarding fragmented IPv6 packets from a port with trusted-ra=yes.
When I send a fragmented IPv6 packet from such a port, only the first fragment is forwarded by the switch. Subsequent fragments do not arrive at the destination port.
I can reproduce this with:
ping -6 -c 4 -s 1453 2001:db8::1
1453 bytes ICMP payload + 8 bytes ICMPv6 header + 40 bytes IPv6 header = 1501 bytes, which exceeds the 1500-byte MTU and therefore causes IPv6 fragmentation.
Using tcpdump on the destination host, I can clearly see that the first fragment arrives, while the second fragment does not. There is no routing involved, both hosts are connected directly to the switch and are in the same vlan.
The issue goes away when I either set trusted-ra=no on the sending port or dhcpv6-snooping=no on the bridge. It therefore looks like a problem with the combination of both features.
In IPv6, packets are transmitted by routers without fragmentation.
It's up to the host to first negotiate the correct MTU and send fragmented packets at the start.
Routers in the middle, as per the protocol, RIGHTLY do not fragment.
In order to send a packet that is larger than the path MTU, the sending node splits the packet into fragments. The Fragment extension header carries the information necessary to reassemble the original (unfragmented) packet.
This can still be a RouterOS bug. Last year that was the same case for IPv4 (I was affected by that bug and reported it):
On the CRS3xx devices, DHCPv6 Snooping and RA Guard are HW-Offloaded. That's means most probably like DHCP Snooping on the RB5009 (an affected device from last year that has HW-Offload support for DHCPv4 snooping), some of the TCAMs are used to detect DHCPv6 / RA packets and maybe quickly discard them or redirect them to the CPU. It could be that those TCAMs somehow match fragmented IPv6 packets (packets fragmented by the source, not the CRS) because some field/byte/offset checks are too broad or wrong and cause fragmented IPv6 packets to be seen as DHCPv6 or RA packets.
On devices with no HW-Offload support for DHCPv6 Snooping / RA Guard the bug will probably not be present, because the packets are checked by normal code running on the CPU.
It would be better if OP fill a support ticket with the bug report because MikroTik is not reading this thread.
Sure, I do not expect RouterOS to tamper with the packet in transit at all. One host running Linux executes the ping, sees that it does not fit in MTU of 1500 and fragments the packet. Two packets are delivered into the switch port and the expectation is that after switching, two packets come out of the destination port. The receiving Linux host then sees the fragmentation header in the first packet and waits for the second packet to reassemble the whole data.
With dhcpv6 snooping disabled or trusted-ra=no on the sending port, this works as expected. But with dhcpv6 snooping enabled and trusted-ra=yes on the sending port, only the first packet comes out of the destination port. The receiving host waits, but does not receive the remaining data.
Both DHCPv6 snooping and RA Guard add dynamic rules to the switch chip that redirect traffic with IPv6 extension headers to the CPU. The fragmentation is on of the possible extension headers. The packet parsing process states:
Fragmentation Handling: These parsing rules apply exclusively to the first fragment of fragmented IPv6 packets. Subsequent fragments are forwarded regardless of their content, as they do not contain the protocol headers necessary for RA identification.
This forwarding of subsequent fragments seems to be broken when dhcpv6 snooping is enabled and the ingress port is marked as trusted-ra=yes.
Thanks, I was not aware that there is a separate support platform. I've now filed a bug report directly to MikroTik.
And please do not wonder my timing of replies in this thread, my account here is quite new and all posts have to be approved by moderators, which takes some time.
That's understandable as mikrotik.com/support shows the forum prominently on the top middle of the page, whereas the "support system" link is inconspicuously placed at the bottom, small and not visible without scrolling down.
And be aware that communication style of support staff might be different to what one is used by "western" standards. It seems to be a cultural thing.