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

[Maoke <[e-mail]>]

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.

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


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). i understand Ole has the same opinion: as we anyway
have it, we don't need it in the address scheme standard (but it could be a
recommendation for the operators to enable the address-level checksum
neutrality, 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


>
> I added Dan as destination of this mail, hoping to have his comment.
>
> RD
>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>