From: Stephen Hemminger <stephen@networkplumber.org>
To: "Gábor LENCSE" <lencse@hit.bme.hu>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: How to calculate ICMPv6 checksum?
Date: Thu, 7 Aug 2025 10:57:03 -0700 [thread overview]
Message-ID: <20250807105703.22de669d@hermes.local> (raw)
In-Reply-To: <40938de8-49b3-46d0-964b-9cd296000d10@hit.bme.hu>
On Thu, 7 Aug 2025 17:32:02 +0200
Gábor LENCSE <lencse@hit.bme.hu> wrote:
> Dear All,
>
> I am working on adding ARP/NDP support to my SIIT / Stateful NAT64
> benchmarking tool, siitperf [1]. (So far, the ARP / NDP table entries
> had to be set manually at the device under test, as siitperf was not
> able to reply to ARP / NDP requests).
>
> The ARP reply functionality seems to work fine, but I have a problem
> with NDP. As ICMPv6 messages contain checksum, I would need a function
> that computes it. However, I only found the rte_ipv6_udptcp_cksum()
> function, but I did not find a similar one for calculating ICMPv6 checksum.
>
> I have been checking the functions shown here:
> https://doc.dpdk.org/api/rte__ip6_8h.html
>
> Could you please advise me about the function to use for ICMPv6 checksum
> calculation?
>
> Best regards,
>
> Gábor
>
> [1] https://github.com/lencsegabor/siitperf
The pseudo-header part is different.
https://www.rfc-editor.org/rfc/rfc4443
2.3. Message Checksum Calculation
The checksum is the 16-bit one's complement of the one's complement
sum of the entire ICMPv6 message, starting with the ICMPv6 message
type field, and prepended with a "pseudo-header" of IPv6 header
fields, as specified in [IPv6, Section 8.1]. The Next Header value
used in the pseudo-header is 58. (The inclusion of a pseudo-header
in the ICMPv6 checksum is a change from IPv4; see [IPv6] for the
rationale for this change.)
For computing the checksum, the checksum field is first set to zero.
https://www.rfc-editor.org/rfc/rfc2460#section-8.1
8.1 Upper-Layer Checksums
Any transport or other upper-layer protocol that includes the
addresses from the IP header in its checksum computation must be
modified for use over IPv6, to include the 128-bit IPv6 addresses
instead of 32-bit IPv4 addresses. In particular, the following
illustration shows the TCP and UDP "pseudo-header" for IPv6:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upper-Layer Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o If the IPv6 packet contains a Routing header, the Destination
Address used in the pseudo-header is that of the final
destination. At the originating node, that address will be in
the last element of the Routing header; at the recipient(s),
that address will be in the Destination Address field of the
IPv6 header.
o The Next Header value in the pseudo-header identifies the
upper-layer protocol (e.g., 6 for TCP, or 17 for UDP). It will
differ from the Next Header value in the IPv6 header if there
are extension headers between the IPv6 header and the upper-
layer header.
o The Upper-Layer Packet Length in the pseudo-header is the
length of the upper-layer header and data (e.g., TCP header
plus TCP data). Some upper-layer protocols carry their own
length information (e.g., the Length field in the UDP header);
for such protocols, that is the length used in the pseudo-
header. Other protocols (such as TCP) do not carry their own
length information, in which case the length used in the
pseudo-header is the Payload Length from the IPv6 header, minus
the length of any extension headers present between the IPv6
header and the upper-layer header.
o Unlike IPv4, when UDP packets are originated by an IPv6 node,
the UDP checksum is not optional. That is, whenever
originating a UDP packet, an IPv6 node must compute a UDP
checksum over the packet and the pseudo-header, and, if that
computation yields a result of zero, it must be changed to hex
FFFF for placement in the UDP header. IPv6 receivers must
discard UDP packets containing a zero checksum, and should log
the error.
The IPv6 version of ICMP [ICMPv6] includes the above pseudo-header in
its checksum computation; this is a change from the IPv4 version of
ICMP, which does not include a pseudo-header in its checksum. The
reason for the change is to protect ICMP from misdelivery or
corruption of those fields of the IPv6 header on which it depends,
which, unlike IPv4, are not covered by an internet-layer checksum.
The Next Header field in the pseudo-header for ICMP contains the
value 58, which identifies the IPv6 version of ICMP.
next prev parent reply other threads:[~2025-08-07 17:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 15:32 Gábor LENCSE
2025-08-07 17:57 ` Stephen Hemminger [this message]
2025-08-08 18:56 ` Gábor LENCSE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250807105703.22de669d@hermes.local \
--to=stephen@networkplumber.org \
--cc=lencse@hit.bme.hu \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).