Skip to main content

SRv6 Upper-Layer Checksum
draft-xiao-spring-srv6-checksum-05

Document Type Active Internet-Draft (individual)
Authors Xiao Min , Yao Liu , Chongfeng Xie , Yisong Liu
Last updated 2024-05-06
Replaces draft-xiao-6man-srv6-checksum
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-xiao-spring-srv6-checksum-05
SPRING Working Group                                              X. Min
Internet-Draft                                                    Y. Liu
Intended status: Standards Track                               ZTE Corp.
Expires: 7 November 2024                                          C. Xie
                                                           China Telecom
                                                                  Y. Liu
                                                            China Mobile
                                                              6 May 2024

                       SRv6 Upper-Layer Checksum
                   draft-xiao-spring-srv6-checksum-05

Abstract

   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.

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

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Min, et al.              Expires 7 November 2024                [Page 1]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Upper-Layer Checksum in SRv6 Networks . . . . . . . . . . . .   4
     3.1.  C-flag in Segment Routing Header  . . . . . . . . . . . .   5
     3.2.  C-flag Processing . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   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

Min, et al.              Expires 7 November 2024                [Page 2]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

   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.

2.  Conventions

Min, et al.              Expires 7 November 2024                [Page 3]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

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

2.2.  Abbreviations

   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]

   OSPF: Open Shortest Path First protocol [RFC2328]

3.  Upper-Layer Checksum in SRv6 Networks

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

Min, et al.              Expires 7 November 2024                [Page 4]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

3.1.  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 a
      128-bit IPv6 address of the final destination.

3.2.  C-flag Processing

   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.

Min, et al.              Expires 7 November 2024                [Page 5]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

   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.

Min, et al.              Expires 7 November 2024                [Page 6]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

4.  IANA Considerations

   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  | Reference |
     |              |        |             | Definition |           |
     +==============+========+=============+============+===========+
     | 3            | C      | Checksum    | Section    | This      |
     |              |        | Flag        | 3.1        | Document  |
     +--------------+--------+-------------+------------+-----------+

                          Table 1: New SRH Flag

5.  Security Considerations

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

6.  Acknowledgements

   The authors would like to acknowledge Detao Zhao for the very helpful
   discussion.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [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,
              <https://www.rfc-editor.org/info/rfc8754>.

Min, et al.              Expires 7 November 2024                [Page 7]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

   [RFC9259]  Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
              Chen, "Operations, Administration, and Maintenance (OAM)
              in Segment Routing over IPv6 (SRv6)", RFC 9259,
              DOI 10.17487/RFC9259, June 2022,
              <https://www.rfc-editor.org/info/rfc9259>.

7.2.  Informative References

   [I-D.ietf-spring-srv6-srh-compression]
              Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
              Clad, "Compressed SRv6 Segment List Encoding", Work in
              Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
              compression-16, 24 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-srh-compression-16>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC6936]  Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the Use of IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, DOI 10.17487/RFC6936, April 2013,
              <https://www.rfc-editor.org/info/rfc6936>.

   [RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
              Pallagatti, "Seamless Bidirectional Forwarding Detection
              (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
              <https://www.rfc-editor.org/info/rfc7880>.

   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
              Two-Way Active Measurement Protocol", RFC 8762,
              DOI 10.17487/RFC8762, March 2020,
              <https://www.rfc-editor.org/info/rfc8762>.

Min, et al.              Expires 7 November 2024                [Page 8]
Internet-Draft          SRv6 Upper-Layer Checksum               May 2024

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/info/rfc9293>.

Authors' Addresses

   Xiao Min
   ZTE Corp.
   Nanjing
   China
   Phone: +86 18061680168
   Email: xiao.min2@zte.com.cn

   Yao Liu
   ZTE Corp.
   Nanjing
   China
   Email: liu.yao71@zte.com.cn

   Chongfeng Xie
   China Telecom
   Beijing
   China
   Email: xiechf@chinatelecom.cn

   Yisong Liu
   China Mobile
   Beijing
   China
   Email: liuyisong@chinamobile.com

Min, et al.              Expires 7 November 2024                [Page 9]