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

From: Rémi Després <[email-masked]>
Date: Mon, 27 Jul 2009 18:46:47 +0200

We understand that UDP checksums being optional in IPv4 and mandatory  
in IPv6 creates a problem for IPv4 to IPv6 translators:
(1) To completely translate from v4 to v6 a UDP datagram having a  
zero checksum, a complete computation of the datagram checksum is  
necessary.
(2) If the datagram has several fragments, this cannot be done  
statelessly.

A simple solution would IMHO be to complement to the UDP rule in IPv6  
as follows:
- IPv6 hosts MUST create UDP datagrams with non-zero checksums.  
(Nothing new here.)
- IPv6 hosts SHOULD accept UDP datagrams with zero checksum.  
(Application of the classic principle "be strict in what you send,  
tolerant in what you receive").
- IPv4 to IPv6 translators that receive UDP datagrams having zero  
checksums MAY keep these checksums in translated datagrams.
(On one hand, computing the UDP checksum still provides a better  
connectivity than without it, as long as there are IPv6 hosts that  
discard UDP datagrams having zero checksum. On the other hand, there  
may be tradeoffs to be made between maximum connectivity in all cases  
and scalability, DOS attack protection etc.)

Thoughts?

RD

---

From: Lars Eggert <[email-masked]>
Date: Tue, 28 Jul 2009 08:24:30 +0200

Hi,

> checksums MAY keep these checksums in translated datagrams.

as an individual, I prefer something along the lines of draft- 
fairhurst-6man-tsvwg-udptt instead.

Lars

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 28 Jul 2009 17:34:44 +1000

On 28/07/09 5:29 PM, "Francis Dupont" <[email-masked]> wrote:

>  In your previous mail you wrote:
> 
>    Thoughts?
>    
> => I am strongly against changing all IPv6 implementations.
> IMHO the simplest solution is to drop UDP packets with zero checksums
> (as far as I know all IPv4 implementations use non-zero checksums
> per default and some UDP applications, for instance DNS, work far
> better with non-zero checksums. BTW it is an easy condition to check
> in firewalls).

=> I agree with Francis. SIIT talks about this case and addresses it the way
Francis suggests. Let's not re-invent the wheel, this is a known issue.

Hesham

> 
> Regards
> 
> [email-masked]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 28 Jul 2009 18:23:44 +1000

All 

I strongly recommend that people read section 1 of RFC 2765. Here is some of
the relevant text:

Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e.
   the UDP checksum field is zero) are not of significant use over
   wide-areas in the Internet and will not be translated by the
   translator.  An informal trace [MILLER] in the backbone showed that
   out of 34,984,468 IP packets there were 769 fragmented UDP packets
   with a zero checksum.  However, all of them were due to malicious or
   broken behavior; a port scan and first fragments of IP packets that
   are not a multiple of 8 bytes.

Hesham

On 28/07/09 6:14 PM, "Christopher Morrow" <[email-masked]>
wrote:

> On Tue, Jul 28, 2009 at 3:29 AM, Francis
> Dupont<[email-masked]> wrote:
> Out of curiosity, what's the signal back to the sender that his/her
> packet was dropped?? NFS (in some implementations) doesn't checksum
> UDP packets, DNS doesn't, there are quite a few things that don't
> checksum UDP packets.
> 
> Simply dropping packets on the floor isn't polite. Dropping them and
> notifying (icmp <somethingbadhappenedhere>) is also hard to deal with
> since users can't force udp checksums to happen (per
> application/stack) and there's not a clear (aside from application
> failure) idea to the user that something isn't working.
> 
> If you choose to drop the packet tell the sender that it happened
> (port-unreachable or something along those lines, still the wrong
> semantics though), I believe you should accept and correct the
> checksum issue though in the end, it's the only proper path.
> 
> -Chris

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Jul 2009 11:41:08 +0200

> => I am strongly against changing all IPv6 implementations.
In this instance, the change is only a backward compatible additional  
rule which is not a MUST.
There is no urgency to upgrade any host.
If an IPv6 host becomes capable to receive more UDP packets  
translated from IPv4 (including those that are sent with checksum  
zero), I don't see what harm it may cause to anyone else.

