Re: [TERNLI] Forwarding corrupt packets

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 04 September 2006 17:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIBV-0005Eu-3F; Mon, 04 Sep 2006 13:24:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKIBU-0005Ep-55 for ternli@ietf.org; Mon, 04 Sep 2006 13:24:32 -0400
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKIBS-0005h5-OT for ternli@ietf.org; Mon, 04 Sep 2006 13:24:32 -0400
Received: from [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k84HOK8S007315; Mon, 4 Sep 2006 18:24:20 +0100 (BST)
Message-ID: <44FC6144.7000701@erg.abdn.ac.uk>
Date: Mon, 04 Sep 2006 18:24:20 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: University of Aberdeen, UK
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [TERNLI] Forwarding corrupt packets
References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> <44F83E74.1080603@isi.edu> <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> <44F84AD5.7070307@isi.edu> <1157131227.3192.220.camel@lap10-c703.uibk.ac.at> <44F8780D.9060503@isi.edu> <1157356740.3197.57.camel@lap10-c703.uibk.ac.at> <44FC4DF4.8090004@isi.edu>
In-Reply-To: <44FC4DF4.8090004@isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Spam-Status: No
X-Spam-Score: -2.8 (--)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: ternli@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

So, from a quick look:

The first place I looked was the book on IPNG by Bradner and Mankin, and 
this say (p193, from Craig Partridge) and I found:

"IP Header Checksum. There has been discussion indicating that the 
IP[v4] Checksum does not provide enough error protection to warrant its 
performance impact. The argument states that there is almost always a 
stronger datalink level CRC, and that end-to-end protection is provided 
by the TCP Checksum. Therefore, an IPng checksum is not reqiuired."

This was the basis of what I understood, when working with UDP-Lite, and 
also what was finally was expressed in RFC3819:

   " Any new subnetwork designed to carry IP should therefore provide
     error detection at least as strong as the 32-bit CRC specified in
     [ISO3309]."

Section 8.3 said:

   "Errors in other IPv6 header fields may go
    undetected within the network; this was considered a reasonable price
    to pay for a considerable reduction in the processing required by
    each router, and it was assumed that subnetworks would use a strong
    link CRC."

It would be good to uncover more IETF History.

Gorry