On 2011-08-24 05:29, Nejc Škoberne wrote: >> Agree. I think transmitting packets with invalid TCP checksum field is >> dangerous. >> Stateful NAT is ubiquitous nowadays. > > Simon? How was the conclusion, "that the transport checksum does not > need to be modified", reached?
Look, this is a deployment issue. It is simple. X ----> NAT64 --------> NAT46 ----> Y (Assume NAT46 is the exact reverse of NAT64.) There are two cases: - If there is no layer 4 processing (stateful firewall, DPI, etc.) taking place between NT64 and NAT46, then there is no need to update the layer 4 checksum at NAT64 and NAT46. - Otherwise, then the layer 4 checksum needs updating. Is there anything worth arguing about this? >> Besides, the purpose of checksum is to do error checking. So sending >> packets with wrong checksum does not make sense. (How could the >> translator itself checks the integrity of the packet, if it wants to?) > > Good point. Anyone? The translator does not check the layer 4 checksum. Doing so would be very wrong. It would also imply statefulness because the translator would need to reassemble fragments. Layer 4 checksum validation is done end-to-end, not hop-by-hop. Compare this with layer 3 checksum validation which is done hop-by-hop (and was eliminated with IPv6 because end-to-end checksum is sufficient). See RFC 6145 for the details for the translation algorithm. There is no layer 4 checksum validation nor fragment reassembly. Fragment reassembly is described for the stateful translation algorithm, in RFC 6146. The translation algorithm we're considering for 4rd is of course stateless and corresponds to RFC 6145. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