> better with non-zero checksums. BTW it is an easy condition to check

The point is just to improve connectivity where UDP zero checksums  
ARE actually used, and this at no cost where they are not used.

To take in consideration your (useful) remark, the proposal could be  
improved by replacing a SHOULD by a MAY:
- IPv6 hosts MAY accept UDP zero checksums (but of course MUST still  
send non-zero UDP checksums).
- v4 to v6 translators MAY either compute UDP checksums when  
receiving UDP zero checksums OR translate with the zero checksum  
unchanged.

RD

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 28 Jul 2009 14:01:42 +0200

It's my understanding that checksum zero udp packets were rare 10 years
ago... how common are they really?

joel

Rémi Després wrote:
> If an IPv6 host becomes capable to receive more UDP packets translated
> from IPv4 (including those that are sent with checksum zero), I don't
> see what harm it may cause to anyone else.
> 
> 
> The point is just to improve connectivity where UDP zero checksums ARE
> actually used, and this at no cost where they are not used.
> 
> - v4 to v6 translators MAY either compute UDP checksums when receiving
> UDP zero checksums OR translate with the zero checksum unchanged.
> 
> RD
> 
> 
> 
>>
>> Regards
>>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Jul 2009 14:34:04 +0200

Le 28 juil. 09 à 13:19, Francis Dupont a écrit :

> => if you believe this non-issue still needs a solution in standards
> IMHO it is far better to deprecate zero UDP checksums.

Different view here.
- Deprecating a permitted behavior doesn't change existing hosts in  
any short time.
- Relaxing an unnecessary constraint lets host free to take advantage  
of it or not.

> If you don't
> believe just reuse RFC 2765 choice.

RFC 2765 says
    Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e.
    the UDP checksum field is zero) ... will not be translated by the
    translator.
The (improved again) proposal would be that two additional behaviors  
are permitted (with a MAY).
They are:
- translate with the zero checksum unchanged
- Compute the UDP checksum (in the single fragment case where it  
consumes CPU power but is not complex).

Regards,
RD

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 28 Jul 2009 22:45:16 +1000

On 28/07/09 6:49 PM, "Christopher Morrow" <[email-masked]> wrote:

> On Tue, Jul 28, 2009 at 4:23 AM, Hesham Soliman<[email-masked]>
> wrote:
>> All
>> 
> 'in the sample taken by one researcher'
> 
> (where's the actual email/research/numbers?
>    [MILLER]     G. Miller, Email to the ngtrans mailing list on 26 March
>                 1999.
> doesn't say actually)
> 
> I have some dns packets at least that aren't checksumed and do
> traverse a wide-area-network. The work referenced is from at least 10
> years ago, certainly things have changed, we can hope they changed in
> the positive direction, but it's not clear to me that that is the
> case.

=> Can you point to another study? If not, then I'd rather take that one
researcher's study than nothing, or worse, change IPv6 implementations

Hesham

> 
> Google searching provides the email which says (among other things)
> (ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/1999-03.mail)
> 
> From Greg Miller (mci.net)
> "I just did a little analysis on the UDP checksum issue. This is by no means a
> comprehensive study, but I hope it's better than nothing. (To give credit
> where it's due, Bill Kroah, a colleague here did lots of the number
> crunching.)"
> 
> and: (erik nordmark)
> "I'm unsure of the operational implications.
> It would be great if we could determine the amount of UDP Internet traffic
> (outside a single or a few LANs) that don't use UDP checksums today.
> 
> At a minimum we need to list this issue in the draft - I don't know
> if we need to support it."
> 
> original poster lost in time:
> "The memo says that no cheksum update is necessary for UDP. But we
> think this is not ture. There is one exception.
> 
> If a UDP/IPv4 packet whose checksum is 0(ie. not calculated), SIIT
> have to calculate checksum for a new UDP/IPv6 packet."
> 
> It seems that the case hasn't been refreshed/touched in ~10 years, so
> saying now that 'eh, just toss away the packets...' is a little
> cavalier.
> 
> -chris
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 28 Jul 2009 15:17:42 +0200

