Subject: Re: [lisp] IPv6 UDP checksum issue

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Jul 2009 10:47:19 +0300 (EEST)

On Thu, 30 Jul 2009, byzek wrote:
> It's not about performance; a large percentage of the currently-deployed
> hardware can¹t do UDP checksum calculations during encapsulation because it
> doesn¹t have access to the entire packet.  Most hardware is streamlined to
> only provide the first n bytes of a packet to the forwarding engine, where
> typically n < 128.

I'm somewhat sympathetic to this concern, but I've been assured that 
it's possible to compute the outer checksum by doing an incremental 
checksum calculation (see e.g. RFC1624) using the inner packet's 
checksum.  This would not require the access to the whole packet. This 
might work at least when encapsulating IPv4 over IPv6 UDP; I don't see 
how you could do this with IPv6 over IPv6 UDP due to the lack of 
"base" checksum.  Any thoughts on how applicable this could be?

>From the point of view of AMT specification, I don't see the need for 
IPv6 UDP encapsulation, even if you buy the LAG argument (I'm not sure 
if I can see 10G+ of traffic being LISP encapsulated between a couple 
of routers), it doesn't apply to AMT due to different traffic 
patterns.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 4 Aug 2009 20:53:53 -0400

Hi Byzek,

On Jul 30, 2009, at 8:31 PM, byzek wrote:
> hardware can’t do UDP checksum calculations during encapsulation  
> because it
> doesn’t have access to the entire packet.  Most hardware is  
> streamlined to

This is one of the primary reasons, as I understood it, why UDP-Lite  
was defined the way it was -- to allow for a transport-layer checksum,  
including an IP pseudo-header checksum, in IPv6, without the need to  
traverse the entire packet.  In the LISP case, all of the bytes that  
would need to be "checksummed" for UDP-Lite would be bytes that were  
_added to the packet_ by the LISP encapsulating router.

When an IPv4/UDP header is pre-pended by a LISP router, the lisp ETR  
needs to calculate the IP header checksum over 20 bytes (the IP header).

If an IPv6/UDP-Lite header were pre-pended by a LISP router, the ETR  
would need to calculate an IP header checksum over 48 bytes (the IP  
pseudo-header and the UDP header).

While I understand that 48 bytes is larger than 20 bytes, we aren't  
really talking about a major difference when the checksum algorithm is  
well-optimized and all of the pre-pended header bytes are already in  
memory.

Margaret

---

From: byzek <[email-masked]>
Date: Wed, 05 Aug 2009 10:59:46 -0400

Hi Margaret,

> pseudo-header and the UDP header).

I think you mean xTR, correct?  ITR does it on ingress, ETR does it on
egress.

As long as we don't have to go deeper in the packet than that, most hardware
that would be performing encap/decap is at least capable of doing this, yes.

-J

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 4 Aug 2009 15:05:47 -0400

Hi Pekka,

On Jul 31, 2009, at 3:47 AM, Pekka Savola wrote:

> checksum.  This would not require the access to the whole packet.  
> This might work at least when encapsulating IPv4 over IPv6 UDP; I  
> don't see how you could do this with IPv6 over IPv6 UDP due to the  
> lack of "base" checksum.  Any thoughts on how applicable this could  
> be?

You would not be able to incrementally calculate the outer UDP  
checksum based on the inner IPv4 checksum, you would have to do it  
based on the inner UDP or TCP checksum by subtracting the inner IP  
pseudo-header checksum and adding the checksum for the outer IP pseudo- 
header, the UDP header and the inner IP header (all bytes, because it  
is being treated as UDP payload by the outer UDP header).  You might  
run into problems with this approach, though, if you needed to  
encapsulate non-TCP/UDP packets and/or encapsulated IPv4 packets with  
a zero UDP checksum.  In those cases, you'd have to checksum the whole  
packet.
>
> From the point of view of AMT specification, I don't see the need  
> for IPv6 UDP encapsulation, even if you buy the LAG argument (I'm  
> not sure if I can see 10G+ of traffic being LISP encapsulated  
> between a couple of routers), it doesn't apply to AMT due to  
> different traffic patterns.

My understanding is that AMT is using UDP so that they can use  
different UDP ports for different AMT flows, similar to the LAG  
argument for LISP.

Margaret