* [dpdk-users] checksums?
@ 2019-04-05 1:29 William Herrin
2019-04-05 9:31 ` N. Benes
0 siblings, 1 reply; 3+ messages in thread
From: William Herrin @ 2019-04-05 1:29 UTC (permalink / raw)
To: users
Hi folks,
I've recently done a deep dive in to IP checksums and I've run in to
something I don't understand. Any insight would be helpful.
rte_ipv4_cksum() is implemented as:
return (cksum == 0xffff) ? cksum : (uint16_t)~cksum;
Which means: if the sum is zero, return -0 (0xffff) never +0 (0x0000).
Welcome to the wonderful world of 1's complement arithmetic.
RFC 1624, on the other hand, says:
"In one's complement, there are two representations of zero: the all zero
and the all one bit values, often referred to as +0 and -0. One's
complement addition of non-zero inputs can produce -0 as a result, but
never +0. Since there is guaranteed to be at least one non-zero field in
the IP header, and the checksum field in the protocol header is the
complement of the sum, the checksum field can never contain ~(+0), which is
-0 (0xFFFF). It can, however, contain ~(-0), which is +0 (0x0000)."
Which I understand to mean that +0 (0x0000) is a legal value in an IPv4
checksum field, but -0 (0xffff) is not.
Is this a bug? Is there a more authoritative source for which zero is
correct in an IPv4 header? Please help me find the error in my
understanding.
Thanks,
Bill Herrin
--
William Herrin ................ herrin@dirtside.com bill@herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-users] checksums?
2019-04-05 1:29 [dpdk-users] checksums? William Herrin
@ 2019-04-05 9:31 ` N. Benes
2019-04-05 20:52 ` William Herrin
0 siblings, 1 reply; 3+ messages in thread
From: N. Benes @ 2019-04-05 9:31 UTC (permalink / raw)
To: users
Hi,
William Herrin:
> Hi folks,
>
> I've recently done a deep dive in to IP checksums and I've run in to
> something I don't understand. Any insight would be helpful.
>
> rte_ipv4_cksum() is implemented as:
>
> return (cksum == 0xffff) ? cksum : (uint16_t)~cksum;
>
> Which means: if the sum is zero, return -0 (0xffff) never +0 (0x0000).
> Welcome to the wonderful world of 1's complement arithmetic.
>
> RFC 1624, on the other hand, says:
>
> "In one's complement, there are two representations of zero: the all zero
> and the all one bit values, often referred to as +0 and -0. One's
> complement addition of non-zero inputs can produce -0 as a result, but
> never +0. Since there is guaranteed to be at least one non-zero field in
> the IP header, and the checksum field in the protocol header is the
> complement of the sum, the checksum field can never contain ~(+0), which is
> -0 (0xFFFF). It can, however, contain ~(-0), which is +0 (0x0000)."
>
> Which I understand to mean that +0 (0x0000) is a legal value in an IPv4
> checksum field, but -0 (0xffff) is not.
>
> Is this a bug? Is there a more authoritative source for which zero is
> correct in an IPv4 header? Please help me find the error in my
> understanding.
>
> Thanks,
> Bill Herrin
>
>
Related threads:
https://mails.dpdk.org/archives/users/2019-March/004021.html
https://mails.dpdk.org/archives/dev/2019-April/128473.html
Cheers!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-users] checksums?
2019-04-05 9:31 ` N. Benes
@ 2019-04-05 20:52 ` William Herrin
0 siblings, 0 replies; 3+ messages in thread
From: William Herrin @ 2019-04-05 20:52 UTC (permalink / raw)
To: N. Benes; +Cc: users
On Fri, Apr 5, 2019 at 2:31 AM N. Benes <nbenes@eso.org> wrote:
> William Herrin:
> > Which I understand to mean that +0 (0x0000) is a legal value in an IPv4
> > checksum field, but -0 (0xffff) is not.
> >
> > Is this a bug?
>
> Related threads:
>
> https://mails.dpdk.org/archives/users/2019-March/004021.html
> https://mails.dpdk.org/archives/dev/2019-April/128473.html
Ah, my google-fu failed me. Thanks for the refs!
So it is a bug and Olivier Matz is writing a patch. Few receivers stumble
when presented with -0 as a checksum so it shouldn't be causing much of a
problem but I did stumble across this long-ago conversation:
https://mailarchive.ietf.org/arch/msg/ietf/2EZyjq9tiQvyfyAXgPMKQ7MtToU
https://mailarchive.ietf.org/arch/msg/ietf/36lReuBvahPjxVTth1wpm7kt7zs
Regards,
Bill Herrin
--
William Herrin ................ herrin@dirtside.com bill@herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-04-05 20:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-05 1:29 [dpdk-users] checksums? William Herrin
2019-04-05 9:31 ` N. Benes
2019-04-05 20:52 ` William Herrin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).