Hi Dino,
On Jul 30, 2009, at 4:25 PM, Dino Farinacci wrote:
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator
(ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how much of a performance impact we're
talking about here? I was under the (maybe naive) impression that
checksum offloading was practically ubiquitous these days.
One of the problems with IPv6 is that is so similar to IPv4 but
different enough to cause pain for implementations. So since we can
use 0 UDP checksums for IPv4 in UDP in IPv4, we would want to build
(or use existing hardware) that does IPv6-or-IPv4 in UDP in IPv6.
Reasons being (1) cost in building hardware, (2) chip area, (3)
power, (4) complexity, and (5) inconsistency from IPv4.
This is only for encapsulated packets. This is for the outer header
only.
The problem, as I see it, is that when you set the UDP checksum to 0
in IPv4 and IPv6, you aren't doing the same thing in both cases...
In IPv4, there is an IP header checksum that protects the IP source
and destination addresses. So, when you turn off UDP checksums in
IPv4, you are only turning off checksums for the UDP header and the
UDP payload (in this case, an encapsulated packet). You still need to
calculate the IP header checksum.
In IPv6, the only checksum for the IPv6 source and destination
addresses is included in the UDP checksum (via the IPv6 pseudo-header
checksum). So, when you turn off UDP checksums in IPv6, you are also
turning off checksums for the IPv6 source and destination addresses.
For cases where the payload is loss-tolerant and/or protected by a
different mechanism, we have defined UDP-Lite, which allows you to
calculate a checksum on the header fields only, not on the entire
payload. This is not much more computational expensive than computing
the IP header checksum for IPv4-encapsulated packets.
So, we have two standards-compliant alternatives in IPv6 that would
not require you to calculate a UDP checksum on the entire payload:
(1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable
choice for LISP encapsulation? When we looked into this for CAPWAP
(another IP-in-UDP/IP tunneling case), we found that UDP-Lite would
meet our needs for IPv6, so we did not need to specify the use of zero
UDP checksums.
(2) IP-in-IPv6: Why do you need the UDP encapsulation at all in
IPv6? In IPv4, you may need it for NAT traversal, but it is not clear
that NATs will work the same way in IPv6. Or are there other reasons
why you need the UDP encapsulation? When you encapsulate IP in IPv6,
you do not have a checksum that covers the outer IP header, so you
would need to make sure that LISP is robust against corruption of the
source and destination addresses. However, you do not have to worry
as much about confusing non-LISP applications and/or corrupting their
data, as there won't be a transport header there to misdeliver LISP
packets to an unsuspecting application if the addresses and/or ports
are corrupted.
I personally think it is important to consider the standards-compliant
choices before we decide to do something non-standards-compliant.
FWIW, I agree that practical needs are very important. I am just not
sure that we can't meet the practical needs with a standards-compliant
solution.
Margaret
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
