SPRING T. Mizrahi Internet-Draft Huawei Updates: RFC8200 (if approved) 3 August 2023 Intended status: Standards Track Expires: 4 February 2024 Layer 4 Checksum Computation in Segment Routing over IPv6 (SRv6) draft-mizrahi-spring-l4-checksum-srv6-00 Abstract This document updates the IPv6 specification with respect to the layer 4 checksum computation in packets that use Segment Routing over IPv6 (SRv6) with compressed segment lists. 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/. 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 4 February 2024. Copyright Notice Copyright (c) 2023 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. Mizrahi Expires 4 February 2024 [Page 1] Internet-Draft L4 Checksums in SRv6 August 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Checksum Computation Update . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Segment routing [RFC8402] is a routing paradigm in which a node steers a packet through an ordered list of segments. The IPv6 specification [RFC8200] defines the Routing header, which is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. The Segment Routing Header (SRH) [RFC8754] is a type of Routing header that is used in Segment Routing over IPv6 (SRv6). Compressed segment lists [I-D.ietf-spring-srv6-srh-compression] enable multiple segment endpoints to be encoded within a single Segment Identifier (SID). The SRH can consist of one or more SID that includes a compressed segment list. Furthermore, a compressed segment list can be used in the IPv6 Destination Address field without using an SRH. Transport layer and upper-layer checksums, such as the checksums in TCP, UDP and ICMP, are computed over the layer 4 header and payload, as well as a pseudo-header that includes the IP source and destination addresses. However, when using the Routing header, the IPv6 Destination Address can be modified by intermediate nodes along the path to the destination. As specified in Section 8.1 of [RFC8200], the layer 4 checksum computation for a packet that includes the Routing header uses the final IPv6 Destination Address. Compressed segment lists introduce two main changes in the way that layer 4 checksums are computed compared to [RFC8200]: Mizrahi Expires 4 February 2024 [Page 2] Internet-Draft L4 Checksums in SRv6 August 2023 * [RFC8200] specifies that when the Routing header is present the checksum is computed by the originating node based on the last element of the Routing header. When compressed segment lists are used, the last element of the Routing header may be different than the Destination Address as received by the final destination, and therefore the checksum is computed based on the Destination Address as it is expected to be received by the destination. * Compressed segment lists can be used in the Destination Address without the presence of a Routing header, and in this case the IPv6 Destination address can be modified along the path. This is another case in which the checksum is computed based on the Destination Address value as expected to be received by the destination. This document updates the IPv6 specification [RFC8200] with respect to the layer 4 checksum computation in packets that use SRv6, and specifically packets that use compressed segment lists. 2. Conventions 2.1. Requirement 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. 2.2. Terminology Abbreviations used in this document: SID: Segment Identifier SRH: Segment Routing Header SRv6: Segment Routing over IPv6 3. Checksum Computation Update This document updates the following text from Section 8.1 of [RFC8200] as follows: OLD: Mizrahi Expires 4 February 2024 [Page 3] Internet-Draft L4 Checksums in SRv6 August 2023 If the IPv6 packet contains a Routing header, the Destination Address used in the pseudo-header is that of the final destination. 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. NEW: If the IPv6 packet contains a Routing header, the Destination Address used in the pseudo-header is that of the final destination. At the recipient(s), that address will be in the Destination Address field of the IPv6 header. At the originating node, that address will be the Destination Address as it is expected to be received by the destination. Note, that if segment list compression [I-D.ietf-spring-srv6-srh-compression] is used, then the Destination Address as received by the destination may be different than the last element of the Routing header. Similarly, if segment list compression is used without using the Routing header, then the Destination Address used in the pseudo-header is the address that is expected to be received by the destination. 4. IANA Considerations This document includes no request to IANA. 5. Security Considerations This document clarifies the way that the layer 4 checksum is computed with SRv6, and does not present new security considerations. 6. References 6.1. Normative References [I-D.ietf-spring-srv6-srh-compression] Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F. Clad, "Compressed SRv6 Segment List Encoding in SRH", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-srh- compression-06, 28 July 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Mizrahi Expires 4 February 2024 [Page 4] Internet-Draft L4 Checksums in SRv6 August 2023 [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, . 6.2. Informative References [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . Author's Address Tal Mizrahi Huawei Email: tal.mizrahi.phd@gmail.com Mizrahi Expires 4 February 2024 [Page 5]