Re: RFC 1812, section 4.2.2.5

[Noel Chiappa <[e-mail]>]

    From: Tony Li <[e-mail]>

    having IPv4 and IPv6 with completely inconsistent design criteria simply
    indicates SOME semblance of irrationality on behalf of the IETF.

No, not necessarily, goals (and attitudes) change. IPv4 had a header checksum
since we assumed, without thinking hard (as I recall) that we needed one.
Steve Deering made a reasonable argument that it doesn't buy you that much,
and it was dropped from IPv6.

Not sure which way I lean, to be honest; most protocols now have their own
checksums which will tend to prevent misdirected packets from causing any
harm. So maybe it's OK. In any case, this is the wrong place to open the IPv6
can...

    Either a) the header checksum is important, in which case interpretation 1
    makes sense ... xor b) the header checksum is unimportant in which case
    interpretation 2 is perfectly acceptable

Now, this much is true. If header checksums aren't that big a deal, routers
can just update checksums, not check them on every hop (and then adjust them).

I had always assumed that the Right Thing To Do in an IPv4 router was check
the checksum, and then update it (i.e. interpretation 1). In line with the
thought above, some brave soul(s) might want to try out interpretation 2.

I would recommend that one MUST default to interpretation one (for
conservatism's sake, and continue the current practise; I know, this means you
can't build your hardware to ignore the checksum), but one MAY have a switch
that can be flipped to change checksum handling to interpretation 2.

Of course, if you're brave and don't mind selling a non-compliant router, you
can skip the MUST and just always do 2...

Mind you, anyone buying such a router should ask themselves what happens if we
start including options widely; any hardware which is too dumb to do a
checksum is probably going to croak if a high % of packets have an option in
them. It's perfectly possible to build hardware that can deal with both.

	Noel