Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators

From: Rémi Després <[email-masked]>
Date: Mon, 3 Aug 2009 12:18:29 +0200

Le 30 juil. 09 à 03:09, Christian Huitema a écrit :

>> On 2009-07-29 19:43, Benny Amorsen wrote:
>>> Brian E Carpenter <[email-masked]> writes:
>>>
>>>> Er, do your routers do that when they throw away packets due to
>>>> congestion?
>>>
>>> If a router throws away a packet due to congestion, there's a good
>>> chance that a retransmission will go through. In this case you can
>>> retransmit as many no-UDP-checksum packets you want, none of them  
>>> will
>>> get through. The host really ought to be told that it is wasting its
>>> time.
>>
>> There's no retransmission in UDP.
>>
>> Presumably there is no harm in sending back some kind of ICMP error,
>> most likely Parameter Problem, at a throttled rate. But we shouldn't
>> mandate
>> it IMHO, and you certainly can't rely on a host stopping a UDP stream
>> as a result.
>
> What happened to being conservative with what we send and  
> permissive with what we receive?
>
> It seems that the direct application should be:
>
> 1) Be conservative: hosts should not send UDP packets with null  
> checksums.
> 2) Permissive: gateways who receive UDP packets with null checksum  
> should compute a checksum based on the received bytes, and then  
> forward the packet.
>
> I understand there may be resource limits on gateways, and that the  
> UDP checksum compute requirement might throw the packet back to  
> some kind of slow path, with potential packet loss due to  
> congestion. But that's way better than a black hole.

In view of the various arguments made, here is IMHO a good combination:
- IPv6 hosts MUST create UDP datagrams with non-zero checksums.
   (Nothing new here.)
- IPv6 hosts MAY accept UDP datagrams with zero checksum.
   ((1) Application of the classic principle "be strict in what you  
send, tolerant in what you receive"; (2) useful for some UDP  
datagrams that cross some v4-v6 translators.)
- IPv6 hosts that accept zero-checksum UDP datagrams MAY restrict  
this tolerance to remote hosts whose IPv6 addresses include an IPv4  
mapped address.
(Thus no new tolerance is introduced for IPv6 hosts.)
- IPv4 to IPv6 translators that receive UDP datagrams with zero  
checksums MAY keep these checksums in translated datagrams.
((1) Simple to implement; (2) works for fragmented IPv4 datagrams;  
(3) avoids the waste of CPU power to compute UDP checksums of IPv4  
unfragmented UDP datagrams received with zero checksums.)

Regards,
RD

---

From: Lars Eggert <[email-masked]>
Date: Mon, 3 Aug 2009 14:54:23 +0300

Hi,

> In view of the various arguments made, here is IMHO a good  
...
> - IPv6 hosts MAY accept UDP datagrams with zero checksum.

I see no reason why allowing a UDP checksum of zero for router-to- 
router tunnels under specific circumstances (existence of a payload  
checksum), which is what we've been discussing for AMT and LISP,  
motivates *any* changes for the host. As far as hosts as concerned,  
nothing changes with regards to RFC2460.

> (Thus no new tolerance is introduced for IPv6 hosts.)

Since there is no IP header checksum in IPv6, these IP addresses can  
be corrupted, and so this check may fail.

> checksums MAY keep these checksums in translated datagrams.

Translators are not tunnels. The argument why a zero outer checksum  
may be OK for tunnels is that the inner payload is still protected by  
a checksum, which is not true for translators.

Lars

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Aug 2009 15:28:59 +0300 (EEST)

On Mon, 3 Aug 2009, Lars Eggert wrote:
> I see no reason why allowing a UDP checksum of zero for router-to-router 
> tunnels under specific circumstances (existence of a payload checksum), which 
> is what we've been discussing for AMT and LISP, motivates *any* changes for 
> the host. As far as hosts as concerned, nothing changes with regards to 
> RFC2460.

While this is true for LISP, unfortunately an AMT tunnel endpoint may 
be a host; in fact it's likely it will be. :-/

For the specific case of AMT, I wouldn't personally see a problem with 
IPv6 encapsulating plain IP instead of UDP, though this would 
complicate the spec slightly.  The LAG argument doesn't apply in the 
case of AMT.

