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

Michael Scharf <michael.scharf@ikr.uni-stuttgart.de> Mon, 14 July 2008 12:14 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9783A68FF; Mon, 14 Jul 2008 05:14:02 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B323A6932 for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 05:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A8MnctejcOG for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 05:14:00 -0700 (PDT)
Received: from wall.ikr.uni-stuttgart.de (wall.ikr.uni-stuttgart.de [129.69.170.1]) by core3.amsl.com (Postfix) with ESMTP id 4377A3A683D for <tcpm@ietf.org>; Mon, 14 Jul 2008 05:14:00 -0700 (PDT)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 280B156CDD for <tcpm@ietf.org>; Mon, 14 Jul 2008 14:14:25 +0200 (CEST)
Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 2164BBC081; Mon, 14 Jul 2008 14:14:25 +0200 (CEST)
Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id E52DFBC07E for <tcpm@ietf.org>; Mon, 14 Jul 2008 14:14:24 +0200 (CEST)
Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 14 Jul 2008 14:14:24 +0200
Date: Mon, 14 Jul 2008 14:14:24 +0200
From: Michael Scharf <michael.scharf@ikr.uni-stuttgart.de>
To: tcpm@ietf.org
Message-ID: <20080714121424.GA31382@ikr.uni-stuttgart.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: [tcpm] TCP Long Options - Why not as payload in SYNs?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Hi all,

I wonder whether "modern" TCP stacks indeed process application
payload data in SYN segments.

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.

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