On 2011-08-24 06:21, Nejc Škoberne wrote: > Dear Simon, > >>>> A consequence is that the 4rd address >>>> scheme does not need to care about checksum neutrality (contrary to e.g. >>>> NAT64 >>>> and NAT66). >>> >>> Sorry, but I don't understand this. Can you please paraphrase? >> >> Please refer to: >> http://tools.ietf.org/html/rfc6052#section-4.1 >> http://tools.ietf.org/html/rfc6296#section-2.6 > > Please correct me if I am wrong: > > - The RFC 6145-compliant stateless NAT64 solutions do not have to > recalculate transport-layer checksums if and only if the Well-Known > Prefix or a checksum-neutral Network-Specific Prefix is used and > if the suffix is 0.
Right. > - All double stateless NAT64 solutions (dIVI, 4via6-T), since they > can not have checksum-neutral IPv6 addresses (because they also > encode port-set ID) MUST recalculate transport-layer checksums or > else they are not RFC 6145-compliant. First, I think it would be feasible to change the 4rd address scheme so that the IPv6 prefix is checksum-neutral, even with encoding the port set ID. But it would be super complex, so I'm not pursuing this idea further. Second, I don't like the term "RFC 6145-compliant". In the 4rd-T draft one could specify that the RFC6145 algorithm is used with the exception that the transport checksum is not updated. There is no "compliance" involved. We're free to specify that if it makes sense. > So are you saying, that it is OK if we choose to not recalculate > checksums (and therefore violate RFC 6145) in > case we are sure, that there will be no transport-layer processing > between the CPE and AFTR in double stateless NAT64 scenarios? Once again, I dislike the "violate" term. If the exception is written in a hypothetic 4rd-T RFC, then we're fine and nobody's violating anything. Beyond that remark, yes, that's exactly what I'm saying. 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
