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, 05 Jan 1995 11:20:46 -0500
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...
- checksum updating John Shriver
- Re: checksum updating Fred Baker
- Re: checksum updating Anil Rijsinghani 05-Jan-1995 1032 -0500
- checksum updating John Shriver