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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
