[Softwires] Checksum neutrality and L4-protocol independence

Rémi Després <despres.remi@laposte.net> Mon, 06 February 2012 08:52 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 04CDE21F85EA for <softwires@ietfa.amsl.com>; Mon, 6 Feb 2012 00:52:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FtlBIpVANWTc for <softwires@ietfa.amsl.com>; Mon, 6 Feb 2012 00:52:07 -0800 (PST)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 4E42F21F85DF for <softwires@ietf.org>; Mon, 6 Feb 2012 00:52:06 -0800 (PST)
Received: from filter.sfr.fr (localhost []) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 48C88700061E; Mon, 6 Feb 2012 09:52:05 +0100 (CET)
Received: from [] (per92-10-88-166-221-144.fbx.proxad.net []) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id C0CDD70002D8; Mon, 6 Feb 2012 09:52:04 +0100 (CET)
X-SFR-UUID: 20120206085204789.C0CDD70002D8@msfrf2114.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>
Date: Mon, 6 Feb 2012 09:52:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C38B2AD1-08F1-4ECD-8ADB-AE88BC34A0B9@laposte.net>
References: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net> <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <C694D7DC-2F98-434F-8123-751E2C1A98D0@employees.org> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <B94D39A0-CA66-4AE6-BDC5-E4DFA2D47BEC@employees.org> <A8A6FDA2-0FFC-44D2-BEDF-29FB012D3113@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>
To: =?iso-8859-1?Q?Ole_Tr=F8an?= <otroan@employees.org>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
Cc: Softwires WG <softwires@ietf.org>
Subject: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2012 08:52:08 -0000

Le 2012-02-05 à 10:05, Ole Trøan a écrit :
>>> any A+P solution requires support for L4 protocols to extract ports.
>>> L4 checksum rewrite, as well as port extraction will have to be supported for all new L4 protocols.
>>> the L4 checksum rewrite approach can work with any checksum algorithm.
>>> that said, do we really think NAT44s will be upgraded to support any new L4?
>> Imagine a variant of the SCTP of RFC4960 is introduced where the TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis (not a bad idea IMHO, but here just a hypothesis to answer your point). 
>> => 4rd-H would be compatible with it without any evolution; RFC6145 would need an upgrade to support it.
>> Upgrading NAT44s to support this SCTP-bis would be trivial (ports as the same place as usual can be mapped as usual.
> my point is that MAP is L4 aware anyway, and has to be modified to support any new transport protocol. since code modifications have to be made, then having a checksum neutral function at the network layer doesn't help much. you still need to change code. L4 rewrite is also more flexible in that it will support _any_ checksum algorithm, and most importantly is already implemented in every node.

Thus, you continue to negate that 4rd-U would support without any change a protocol such as, for example, a SCTP variant using TCP-like checksum instead of its CRC32c checksum.

This negation is AFAIK based on a lack of understanding:
- UDP, TCP, DCCP, SCTP have the same places for port their fields, but have their own places for their checksum fields. 
- A solution based on L4 checksum adjustment MUST know _for each protocol_ where checksum fields are placed.
- A solution based on checksum neutrality of IPv6 addresses doesn't need to know where checksum fields are placed. 
- For address sharing, knowing places of port fields is sufficient.

I added Dan as destination of this mail, hoping to have his comment.