Subject: [lisp] IPv6 UDP checksum issue

From: Marshall Eubanks <[email-masked]>
Date: Tue, 28 Jul 2009 03:56:16 -0400

This is a reminder that  draft-fairhurst-6man-tsvwg-udptt and

http://tools.ietf.org/html/draft-eubanks-chimento-6man-00

are still open and will be discussed at the 6man meeting Wednesday.

Basically, one prescribes no checksum for the "outer" packet in
IPv6 encapsulations, the other a fixed checksum per flow. My
understanding is that this matter is relevant to LISP.

If you are interested, please try to attend as a decision may be made  
soon.

Regards
Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Jul 2009 05:02:51 -0700

> If you are interested, please try to attend as a decision may be  
> made soon.

Sorry, I have a conflict right now. But here is the position of one  
LISP implementor and a coauthor of the LISP specifications:

 From a practical perspective, we prefer that a LISP encapsulator (ITR  
and PTR) not incurred additional work when encapsulating packets. The  
main LISP spec indicates:

(1) The UDP checksum in the outer header MUST be set to 0 by an  
encapsulator.
(2) The decapsulator MUST ignore the UDP checksum.

We stand by this text and see no reason to change it.

There are no practical reasons to use outer header UDP checksums  
regardless of the 4 combinations of packet types (v4-in-v4, v6-in-v6,  
v6-in-v4, or v4-or-v6) being forwarded by LISP routers.

Dino

>
> Regards
> Marshall
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Jul 2009 14:09:45 +0200

On 29 jul 2009, 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. The main LISP spec indicates:

> We stand by this text and see no reason to change it.

Others, please note that this is orthogonal to the discussion at hand,  
as LISP packets will not go to unsuspecting IPv6 hosts, while with the  
help of a translator, legal-but-ill-advised IPv4 packets with UDP  
payload without a checksum will.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 30 Jul 2009 12:49:49 -0400

> We stand by this text and see no reason to change it.

Are you using "we" to refer to yourself as both an implementor and a  
co-author?  ;-)

FWIW, I have serious concerns about draft-fairhurst-6man-tsvwg-udptt,  
as it involves overloading the UDP "next-header" value to refer to two  
different header types (real UDP and UDP-TT).

However, I also have serious concerns about using zero UDP checksums  
with IPv6.
> regardless of the 4 combinations of packet types (v4-in-v4, v6-in- 
> v6, v6-in-v4, or v4-or-v6) being forwarded by LISP routers.

I think that this statement is answering the wrong question...

Since we have standards-track protocols that indicate that UDP  
checksums must not be zero in IPv6 (for good reasons), I believe that  
we should use valid UDP checksums in IPv6 outer headers, unless we can  
provide practical (and compelling) reasons why _not_ to do so.  So,  
what are those reasons?

If we do manage to achieve consensus that it makes sense to zero-out  
the UDP checksum in IPv6 outer headers, there are a number of  
questions we will have to answer...

The problem with eliminating the UDP checksum in UDP over IPv6 is that  
(unlike in IPv4) the IPv6 source and destination addresses are not  
protected.  So, the packet may be corrupted such that it is sent to  
the wrong destination.  When it arrives at the wrong destination, it  
may be processed by an IP stack that is unaware of LISP.

We need to consider what will happen if one of these packets is  
received by a non-LISP node.  Are you assuming that non-LISP stacks  
will simply throw away these packets, because they have zero (and  
therefore invalid) UDP checksums?  That's only a good assumption if we  
assume that LISP is the _only_ protocol that will allow the use of  
zero checksums.  If the packet is processed by the stack, there  
shouldn't be a non-LISP application on port 4342, so the packet should  
be dropped.  We should define, however, how the sending LISP node will  
deal with an ICMPv6 "port unreachable" error, so that an error  
received from the wrong destination does not interfere with  
communication with the right destination.

We also need to consider the possibility that a packet will be  
received by a different LISP node than the one for which it was  
intended, or that it will arrive at the correct LISP destination with  
the wrong source address in the external header.  What happens in  
those cases?

