[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
- [tcpm] TCP Long Options - Why not as payload in S… Michael Scharf
- Re: [tcpm] TCP Long Options - Why not as payload … Adam Langley
- Re: [tcpm] TCP Long Options - Why not as payload … Joe Touch
- Re: [tcpm] TCP Long Options - Why not as payload … Michael Scharf
- Re: [tcpm] TCP Long Options - Why not as payload … Joe Touch
- Re: [tcpm] TCP Long Options - Why not as payload … Adam Langley
- Re: [tcpm] TCP Long Options - Why not as payload … Caitlin Bestler
- Re: [tcpm] TCP Long Options - Why not as payload … Joe Touch
- Re: [tcpm] TCP Long Options - Why not as payload … Joe Touch
- Re: [tcpm] TCP Long Options - Why not as payload … Joe Touch
- Re: [tcpm] TCP Long Options - Why not as payload … Christian Huitema
- Re: [tcpm] TCP Long Options - Why not as payload … Sergio Freire
- Re: [tcpm] TCP Long Options - Why not as payload … Joe Touch
- Re: [tcpm] TCP Long Options - Why not as payload … Adam Langley
- Re: [tcpm] TCP Long Options - Why not as payload … Joe Touch