Network Working Group T. Herbert Internet-Draft 20 February 2025 Intended status: Standards Track Expires: 24 August 2025 IPv6 Checksum Option draft-herbert-ipv6-checksum-option-00 Abstract This document specifies a Checksum Option for IPv6. This is a Destination Option that allows a checksum to be computed over a variable number of bytes in the packet. The option allows the ICMPv6 checksum to be optional, and the UDPv6 checksum to be generally optional. 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 24 August 2025. Copyright Notice Copyright (c) 2025 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. Herbert Expires 24 August 2025 [Page 1] Internet-Draft IPv6 Csum Option February 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol format . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Sender operation . . . . . . . . . . . . . . . . . . . . 4 3.2. Receiver operation . . . . . . . . . . . . . . . . . . . 5 4. Optional ICMP and UDP checksums . . . . . . . . . . . . . . . 5 4.1. ICMP checksums . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Sender requirements . . . . . . . . . . . . . . . . . 5 4.1.2. Receiver requirements . . . . . . . . . . . . . . . . 6 4.1.3. Considerations . . . . . . . . . . . . . . . . . . . 6 4.2. UDP checksums . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Sender requirements . . . . . . . . . . . . . . . . . 7 4.2.2. Receiver requirements . . . . . . . . . . . . . . . . 7 4.2.3. Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document specifies a Checksum Option for IPv6 [RFC8200]. This is a Destination Option that includes a checksum coverage field and checksum field similar to UDP-Lite [RFC3828]. If the option is present then the checksum is computed starting from the first byte of the Destination Options header through the number of bytes indicated by the checksum coverage. The checksum includes coverage over a pseudo header composed of the IP addresses in the packet. The Checksum Option allows the following ICMPv6 checksum [RFC4443] to be optional, and generalizes the following UDPv6 checksum of Section 8.1 of [RFC8200] to be optional beyond that allowed by [RFC6935]. 1.1. Motivation The motivation and goals for the IPv6 Checksum Option are: * Provide an optional checksum, with checksum coverage, that works with any transport protocol. * Allow the ICMPv6 checksum to be optional. This is pertinent for Herbert Expires 24 August 2025 [Page 2] Internet-Draft IPv6 Csum Option February 2025 routers that wish to send ICMP errors but don't have the capability to efficiently calculate checksums over hundreds of bytes. * Allow the UDPv6 checksum to be generally optional. The Checksum Option allows the UDPv6 checksum to be zero outside of use with UDP tunnels. Also, the Checksum Option allows partial coverage similar to UDP-lite. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Protocol format The Checksum Option is a Destination Option with the format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Type | Opt Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum Coverage | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Opt Type The Option Type is TBD. The highest-order two bits MUST be 10, 01, or 11 to indicate that the packet MUST be dropped if the option type is unrecognized. The third-highest-order bit MUST be 0 to indicate that the option may not change en route. Opt Len The Option Length is set to 4. Checksum Coverage The number of bytes, counting from the first byte of the containing Destination Options header, that are covered by the checksum. Checksum The 16-bit one's complement of the one's sum of a pseudo-header of information collected from the IP header and over the number of bytes specified by the Checksum Coverage (starting from the first byte of the containing Destination Options header), virtually padded with a zero byte at the end (if necessary) to make a multiple of two bytes. Herbert Expires 24 August 2025 [Page 3] Internet-Draft IPv6 Csum Option February 2025 The Checksum Option includes coverage for a pseudo header consisting of the IP addresses in the packet. The format of the pseudo header is: 0 31 +---------------------------------------+ | | | IPv6 Source Address | | | | | +---------------------------------------+ | | | IPv6 Destination Address | | | | | +---------------------------------------+ 3. Operation 3.1. Sender operation The procedures for setting the Checksum option are: 1. A sender creates the option in a packet. The Option Type field is set with an appropriate option type. The Checksum Option SHOULD NOT be set in Destination Options before the Routing header. 2. The Checksum Coverage field is set to number of bytes covered by the checksum. The Checksum Coverage field MUST be less than or equal to the length of the IP packet starting from the first byte of the Destination Options header. 3. The Checksum field is set to zero for computing the checksum. 4. The ones' complement sum over the pseudo header is computed. This covers the source and destination IP addresses. 5. The ones' complement sum over the bytes starting from the first byte of the Destination Options header for the number of bytes set in the Checksum Coverage field is computed. Note that any other options in the Destination Options header as well as any data following the Destination Options header that is covered by the checksum MUST be set before checksum computation. 6. The results of set #4 and step #5 are ones' complement summed and a sixteen bit value is produced. The 'not' of the value is set in the Checksum field. Herbert Expires 24 August 2025 [Page 4] Internet-Draft IPv6 Csum Option February 2025 3.2. Receiver operation The procedures for processing the Checksum Option are: 1. If the value in the Checksum Coverage field is greater the length of the packet starting from the first byte of the Destination Options header then that is considered an error. In this case the packet is discarded, and if the high-order two bits of the Option Type is 10 or 11 then the receiver MAY send a Parameter Problem message with code 0 ("erroneous header field encountered") back to the sender. 2. The ones' complement sum over the pseudo header is computed. This covers the source and destination IP addresses. 3. The ones' complement sum over the bytes starting from the first byte of the Destination Options header for the number of bytes set in the Checksum Coverage field is computed. 4. The results of set #2 and step #3 are ones' complement summed and a sixteen bit value is produced. If the resultant value is equal to all ones (0xFFFF) then the checksum is valid and the packet may be accepted. If the resultant value is not all ones then the checksum is invalid. In this case, the packet MUST be discarded, and if the highest-order two bits of the Option Type is 10 or 11 then the receiver MAY send and Parameter Problem message with code 0 ("erroneous header field encountered") back to the sender. 4. Optional ICMP and UDP checksums The ICMPv6 checksum and UDPv6 checksum are optional with the Checksum Option per the requirements in this section. 4.1. ICMP checksums If a Destination Options header containing a Checksum Option immediately precedes an ICMP header, that is the Next Header field of the Destination Options header is equal to 1, then requirements of the ICMP checksum are modified. 4.1.1. Sender requirements The ICMPv6 checksum MAY be set by a sender to be skipped. This is done by setting a Checksum Option in the Destination Options header immediately preceding the ICMPv6 header and setting the ICMPv6 checksum field to 0. Effectively, this makes the ICMPv6 checksum optional. Herbert Expires 24 August 2025 [Page 5] Internet-Draft IPv6 Csum Option February 2025 If the Checksum Option is present in the Destination Options header immediately preceding the ICMPv6 header, the ICMPv6 checksum is being computed, and the computed checksum is zero, then the ICMP checksum field is set to all ones (0xFFFF). 4.1.2. Receiver requirements If ICMPv6 checksum is zero in a received packet and the ICMPv6 header is preceded by a Destination Options header containing the Checksum Option then the packet MAY be accepted without further consideration of the ICMP checksum. If the ICMPv6 checksum is non-zero then the checksum processed as normal regardless of whether the Checksum Option is present. 4.1.3. Considerations The requirements for optional ICMPv6 checksums are similar to those for a optional UDPv6 checksums described in Section 5 of [RFC6936] with a few amendments. * Since the Checksum Option includes the checksum over the pseudo header this mitigates concerns of packet misdelivery. * A sender MAY include the ICMP header in the checksum coverage of the Checksum Option. This provides protection of the ICMP header. * A sender MAY include some number of bytes of the ICMP payload in the checksum coverage of the Checksum Option. This could, for instance, include coverage of the IP headers and maybe transport layer headers of the invoking packet. * It is optional at a receiver to accept ICMPv6 packets with a zero checksum. The default behavior SHOULD be to not accept packets with a zero ICMPv6 checksum. 4.2. UDP checksums If a Destination Options header containing a Checksum Operation immediately precedes a UDP header, that is the Next Header field of the Destination Options header is equal to 17, then the requirements of the UDP checksum are modified. Herbert Expires 24 August 2025 [Page 6] Internet-Draft IPv6 Csum Option February 2025 4.2.1. Sender requirements The UDPv6 checksum MAY be set by a sender to be skipped. This is done by setting a Checksum Option in the Destination Options header immediately preceding the UDPv6 header and setting the ICMPv6 checksum field to 0. Effectively, this makes the UDPv6 checksum generally optional. 4.2.2. Receiver requirements If a UDPv6 checksum is zero in a received packet and the UDP header is immediately preceded by a Destination Options header containing the Checksum Option then the packet MAY be accepted without further consideration of the UDP checksum. If UDPv6 checksum is non-zero then the checksum is processed normally regardless of whether the Checksum Option is present. 4.2.3. Considerations [RFC6936] permits a zero UDPv6 checksum to be used with UDP tunnels. This specification extends that to allow the UDPv6 checksum to be zero in non-UDP tunnel scenarios. The requirements of Section 5 of [RFC6936] are generally applicable to the protocol of this specification with the following amendments. * Since the Checksum Option includes the checksum over the pseudo header that mitigates concerns of packet misdelivery. * The Checksum Coverage allows alternate coverage. A sender MAY ensure that the UDP header is covered by the Checksum Options. 5. Security Considerations This specification does not introduce any new security concerns. 6. IANA Considerations IANA is requested to allocate an IPv6 Destination type for the Checksum Option in the "Destination Options and Hop-by-Hop Options" registry within the "Internet Protocol Version 6 (IPv6) Parameters" registry group [IANA-DESTOPT]. Variants are: Herbert Expires 24 August 2025 [Page 7] Internet-Draft IPv6 Csum Option February 2025 +-----------+---------------+-------------+---------------+ | Hex Value | Binary value | Description | Reference | | | act chg rest | | | +-----------+---------------+-------------+---------------+ | TBD | 01 0 xxxxx | Checksum | This document | | | | option | | +-----------+---------------+-------------+---------------+ | TBD | 10 0 xxxxx | Checksum | This document | | | | option | | +-----------+---------------+-------------+---------------+ | TBD | 11 0 xxxxx | Checksum | This document | | | | option | | +-----------+---------------+-------------+---------------+ 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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 7.2. Informative References [IANA-DESTOPT] "Destination Options and Hop-by-Hop Options", . [RFC3828] Larzon, L., Degermark, M., Pink, S., Jonsson, L., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, . [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, . Herbert Expires 24 August 2025 [Page 8] Internet-Draft IPv6 Csum Option February 2025 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [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, . Author's Address Tom Herbert Los Gatos, CA, United States of America Email: tom@herbertland.com Herbert Expires 24 August 2025 [Page 9]