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

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

Le 2012-02-14 à 12:09, Maoke a écrit :

> Remi, Ole, and others,
> 
> sorry but i follow this quite late due to recent busy work. i would like to share some of my understandings to this issue. 
> 
> 2012/2/6 Rémi Després <[e-mail]>
> 
> Le 2012-02-05 à 10:05, Ole Trøan a écrit :
> ...
> >>> any A+P solution requires support for L4 protocols to extract ports.
> >>> L4 checksum rewrite, as well as port extraction will have to be supported for all new L4 protocols.
> >>> the L4 checksum rewrite approach can work with any checksum algorithm.
> >>> that said, do we really think NAT44s will be upgraded to support any new L4?
> >>
> >> Imagine a variant of the SCTP of RFC4960 is introduced where the TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis (not a bad idea IMHO, but here just a hypothesis to answer your point).
> >> => 4rd-H would be compatible with it without any evolution; RFC6145 would need an upgrade to support it.
> 
> i understand that Remi's concern is, RFC6145 left an "OPTIONAL" for the support of the DCCP checksum. this "OPTIONAL" may impact as 1) for the single translation, DCCP checksum check might fail in the alien protocol family; 2) for the double translation, there is a risk that the sender-translator has done the L4 checksum rewrite while the receiver side doesn't, and thus the DCCP checksum transparency is voilated. the same concern is applicable for the SCTP, if someday TCP-fashion checksum is applied too.

This is indeed one point.

> if the both sides consistently do not do L4 checksum-rewriting for DCCP, there is no problem for the end-to-end communication but only the boxes in IPv6 domains, if they check the L4 checksum to approve the packet integrity, might drop packets with wrong checksum. it could be a recommendation if RFC6145 would make the L4 checksum rewriting fixed for any protocols or make an emphasis on the consistency in configuration, (i.e., OPTIONAL in the term of domain operation rather than in the term of equipment making/configuration). 
>  
> >>
> >> Upgrading NAT44s to support this SCTP-bis would be trivial (ports as the same place as usual can be mapped as usual.
> >
> > my point is that MAP is L4 aware anyway, and has to be modified to support any new transport protocol. since code modifications have to be made, then having a checksum neutral function at the network layer doesn't help much. you still need to change code. L4 rewrite is also more flexible in that it will support _any_ checksum algorithm, and most importantly is already implemented in every node.
> 
> Thus, you continue to negate that 4rd-U would support without any change a protocol such as, for example, a SCTP variant using TCP-like checksum instead of its CRC32c checksum.
> 
> This negation is AFAIK based on a lack of understanding:
> - UDP, TCP, DCCP, SCTP have the same places for port their fields, but have their own places for their checksum fields.
> - A solution based on L4 checksum adjustment MUST know _for each protocol_ where checksum fields are placed.
> - A solution based on checksum neutrality of IPv6 addresses doesn't need to know where checksum fields are placed.
> - For address sharing, knowing places of port fields is sufficient.
> 
> however, dear Remi, the problem is,


ANOTHER problem. 
The point just above remains true, right?
 
> even we have the checksum neutrality in address scheme, there are still some problems need to concern:
> 1) ICMPv6 checksum contains pseudo-header like TCP while ICMPv4 doesn't and therefore the checksum rewrite is anyway needed for ICMP; we cannot ensure that future L4 procotols may definitely have the same checksum as in TCP.

ICMP is as subject per se, and dealt with as such.
(ICMP isn't a transport protocol having _port fields at their usual place_)
>  
> 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.

> therefore, even it is possible that the address scheme could support checksum neutrallity, the equipment designer must anyway make the module for L4 rewrite for any well-known L4 protocol (and fortunately it is not a big coding at all).

Coding complexity is not the point (trivial in both cases).
The point is that, where it can be used, checksum neutrality is MORE GENERAL than L4 update.
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.)
 

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