Fred, I could add, that at the time, it was known that more and more, some newer IPv4 forwarding machines circumvent TRUE checksum validation on input/ingress, and/or recalculation on output/egress. This was facilitated by things already mentioned: the stability of the IPv4 implementations - the "debug" factor mentioned by Fred B. lost its importance - and by the fact that statistically, packet errors caused by faulty links between two routers would be uncovered a lot more often, if not exclusively, at L2.
Performance wise, clever implementations already existed, which would reduce the number of memory accesses involved for checksum calculations - a few to begin with, since it is only a header checksum - by combining the checksum calculation with regular operations on the header fields involved in checksum. Regards, Alex > -----Original Message----- > From: Templin, Fred L [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 11:10 AM > To: Rahim Choudhary; Fred Baker > Cc: [email protected] > Subject: RE: Checksum in IPv6 header > > > Rahim, > > About the layer 2 and layer 4 checksums, from what I have > been told and AFAICT the IPv6 Extension Headers are only > covered by L2 checksums; not L4. The question comes to > 1) how likely is it that an error could occur in the > extension headers that was not caught by the L2 checks, > and 2) how bad would it be if that happened. > > About 1), as Fred said this should only be problematic > when there are implementation errors. That assertion I > believe is supported by the work of Stone et al: > > "When the CRC and TCP Checksum Disagree" > http://citeseer.ist.psu.edu/cache/papers/cs/21401/http:zSzzSzs > igcomm.it. > uu.sezSzconfzSzpaperzSzsigcomm2000-9-1.pdf/stone00when.pdf > > "Performance of Checksums and CRCs Over Real Data" > http://citeseer.ist.psu.edu/cache/papers/cs/1909/ftp:zSzzSzftp > .dsg.stanf > ord.eduzSzpubzSzpaperszSzsplice-paper.pdf/stone98performance.pdf > > especially in the first of these two where it was observed > that only a small number of "bad apple" machines were > responsible for contributing the largest portion of packets > with incorrect header checksums. (But, that work also asserts > that the L4 checksums in the Internet today are inadequate.) > > About 2), there are a number of considerations as to what > would happened if an error occurred in the IPv6 extension > headers that was not caught by the L2 checksums. For example, > if an error occurred in the ID field of a fragment header > there would be possiblity for the fragment of a first packet > to be combined with a fragment of a second packet. But, such > an unlikely combination should be caught by the L4 checksums. > As another example, if an error occurred in an address field > in a routing header, the packet could be mis-delivered. But, > this would appear as simply a lost packet from the > perspective of the intended target and a spurious packet from > the perspective of a target to which the packet may have been > mis-directed. > > I haven't tried to track down all of the IPv6 extension > headers and make analysis of what could happen if an error > occurred, but I think the correct questions in each instance > are: 1) how likely is an error not caught by L2 CRCSs to > occur, and 2) how bad would it be if that happened? > > Thanks - Fred > [EMAIL PROTECTED] > > ________________________________ > > From: Rahim Choudhary [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 7:43 AM > To: Fred Baker > Cc: [email protected] > Subject: Re: Checksum in IPv6 header > > > Thanks. I also heard from Brian McGehee. It is > basically the same reason: efficiency by removing processing > that is deemed unneeded. In this case the layer 2 and 4 > checksums are relied upon and simplification and thereby > performance is achieved at layer 3. > > These are obvious reasons and I have seen them > documented. Wonder on two things: > > 1. one if there were other reasons for not including > checksum in IPv6 header, historically speaking if there was a > contrary view? > > 2. second, concerns the security implication if any. > Yes the checksum was intended for guarding against > transmission errors, not as a security technique. The > question is if there are some unintended security impact > possible? Eventually the presence or absence of a checksum at > layer 3 may be not too important because the checksum can be > recomputed if some malicious change is inserted. > > Thanks for the input. > > > > Fred Baker <[EMAIL PROTECTED]> wrote: > > > On Jan 28, 2008, at 2:03 PM, Rahim Choudhary wrote: > > > This may be a matter that is common knowledge to > this list. But please forgive me for asking. What were the > reasons that the IPv6 working group decided not to include a > checksum field for the IPv6 packet Header? Does it have no > security impact to omit the checksum? > > > The short version is that in general the > checksum found implementation errors, but given a working > system rarely found true operational errors. It's not stupid > as a debug technique, but it doesn't result in packet discard > in real networks, and so was deemed unjustified. > > > > ________________________________ > > Looking for last minute shopping deals? Find them fast > with Yahoo! Search. > <http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.c om/newsear ch/category.php?category=shopping> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
