Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

TCP and UDP checksum calculations for ILNP
draft-bhatti-ilnp-tcp-udp-checksums-00

Versions:

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

Document	Type	Active Internet-Draft (individual)
	Authors	SN Bhatti , Rodney Grimes , Gorry Fairhurst
	Last updated	2026-06-17
	RFC stream	(None)
	Intended RFC status	(None)
	Formats	txt html xml htmlized bibtex bibxml
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Nits v3 Search email archive

draft-bhatti-ilnp-tcp-udp-checksums-00

Network Working Group S. N. Bhatti
Internet-Draft University of St Andrews, UK
Updates: 6740, 6741, 6748 (if approved) R. W. Grimes
Intended status: Experimental Independent, USA
Expires: 19 December 2026 G. Fairhurst
University of Aberdeen, UK
17 June 2026

TCP and UDP checksum calculations for ILNP
draft-bhatti-ilnp-tcp-udp-checksums-00

Abstract

The Identifier Locator Network Protocol (ILNP) for IPv6 is described
in Experimental RFCs 6740-6744. ILNP defines the use of an
Identifier-Locator Vector (I-LV) with a zero value L64 value and a
relevant Node Identifier (NID) value in place of an IPv6 address in
the pseudo-header for transport protocol checksum computations.
However, as TCP and UDP predate ILNP, this change causes TCP and UDP
checksum values to be generated for ILNP flows that are different to
the same flows on IPv6. This document changes the checksum
computation for TCP and UDP with ILNP so that the checksum values are
the same for ILNP and IPv6. This document updates the checksum
processing for TCP and UDP described in RFC6740 and RFC6741, and the
way the checksum processing should be applied for TCP and UDP in
RFC6748.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-bhatti-ilnp-tcp-udp-
checksums/.

Discussion of this document takes place on the Network Network
Working Group mailing list (mailto:saleem@st-andrews.ac.uk).

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Bhatti, et al. Expires 19 December 2026 [Page 1]
Internet-Draft ILNP TCP/UDP checksums June 2026

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 19 December 2026.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
2.1. Definitions from other documents . . . . . . . . . . . . 4
3. Updates to previous RFC documents . . . . . . . . . . . . . . 5
3.1. RFC6740 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. RFC6741 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. RFC6748 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. L64 values in checksum computations for TCP and UDP . . . . . 6
4.1. Change to the ILNP checksum computation for TCP and
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Benefits of the change . . . . . . . . . . . . . . . . . 6
4.3. Previous ILNP checksum computation for TCP and UDP . . . 7
4.4. Principle of end-to-end transport state for ILNP . . . . 7
4.5. Operational considerations . . . . . . . . . . . . . . . 8
5. Incremental checksum update for TCP and UDP . . . . . . . . . 8
5.1. Background . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Example implementations . . . . . . . . . . . . . . . . . 9
5.3. TCP and UDP and incremental checksum update . . . . . . . 10
5.3.1. Example implementation: pre-calculated s_L64 and
d_L64 . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. Example implementation: packet buffer . . . . . . . . 11
5.4. Incremental update for an ILNP-aware packet forwarder . . 12
5.4.1. Example implementation for the LRR . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14

Bhatti, et al. Expires 19 December 2026 [Page 2]
Internet-Draft ILNP TCP/UDP checksums June 2026

9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16

1. Introduction

The Identifier Locator Network Protocol (ILNP) redefines the IP
addressing architecture by use of new addressing datatypes [RFC6740]
[RFC6741]. The ILNP addressing datatypes considered in this document
are:

* _Locator (L64)_: A 64-bit value (8 bytes, in network / canonical
byte order) that is a label for a network.

* _Node Identifier (NID)_: A 64-bit value (8 bytes, in network /
canonical byte order) that is a label for a node.

* _Identifier-Locator Vector (I-LV)_: The 128-bit concatenation of a
single L64 value and single NID value for use in the IPv6 packet
header in the source address and destination address fields.

These datatypes are realised and used within the context of IPv6
[RFC6741]: an ILNP packet will use the address fields in an IPv6
packet [RFC8200] to carry I-LV values constructed from L64 and NID
values, as shown in Figure 1.

[RFC6740] and [RFC6741] redefine the checksum computation for TCP and
UDP in light of these new datatypes and as discussed in Section 4.3.

IPv6 (RFC8200 / STD86) - general IPv6 global address format:

ILNP (RFC6741) - Identifier Locator Vector (I-LV):

