| Internet-Draft | SRv6 Upper-Layer Checksum | May 2024 |
| Min, et al. | Expires 7 November 2024 | [Page] |
This document defines SRH C-flag and its processing, which makes the IPv6 upper-layer checksum computation rule applicable to both compressed and uncompressed SRv6 SIDs.¶
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/.¶
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 7 November 2024.¶
Copyright (c) 2024 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
IPv6 specification [RFC8200] Section 8.1 defines the rule how upper-layer (e.g., TCP, UDP, ICMPv6, OSPF) checksum over IPv6 packet is computed, which requires a "pseudo-header" for IPv6 is constructed as a portion of fields included in upper-layer checksum computation. If the IPv6 packet doesn't contain a Routing header, the Destination Address used in the pseudo-header is that 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. Note that any node implementing zero-checksum mode must follow the requirements specified in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936], and the zero-checksum mode is 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, also known as the last Segment Identifier (SID), would be used as the Destination Address of the pseudo-header for upper-layer checksum computation; at the SRv6 egress node, after the SRH processing is done, the Destination Address of the IPv6 header would be used as the Destination Address of the pseudo-header. Note that at the SRv6 egress node, the SRH processing may still invoke IPv6 Destination Address substitution.¶
The C-SID document [I-D.ietf-spring-srv6-srh-compression] defines compressed SRv6 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 a Routing header, multiple C-SIDs are carried in the 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.¶
While an SRv6 Policy is monitored by the S-BFD or STAMP, the SRv6 Policy endpoint (other than a null endpoint) IPv6 address or the IPv6 loopback address ::1/128 (for a null endpoint) should be used as the final Destination Address (Segment List[0]) of the S-BFD or STAMP packets, at this time some SRv6 Endpoint behaviors defined in [RFC8986] don't apply anymore. For example, if the last segment in a monitored SRv6 Policy is an End.DX6 SID, then as specified in Section 4.4 of [RFC8986], while processing the received End.DX6 SID, if the Segments Left is not equal to 0, then an ICMP Parameter Problem would be sent to the Source Address, however that's not the expected behavior in this case. One recipe of resolving this issue is to require the headend node to do a judgment, whether the last segment is a SID that must be the last segment in an SR Policy as specified in [RFC8986], if that's the case, then the last segment must be a uncompressed SRv6 SID and used as the final Destination Address (Segment List[0]) of the S-BFD or STAMP packets. Another recipe of resolving this issue is specified in this document.¶
This document defines SRH C-flag and its processing, which makes the IPv6 upper-layer checksum computation rule applicable to both compressed and uncompressed SRv6 SIDs.¶
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.¶
S-BFD: Seamless BFD [RFC7880]¶
SR: Segment Routing¶
SRv6: Segment Routing with IPv6 data plane¶
SID: Segment ID¶
C-SID: Compressed SID [I-D.ietf-spring-srv6-srh-compression]¶
SRH: Segment Routing Header [RFC8754]¶
STAMP: Simple Two-Way Active Measurement Protocol [RFC8762]¶
PSP: Penultimate Segment Pop of the SRH [RFC8986]¶
TCP: Transmission Control Protocol [RFC9293]¶
UDP: User Datagram Protocol [RFC0768]¶
ICMPv6: Internet Control Message Protocol for IPv6 [RFC4443]¶
This section defines a mechanism for upper-layer checksum in SRv6 networks. This mechanism utilizes a new SRH flag called C-flag. Implementation of the C-flag is only required for the checksum originating/validating node and the penultimate Segment Endpoint node (with a Penultimate Segment Pop (PSP) operation). For a node other than the checksum originating/validating node and the penultimate Segment Endpoint node (with a PSP operation), if it does not support the C-flag, then it simply ignores it upon reception. If a node supports the C-flag, it can optionally advertise its potential via control plane protocol(s).¶
[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:¶
The C-flag in SRH is used as a marking-bit in the SRv6 packets carrying upper-layer checksum, each segment endpoint would process the C-flag to make the upper-layer checksum computation at the SRv6 ingress and egress nodes complied to [RFC8200].¶
At the 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 multiple compressed SIDs, an SRH MUST be added with C-flag set and Segment List[0] set to a 128-bit IPv6 address of the final destination. With regard to the Segment List[0], if the checksum originating node knows multiple IPv6 addresses of the final destination, e.g., including a local interface address of the final destination, a 128-bit SID locally instantiated at the final destination, and a 128-bit address transformed from a 16-bit/32-bit compressed SID locally instantiated at the final destination, then the checksum originating node needs to select one of them as the last element of SRH, how the checksum originating node makes the choice is beyond the scope of this document.¶
When the penultimate segment of a segment-list is a PSP SID, the SRH is removed at the penultimate segment endpoint and the C-flag is not processed at the ultimate segment endpoint. 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 endpoint can still compute the 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 the regular processing of the local SID S. In other words, 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]. If the C-flag defined in this document and the O-flag defined in Section 2.1 of [RFC9259] are both set, then the C-flag processing happens after the O-flag processing. In other words, 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 [RFC9259] and line S02 of the pseudo-code defined in Section 4.3.1.1 of [RFC8754].¶
Also note that if the final destination is programmed to be reached more than once, the SRv6 packets with C-flag set would be terminated at the first time the final destination is reached. If it's necessary to make the SRv6 packets with C-flag set reaching the final destination more than once, more judgment conditions need to be added to the pseudo-code of C-flag processing.¶
In the "Segment Routing Header Flags" registry created for [RFC8754], a new Checksum Flag is requested from IANA as follows:¶
| Bit Position | Symbol | Description | Semantics Definition | Reference |
|---|---|---|---|---|
| 3 | C | Checksum Flag | Section 3.1 | This Document |
This document does not raise additional security issues beyond those of the specifications referred to in the list of references.¶
The authors would like to acknowledge Detao Zhao for the very helpful discussion.¶