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. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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: | 3 | 45 bits | 16 bits | 64 bits | +---+---------------------+---------+----------------------------------+ |001|global routing prefix|subnet ID| Interface Identifier (IID) | +---+---------------------+---------+----------------------------------+ ILNP (RFC6741) - Identifier Locator Vector (I-LV): | 64 bits | 64 bits | +---+---------------------+---------+----------------------------------+ | Locator (L64) | Node Identifier (NID) | +---+---------------------+---------+----------------------------------+ 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, . [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, DOI 10.17487/RFC1141, January 1990, . [RFC1624] Rijsinghani, A., Ed., "Computation of the Internet Checksum via Incremental Update", RFC 1624, DOI 10.17487/RFC1624, May 1994, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6741] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, DOI 10.17487/RFC6741, November 2012, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 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]