On 11/12/18 19:56, Wes Hardaker wrote: > Brian E Carpenter <[email protected]> writes: > >> It's a shame. Can you characterise those sessions in any way? >> >> (This shouldn't invalidate ECMP/LAG usage as described in RFC6438, >> since there it is the operator that sets the flow label.) > > I had to go dig out the bug that we dealt with "way back then" (to be > fair, btw, credit to Duane Wessles at Verisign who tracked down and > could reproduce the issue). [...] > > 2) Some clients were sending a flowlabel for the initial TCP handshake > and then zeroing it out in subsequent packets: > > SYN: > .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564 > > SYNACK from server: (no label) > > ACK from client: > .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564 > > First data packet: > .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 > > Which what was causing the problem. >
At least some version of FreeBSD used to do the opposite: FL set to zero during the TCP 3WHS, and non-zero afterwards. -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