On 2009-7-28, at 10:37, Christopher Morrow wrote:
> apologies, I had a tcpdump expr fail :( I do see DNS though with out
> checksums, I'll go dig for some more NFS or other UDP on my test
> host(s).

Just as a hint: you'll need to look at inbound traffic if your NIC  
does checksum offloading, because chksum=0 on output is a hint to the  
NIC to overwrite it before transmission.

Lars

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 28 Jul 2009 15:49:15 +0200

I did this for the ietf ids sensor and I haven't see any having run it
since noon.

udp[6:2] == 0

joel

Lars Eggert wrote:
> Just as a hint: you'll need to look at inbound traffic if your NIC does
> checksum offloading, because chksum=0 on output is a hint to the NIC to
> overwrite it before transmission.
> 
> Lars
> 
> 
> ------------------------------------------------------------------------
>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 28 Jul 2009 06:52:49 -0700

> I did this for the ietf ids sensor and I haven't see any having run it

I would be interested in some statistics on IPv4 multicast, since I'm
working on IPv4 - IPv6 multicast translation. I think it's more common
to not use checksums for multicast.

I might try to collect some statistics myself at some point...

Stig

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Jul 2009 11:02:49 -0400

As I mentioned at the mic during yesterday's meeting, UDP checksum=0 is used/seen quite a bit in RTP traffic.  Clearly VoIP was rather in its infancy in 1999 when that study was done.  And to be frank, I rather doubt SIP will successfully work through inline v4-v6 translators anyway, so I'm not sure it actually matters much to y'all if RTP uses checksum=0.

However, I just checked some wireshark traces, and apparently even emule/edonkey p2p sends UDP checksum=0 from some hosts.  I can provide the trace if anyone wishes to see it.  And considering that was only the second wireshark trace I went to look for when trying to find an example of checksum=0, this may be more common than one may think. (or I'm lucky)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hesham Soliman
> Sent: Tuesday, July 28, 2009 8:45 AM
> >

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Jul 2009 09:29:57 +0200

Thoughts?

Regards

---

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

> fairhurst-6man-tsvwg-udptt instead.

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

I would urge people interested in this to attend as a decision may be  
made soon.

Regards
Marshall

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 28 Jul 2009 04:30:53 -0400

(hopefully this time gmail selects the right outbound from addr grr)

On Tue, Jul 28, 2009 at 4:24 AM, <[email-masked]> wrote:
> I believe this is normally a function of the operating system, not
> NFS, DNS etc. Hopefully old SunOS versions that had UDP checksums

sure, but still how does the application and user know that their
'thing they are doing' is broken, why it's broken and how to fix it?
Keep in mind that today this all works and users don't have to
understand 'checksum' or 'udp' or 'ip version'... tomorrow something
(hopefully) seemless will happen and their 'thing they are doing' will
just keep on working.

Spurious failures as would be happen in this proposal will be
problematic, and will (again) cause hesitance in deployments.

> off by default are dead by now.

linux nfs doesn't do (nor does netapp apparently) checksums on udp nfs
today (current 2.6 linux kernel, ubuntu 8.x)

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 28 Jul 2009 04:37:46 -0400

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 28 Jul 2009 04:49:53 -0400

and: (erik nordmark)

-chris

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Jul 2009 10:53:54 +0200

packet was dropped??

=> none but if you really want something an unreachable / admin forbidden
seems not so bad.

   NFS (in some implementations) doesn't checksum UDP packets,

=> NFS over UDP throught a translator is already a bad idea.

   DNS doesn't,

=> I have the opposite view and I know at least a TLD which has a UDP
checksum check in its sanity tool (so when you add a new domain you
are required to do UDP checksums for all name servers for this domain).
There is no standard knob to drop UDP packets with zero checksums
but if there is one I believe many name servers will switch it on.

   there are quite a few things that don't checksum UDP packets.

=> not many because the zero checksum choice is system wide and
off by default. So it is enough to get non-zero checksums in general.
(if someone has a good stat, please...)

=> it is not polite too to send packets with zero checksums.
As it is hard to send zero checksum packets IMHO the best is
to handle them in a firewall with possibly smarter behavior.

=> fixing zero checksums can accept bad packets, IMHO it is simpler
and easier to just get rid of zero checksums: they make sense 20
years ago but not these days. BTW checksums are offloaded on
all modern NICs so zero checksums are no longer "faster".

Regards

PS: NATs (PT or not) in general adjust transport checksums and
don't (re)compute them.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Jul 2009 10:58:13 +0200

=> G. Miller message is 10 year old so should be even more valid today.
Thanks for the quote, IMHO the subject can be closed (again).

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Jul 2009 13:19:44 +0200

=> if you believe this non-issue still needs a solution in standards
IMHO it is far better to deprecate zero UDP checksums. If you don't
believe just reuse RFC 2765 choice.

Regards

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 28 Jul 2009 10:01:04 -0400

> I might try to collect some statistics myself at some point...

I believe that LISP does not use checksums in v4 or v6, at least so  
far. And, of course, AMT doesn't either (so far).

Regards
Marshall

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 28 Jul 2009 10:05:30 +0200 (CEST)

I also support Francis.

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 28 Jul 2009 04:14:44 -0400

-Chris

---

From: [email-masked]
Date: Tue, 28 Jul 2009 10:24:00 +0200 (CEST)

I support the view of Francis Dupont here.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: [email-masked]
Date: Tue, 28 Jul 2009 11:01:08 +0200 (CEST)

> the positive direction, but it's not clear to me that that is the

On the DNS servers I have access to (which includes one ccTLD server)
the UDP non-checksum packet rate is in the range of 2 to 4 per thousand
for *unfragmented* packets.

It would be interesting to see similar statistics for some of the
bigger root/gTLD server clusters.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 28 Jul 2009 05:03:27 -0400

On Tue, Jul 28, 2009 at 4:53 AM, Francis
Dupont<[email-masked]> wrote:
>   >  In your previous mail you wrote:
>   >
>   >   Thoughts?
>   >
>   > => I am strongly against changing all IPv6 implementations.
>   > IMHO the simplest solution is to drop UDP packets with zero checksums
>   > (as far as I know all IPv4 implementations use non-zero checksums
>   > per default and some UDP applications, for instance DNS, work far
>   > better with non-zero checksums. BTW it is an easy condition to check
>   > in firewalls).
>

ok. my sole point really was 'discard' is not acceptable. if you toss
away a packet you ought to tell someone you did that.

> => NFS over UDP throught a translator is already a bad idea.

it's not that the user chooses this, they just get pushed across this
without their knowledge. windows-sharing over the internet isn't
smart, but a shockingly large number of people do it. Same for ms-sql
server...

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 28 Jul 2009 05:00:22 -0400

> Thanks for the quote, IMHO the subject can be closed (again).

it's 10 years old, from a single network link, in what I suspect was
VBNS+, so not even today's internet (scale or applications or users or
traffic levels or uses)

So I'm not sure it's applicable at all to today, or the discusison ongoing.

---

From: David Malone <[email-masked]>
Date: Tue, 28 Jul 2009 13:59:45 +0100

> VBNS+, so not even today's internet (scale or applications or users or

People might want to check "netstat -s" - on some OSes it displays
the number of datagrams with no checksum. From some machines I have
access to:

	Datagrams	with no csum	Fraction
	1643918434	1660		~0.000001
	1780472220	233156		~0.00001
	1335609090	918129		~0.0007
	4157989		931		~0.0002
	122783361	43532		~0.0004

The second machine is a moderately busy DNS server. The third a
public NTP server. I don't think the counters have wrapped - I get
plausible looking pps numbers if I divide the datagrams by uptime.

Checking some other traces, I see about 21420/17253070 NTP packets
with no checksum. Of non-NTP, non-DNS traffic I see about half a
percent of UDP with no checksums. A lot of this looks like either
port scans or people trying to use obsolete services like port 37.

	David.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jul 2009 11:40:28 +1200

Hi Chris,

> away a packet you ought to tell someone you did that.

Er, do your routers do that when they throw away packets due to
congestion?

   Brian

---

From: Benny Amorsen <[email-masked]>
Date: Wed, 29 Jul 2009 09:43:16 +0200

> Er, do your routers do that when they throw away packets due to

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.

/Benny

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 29 Jul 2009 12:32:51 +0200

At Tue, 28 Jul 2009 10:53:54 +0200,

> => none but if you really want something an unreachable / admin forbidden

The (or one) difficult part is that in case of IPv6 if transport-layer
checksum isn't provided the responder cannot even be sure about the
source address is valid (to which a "signal" would be sent) since IPv6
doesn't have a checksum at the IP layer.

BTW, I agree with you; I oppose to loosening the current restriction.
The lack of IP layer checksum and its implication are one reason for
that.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Jul 2009 10:20:45 +1200

> get through. The host really ought to be told that it is wasting its

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.

   Brian

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Jul 2009 01:09:51 +0000

> it IMHO, and you certainly can't rely on a host stopping a UDP stream

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.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Jul 2009 13:15:13 +1200

> 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 congest…

The problem is *fragmented* IPv4 UDP packets with zero checksum; the
translator would have to reassemble them.

   Brian

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Jul 2009 01:35:19 +0000

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

The fragmentation issue is different from the zero-checksum issue. Many IPv4 NAT drop fragmented packets already. They rely on port numbers to find the mappings, fragments don't carry port numbers, so fragments get dropped. Application developers ought to know by now that sending large UDP packets over IPv4 is problematic.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Jul 2009 14:42:52 +1200

> The fragmentation issue is different from the zero-checksum issue. Many IPv4 NAT drop fragmented packets already. They rely on port numbers to find the mappings, fragments don't carry port numbers,…

BEHAVE's issue is to decide whether dropping them is
an acceptable recommendation for v4->v6 translators.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Jul 2009 04:54:13 +0000

> an acceptable recommendation for v4->v6 translators.

So there are really several cases

1) No fragmentation:
        1a) Checksum correct, => No issue, just translate.
        1b) Zero checksum, no fragmentation => Should compute the checksum, then translate
        1c) Invalid checksum => Should drop.

