[Softwires] Checksum neutrality and L4-protocol independence

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

I added Dan as destination of this mail, hoping to have his comment.

RD