SRv6 Upper-Layer Checksum
Xiao Min
ZTE Corp.
Nanjing
China
+86 25 88013062
xiao.min2@zte.com.cn
Yao Liu
ZTE Corp.
Nanjing
China
liu.yao71@zte.com.cn
Chongfeng Xie
China Telecom
Beijing
China
xiechf@chinatelecom.cn
2022
Internet
6MAN Working Group
Request for Comments
RFC
Internet Draft
I-D
This document provides a unified mechanism that makes the upper-layer checksum computation rule defined in IPv6 Specification applicable, whether SRv6 SIDs or SRv6 compressed SIDs are used.

Introduction
IPv6 Specification [RFC8200] defines how upper-layer checksum is computed. Specifically, a "pseudo-header" for IPv6 is constructed as a portion of fields included in upper-layer (e.g., TCP, UDP, ICMPv6, OSPF) checksum computation. As defined in Section 8.1 of [RFC8200], if the IPv6 packet doesn't contain Routing header, the Destination Address used in the pseudo-header will be in the Destination Address field of the IPv6 header; if the IPv6 packet contains a Routing header, the Destination Address used in the pseudo-header is that of the final destination. In the latter case, 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. As also defined in Section 8.1 of [RFC8200], any node implementing zero-checksum mode of UDP tunnel must follow the requirements specified in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936], and it's outside the scope of this document.
Segment Routing over IPv6 (SRv6) [RFC8754] defines an IPv6 Routing header called Segment Routing Header (SRH). To comply with the upper-layer checksum computation rule defined in [RFC8200], at the SRv6 ingress node, the last element of the SRH, i.e., the last Segment Identifier (SID), will become the Destination Address used in the pseudo-header for upper-layer checksum computation; at the SRv6 egress node, after SRH processing is finished, the Destination Address in the IPv6 header will become the Destination Address used in the pseudo-header for upper-layer checksum computation. Note that even at the SRv6 egress node, SRH processing may still invoke IPv6 Destination Address substitution.
The C-SID document [I-D.ietf-spring-srv6-srh-compression] defines SRv6 compressed SIDs, which use 16-bit or 32-bit SRv6 C-SID to substitute 128-bit SRv6 SID. The NEXT-C-SID flavor and REPLACE-C-SID flavor are defined in the C-SID document. In one case of NEXT-C-SID flavor, at the SRv6 ingress node, the IPv6 packet doesn't contain Routing header, more than one C-SIDs are included in IPv6 Destination Address, the upper-layer checksum computation rule defined in [RFC8200] doesn't apply anymore. In another case of REPLACE-C-SID flavor, at the SRv6 ingress node, the IPv6 packet contains an SRH, the last element of the SRH is not a 128-bit IPv6 address, but a 16-bit or 32-bit C-SID, the upper-layer checksum computation rule defined in [RFC8200] doesn't apply anymore.
This document provides a unified mechanism that makes the upper-layer checksum computation rule defined in IPv6 Specification applicable, whether SRv6 SIDs or SRv6 compressed SIDs are used.

Conventions

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

Abbreviations
SR: Segment Routing
SRv6: Segment Routing with IPv6 data plane
SID: Segment ID
C-SID: Compressed Segment ID [I-D.ietf-spring-srv6-srh-compression]
SRH: Segment Routing Header [RFC8754]
PSP: Penultimate Segment Pop of the SRH [RFC8986]
TCP: Transmission Control Protocol [RFC0793]
UDP: User Datagram Protocol [RFC0768]
ICMPv6: Internet Control Message Protocol for IPv6 [RFC4443]
OSPF: Open Shortest Path First protocol [RFC2328]

Unified Mechanism for Upper-Layer Checksum in SRv6
This section defines a unified mechanism for upper-layer checksum in SRv6 networks. This mechanism utilizes a new SRH flag and requests all SRv6 nodes along the transport path to act on the new SRH flag.

C-flag in Segment Routing Header
[RFC8754] describes the Segment Routing Header (SRH) and how SRv6 capable nodes use it. The SRH contains an 8-bit "Flags" field.
This document defines the following bit in the SRH Flags field to carry the C-flag:

               0 1 2 3 4 5 6 7
              +-+-+-+-+-+-+-+-+
              |     |C|       |
              +-+-+-+-+-+-+-+-+

