2012/2/14 Rémi Després [email protected] > > 2) in the environment where single translation is also envolved (either > stateless or stateful), L4 checksum rewriting is a MUST because sometimes > there is only one address of the (src, dst)-pair following the > checksum-neutral address scheme. (this is mentioned in RFC6052, giving up > to enforce the checksum-neutrality in the address format, to my knowledge). > > > I have aways acknowledged that L4 update is necessary for single > translation, no disagreement. > But here the problem is stateless IPv4 service across IPv6, a different > problem where there is no such necessity. > >
RFC6052 includes also the double-translation case. i guess operators wouldn't like to deploy different translators here for single translation while there for double. > > The point is that, where it can be used, checksum neutrality is MORE > GENERAL than L4 update. > > how do you define the "generality"? doing L4 update is a safe choice no matter if the addresses are checksum-neutral or not. > > Besides, but less important, it is simpler as far as the number of > specifications it depends on is concerned (no need to know where checksum > fields are for different protocols). > > > > i understand Ole has the same opinion: as we anyway have it, > > > There can be implementations of BRs that are independent of single > translation. > They don't need to know where checksums are placed in various protocols. > > > we don't need it in the address scheme standard > > > One can live with a standard less good than it could be but, since we are > working for the future, let's make them as good as we can now. > In any case, this is no excuse to claim that, with checksum neutrality the > following is not correct "BRs need no change for any new protocol having > ports at their usual place and TCP-like checksum" (DCCP, SCTP if it would > acce^t TCP-like checksum, any other.) > > i think making L4 checksum update is a safe choice for standard. once we have a new L4 protocol, the BR surely need a change to check if this new protocol is a TCP-checksumed one. at least the BR's code should include the new protocol number in to the list of checksum-neutrality-compatible. A better BR needs also to check the packet integrity with ensuring that the checksum is correct and there a L4 activity is not avoidable. therefore i do agree with Ole's argument. if i make anything incorrect, please point out. best, maoke > (but it could be a recommendation for the operators to enable the > address-level checksum neutrality, > > > What remains to be seen is what is gained by not having it a MUST while we > are specifying a new standard for a new problem. > > Cheers, > RD > > put in either prefix or interface id, through the address assignment, in > order to help any L4 protocol when its TCP-flavor checksum rewrite happens > not to be considered/implemented). > > cheers, > maoke > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
