In the recent v6 RC there is a new default firewall rule for IPv6 input filtering.
/ipv6 firewall filter
add action=drop chain=input comment=\
"defconf: rfc4890 drop ll if hop-limit!=255" dst-address=fe80::/10 \
hop-limit=not-equal:255 protocol=icmpv6
This is causing problems when pinging from Windows or Linux machines. Sometimes those hosts are pinging with 128 or 64 ttl value instead of ttl=255.
The reason of this is unknown to me, normally they are pinging with ttl=255, but sometimes linux switch to ttl=64, and Windows switch to ttl=128.
This seems to be something that is a function of the ping utility, because i have no L3 devices on the path that could intercept IPv6 traffic and reduce the ttl value.
If i disable the rule when traffic is rejected, i can see the reduced ttl value on the linux console :
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=779 ttl=255 time=0.154 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=780 ttl=255 time=0.159 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=781 ttl=255 time=0.165 ms
here there is rejected traffic, sequence number jump from 781 to 828. Missing ping response because of rejected traffic by the filter rule.
I disable the filter rule then Linux get ping responses, but we can see that linux switched to ttl=64.
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=828 ttl=64 time=1.36 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=829 ttl=64 time=0.207 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=830 ttl=64 time=0.214 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=831 ttl=64 time=0.225 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=832 ttl=64 time=0.202 ms
And then, Linux strangely come back to ttl=255 after a few pings :)
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=833 ttl=255 time=0.155 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=834 ttl=255 time=0.246 ms
64 bytes from fe80::66d1:54ff:fe31:8d4e: icmp_seq=835 ttl=255 time=0.221 ms
As soon as hosts are pinging with something else than ttl=255, the new default rule reject the ICMP packet.
I did confirm that the packet ttl is really reduced to 128 or 64 by packet capture and Wireshark analysis.
Strange isn’t it ? But it is real world.