Checksum goals in IPFF: 1. support for IPsec ESP NAT (+PAT) 2. ILNP 3. Device Mangling 4. be short IPsec NAT, ILNP, Device Mangling, be short, be fast ooooo +++- IP-layer checksum + protects all data + TCP-layer checksum (data only) ++-+ IP-layer checksum + protects all data +++- IP-layer checksum; header only + port + TCP-layer checksum (data only) ++-- IP-layer checksum; header only + TCP-layer checksum (data+port) ---+ TCP-layer checksum; covers IP pseudo-header (like IPv6) We can't defend vs Mangling devices fully, sadly. (without encryption) What if data-mangling device (NAT), changes port, and re-computes new good checksum on it... ? Server will accept a valid-data of a packet, that doesn't belong to the session. Basically, due to "shortness" requirements, it is hard to build better checksums than in IPv6. (TCP checksum covers parts of IP) Only thing, is that I consider upgrading IPFF TCP to CRC32, which will take 4 more bytes of overhead. ILNP-like concept can be done at transport-layer (like MP-TCP). -- -Alexey Eromenko "Technologov"