Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

[Olivier Bonaventure <[e-mail]>]

David, Joe, Bob,

>> What is impossible is to expand the option space in the initial SYN
>> packet and maintain 100% backwards compatibility with the following
>> restrictions:
>>     1) No additional packets are sent, just the initial SYN
>>     2) There is no a priori knowledge as to whether or not the remote
>> host understands expanded option space.
>
> I would pose the conditions as follows:
>
>      1) is robust to packet loss, reordering, and alternate paths
>          any assumption of "back to back" packets isn't
>
>      2) does not negatively impact legacy hosts
>          e.g., dual-stack/multiple SYN approaches fail here when
>          a legacy system is trying to connect to an updated one
>          (which has to wait to see if the updated SYN will show)
>
>      3) succeeds through basic NAT/NAPTs
>          anything that uses a nonstandard checksum will fail
>          to support the extended space
>
>      4) addresses new connections to hosts not previously contacted
>          it's trivial to retain state across sequences of
>          connections, as per RFC 2140.


Let me make two rough proposals that could be worth being explored or at 
least documented.

1. The TCP option space is limited, but not the IPv6 destination options 
in the IPv6 header. One possibility to extend the TCP option space, 
notably (but not only) in the SYN would be to place part of the TCP 
option inside an IPv6 destination option. Given that the IPv6 
destination option is only limited by the IPv6 packet size, we are safe 
for the long term and the solution seems to be clean.

  This approach has two limitations :

  - It is a violation of the layering principle since the receiving host 
needs to provide the content of the IPv6 destination option to the TCP 
stack.

  - It only works with IPv6 and does not work with IPv4. In the short 
term, IPv4 support is mandatory, but in the long term IPv6 support is 
clearly more important.


2. TCP assumes that the client proposes the TCP extensions and the 
server selects the ones that it supports. In practice, measurements show 
that the TCP stack running on servers is usually upgraded after the 
stack running on clients. It might be interesting to allow the client to 
insert in the SYN a special option that indicates that it would accept 
new options proposed in the SYN+ACK (or perhaps later). These options 
proposed in the SYN+ACK would be confirmed in the third ACK.


If one of these solutions does not seems completely crazy, I can write a 
more detailed proposal to see how it would work in practice


Olivier