Re: [tcpm] TCP Long Options

On Mon, 14 Jul 2008 at 06:48:43, Adam Langley wrote:
> > Even though RFC 793 explicitly allows payload in SYN segments, there
> > are TCP stacks that just seem to ignore it. Couldn't this offer an
> > opportunity to transport long TCP options in the payload of SYN
> > segments, instead of expanding the header option space?
> 
> I don't have the necessary menagerie of operating systems needed to
> gather good data. But Linux's net/ipv4/tcp_input.c [1] says
> 
> 5188                         /* Now we have several options: In theory there is
> 5189                          * nothing else in the frame. KA9Q has an option to
> 5190                          * send data with the syn, BSD accepts
> data with the
> 5191                          * syn up to the [to be] advertised window and
> 5192                          * Solaris 2.1 gives you a protocol error. For now
> 5193                          * we just ignore it, that fits the spec precisely
> 5194                          * and avoids incompatibilities. It would
> be nice in
> 5195                          * future to drop through and process the data.
> 
> [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/ipv4/tcp_input.c;h=cad73b7dfef07798ddc0b8debba24c9aad94c53b;hb=HEAD
> 
> And that suggests that it's not just those OSes which ignore SYNs with
> payloads - it's also those which reject the packet completely. Having
> to retransmit SYNs in such cases is sufficiently common, and
> sufficiently painful that I think it's a non-starter.

This comment is probably over 10 years old (Linux kernel version
2.0.3x or earlier). This is why I asked for the behavior of "modern"
stacks (and, of course, "modern" middlebox implementations).

Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

Re: [tcpm] TCP Long Options - Why not as payload in SYNs?