Re: [TERNLI] Forwarding corrupt packets

Joe Touch <touch@ISI.EDU> Mon, 04 September 2006 16:02 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GKGtv-00081X-Uy; Mon, 04 Sep 2006 12:02:19 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GKGtu-0007zo-2v for; Mon, 04 Sep 2006 12:02:18 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GKGts-0000aJ-NI for; Mon, 04 Sep 2006 12:02:18 -0400
Received: from [] ( []) by (8.13.8/8.13.6) with ESMTP id k84G1vGo023429; Mon, 4 Sep 2006 09:01:57 -0700 (PDT)
Message-ID: <>
Date: Mon, 04 Sep 2006 09:01:56 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20060719)
MIME-Version: 1.0
To: Michael Welzl <>
Subject: Re: [TERNLI] Forwarding corrupt packets
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EAA8E7D0EAE85CFB4290C91"
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Michael Welzl wrote:
>> The question is the impact of the bad packet.
>> If the transport reacts to corrupt packets - as would be the case with
>> UDP-lite and some configs of DCCP - that would be very bad. The
>> difference is whether we're talking about corrupted data and corrupted
>> headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are
>> designed for). Corrupt headers are VERY bad to forward.
> I still don't get it - no matter how you use them, the
> reaction of DCCP and UDP-Lite would always be to silently
> discard a packet if the transport header is wrong, so
> no harm is being done (except for the potential waste of
> bandwidth you mention above, but we agree that this isn't
> substantial).

Bad body, good header: the harm is the bandwidth to the correct
endpoint; the benefit is that this endpoint knows something legitimate,
and the packet serves as its own corruption signal

Bad header: the harm is the signal is sent to the WRONG endpoint.

I reviewed the Feb 2005 discussion on this issue from End2end-interest.

Here's the summary:

- IPv6 does NOT, in RFC2640, require link checksums (as UDP-Lite does).

The relevant text is:

> Although IPv6 (at 
> least as I recall) omits the IP checksum because of sufficient link 
> checksums to detect corrupted packets, there's no requirement that link 
> layers have such checksums (as hinted in the UDP-Lite RFC) - at least 
> not in 2460 (anyone else know anywhere else a body is buried in this 
> regard?)

I saw no followup to that question.

- I said that UDP-Lite's requirement of link checksums was an ugly layer
violation. I still think that's the case.

As far as I can tell, UDP-Lite is relaxing a requirement in IPv6 -
allowing partial link checksums rather than full, but I can't locate
that requirement, as per above.


I don't have a problem with forwarding the information to the wrong
place; I have a problem with the wrong place acting on it. You're
assuming that the UDP-Lite partial checksum is sufficient to avoid that;
for some reason, the UDP-Lite authors and WG clearly did not.

It'd be useful to review the UDP-lite discussions as to why that text
was required so prominently.