Date: Thu, 30 Dec 1999 10:55:43 -0800 From: "Justin C. Walker" <justin@apple.com> To: freebsd-net@freebsd.org Subject: Re: Two many CRCs? Message-ID: <199912301855.KAA00672@rhapture.apple.com> In-Reply-To: <199912290213.SAA01337@walker3.apple.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Fernando Ariel Gont <fgont@softhome.net> > Date: 1999-12-30 03:02:54 -0800 > To: justin@apple.com > Subject: Re: Two many CRCs? > Cc: freebsd-net@FreeBSD.ORG > In-reply-to: <199912290213.SAA01337@walker3.apple.com> > X-Sender: fgont@pop.softhome.net > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 > > At 18:13 28/12/1999 -0800, Justin C. Walker wrote: > > >Third, there's still a chance (cosmic rays, you know) that a packet > >really might get munged after it is in host memory, but before the > >stack layers have their look at it. This is possible, and has been > >observed. It gets less likely over time. > > Ok, but... Was that taken as a *reason* for adding a CRC field? > I mean, I can't understand that a CRC field was added because someone thought that > the packets could get damaged in memory... If so, what about the OS code that is in > memory???? This has to be viewed through a lens of history (or, in reality, "history as recalled by those with faulty recall" :-}). CRC's were put in the IP Family of Fine Protocols to provide some level of assurance that (end-to-end, as someone else pointed out) the chances of packet munging were minimized. CRCs were put in the various media that IP uses independently of IP (IP isn't the only thing using ethernet, and ethernet wasn't invented so that IP could work). The bit about cosmic rays is just an observation, and wasn't part of the reasoning at the time (far as I know). > >Forth, the protocol CRCs cover different portions of the packet. > >For IP, it's *just* the IP header; for TCP, it's just the TCP > >"packet" (plus the "pseudo header"). > > Ok, but.... why isn't there only one CRC field at the IP layer that covers the > *whole* IP datagram? > If it were like this, I think a CRC field at TCP or UDP would not be necessary... The point to the split of CRC coverage is that IP deals with forwarding packets through a mixed bag of network fabrics; the important point at that layer is to assure that the header is correct (else the routing scheme goes to hell). For transport layers, the protocol designer is free to require (or not) a CRC covering the transport bits. To sum this one up, I think the use of IP header checksums has been judged (based on IPv6) to be extraneous; those for transports (because of end-to-end issues) have not. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912301855.KAA00672>