DPDK usage discussions
 help / color / mirror / Atom feed
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.

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