[e2e] purpose of pseudo header in TCP checksum
touch at ISI.EDU
Wed Feb 16 02:29:47 PST 2005
Michael Welzl wrote:
>>>I also searched RFC 2460 for this once, but couldn't find anything.
>>>Still, that doesn't make sense to me. What if you transfer an
>>>IPv6 packet across a link layer that does *NOT* check your data -
>>>why wouldn't this cause harm to the source / destination addresses,
>>>and therefore cause wrong router behavior downstream?
>>It doesn't cause harm at the destination, since there's supposed to be a
>>transport checksum (even for ICMP - one was added). I suppose there's no
>>perceived harm in sending some corrupted traffic through the wrong paths.
>>Note - this is designed to address corruption, not malicious behavior.
> Okay, I agree that end-to-end integrity is preserved, nothing
> wrong about that. It's just that I find it hard to believe
> that there's no perceived harm in having routers make decisions
> based upon an erroneous IP header. Is sending some corrupted
> traffic through the wrong paths really all that can happen?
> Hm, it could affect the hop limit, too, but who cares.
> Okay, so what about the "payload length" field - couldn't
> it lead to errors (a router allocates a buffer that is way
> too large ... hmmm, do we care?) ...
I don't know if we care much more than we care about misuse of the
> I'm unsure, but still, I find it hard to believe.
Anyone on the list more familiar with the history of IPv6 care to comment?
>>>what about the other fields - say, "next header"; a checksum
>>>error could turn a TCP packet into a UDP packet, change the
>>>payload length field, whatever.
>>Sure - but then that checksum should either match or somebody's
>>overwriting packets anyway, which they can do even if there are IP
>>checksums. Onec you overwrite things, all bets are off.
> I don't get that. There's no IPv6 checksum, so these fields
> could be changed by corruption and noone would notice. We
> could say that we don't care about the "next header" field
> too, because that's relevant in the end system, where the
> pseudo header will take effect.
Again, that appears to be the logic.
> So, I wonder: was the reason not to have an IPv6 checksum:
> * because the assumption was that link layers provide
> strong CRC protection anyway ( = "IP no longer over everything")
> * because end-to-end integrity would be preserved anyway
> and having routers make decisions based on an erroneous
> IPv6 header won't really hurt anybody (I still somehow
> find that hard to believe).
Combination of the two - that link layers that want to check are better
than what IP provided, and that when they don't it's good enough to
check at the transport layer.
There's also a notion (AFAIR) that IP checksums don't catch malicious
behavior or much about link corruption (which is more about bursts than
random, typically) - they have tended to catch buggy implementations,
and the effort of putting that check in all routers isn't worth using it
as a "can you implement a router properly" check (which is more what it
>>>What if we had a CRC-32 checksum in the IPv4 header, in
>>>the IPv6 header, in UDP Lite's header, in TCP's header,
>>>in the UDP header, well - just all over the place.
>>The argument (far as I recall) was that things would be slower, not better.
> Sure, the checksum was removed to speed things up - but,
> see below...
>>>Then, we could just say "disable your checksums" to
>>>link layers when they notice a UDP Lite packet. It would
>>>even make sense to have a "corruption acceptable" bit
>>>somewhere in the IP header in such a scenario (I know,
>>>no bits to spare).
>>>Wouldn't that be better design?
>>Define better. Again, the assumption is that not that many packets are
> Here's a try. Better = "guided by principles (*), not short-sighted
> performance optimizations (**)".
> (*) ... such as "IP over everything"
> (**) ... such as "let's speed things up"
How about "doesn't help for the purpose intended"?
I.e., if the checksum basically helped find buggy router
implementations, not avoiding link errors as much (typically, as will be
discussed), then it's more effort than it's worth.
The idea, again, AFAIR, is that buggy links ought to use link error
detection, not rely on IP layer protection. This may indeed be counter
to the UDP-Lite assumption, but I never bought that one per se anyway.
All this work to get arbitrarily corrupted data to the app seems
misguided, moreso (IMO) than forwarding buggy packets even.
>>corrupted, and that when they are their path doesn't matter so long as
>>the packets aren't accepted at the alleged destination. How would
> Assumption #1 is an ugly one because it breaks the "IP over
> everything" principle and now prevents us from cleanly realizing
> stuff like UDP Lite.
"cleanly realizing stuff like UDP Lite" - poster-child for unclean layer
violation, in how it wants the _app_ to change how the transport
interacts with the link layer? I need to clean my keyboard for just
typing about it ;-)
> Assumption #2 seems strange to me, but okay, if that was it,
> I could live with it (i.e. not call it ugly).
I think it's more like "not worth the effort" than "speeds things up".
The checksum isn't a particularly slow part; it can force a
store-and-forward delay, rather than cut-through processing, as well as
an additional $0.01 of hardware (if that), but it's not slow.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050216/c787ef5e/signature-0001.bin
More information about the end2end-interest