Figure 1: An IPv6 address (RFC8200 / STD86) and an ILNP
Identifier-Locator Vector (RFC6741), as used in the address
fields of the IPv6 packet header.

Bhatti, et al. Expires 19 December 2026 [Page 3]
Internet-Draft ILNP TCP/UDP checksums June 2026

1.1. Purpose

This document changes the guidance in [RFC6740] and [RFC6741] for the
computation of the checksums for TCP and UDP when used with ILNP so
that there is:

1. alignment with existing definitions and deployments of TCP and
UDP for IPv6.

2. alignment with use of TCP and UDP by existing IPv6 applications
to allow operation over ILNP.

_That is, the checksum computation for TCP and UDP for ILNP becomes
the same as for IPv6._

ILNP is defined for use with IPv6 and for use with IPv4, but all
references in this document to ILNP are for IPv6 only.

1.2. Rationale

The discussion and arguments presented in [RFC6740] for using only
NID values for transport protocol end-to-end state in ILNP still
stand. However, as ILNP packets are IPv6 packets, and existing
deployments that are not ILNP-aware expect TCP and UDP checksums to
be as defined for IPv6, so changing the checksum computation for ILNP
creates a tension. In keeping with enabling ILNP usage by IPv6
applications [draft-bhatti-ilnp-ip6-apps], and improving the
deployment capability for ILNP in general, this document removes that
tension.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2.1. Definitions from other documents

The following terms are defined in [RFC6740]:

* Locator, L64

* Node Identifier, NID

* Identifier-Locator Vector, I-LV

Bhatti, et al. Expires 19 December 2026 [Page 4]
Internet-Draft ILNP TCP/UDP checksums June 2026

* Identifier Locator Communications Cache, ILCC

* Source I-LV

* Destination I-LV

The following terms are defined in [RFC6748]:

* Locator Re-writing Relay, LRR

3. Updates to previous RFC documents

RFC documents that are updated by this document are:

* RFC6740 "Identifier-Locator Network Protocol (ILNP) Architectural
Description" [RFC6740].

* RFC6741 "Identifier-Locator Network Protocol (ILNP) Engineering
Considerations" [RFC6741].

* RFC6748 "Optional Advanced Deployment Scenarios for the
Identifier-Locator Network Protocol (ILNP)" [RFC6748].

3.1. RFC6740

Section 3.5 of [RFC6740] is updated: the pseudo-header for a TCP or
UDP checksum computation now includes the whole source I-LV and
destination I-LV at the sender, and the whole source I-LV and
destination I-LV in the packet that is received at the receiver.

3.2. RFC6741

Section 4.2 of [RFC6741] is updated, as for Section 3.5 of [RFC6740]
described above.

The text in the final paragraph of Section 5.4 of [RFC6741] is no
longer relevant.

Note that Section 4.3 of [RFC6741] already defined that the checksum
computation for ICMPv6 messages use the whole source I-LV and whole
destination I-LV for backwards compatibility with IPv6, i.e. that the
checksum computation for ICMPv6 messages over ILNP are the same as
for IPv6.

Bhatti, et al. Expires 19 December 2026 [Page 5]
Internet-Draft ILNP TCP/UDP checksums June 2026

3.3. RFC6748

[RFC6748] describes use cases and scenarios for ILNP. Many of the
use cases employ an ILNP-aware Site Border Routers (SBR). SBRs that
change the L64 value for ILNP packets in a flow are said to contain a
Locator Re-writing Relay (LRR) function. If the LRR function is
applied to a TCP or UDP flow, the checksum recomputation as described
in Section 4.1 MUST be applied. As these changes make ILNP flows
align with the current use of TCP and UDP with IPv6, so the operation
of firewall functions at SBRs is made easier and more consistent with
TCP and UDP as used over IPv6.

4. L64 values in checksum computations for TCP and UDP

Overall, the changes in Section 4.1 have the effect of making the
ILNP checksum computation for TCP and UDP to be exactly the same as
the IPv6 checksum computation for TCP and UDP.

TCP segments and UDP datagrams are just referred to as "packets" in
this document, for ease: the principle is the same, as the checksum
computation for both is the same, but using different pseudo-header
fields.

4.1. Change to the ILNP checksum computation for TCP and UDP

The description in Section 4.3 is changed so that when TCP and UDP
flows use ILNP, the pseudo-header used for the checksum computation:

1. at the sender, MUST include the whole source I-LV and whole
destination I-LV values that will be used in the transmitted
packet header.

2. at the receiver, MUST include the whole source I-LV and whole
destination I-LV from the received packet header.

