Morning, I'm experimenting with flow label reflection from a server point of view. I'm able to get it working in both supported ways:
(a) per-socket with flow manager IPV6_FL_F_REFLECT and flowlabel_consistency=0 (b) with global flowlabel_reflect sysctl However, I was surprised to see that RST after the connection is torn down, doesn't have the correct flow label value: IP6 (flowlabel 0x3ba3d) ::1.59276 > ::1.1235: Flags [S] IP6 (flowlabel 0x3ba3d) ::1.1235 > ::1.59276: Flags [S.] IP6 (flowlabel 0x3ba3d) ::1.59276 > ::1.1235: Flags [.] IP6 (flowlabel 0x3ba3d) ::1.1235 > ::1.59276: Flags [F.] IP6 (flowlabel 0x3ba3d) ::1.59276 > ::1.1235: Flags [P.] IP6 (flowlabel 0xdfc46) ::1.1235 > ::1.59276: Flags [R] Notice, the last RST packet has inconsistent flow label. Perhaps we can argue this behaviour might be acceptable for a per-socket IPV6_FL_F_REFLECT option, but with global flowlabel_reflect, I would expect the RST to preserve the reflected flow label value. I suspect the same behaviour is true for kernel-generated ICMPv6. Prepared test case: https://gist.github.com/majek/139081b84f9b5b6187c8ccff802e3ab3 This behaviour is not necessarily a bug, more of a surprise. Flow label reflection is mostly useful in deployments where Linux servers stand behind ECMP router, which uses flow-label to compute the hash. Flow label reflection allows ICMP PTB message to be routed back to correct server. It's hard to imagine a situation where generated RST or ICMP echo response would trigger a ICMP PTB. Flow label reflection is explained here: https://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-01 and: https://tools.ietf.org/html/rfc7098 https://tools.ietf.org/html/rfc6438 Cheers, Marek (Note: the unrelated "fwmark_reflect" toggle is about something different - flow marks, but also addresses RST and ICMP generated by the server)
