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

[Rémi Després <[e-mail]>]

Le 2012-02-14 à 16:21, Maoke a écrit :

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

1. A key, that probably hasn't been clarified enough so far (thanks for in fact raising it), is the following:
- With checksum neutrality, the BR DOESN'T NEED to know about UDP, TCP etc. (see R-22 (3) of the 4rd-U draft).

If, by mistake a remote host sends to a shared IPv4 address a packet whose L4 payload has no ports at their usual places, the packet, if it reaches a CE, will ALWAYS be  discarded there (protocol unknown by the NAT44) => no operational problem. 

This is one more instance where it isn't useful to try and guess what mistakes people might make, and to add specific software for them while tools already exist to detect and signal them. (Keep it simple)

OK?


> at least the BR's code should include the new protocol number in to the list of checksum-neutrality-compatible.

See above.

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

2. A less good BR in my understanding: more processing for no appreciable gain.

>  therefore i do agree with Ole's argument.

> if i make anything incorrect, please point out.

See above.

Cheers,
RD


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