_So, the algorithm and pseudo-header used in the checksum computation
with TCP and UDP for ILNP are now exactly the same as for IPv6._

4.2. Benefits of the change

Overall, the changes in Section 4.1 improve compatibility of ILNP for
TCP and UDP flows with IPv6 flows, and particularly in the following
situations:

1. When used with existing IPv6 applications, and is in keeping with
the aim of [draft-bhatti-ilnp-ip6-apps].

Bhatti, et al. Expires 19 December 2026 [Page 6]
Internet-Draft ILNP TCP/UDP checksums June 2026

2. For existing firewall deployments and configurations, as ILNP
flows for TCP and UDP will now appear just as IPv6 flows for TCP
and UDP. No extra processing is needed for ILNP packets for TCP
and UDP compared to what is already needed for IPv6.

3. When using off-load processing for TCP and UDP with IPv6 in
hardware, e.g. server NICs, where the ILNP checksum computation
as defined in Section 4.2 of [RFC6741] is unlikely to be
implemented, but where the standard IPv6 checksum algorithm for
TCP and UDP is already implemented and deployed. This means that
no extra or different processing is needed for ILNP packets for
TCP and UDP ath the reciever compared to what is already done for
IPv6.

4.3. Previous ILNP checksum computation for TCP and UDP

In Section 4.2 of [RFC6741] is the following text:

To minimise the changes required within transport protocol
implementations, and to maximise interoperability, current
implementations are modified to zero the Locator fields (only for the
purpose of TCP or UDP checksum calculations).

That is, the checksum computation is the same as for IPv6, but the
top 64 bits of the 128-bit values for the source I-LV and destination
I-LV (carried, respectively, in the source and destination IPv6
address fields of the packet header) are set to zero. This is a
small change in terms of overall implementation footprint for the
checksum, but it results in a checksum value for TCP and UDP with
ILNP that is different compared to IPv6.

4.4. Principle of end-to-end transport state for ILNP

In Section 3.5 of [RFC6740] is the following text:

In ILNP, protocols above the network layer do not use the Locator
values. Thus, the transport layer uses only the I values for the
transport-layer session state [ ... ]

The changes in Section 4.1 do not negate that general principle
proposed for ILNP: that transport layer state needs to use (I values)
NID values only, and not L64 values, i.e. not the whole of the
128-bit I-LV. This is so that there is end-to-end state invariance
for the duration of the transport flow, and that end-to-end state
does not use datatypes that are bound to any topological state or
forwarding state. This remains true for end-to-end state for TCP and
UDP operating over ILNP. However, the checksum for TCP and UDP is
not part of the end-to-end state and is only used on a per-packet

Bhatti, et al. Expires 19 December 2026 [Page 7]
Internet-Draft ILNP TCP/UDP checksums June 2026

basis for detecting errors in transmission. So, we can maintain the
principle stated above for ILNP, but achieve better compatibility
with existing IPv6 deployments by aligning the checksum computation
for TCP and UDP with IPv6. This will give a wire-image for a TCP
packet and UDP packet that is fully-compatible with IPv6.

TCP and UDP and their respective checksum algorithm definitions
predate ILNP. Future transport protocols that are designed
specifically to operate over ILNP might define a checksum algorithm
that uses the NID values only as part of a pseudo-header, but that is
not a requirement.

So, the changes in Section 4.1 recognise the need for, and value of,
improved backwards compatibility with TCP and UDP when used over ILNP
for IPv6 applications [draft-bhatti-ilnp-ip6-apps], as well as the
improved deployment compatibility for ILNP.

Indeed, as noted in Section 4.3, the intention for Section 4.2 of
[RFC6741] was:

To minimise the changes required within transport protocol
implementations, and to maximise interoperability, ...

So the change introduced in this document aligns better with that
intention from [RFC6741], and is still in keeping with the ILNP
principle of end-to-end transport state.

4.5. Operational considerations

ILNP functionality overall is not impacted. The changes in
Section 4.1 should have a minimal code-change footprint for existing
ILNP implementations, and will be easy to implement and deploy --
example implementations are provided in Section 5.

The changes documented here mean that existing firewalls and hardware
offload implementations for IPv6 should not need to be updated when
ILNP is used with TCP and UDP.

5. Incremental checksum update for TCP and UDP

Essentially, the incremental checksum update for TCP and UDP over
ILNP requires the source and destination L64 values to be included in
the pseudo-header.

