There were additional secondary considerations. The IPv6 headers were carefully crafter and compartmented, in terms of functionality. The main header was carefully crafted not only to carry the very essential information for delivering the packet to the next hop, but also in terms of its size, and alignment of its fields. The alignment was a criterion for faster processing - for instance, the IPv6 addresses, have 8 byte alignment. Furthermore, the entire main header yields 8 byte alignment to the next header. Header integrity, which you refer to, seems to me of going beyond just uncovering some hardware or software errors between the transmitting and receiving of the IP header, which is the (only) object of the IPv4 checksum. In that regard, as its function is really one IP hop, it still stands that an IPv6 checksum, if it existed, it would have only duplicated the functions of the L2 checksum as far as the header is concerned even in cases when the IP one hop corresponds to multiple L2 hops, Integrity, in terms of security, was considered part of the functionality and job which was assigned to the IPsec headers. Regards, Alex -----Original Message----- From: Rahim Choudhary [mailto:[EMAIL PROTECTED] Sent: Thursday, January 31, 2008 11:49 AM To: Alex Conta; 'Templin, Fred L'; 'Fred Baker' Cc: ipv6@ietf.org Subject: RE: Checksum in IPv6 header
This is very interesting insight into what actually guided the decision to exclude the checksum field from the IPv6 header. However there were alternatives possible. For example it could be retained and its usage made optional. Further the usage could be allowed to employ a cryptographic hash of the header bits. That would have guaranteed integrity for the entire IPv6 header, though everyone would not be forced to use it. Such a guaranteed integrity for the packet header is currently not available, even with the use of IPSec because of the matter of the mutable fields. From this angle it could be argued that not including the "checksum" field amounts to a lost opportunity. Perhaps security did not have such an overarching posture in those days :-) Rahim Alex Conta <[EMAIL PROTECTED]> wrote: 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: ipv6@ietf.org > 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: 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 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. > om/newsear ch/category.php?category=shopping> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _____ Never miss a thing. Make Yahoo <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs> your homepage.
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------