checksum updating

John Shriver <jas@shiva.com> Thu, 05 January 1995 17:19 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05850; 5 Jan 95 12:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05846; 5 Jan 95 12:19 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10485; 5 Jan 95 12:19 EST
Received: from Shiva.COM by venera.isi.edu (5.65c/5.61+local-20) id <AA18042>; Thu, 5 Jan 1995 08:22:11 -0800
Received: by Shiva.COM (1.34b) Thu, 5 Jan 95 11:20:46 EST
Date: Thu, 5 Jan 95 11:20:46 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Shriver <jas@shiva.com>
Message-Id: <9501051620.AA04749@Shiva.COM>
To: anil@netcad.enet.dec.com
Cc: fred@cisco.com, rreq@isi.edu
In-Reply-To: Anil Rijsinghani 05-Jan-1995 1032 -0500's message of Thu, 5 Jan 95 10:35:39 EST <9501051535.AA20030@us1rmc.bb.dec.com>
Subject: checksum updating

   Date: Thu, 5 Jan 95 10:35:39 EST
   From: Anil Rijsinghani  05-Jan-1995 1032 -0500 <anil@netcad.enet.dec.com>
   To: fred@cisco.com
   Cc: jas@Shiva.COM, rreq@isi.edu
   Subject: Re: checksum updating

   If you do so (I think it would be a good idea), please add a reference
   to RFC1624.

   Anil

Yes, indeed!  Citing RFC 1071 without citing RFC 1624 looks like a
mistake.  (Especially since our product currently recomputes the
checksum from scratch!)

Bugs that cause 1 in 65536 packets to lose are not fun...