-- 
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: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 3 Aug 2009 16:02:26 +0300

On Monday 03 August 2009 15:28:59 ext Pekka Savola wrote:
> > tunnels under specific circumstances (existence of a payload checksum),
> > which is what we've been discussing for AMT and LISP, motivates *any*
> > changes for the host. As far as hosts as concerned, nothing changes with
> > regards to RFC2460.
>

I still don't understand why AMT cannot use a new Foobar protocol number.
Then we can specify that 64 translators translate:
- UDP/IPv6 to summed UDP/IPv4, and vice versa, and
- Foobar/IPv6 to unsummed UDP/IPv4, and vice versa.
And conversely, that LISP and AMT shall use Foobar instead of UDP in the case 
of IPv6.

Then, we can have a _constant_ checksum that protects the Foobar port numbers 
but not the inner packets. Basically it's just like UDP-Lite with 8-bytes 
coverage.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 3 Aug 2009 10:32:48 -0400

> nothing changes with regards to RFC2460.

I don't see this as a very clear distinction. AMT, as Pekka pointed  
out, will
frequently have host endpoints. If I am running Zebra and LISP and  
Apache 2 on a Dell server, is that a router or an endpoint ?

So, hosts SHOULD drop zero-checksums unless they are participating in  
a tunnel
protocol, which was what we tried to capture.

Regards
Marshall

> may be OK for tunnels is that the inner payload is still protected  
> by a checksum, which is not true for translators.
>
> Lars 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Rémi Després <[email-masked]>
Date: Mon, 3 Aug 2009 17:46:35 +0200

Le 3 août 09 à 13:54, Lars Eggert a écrit :

> Since there is no IP header checksum in IPv6, these IP addresses  
> can be corrupted, and so this check may fail.

If a host may receive receive a zero-checksum UDP datagram destined  
to another host, this is acceptable because:
- Probability of this happening is very low (with link layer  
checksums etc.).
- It is even more UNLIKELY that the source address and the two ports  
of the datagram match those of an existing connection (connection  
where, in addition, such datagrams must be accepted).
- If this nevertheless happens, the harm must be limited because of  
the application nature. (For example, an application that accepts  
queries in unchecked datagrams may receive an extra query without  
significant consequence).

If in charge of an IPv6 TCP/IP stack (which I am not), I would ensure  
that, although it never sends zero-checksum UDP datagrams, it does  
accept to receive them.
Similarly, if in charge of of an SIIT (which I am not either), I  
would ensure that rather than discarding IPv4 zero-checksum datagrams  
it forwards them with its zero checksum.
This being said, it's up to people in charge to decide. (I don't care  
very much. Efforts to have IPv6 end-to-end rapidly deployed are IMHO  
more important than efforts to keep IPv4-only environments work as  
well as if they would be dual stack.)

Regards,
RD

---

From: Christian Huitema <[email-masked]>
Date: Mon, 3 Aug 2009 20:14:13 +0000

> datagrams that cross some v4-v6 translators.)

Except you do not get to specify that as part of the translator specification. The translator spec applies to translators, not to hosts. Translators must assume that IPv6 UDP packets with null checksum will be dropped by the receiving host. For a translator, forwarding such a packet with a null checksum is pretty much the same as dropping it.

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Aug 2009 09:40:46 +0200

Le 3 août 09 à 22:14, Christian Huitema a écrit :

> Except you do not get to specify that as part of the translator  
> specification.

> The translator spec applies to translators, not to hosts.

Agreed.

> Translators must assume that IPv6 UDP packets with null checksum  
> will be dropped by the receiving host.

Different understanding here.
A better sentence IMHO would be "Translators MAY assume that IPv6 UDP  
packets with null checksum are accepted by some receiving hosts (or  
will be in the future)."
> For a translator, forwarding such a packet with a null checksum is  
> pretty much the same as dropping it.

If all destination hosts drop them, the effect is indeed the same.
But if some hosts start being open to receive them (a backward  
compatible extension), then it makes a useful difference.

The proposal is a combination of backward compatible extensions in  
hosts and translators:
- They make no harm in general.
- They are useful when used in combination.

