[e2e] purpose of pseudo header in TCP checksum

[Joe Touch]

Michael Welzl wrote:
>>IPv6 makes no mention of a problem with 'sending packets god knows 
>>where', so long as they're checked at the receiver. Although IPv6 (at 
>>least as I recall) omits the IP checksum because of sufficient link 
>>checksums to detect corrupted packets, there's no requirement that link 
>>layers have such checksums (as hinted in the UDP-Lite RFC) - at least 
>>not in 2460 (anyone else know anywhere else a body is buried in this 
>>regard?)
> 
> 
> 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.

> And
> 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.

> There must be a requirement for link layers to do a strong
> check somewhere?!

Link won't find routers that rewrite headers ;-) And IP is supposed to 
work over everything - not all link layers have checksums.

>>>So we need to specify that link layers DO check the headers
>>>and just do NOT check the payload if it's a UDP Lite packet.
>>>This is the part that I consider inevitable (given the
>>>current situation) but ugly.
>>
>>The first part, not AFAICT.
>>
>>The second IS ugly. Complain to UDP-Lite - it's definitely reaching 
>>across layers to coordinate the link checksum configuration with UDP's 
>>presence or lack of checksumming.
>>
>>
>>>>IP still works over everything; things that work over IP need to know 
>>>>something about it, as always.
>>>
>>>"over" is fine with me, but I don't like to have things
>>>underneath know so much about it.
>>
>>Agreeed. IMO, that's UDP-Lite's problem, not IPv6.
> 
> 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.

> 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 
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 
checksums everywhere help that? Is it necessary (and worth it) to do 
more (the argument for IPv6 was "no")?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050215/dc4590ad/signature.bin