From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DFD4B46CE9 for ; Thu, 7 Aug 2025 19:57:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7EB694027C; Thu, 7 Aug 2025 19:57:11 +0200 (CEST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by mails.dpdk.org (Postfix) with ESMTP id 8433140270 for ; Thu, 7 Aug 2025 19:57:09 +0200 (CEST) Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-3b78bca0890so624981f8f.3 for ; Thu, 07 Aug 2025 10:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1754589429; x=1755194229; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=ULccUHwRSayZB7I4va1XRLGknXxFRXGpiqqRHe5/BAU=; b=qU8BoA9lMbMzbABUuGzKTIaAHxuRgezQ188Pbvwl6mO11FKCIcHmzdxa6Mrn+JlzyP j4Ztzp0vZVsv7SqOjvO8J0k0jsUmgTOFAkKOIDDDKdcWaZql2vTb9ZJ8F8Sp4TUtdJrT vjk8TwXOLHHy0iELzhQBOJ3RHIvqsGqlStcmoc2cRhHa5p0AHUEGWVjK3XrtLWIK3RdR FjZIX5XgZnSAg6ClPXHWI3PWqAk/7bVG5NdKj0TlDvdF4w35EyhcPEAlZfEPgerDa2lV xjVOe+pKoK6mwhkZfGhDm+WerrWz/dDVeeswEc2dAD59IJsnCGphabYmVw1XjoGhiys7 sglw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754589429; x=1755194229; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ULccUHwRSayZB7I4va1XRLGknXxFRXGpiqqRHe5/BAU=; b=LiiWUJadlOVEBqVtnZumsdpPZoeTHQeywZts59GFmNeCG2rTDVcKR6RW0bRfhWx4S5 5wangISD1CwnFRkJ56/P0Jx5PmOrwJ0Pp0mKSm1znQIQi8HKxCpbCbUWxOmJEETBisP0 htVgzjIouQm/qoODFPGIRZMcWlxVEvP07SIktNSPdF809sOYgiJ4jIU/GFK47b1DNaFd GLtLEk/GWieyYbTu3eJuKOe4X1UCwtnnpsAmoAtDBF054QAt4ZsecKhXpOBhkM82a7FR NKjc3mSx0DraK/WUqqihZBeYaQt/TgG0HdGPUzzNo5qhB5JcLWMyZQDAEJF7iTaYGoYr A1AA== X-Gm-Message-State: AOJu0YylBaH8KqsKu0dCh7CgklUCV6lucA9CKeonttzZy/R6SbD07ha4 2DRnaY+zVgQVMDwwnpPIIHTs63jZFKRpf4zm4+nsUS9ZhPgDmCBfU6MTZ2v4CYL6WutANmpKGju E/Q2A X-Gm-Gg: ASbGnctN9AwEZe4oDCTg39g6FQgXmI5LlGOmhWdHuLrLGT/5fviR9kbVIU3D7XyWNna ZdrFzi0dvnLfX4wux+NEv5gKMEG5QuHIt9jdBaRiqz6/kh3o96fdezX8Wp+gzdPlYjiDMQ1JgGE E0Y5nff1jTUniCP93NsC7NUpJ9+coK1WmPxucy8zG9phftdekuQZf7+JSDcoAqiD3MIfkt4f1M8 UqZ1JykDVcKdUaIHMFSOTnhl58vNP5i7fAX9Q8obXOGWHMbtstRWvpe0HSAEqfFT6CtotmP3pGP ERcAE8fHXSRk/rAM5fEqPFmXQTY3lboRHHRkV6DqElrspWwltW3Nh+P3FxjQjJ9ErdOsF055sXb XNMYYp7EqFr/ce3U/+iDa3DXlhwMkM/6up2SWyyBivsvrEokAmbwDvLCbjQJ4yc5dt4RiOAVrku A= X-Google-Smtp-Source: AGHT+IHJZe+ACD2jnqNqMHz3ZoY7diPKAxeZWmP6Bxvm+v/6455t0Ou4gMqsxPyLs2UZP7ZvzBD6MQ== X-Received: by 2002:a5d:64e7:0:b0:3b7:58be:8fc with SMTP id ffacd0b85a97d-3b900b51133mr107948f8f.43.1754589429068; Thu, 07 Aug 2025 10:57:09 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-458be70c5f7sm227111345e9.26.2025.08.07.10.57.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Aug 2025 10:57:08 -0700 (PDT) Date: Thu, 7 Aug 2025 10:57:03 -0700 From: Stephen Hemminger To: =?UTF-8?B?R8OhYm9y?= LENCSE Cc: "users@dpdk.org" Subject: Re: How to calculate ICMPv6 checksum? Message-ID: <20250807105703.22de669d@hermes.local> In-Reply-To: <40938de8-49b3-46d0-964b-9cd296000d10@hit.bme.hu> References: <40938de8-49b3-46d0-964b-9cd296000d10@hit.bme.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Thu, 7 Aug 2025 17:32:02 +0200 G=C3=A1bor LENCSE wrote: > Dear All, >=20 > I am working on adding ARP/NDP support to my SIIT / Stateful NAT64=20 > benchmarking tool, siitperf [1]. (So far, the ARP / NDP table entries=20 > had to be set manually at the device under test, as siitperf was not=20 > able to reply to ARP / NDP requests). >=20 > The ARP reply functionality seems to work fine, but I have a problem=20 > with NDP. As ICMPv6 messages contain checksum, I would need a function=20 > that computes it. However, I only found=C2=A0 the=C2=A0rte_ipv6_udptcp_ck= sum()=20 > function, but I did not find a similar one for calculating ICMPv6 checksu= m. >=20 > I have been checking the functions shown here:=20 > https://doc.dpdk.org/api/rte__ip6_8h.html >=20 > Could you please advise me about the function to use for ICMPv6 checksum= =20 > calculation? >=20 > Best regards, >=20 > G=C3=A1bor >=20 > [1]=C2=A0https://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.