Regards,
RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Aug 2009 13:20:04 +0200

On 30 jul 2009, at 3:35, Christian Huitema wrote:

> The fragmentation issue is different from the zero-checksum issue.  
> Many IPv4 NAT drop fragmented packets already.

That is unacceptable; fragments happen, even with TCP.

> They rely on port numbers to find the mappings, fragments don't  
> carry port numbers, so fragments get dropped.

Well the graybeards among us screwed up here, the port numbers should  
have been part of the unfragmentable headers in IPv6. (Not that that  
would have helped the problem at hand.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Aug 2009 13:35:30 +0200

On 3 aug 2009, at 17:46, Rémi Després wrote:

> if in charge of of an SIIT (which I am not either), I would ensure  
> that rather than discarding IPv4 zero-checksum datagrams it forwards  
> them with its zero checksum.

That's pointless, because the IPv6 spec, against which implementations  
have been heavily tested, reject such packets.

There is really no substitute for doing the right thing.

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Aug 2009 15:27:42 +0200

Le 4 août 09 à 13:35, Iljitsch van Beijnum a écrit :

>> that rather than discarding IPv4 zero-checksum datagrams it  
>> forwards them with its zero checksum.
>
> That's pointless, because the IPv6 spec, against which  
> implementations have been heavily tested, reject such packets.

You seem to have missed that the proposal includes a relaxation of  
the constraint that zero-checksum UDP datagrams MAY be accepted by  
hosts ion the future, just to avoid unnecessary black holes in case  
of v4 to v6 translations.

Is progress from what is implemented today a taboo?
(I hope not.)

Agreed.

RD

---

From: Lars Eggert <[email-masked]>
Date: Tue, 4 Aug 2009 17:30:34 +0300

Hi,

> of v4 to v6 translations.

isn't it a non-starter for a translation based *transition* mechanism  
to depend on host changes?

Lars

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Aug 2009 16:49:25 +0200

Le 4 août 09 à 16:30, Lars Eggert a écrit :

> isn't it a non-starter for a translation based *transition*  
> mechanism to depend on host changes?

I don't think so, because it's never too late do do some good without  
doing any harm.

IMHO, translators SHOULD forward zero-checksum datagrams RATHER THAN  
dropping them. No harm expected.
Avoiding to drop them by computing payload checksums is another  
possible behavior, at least for single fragment datagrams. But it  
implies to compute payload checksums, which may be considered too  
expensive and opening a door to DOS attacks.

IMHO also, hosts, at their next patch release, SHOULD silently accept  
zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No  
harm expected.

By doing this, connectivity during the transition period will  
eventually be improved, possibly before translators are largely  
deployed.
Some people say this transition period is bound to be long. Who knows?

Regards,
RD

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 4 Aug 2009 16:55:51 +0200 (CEST)

On Tue, 4 Aug 2009, Rémi Després wrote:

>
> Le 4 ao?t 09 ? 13:35, Iljitsch van Beijnum a écrit :
>
>>> if in charge of of an SIIT (which I am not either), I would ensure that 
>>> rather than discarding IPv4 zero-checksum datagrams it forwards them with 
>>> its zero checksum.
>> 
>> That's pointless, because the IPv6 spec, against which implementations have 
>> been heavily tested, reject such packets.
>
> You seem to have missed that the proposal includes a relaxation of the 
> constraint that zero-checksum UDP datagrams MAY be accepted by hosts ion the 
> future, just to avoid unnecessary black holes in case of v4 to v6 
> translations.
>

But the translations cannot expect acceptance of zero checksum.  So I 
think it would be better to use other options...

> Is progress from what is implemented today a taboo?

Not taboo, but changing implementation is very painful. Have a look at 
e.g. RH0 deprecation. You cannot expect that every single IPv6 
implementation is follows RFC 5095...  Especially in the embedded 
devices...

Best Regards,
 		Janos Mohacsi

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 4 Aug 2009 16:59:53 +0200 (CEST)

On Tue, 4 Aug 2009, Rémi Després wrote:

>
> Le 4 ao?t 09 ? 16:30, Lars Eggert a écrit :
>
>> Hi,
>> 
>> isn't it a non-starter for a translation based *transition* mechanism to 
>> depend on host changes?
>
> I don't think so, because it's never too late do do some good without doing 
> any harm.
>
> IMHO, translators SHOULD forward zero-checksum datagrams RATHER THAN dropping 
> them. No harm expected.
> Avoiding to drop them by computing payload checksums is another possible 
> behavior, at least for single fragment datagrams. But it implies to compute 
> payload checksums, which may be considered too expensive and opening a door 
> to DOS attacks.
>
> zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No harm 
> expected.

In your previous mail your state MAY instead of SHOULD. Or you are 
proposing submitting a draft? :
"Acceptance of zero checksum IPv6-UDP headers at end-host"

Best Regards,
 		Janos Mohacsi

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Aug 2009 17:28:34 +0200

Le 4 août 09 à 16:55, Mohacsi Janos a écrit :

>>>> if in charge of of an SIIT (which I am not either), I would  
>>>> ensure that rather than discarding IPv4 zero-checksum datagrams  
>> hosts ion the future, just to avoid unnecessary black holes in  
>> case of v4 to v6 translations.
>>
>
> But the translations cannot expect acceptance of zero checksum.  So  
> I think it would be better to use other options...

YES, translators cannot expect that all hosts accept them.
But they can expect that at least some host will take advantage of it  
once upgraded to accept them.

The point is what else do you prefer:
- Always dropping?
- Always computing payload checksums? (Not realistic in practice for  
multi-segment datagrams)

> Not taboo, but changing implementation is very painful.

It depends on the modification.
Here it is just that hosts delete the current test that the received  
IPv6 UDP checksums are zero in order to drop them. A trivial patch.
The following sentence of RFC 2460 was clearly not written with the  
v4 to v6 translation in mind, and could advantageously be deprecated:  
"IPv6 receivers must discard UDP packets containing a zero checksum,  
and should log the error."

> Have a look at e.g. RH0 deprecation.
See previous comment.

> You cannot expect that every single IPv6 implementation is follows  
> RFC 5095...  Especially in the embedded devices...

There is no need to expect all hosts to accept IPv6 zero-checksums  
for others to benefit from it.

Regards,
RD

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 4 Aug 2009 18:00:33 +0300

> dropping them. No harm expected.

"No harm expected"? I find that generating scary-reading false positive in my 
system logs is harmful.

> zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No

That will cause silent software failures when running on a "too old" system. 
Silent failures are the most harmful kind of failures to me.

> eventually be improved, possibly before translators are largely

No. By doing this, people will experience odd failure modes and weird error 
reports during the long transition period for IPv6 stacks to accept checksum-
less packets.

Harm very much expected.

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Aug 2009 17:34:08 +0200

Le 4 août 09 à 16:59, Mohacsi Janos a écrit :

>> I don't think so, because it's never too late do do some good  
>> without doing any harm.
>>
>> IMHO, translators SHOULD forward zero-checksum datagrams RATHER  
>> THAN dropping them. No harm expected.
>> IMHO also, hosts, at their next patch release, SHOULD silently  
>> accept zero-checksum IPv6 datagrams RATHER THAN silently dropping  
>> them. No harm expected.
>
> In your previous mail your state MAY instead of SHOULD.

True, but here this is a SHOULD "RATHER THAN drop"

> Or you are proposing submitting a draft? :

No plan to do this as long as the discussion shows it will be flatly  
rejected.
(So far I received only  doubts, objections and criticisms, but not  
any support.)

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Aug 2009 23:09:13 +0200

> "No harm expected"? I find that generating scary-reading false  

I don't get the point about "scary-reading false positive".

On the other hand, I still believe what I wrote yesterday is valid:
*If a host may receive receive a zero-checksum UDP datagram destined  
to another host, this is acceptable because:
- Probability of this happening is very low (with link layer  
checksums etc.).
- It is even more UNLIKELY that the source address and the two ports  
of the datagram match those of an existing connection (connection  
where, in addition, such datagrams must be accepted).
- If this nevertheless happens, the harm must be limited because of  
the application nature. (For example, an application that accepts  
queries in unchecked datagrams may receive an extra query without  
significant consequence).*

> That will cause silent software failures when running on a "too  
*IPv4 compatible applications should have no problem with UDP zero- 
checksums*, or I am mistaken?

> Silent failures are the most harmful kind of failures to me.

And to me too, but I don't see any silent "failure" here.
> reports during the long transition period for IPv6 stacks to accept  

If you could prove your assertion, I would reconsider mines  
(sentences between *s .

> Harm very much expected.

An example would be helpful to understand what you fear.

Regards,
RD

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 5 Aug 2009 09:29:19 +0300

> I don't get the point about "scary-reading false positive".

As already mentioned (several times?), some operating systems log errors when 
they receive packets with invalid checksums. The rationale is that some piece 
of hardware might be defective, or whatever.

> checksums*, or I am mistaken?

It will break silently when an *IPv6* application is run on a system that has 
not been updated to accept zero-checksum. The system will drop the packet, and 
the application will mysteriously not receive anything.

---

From: Rémi Després <[email-masked]>
Date: Wed, 5 Aug 2009 09:58:58 +0200

Le 5 août 09 à 08:29, Rémi Denis-Courmont a écrit :

> they receive packets with invalid checksums.

Right.
They do what RFC 2460 says they should: "IPv6 receivers must discard  
UDP packets containing a zero checksum, and should log
the error".
(You don't need to repeat it once more ;-))

But if *received* UDP zero checksums are no longer considered as  
errors in IPv6 (the proposal), I don't see in what it is relevant to  
note that "some operating systems log errors when they receive  
packets with invalid checksums" .

> The rationale is that some piece

For this, non-zero checksums are available.
(Translators don't change them to zero.)

>>>> accept

My proposal is precisely to AVOID these mysterious blackholes (in  
systems that are patched before translators get largely used).
But maybe you have another proposal to have the same result.
If yes, could you tell what it is?

Regards,
RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Aug 2009 16:09:48 +0200

> of v4 to v6 translations.

Although actual IPv6 packets flowing over the internet aren't as  
numerous as their IPv4 counterparts and at least "legacy" IPv6 stuff  
can't be as old as the oldest IPv4 stuff, we still have a very large  
installed IPv6 base out there that isn't going to adapt to modifying  
standards at the drop of a hat.

If you send UDP packets with 0 checksums to IPv6 hosts, expect many of  
them to reject those packets for a very long time, at the very least 5  
years.

> Is progress from what is implemented today a taboo?

It's not taboo, just very hard. Apple and Microsoft aren't  
particularly quick with building in updates to the network stack, and  
after they've done that, it can take a long time for holdouts to  
upgrade. This is much harder than updating applications from competing  
vendors running in user space.

But nobody is stopping you from coming up with a new UDP-like  
encapsulation that doesn't have a checksum.

---

From: Rémi Després <[email-masked]>
Date: Wed, 5 Aug 2009 19:18:49 +0200

Le 5 août 09 à 16:09, Iljitsch van Beijnum a écrit :

> numerous as their IPv4 counterparts and at least "legacy" IPv6  
> stuff can't be as old as the oldest IPv4 stuff, we still have a  
> very large installed IPv6 base out there that isn't going to adapt  
> to modifying standards at the drop of a hat.

Never thought they were to adapt this way.

> If you send UDP packets with 0 checksums to IPv6 hosts, expect many  
> of them to reject those packets for a very long time, at the very  
> least 5 years.

Too bad for these "many", but there is nothing vital here anyway.
Besides, if it takes 5 years to update IPv6 stacks; it's likely that  
the coexistence period will last much longer.
Then, preventing blackholes in v4 to v6 translation will serve its  
purpose for quite some time.
> particularly quick with building in updates to the network stack,  
> and after they've done that, it can take a long time for holdouts  
> to upgrade. This is much harder than updating applications from  
> competing vendors running in user space.

If we would only work on easy things, we would miss many useful  
opportunities, right?

> encapsulation that doesn't have a checksum.

You are the father of this idea and, as far as I am concerned, should  
remain so.
My point is about translated UDP in general, not focused on to tunnels.

RD