Re: [tcpm] TCP Long Options

On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf
<michael.scharf@ikr.uni-stuttgart.de> 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?
>
> Sorry if this question has already been answered elsewhere.

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.

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

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