On 9 Oct 2010, at 07:37, Andrew Lentvorski wrote: > On 10/8/10 7:25 AM, Phelan, Tom wrote: > >> [TomP] There have been several good comments on this already, but one >> thing I'd like to add is, how can this work? The problem is that the >> DCCP checksum includes the IP addresses, which have potentially been >> changed along the way. > > Ah, the DCCP checksum includes fields that aren't part of its packet > (the pseudoheader) with no way to turn that off. That's what I've been > missing. You'll find that TCP, UDP, and all other sane transport protocols also incorporate this demultiplexing pseudoheader check. This is arguably an artefact of the IP/TCP split happening after the initial design. (IPv6 perpetuates it, repeating the layering overlap, and again placing the onus on the transport to get the demultiplexing check right - rather than doing the reverse by say specifying some transport fields such as port as part of the IP header, and making it an IP-level check. But then port numbers would be part of IP...) This is pretty fundamental to Internet transport protocol design. > Wouldn't we be better off having an actual option (negotiable option, > packet flag, DCCP version bump, whatever) that allows us to say "DCCP > packet checksummed without the pseudoheader"? Then you can just pack > everything up in a UDP packet and forget about it. If the UDP pathway > checksums everything, great. If the UDP pathway completely dumps the > checksums, well, you don't care either. We do, because turning up at the wrong node and handing corrupt data up the stack becomes much more likely if the checksum and its demultiplexing check are turned off. And, of course, having a bit saying 'checksum off' is akin to special-casing a zero-value checksum. Interesting things happen if an error flips that bit. > This is effectively what the encap is doing, just in an implicit > mechanism rather than explicitly. And then forcing the UDP layer to > checksum the *entire* packet to protect itself, even if we have told > DCCP that we only want CsCov == 1 (No application payload coverage). Variable checksum coverage is a lost cause. Even if it saves a little checksum processing time, it's likely that channel MAC framing CRCs still cover the entire packet -- so channel errors are prevented. Errors in router memory trashing the tails of packets, or it being trashed while being handed to the MAC layer, remain, but do you want to preserve that trashing? > I'm still concerned about this through multiple NAT layers, but I need > to think about that a little more. Some reading may help, but the RFCs and most textbooks aren't very good at explaining decisions behind design choices. That leaves Stevens vol. 1, which doesn't contain lessons illustrated by modern transport protocol examples - and isn't bothered by NATs. Lloyd Wood L.Wood@xxxxxxxxxxxx http://sat-net.com/L.Wood
