search

furry13 / v6ops-464xlat-enable

1 stars 1 forks source link

offer a MAY for implementors who may not want to ensure their address is checksum neutral #29

Open mstojens opened 3 months ago

mstojens commented 3 months ago

Notes:

oskar456 commented 3 months ago

Yes! I think the whole checksum neutrality is a bit overrated.

The whole 464XLAT will almost never be checksum neutral, unless the PLAT has a huge pool of /16 IPv4 and do some clever address selection based on source IPv6 address.

So all the hypothetical unknown application protocols that would not be broken by CLAT if checksum neutral address is used would still get eventually broken by PLAT.

justinsapp commented 3 months ago

Thanks for calling this out, Tommy. I believe the checksum adjustment algorithm from RFC 3022, section 4.2 can be applied here:

[4.2](https://www.rfc-editor.org/rfc/rfc3022#section-4.2). Checksum Adjustment

Since all of the relevant checksums are using simple ones' complement sums, we should be able to cache the checksum difference between the v4 CLAT address and the v6 CLAT address, and then the adjustment becomes a very simple O(1) operation of adding/carrying an additional 16 bits to the checksum for each packet.

furry13 commented 3 months ago

I still see benefits for checksum neutrality:

justinsapp commented 3 months ago

Thanks for bringing up those points.

Re: performance, I'm curious if the CLAT code was re-summing all of the bytes in each packet/datagram when calculating new checksums (an O(n) algortithm?). I could see that causing a performance hit, but it's harder for me to imagine the single addition operation from RFC 3022 section 4.2's algorithm causing much of a blip on the radar.

I also believe this is somewhat likely to turn into a latency vs. throughput issue w.r.t. to initial setup, as machines will be trying to create checksum-neutral addresses for the same 192.0.0.0/29 IPv4 address space, and there are bound to be collisions between IPv6 checksum-neutral addresses, which would potentially add extra seconds to the initialization time for additional DAD checks, as opposed to nanoseconds for each O(1) checksum adjustment operation.

Re: compatibility with upper-layer protocols, from what I understand, checksum-neutral addresses are only guaranteed to be useful if these new protocols are also using 16-bit ones' complement sums (by definition, a "checksum-neutral address" is "IP-checksum neutral" right?), so the O(1) algorithm from RFC 3022 section 4.2 would have the same effectiveness there.

It seems like some implementors may prefer to use checksum-neutral addresses, while others may prefer to use the O(1) adjustment algorithm. Implementors could even make this a system-admin-adjustable parameter for those who want to choose optimization of either latency or throughput.

There's probably no reason to use an O(n) algorithm in software for the checksum adjustment, except for ease of re-using existing code. The code can just cache the 16-bit integer difference between the IP-checksum of the v6 address bytes and the IP-checksum of the v4 address bytes, and adjust each packet's checksum by adding that single value.

justinsapp commented 3 months ago

Just following up with one more thought, one way to handle this in the text might be to specify something along the lines that implementors "SHOULD use checksum-neutral IPv6 addresses, the O(1) checksum adjustment algorithm described in RFC 3022 section 4.2, or some other means of checksum adjustment that takes advantage of the constant difference between IPv4 and IPv6 checksums for translated packets. Implementors SHOULD NOT recalculate entire IPv6 checksums for packets where an IPv4 checksum has already been calculated, as the previously mentioned O(1) techniques offer greater efficiency."

Not sure about the language there, but maybe that contrast would be a good way to illustrate the concept of efficient checksum adjustment?