Where:
C-flag: Checksum flag in the SRH Flags field defined in [RFC8754]. When C-flag is set, the last element of the SRH MUST be set to an IPv6 address of the final destination.

C-flag Processing
The C-flag in SRH is used as a marking-bit in the SRv6 packets using upper-layer checksum, each segment endpoint would process the C-flag as defined in this document, to make the SRv6 upper-layer checksum computation smooth and complied to [RFC8200].
At the upper-layer checksum originating node, if the IPv6 packet contains an SRH, the SRH C-flag MUST be set and the Segment List[0] MUST be set to a 128-bit IPv6 address of the final destination; if the IPv6 packet doesn't contain an SRH while the Destination Address field contains more than one compressed SID, an SRH MUST be added with C-flag set and Segment List[0] set to a 128-bit IPv6 address of the final destination. When the upper-layer checksum originating node knows more than one IPv6 address of the final destination, e.g., a local interface address of the final destination, a 128-bit SID locally instantiated at the final destination, and an IPv6 address transformed from a 16-bit or 32-bit compressed SID locally instantiated at the final destination, the originating node needs to select one of them as the last element of SRH, how the originating node makes the choice is beyond the scope of this document.
When the penultimate segment of a segment-list is a Penultimate Segment Pop (PSP) SID, the SRH is removed at the penultimate segment and the C-flag is not processed at the ultimate segment. The penultimate segment as a PSP SID MUST copy Segment List[0] from the SRH to the Destination Address field of the IPv6 header, then the ultimate segment can still compute the upper-layer checksum with correct IPv6 Destination Address even without SRH.
When an SRv6 node receives a packet destined to S and S is a local SID, the line S01 of the pseudo-code associated with the SID S, as defined in Section 4.3.1.1 of [RFC8754], is appended to as follows for the C-flag processing.

S01.2. IF C-flag is set and local configuration permits
     C-flag processing {
         If (Segment List[0] is locally instantiated or represents
                  a local interface) {
            a. Set Segments Left to 0.
            b. Update IPv6 DA with Segment List[0].
         }
         Else {
           If (IPv6 DA is locally instantiated as a PSP SID) {
            a. Update IPv6 DA with Segment List[0].
            b. Submit the packet to the egress IPv6 FIB lookup for
                  transmission to the new destination.
           }
         }

Note that the C-flag processing happens before execution of regular processing of the local SID S. Specifically, the line S01.2 of the pseudo-code specified in this document is inserted between line S01 and S02 of the pseudo-code defined in Section 4.3.1.1 of [RFC8754]. When the C-flag defined in this document and the O-flag defined in Section 2.1 of [I-D.ietf-6man-spring-srv6-oam] are both set, the C-flag processing happens after O-flag processing. Specifically, the line S01.2 of the pseudo-code specified in this document is inserted between line S01.1 of the pseudo-code defined in Section 2.1.1 of [I-D.ietf-6man-spring-srv6-oam] and line S02 of the pseudo-code defined in Section 4.3.1.1 of [RFC8754].
Also note that if the final destination needs to be reached more than once on the programmed transport path, the SRv6 packets with C-flag set would be terminated at the first time the final destination is reached. If it's deemed necessary for the SRv6 packets with C-flag set to reach the final destination more than once, more judgment conditions may be added to the pseudo-code of C-flag processing.

IANA Considerations
In the "Segment Routing Header Flags" registry created for [RFC8754], a new Checksum Flag is requested from IANA as follows:

New SRH Flag
Bit Position | Symbol | Description | Semantics Definition | Reference
3 | C | Checksum Flag | Section 3.1 | This Document

Security Considerations
This document does not raise additional security issues beyond those of the specifications referred to in the list of references.

Acknowledgements
TBA.

Normative References

Informative References
[RFC8200]
[RFC6936]
[RFC8754]
[I-D.ietf-spring-srv6-srh-compression]
[RFC2119]
[RFC8174]
[RFC8986]
[RFC0793]
[RFC0768]
[RFC4443]
[RFC2328]
[I-D.ietf-6man-spring-srv6-oam]