]> University of St Andrews, UK

saleem@st-andrews.ac.uk

Independent, USA

rgrimes@FreeBSD.org

University of Aberdeen, UK

gorry@erg.abdn.ac.uk

Network Network Working Group Identifier Locator Network Protocol (ILNP) Identifier-Locator Vector (I-LV) Locator (L64) Node Identifier (NID) DNS 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. Status information for this document may be found at . Discussion of this document takes place on the Network Network Working Group mailing list ().

Introduction The Identifier Locator Network Protocol (ILNP) redefines the IP addressing architecture by use of new addressing datatypes . 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 : an ILNP packet will use the address fields in an IPv6 packet to carry I-LV values constructed from L64 and NID values, as shown in . and redefine the checksum computation for TCP and UDP in light of these new datatypes and as discussed in .

Purpose This document changes the guidance in and for the computation of the checksums for TCP and UDP when used with ILNP so that there is: alignment with existing definitions and deployments of TCP and UDP for IPv6. 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.

Rationale The discussion and arguments presented in 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 , and improving the deployment capability for ILNP in general, this document removes that tension.

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 when, and only when, they appear in all capitals, as shown here.

Definitions from other documents The following terms are defined in : Locator, L64 Node Identifier, NID Identifier-Locator Vector, I-LV Identifier Locator Communications Cache, ILCC Source I-LV Destination I-LV The following terms are defined in : Locator Re-writing Relay, LRR

Updates to previous RFC documents RFC documents that are updated by this document are: RFC6740 "Identifier-Locator Network Protocol (ILNP) Architectural Description" . RFC6741 "Identifier-Locator Network Protocol (ILNP) Engineering Considerations" . RFC6748 "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)" .

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.

RFC6741 is updated, as for described above. The text in the final paragraph of is no longer relevant. Note that 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.

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

L64 values in checksum computations for TCP and UDP Overall, the changes in 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.

Change to the ILNP checksum computation for TCP and UDP The description in is changed so that when TCP and UDP flows use ILNP, the pseudo-header used for the checksum computation: 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. 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.

Benefits of the change Overall, the changes in improve compatibility of ILNP for TCP and UDP flows with IPv6 flows, and particularly in the following situations: When used with existing IPv6 applications, and is in keeping with the aim of . 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. 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 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.

Previous ILNP checksum computation for TCP and UDP In 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.

Principle of end-to-end transport state for ILNP In 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 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 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 recognise the need for, and value of, improved backwards compatibility with TCP and UDP when used over ILNP for IPv6 applications , as well as the improved deployment compatibility for ILNP. Indeed, as noted in , the intention for 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 , and is still in keeping with the ILNP principle of end-to-end transport state.

Operational considerations ILNP functionality overall is not impacted. The changes in should have a minimal code-change footprint for existing ILNP implementations, and will be easy to implement and deploy -- example implementations are provided in . 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.

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 , 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 and destination L64 values are not. So, one implementation approach is simply that the transport layer checksum is (re-)calculated with the source L64 and destination L64 values included in the pseudo-header. 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.

 Background The incremental update to the checksum is in keeping with previous checksum update mechanisms defined in , , and . updates , and obsoletes . Nevertheless, 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 : 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 , , and .

Example implementations Also, in keeping with and , we provide example implementations in C -- , , . 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 , , and . 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. As unsigned integer values are used, when subtraction of a value is required (in ) the one's complement of that value is used with addition. However, other implementations are possible, of course: these are only examples.

TCP and UDP and incremental checksum update The general approach in relies on the simplicity of the checksum algorithm, and is similar to approaches taken previously, e.g. .

c_i is then copied back into the checksum field for the packet, over-writing the value c_z.

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 is a simple implementation example for the algorithm of . 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: The s_L64 and d_L64 values are the pre-calculated values from the ILCC. The transport checksum field contains an ILNP version of the checksum, c_z, i.e. with zero'd source L64 and destination L64 values.

> 16) + (c_i & 0x0000ffff); /* carry */ c_i = ~c_i & 0x0000ffff; *((uint16_t *) checksum) = htons((uint16_t) c_i); } ]]>

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 . This assumes that pointers are provided to header fields in the packet buffer, for the source L64, destination L64, and checksum: The correct source L64 and destination L64 values to be used are in place in the packet buffer. 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.

> 16) + (c_i & 0x0000ffff); /* carry */ c_i = ~c_i & 0x0000ffff; *((uint16_t *) checksum) = htons((uint16_t) c_i); } ]]>

Incremental update for an ILNP-aware packet forwarder An ILNP-aware packet forwarder, such as described in or , 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 , 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 , 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 . 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. The description of the algorithm is given in . This general approach is also suitable for any other ILNP-aware packet forwarder that makes changes to L64 values.

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_n. c_n is then copied back into the checksum field for the packet, over-writing the value c_o.

 Example implementation for the LRR The example of is a simple implementation of . 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 if there is a requirement to operate directly on the packet buffer.

> 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); } ]]>

Security Considerations There are no new security considerations. Security considerations remain unchanged from those already defined for ILNP (please see , ).

Privacy Considerations There are no new privacy considerations. The existing identity privacy and location privacy mechanisms already defined for ILNP remain unchanged (please see , ).

IANA Considerations This document has no IANA actions.

This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques. This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique. This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. University of St Andrews, UK Abertay University, UK University of St Andrews, UK Independent, USA A related draft that is being produced in parallel.

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. Thanks to Mike Heard (C. M. Heard) for comments to help clarify some of the text in this draft. This work was partly supported by the ICANN Grant Program.