An existing ILNP implementation executes the checksum algorithm as
noted in Section 4.3, which would be the same for TCP and UDP, albeit
with different pseudo-headers in each case. However, in both cases,
the source and destination NID values are included, while the source

Bhatti, et al. Expires 19 December 2026 [Page 8]
Internet-Draft ILNP TCP/UDP checksums June 2026

and destination L64 values are not. So, one implementation approach
is simply that the source L64 and destination L64 values are written
into place in the packet and then the transport layer checksum is
recalculated over the _whole_ packet. However, it is RECOMMENDED
that _incremental checksum update_ methods are used for improved
efficiency and performance.

We describe simple methods below to perform incremental checksum
updates for TCP and UDP over ILNP. These allow the checksum to be
recalculated just-in-time, just before transmission, after a
forwarding decision has been made, and so both the source L64 and
destination L64 values are known.

5.1. Background

The incremental update to the checksum is in keeping with previous
checksum update mechanisms defined in [RFC1624], [RFC1141], and
[RFC1071]. [RFC1624] updates [RFC1141], and [RFC1141] obsoletes
[RFC1071]. Nevertheless, [RFC1624] states:

It is recommended that intermediate systems compute incremental
checksum using the method described in this document, and end systems
verify checksum as per the method described in RFC 1071.

That is, as written in Section 1 of [RFC1071]:

