[e2e] purpose of pseudo header in TCP checksum

[Michael Welzl]

> > 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'm unsure, but still, I find it hard to believe.


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

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.

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")

or

* 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).


> > 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"


> 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.
Assumption #2 seems strange to me, but okay, if that was it,
I could live with it (i.e. not call it ugly).


> checksums everywhere help that? Is it necessary (and worth it) to do 
> more (the argument for IPv6 was "no")?

Yeah, I'd say!     :)

Cheers,
Michael