2) Fragmentation:
        2a) Enough resource to reassemble the packet:
                reassemble;
                2a1) checksum present & correct => translate
                2a2) zero checksum => Should compute the checksum, then translate
                2a3) invalid checksum => drop
        2b) Not enough resource to translate the packet:
                MAY drop the packet.

The main problem in case 2b is, what to do with the next packets. If the relay cannot perform reassembly, it will not know whether subsequent segments follow an initial segment with checksum, or without. There may be ways to pipeline segments, but that does not seem realistic.

-- Christian Huitema

---

From: Benny Amorsen <[email-masked]>
Date: Thu, 30 Jul 2009 09:36:19 +0200

> There's no retransmission in UDP.

Obviously not by the protocol stack. That doesn't stop applications from
retransmitting. TFTP or SIP won't give up just because the first packet
is lost. RTP will keep transmitting new packets, even if it doesn't
retransmit the lost ones.

/Benny

---

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

> retransmit the lost ones.

So, back to my point.. what's the signal to the application that
should stop/backup/try another method? classically either packet-loss
+ tcp-backoff or icmp/error messages does this.

Dropping packets on the floor isn't in these two options. The proposed
path from Christian seems like a great direction though.

(thanks christian)

-Chris

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 30 Jul 2009 14:59:28 +1000

>         1c) Invalid checksum => Should drop.

=> I think we're all ok with this case.

> The main problem in case 2b is, what to do with the next packets. If the relay
> cannot perform reassembly, it will not know whether subsequent segments follow
> an initial segment with checksum, or without. There may be ways to pipeline
> segments, but that does not seem realistic.

=> Agreed, that's why I'm confused about the MAY, what's the other option if
the packet is not dropped?

Hesham