Margaret

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 30 Jul 2009 13:28:18 -0400

On Thu, Jul 30, 2009 at 12:49 PM, Margaret Wasserman<[email-masked]> wrote:
>
>
> Since we have standards-track protocols that indicate that UDP checksums
> must not be zero in IPv6 (for good reasons), I believe that we should use

(enumerate good reasons pls)

> valid UDP checksums in IPv6 outer headers, unless we can provide practical
> (and compelling) reasons why _not_ to do so.  So, what are those reasons?
>
> If we do manage to achieve consensus that it makes sense to zero-out the UDP
> checksum in IPv6 outer headers, there are a number of questions we will have
> to answer...

I thought the question was actually to:
o drop no-checksum packets at transition points (v4 -> v6)
  or
o compute checksums at transition points

I don't think there was discussion about not checksumming ipv6
packets, changing the v6 spec to look more like its predecessor here
isn't a bad thing (I think)... but wasn't part of the original
discussion.

> protected.  So, the packet may be corrupted such that it is sent to the
> wrong destination.  When it arrives at the wrong destination, it may be
> processed by an IP stack that is unaware of LISP.

huh? doesn't this mythical distant system have a network stack with
state for UDP packets and isn't it going to just reject the packet
with an icmp port-unreachable? (as happens today on all os's I've
seen)

>
> We need to consider what will happen if one of these packets is received by
> a non-LISP node.  Are you assuming that non-LISP stacks will simply throw

some list originating node will get a spurious icmp port unreachable.

>
> We also need to consider the possibility that a packet will be received by a
> different LISP node than the one for which it was intended, or that it will
> arrive at the correct LISP destination with the wrong source address in the
> external header.  What happens in those cases?

lisp, I think, has nonce protections (or application layer
protections) for this sort of mishap, it has to  in order to deal with
normal security issues.

-chris

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2009 21:25:29 +0200

Hi, Dino,

On 2009-7-29, at 14:02, Dino Farinacci wrote:
> 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.

> The main LISP spec indicates:
>

This is in direct conflict with what RFC2460 says, and I'd personally  
would find it problematic to approve publication of an Experimental  
protocol that did this, unless there was an IETF consensus on a  
standards-track document that would update RFC2460 accordingly. Such a  
document would IMO need to show extremely strong arguments for why  
this change is needed. Updating RFC2460 is also in direct conflict  
with the message that the IETF has been trying to send, namely, that  
IPv6 is stable and done. Is this really worth it?

> v6-in-v4, or v4-or-v6) being forwarded by LISP routers.

I hear you, but is there any quantifiable downside to just compute the  
checksums, esp. if it can be done in hardware?

Thanks,
Lars

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Jul 2009 13:25:49 -0700

> 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.

> This is in direct conflict with what RFC2460 says, and I'd  
> personally would find it problematic to approve

Sorry, but we want to build practical products. If you don't build  
practical standards, vendors will violate them.

> publication of an Experimental protocol that did this, unless there  
> was an IETF consensus on a standards-track document that would  
> update RFC2460 accordingly. Such a document would IMO need to show  
> extremely strong arguments for why this change is needed. Updating  
> RFC2460 is also in direct conflict with the message that the IETF  
> has been trying to send, namely, that IPv6 is stable and done. Is  
> this really worth it?
>
> I hear you, but is there any quantifiable downside to just compute  
> the checksums, esp. if it can be done in hardware?

A hardware forwarding engine is not going to compute a pseudo-header  
checksum and compute every byte of a packet. It's just not going to  
happen.

There has never been a requirement to do this before. My guess is you  
can slow performance by 20%.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Jul 2009 13:30:10 -0700

> received by a non-LISP node.  Are you assuming

Non-LISP nodes cannot decapsulate LISP packets so they don't have this  
problem.  ;-)

Zero UDP checksums are build in an outer UDP header by an ITR, and an  
ETR which decapsulates the packet will not check the checksum.

