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:zSzzSzsigcomm.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: ipv6@ietf.org 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.com/newsear ch/category.php?category=shopping> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