To check a checksum, the 1's complement sum is computed over the same
set of octets, including the checksum field. If the result is all 1
bits (-0 in 1's complement arithmetic), the check succeeds.

The simple algorithms described in this section are in the same
spirit as described in [RFC1624], [RFC1141], and [RFC1071].

5.2. Example implementations

Also, in keeping with [RFC1141] and [RFC1071], we provide example
implementations in C -- Figure 3, Figure 4, Figure 6. These perform
incremental update of the checksum value in place, for efficiency and
performance, using only the values of the changed header fields:

* All arithmetic uses one's complement sum for 16-bit values, as in
[RFC1624], [RFC1141], and [RFC1071].

* In all cases, 32-bit unsigned integer accumulator variables are
used for arithmetic of 16-bit values to maintain carry bits
correctly, and then a cast is used for 16-bit values when
required.

Bhatti, et al. Expires 19 December 2026 [Page 9]
Internet-Draft ILNP TCP/UDP checksums June 2026

* As unsigned integer values are used, when subtraction of a value
is required (in Figure 6) the one's complement of that value is
used with addition.

However, other implementations are possible, of course: these are
only examples.

5.3. TCP and UDP and incremental checksum update

The general approach in Figure 2 relies on the simplicity of the
checksum algorithm, and is similar to approaches taken previously,
e.g. [RFC1624].

Let:

c_z be the 16-bit value in the checksum field when
calculated with zero'd L64 values.
s_L64 be the one's complement sum of the 16-bit words
for the source L64.
d_L64 be the one's complement sum of the 16-bit words
for the destination L64.
c_i be the incrementally updated checksum value,
including s_L64 and d_L64.

c_i = ~(~c_z + s_L64 + d_L64)

Figure 2: The general algorithm for an incremental checksum
update for the value in the transport layer header checksum for a
TCP or UDP packet over ILNP.

* c_i is then copied back into the checksum field for the packet.

5.3.1. Example implementation: pre-calculated s_L64 and d_L64

The source L64 and destination L64 will be relatively stable,
therefore so will s_L64 and d_l64. s_L64 and d_L64 would be
(re-)calculated once, when new source L64 or destination L64 values
become known, and cached in the ILCC. For communication between
multihomed nodes, there could be multiple source L64 and destination
L64 values in use. Overall, pre-calculating s_L64 and d_L64 for each
L64 in use, when it becomes known, would reduce the per-packet
overhead at transmission time. The C example in Figure 3 is a simple
implementation example for the algorithm of Figure 2. It assumes
that these pre-calculated values are available, and a pointer to the
checksum field in the transport layer header is given for the packet
buffer that is to be transmitted:

Bhatti, et al. Expires 19 December 2026 [Page 10]
Internet-Draft ILNP TCP/UDP checksums June 2026

1. The s_L64 and d_L64 values are the pre-calculated values from the
ILCC.

2. The transport checksum field contains an ILNP version of the
checksum, c_z, i.e. with zero'd source L64 and destination L64
values.

void
ilnp_checksum_update(const uint32_t s_L64, /* src L64 sum */
const uint32_t d_L64, /* dst L64 sum */
uint8_t *checksum) /* checksum field */
{
uint32_t c_z = ntohs(*((uint16_t *) checksum));
uint32_t c_i;

c_i = (~c_z & 0x0000ffff) + s_L64 + d_L64;
c_i = (c_i >> 16) + (c_i & 0x0000ffff); /* carry */
c_i = ~c_i & 0x0000ffff;

*((uint16_t *) checksum) = htons((uint16_t) c_i);
}

Figure 3: A simple implementation example for the incremental
checksum update algorithm for the TCP or UDP header checksum.

5.3.2. Example implementation: packet buffer

As an alternative, if s_L64 and s_L64 cannot be pre-calculated, it is
possible to operate directly on the packet buffer, as in Figure 4.
This assumes that pointers are provided to header fields in the
packet buffer, for the source L64, destination L64, and checksum:

1. The correct source L64 and destination L64 values to be used are
in place in the packet buffer.

2. The transport checksum field contains an ILNP version of the
checksum, c_z, i.e. calculated with zero'd source L64 and
destination L64 values.

Bhatti, et al. Expires 19 December 2026 [Page 11]
Internet-Draft ILNP TCP/UDP checksums June 2026

void
ilnp_checksum_packet(const uint8_t *src_L64, /* src L64 field */
const uint8_t *dst_L64, /* dst L64 field */
uint8_t *checksum) /* checksum field */
{
uint32_t c_z = ntohs(*((uint16_t *) checksum));
uint32_t s_L64 = 0;
uint32_t d_L64 = 0;
uint32_t c_i;

for (int i = 0; i < 4; ++i) {
s_L64 += ntohs(((uint16_t *) src_L64)[i]);
d_L64 += ntohs(((uint16_t *) dst_L64)[i]);
}

c_i = (~c_z & 0x0000ffff) + s_L64 + d_L64;
c_i = (c_i >> 16) + (c_i & 0x0000ffff); /* carry */
c_i = ~c_i & 0x0000ffff;

*((uint16_t *) checksum) = htons((uint16_t) c_i);
}

Figure 4: An alternative implementation example for the
incremental checksum update algorithm, working directly with
packet header fields for a transmission buffer.

5.4. Incremental update for an ILNP-aware packet forwarder

An ILNP-aware packet forwarder, such as described in Section 2 of
[RFC6748] or Section 7 of [RFC6748], can change the source L64 and/or
the destination L64 before it forwards a packet -- this is a Locator
Re-writing Relay (LRR) function. With the ILNP checksum algorithm as
defined Section 4.3, the LRR would simply re-write the source and/or
destination L64 values in the packet and forward the packet. With
the checksum algorithm implemented as in Section 5.3, the LRR must
now also update the transport header checksum.

The incremental checksum update for the LRR function is a logical
extension of the incremental update described in Section 5.3. For
the incremental checksum evaluation for a LRR:

* the sums of the 16-bit words of the "old" L64 values, o_s_L64 and/
or o_d_L64, must be subtracted from the checksum; and

* the sums of the 16-bit words of the "new" L64 values, n_s_L64 and/
or n_s_L64, must be added to the checksum.

Bhatti, et al. Expires 19 December 2026 [Page 12]
Internet-Draft ILNP TCP/UDP checksums June 2026

The description of the algorithm is given in Figure 5. This general
approach is also suitable for any other ILNP-aware packet forwarder
that makes changes to L64 values.

Let:

c_o be the old 16-bit value in the checksum field.
o_s_L64 be the one's complement sum of the 16-bit words
of the old source L64.
o_d_L64 be the one's complement sum of the 16-bit words
of the old destination L64.
n_s_L64 be the one's complement sum of the 16-bit words
of the new source L64.
n_d_L64 be the one's complement sum of the 16-bit words
of the new destination L64.
l_o be the complement of the of sum of o_s_L64 and
o_d_L64 (i.e. the negative value of the sum).
c_n be the new, incrementally updated checksum value,
including n_s_L64 and n_d_L64.

l_o = ~(o_s_L64 + o_d_L64)
c_n = ~(~c_o + l_o + n_s_L64 + n_d_L64)

Figure 5: The general algorithm for an incremental checksum
update for the TCP or UDP header checksum for an ILNP-aware
packet-forwarder that changes the source and/or destination L64
values, such as a LRR function.

* l_o is the accumulator for the negative of the sum of the old L64
values, and is shown separately as a reminder to correctly handle
the carry bits for this accumulator before adding it to c_i.

* c_n is then copied back into the checksum field for the packet.

5.4.1. Example implementation for the LRR

The example of Figure 6 is a simple implementation of Figure 5. This
assumes the use of pre-calculated values for o_s_L64, o_d_L64,
n_s_L64, and n_d_L64. Of course, a similar mechanism can be applied
as for Figure 4 if there is a requirement to operate directly on the
packet buffer.

Bhatti, et al. Expires 19 December 2026 [Page 13]
Internet-Draft ILNP TCP/UDP checksums June 2026

void
ilnp_checksum_lrr(const uint32_t o_s_L64, /* old src L64 sum */
const uint32_t o_d_L64, /* old dst L64 sum */
const uint32_t n_s_L64, /* new src L64 sum */
const uint32_t n_d_L64, /* new dst L64 sum */
uint8_t *checksum) /* checksum field */
{
uint32_t c_o = ntohs(*((uint16_t *) checksum));
uint32_t l_o;
uint32_t c_n;

l_o = ~(o_s_L64 + o_d_L64);
l_o = (l_o >> 16) + (l_o & 0x0000ffff); /* carry */

c_n = (~c_o & 0x0000ffff) + l_o + n_s_L64 + n_d_L64;
c_n = (c_n >> 16) + (c_n & 0x0000ffff); /* carry */
c_n = ~c_n & 0x0000ffff;

*((uint16_t *) checksum) = htons((uint16_t) c_n);
}

Figure 6: A simple implementation example for the incremental
checksum update algorithm for an ILNP-aware forwarder, such as a
LRR function.

6. Security Considerations

There are no new security considerations.

Security considerations remain unchanged from those already defined
for ILNP (please see Section 9 of [RFC6740], Section 11 of
[RFC6741]).

7. Privacy Considerations

There are no new privacy considerations.

The existing identity privacy and location privacy mechanisms already
defined for ILNP remain unchanged (please see Section 10 of
[RFC6740], Section 12 of [RFC6741]).

8. IANA Considerations

This document has no IANA actions.

9. References

9.1. Normative References

Bhatti, et al. Expires 19 December 2026 [Page 14]
Internet-Draft ILNP TCP/UDP checksums June 2026

[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
September 1988, <https://www.rfc-editor.org/rfc/rfc1071>.

[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, DOI 10.17487/RFC1141,
January 1990, <https://www.rfc-editor.org/rfc/rfc1141>.

[RFC1624] Rijsinghani, A., Ed., "Computation of the Internet
Checksum via Incremental Update", RFC 1624,
DOI 10.17487/RFC1624, May 1994,
<https://www.rfc-editor.org/rfc/rfc1624>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012,
<https://www.rfc-editor.org/rfc/rfc6740>.

[RFC6741] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Engineering Considerations", RFC 6741,
DOI 10.17487/RFC6741, November 2012,
<https://www.rfc-editor.org/rfc/rfc6741>.

[RFC6748] Atkinson, RJ. and SN. Bhatti, "Optional Advanced
Deployment Scenarios for the Identifier-Locator Network
Protocol (ILNP)", RFC 6748, DOI 10.17487/RFC6748, November
2012, <https://www.rfc-editor.org/rfc/rfc6748>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.

9.2. Informative References

[draft-bhatti-ilnp-ip6-apps]
Bhatti, S. N., Haywood, G. T., Yanagida, R., and R. W.
Grimes, "ILNP usage by IPv6 applications", 8 May 2026. A
related draft that is being produced in parallel.

Bhatti, et al. Expires 19 December 2026 [Page 15]
Internet-Draft ILNP TCP/UDP checksums June 2026

Acknowledgements

The authors are grateful to the many members of the IETF community
for their feedback on ILNP during IETF meetings, and to the IETF NOC
Team who made possible testing and experiments for ILNP during those
meetings and the IETF Hackathon events.

The authors also thank those participants of the RIPE92 meeting
(18-22 May 2026, Edinburgh, UK) who gave comments, feedback, and
encouragement that led to this document being written.

This work was partly supported by the _ICANN Grant Program_.

Authors' Addresses

Saleem N. Bhatti
University of St Andrews, UK
Email: saleem@st-andrews.ac.uk

Rodney W. Grimes
Independent, USA
Email: rgrimes@FreeBSD.org

Gorry Fairhurst
University of Aberdeen, UK
Email: gorry@erg.abdn.ac.uk

Bhatti, et al. Expires 19 December 2026 [Page 16]

TCP and UDP checksum calculations for ILNP draft-bhatti-ilnp-tcp-udp-checksums-00

TCP and UDP checksum calculations for ILNP
draft-bhatti-ilnp-tcp-udp-checksums-00