Re: [Softwires] Checksum neutrality and L4-protocol independence

[Maoke <[e-mail]>]

2012/2/14 Rémi Després [e-mail]

>
>
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
>
>
>