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.
Right, agree.
My point is that allowing this for this corner use case is
essentially lifting the requirement of a mandatory UDP checksum
altogether.
Just lift it for protocols that encapsulate in UDP. That is, for
tunneling protocols where routers encapsulate packets.
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.
Right, LISP specifies to ignore the checksum. Plus a check for zero is
much cheaper than any other UDP "lite" proposals that have been put
forth. It's one instruction in the forwarding path. But we don't have
to do that in LISP.
So basically we'd be reverting the consensus behind RFC2460 to cover
what I see as a corner use case.
I don't think we should do that.
Marshall Eubanks suggested an additional ID that says that UDP
checksums could avoid use for tunneling protocols.
Why can't we just go forward with that idea?
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.
I never suggested updating 2460.
We cannot pick another encapsulation for the reasons I
said before, LAGs.
Are there significant deployments of port-based LAGs in existing
IPv6 networks?
Yes. At least, there are IPv6 routers that have silicon burned to do
this. Even if those routers have not been configured to forward IPv6
packets.
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.
The products will have their own trajectory path. I am active on this
thread so the IETF drafts and the products can be consistent.
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.
What is "this"?
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.
It is not "has now decided", it was drafted day-1 to use UDP because
of important feedback from network operators.
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.
I would like to propose to have a "how UDP checksums are computed by
hosts" and another document that says "how UDP checksums are computed
by tunnel routers". That is a viable path forward I think. What do you
think?
Dino
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
