Hi,we're going in circles, maybe because I'm unclear. I'll try to explain my concerns in a different way, respond to some of your points below, and then go silent for a while to let others chime in.
I think we're all on the same page that there needs to be a checksum somewhere to protect against misdelivery to an application and data corruption.
With IPv4, there's some redundancy, because the IPv4 checksum and the transport checksums cover some of the same fields.
That redundancy was removed in IPv6 by eliminating an IPv6 checksum, to reduce forwarding cost. The transport checksum was made mandatory. The transport checksum is costlier to calculate than an IP header checksum, because it includes the data, but the argument was that endpoints have the capacity to do this.
Now, if a transport protocol is used for tunneling IP inside its payload, it no longer strictly needs to checksum-protect its payload *if* you require for the inner IP packet and its payload to be protected by some sort of checksum.
My point is that allowing this for this corner use case is essentially lifting the requirement of a mandatory UDP checksum altogether.
Why? Nobody is going to implement a check that verifies that if a UDP checksum of zero is encountered, that the payload of this UDP packet contains an IP packet that has a payload that is protected by some checksum. It's just too complicated.
So basically we'd be reverting the consensus behind RFC2460 to cover what I see as a corner use case.
Now, on to the specific points in your latest email: On 2009-7-31, at 8:58, Dino Farinacci wrote:
I already told the list the cost of "sacrificing some gates". It's a non-starter.
Please understand that for some of us, the idea of updating RFC2460 at this time is pretty close to a non-starter.
We cannot pick another encapsulation for the reasons I said before, LAGs.
Are there significant deployments of port-based LAGs in existing IPv6 networks?
Let me be blunt: If you are going to ignore IETF consensus, why are you here?I am not ignoring IETF consensus. I am trying to convince you, and would urge the IETF to be practical. This is not a big issue, should have been resolved but has been argued since Vancouver IETF.
The paragraph in your original that I replied to here said: "Sorry, but we want to build practical products. If you don't build practical standards, vendors will violate them." To me, this sounds like you are going to do whatever you are going to do, independent of what the current IETF consensus in RFC2460 is.
When you require a forwarder to do an entire packet checksum which must be added into a pseudo header checksum of some fields which are not in contiguous memory, it requires more RTL, additional buffer and memory usage and a lot of time to add in every byte (that increases forwarding latency which users do not like). Entire packet checksums has *never* be done in any shipping router product.
I understand that the overhead of computing a payload checksum is higher than computing a header checksum. I also understand that routers did not need to do this in the past.
LISP, an experimental protocol, has now decided to use UDP on routers with IPv6. The result is that according to the current IETF consensus, this leads to a situation where LISP boxes need to compute UDP checksums.
My personal opinion is that revising the IPv6 consensus around UDP over IPv6 for the purposes of an experimental protocol is not productive at this time. If the IETF comes to a different consensus, I'm fine with being in the rough on this. This is how our decision process works.
Thank you, Lars
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