> that non-LISP stacks will simply throw away these packets, because  
> they have zero (and therefore invalid) UDP checksums?

We spec'ed this out for AMT as well. Same performance issue.

> That's only a good assumption if we assume that LISP is the _only_  
> protocol that will allow the use of zero checksums.  If the packet  
> is processed by the stack, there shouldn't be a non-LISP application  
> on port 4342, so the packet should be dropped.  We should define,  
> however, how the sending LISP node will deal with an ICMPv6 "port  
> unreachable" error, so that an error received from the wrong  
> destination does not interfere with communication with the right  
> destination.

I cannot parse any of this and non of it makes sense to me.

> intended, or that it will arrive at the correct LISP destination  
> with the wrong source address in the external header.  What happens  
> in those cases?

This doesn't happen since the outer IP header is checksum.

Dino

---

From: Lars Eggert <[email-masked]>
Date: Fri, 31 Jul 2009 00:51:03 +0200

Hi,

> (or use existing hardware) that does IPv6-or-IPv4 in UDP in IPv6.

if the existing hardware sends UDP packets over IPv6 with checksum  
zero, it is not compliant to the RFCs. If you're building new  
hardware, you will have to sacrifice some gates to do a UDP checksum  
calculation. Alternatively, you could pick a different encapsulation  
or change the IETF consensus on using UDP in IPv6.

> practical standards, vendors will violate them.

Let me be blunt: If you are going to ignore IETF consensus, why are  
you here?

If you want to change that consensus, please convince the IETF to do  
so. Ignoring the consensus and the process by which we arrive at it is  
not an option.

>>> v6,

I freely admit I'm not a hardware guy, but a hardware checksum was  
cheaply doable at (then) high-performance in 1995. See RFC1936.

> can slow performance by 20%.

There hasn't been a requirement for IPv4 because there is an IP header  
checksum. As to the performance numbers, my guess would be different,  
which is why I asked if you had data.

Lars

---

From: byzek <[email-masked]>
Date: Thu, 30 Jul 2009 20:31:34 -0400

> which is why I asked if you had data.

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.

-J

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Jul 2009 23:58:08 -0700

> or change the IETF consensus on using UDP in IPv6.

Existing hardware has no case of encapsulating in UDP-IPv6. So this is  
a new *feature*.

I already told the list the cost of "sacrificing some gates". It's a  
non-starter. We cannot pick another encapsulation for the reasons I  
said before, LAGs.

Let's do this the right way. We have to make IPv6 stuff *easier* to  
implement rather than creating more barriers to entry.

> Let me be blunt: If you are going to ignore IETF consensus, why are  

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.

> so. Ignoring the consensus and the process by which we arrive at it  
> is not an option.

Why do you think we are ignoring the consensus. Marhsall Eubanks (and  
the MBONED working group)  has been trying to close this issue for AMT  
for around 2 years now. I have been helping him with it. We are being  
proactive.

So I am not sure why you have this defensive tone.

> cheaply doable at (then) high-performance in 1995. See RFC1936.

Header checksums have been in hardware for decades. That is not what  
we are talking about here. 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.

IP header checksums, adds up 20 bytes which are contiguous and at a  
fixed location in a packet. Modifying checksums are easy too. But to  
ask a router to checksum every byte of a packet while encapsulating  
(when the checksum is not placed in a trailer) requires a lot of  
unnecessary complex logic when the packet is already protected at each  
link hop with CRCs.

> There hasn't been a requirement for IPv4 because there is an IP  
> header checksum. As to the performance numbers, my guess would be  
> different, which is why I asked if you had data.

We have really good CRCs on data links today. Requiring a UDP checksum  
in an encapsulating header is chasing a problem that doesn't exist.

Dino

---

From: Lars Eggert <[email-masked]>
Date: Fri, 31 Jul 2009 10:29:32 +0200

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:
> 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?

> 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

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

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 31 Jul 2009 05:26:17 -0700

> 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.

> 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?

> 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.

> 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.

> 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.

> 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.

> I'm fine with being in the rough on this. This is how our decision  

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