INTERNET-DRAFT T. Herbert Intended Status: Standard Intel Expires: January 2020 July 8, 2019 UDP Surplus Header draft-herbert-udp-space-hdr-01 Abstract This specification defines the UDP Surplus Header that is an extensible and generic format applied to the UDP surplus space. The UDP surplus space comprises the bytes between the end of the UDP datagram, as indicated by the UDP Length field, and the end of the IP packet, as indicated by IP packet or payload length. The UDP Surplus Header can be either a protocol trailer of the UDP datagram, or a protocol header which effectively serves as an extended UDP header. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. T. Herbert Expires January 9, 2020 [Page 1] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 UDP Surplus Header format . . . . . . . . . . . . . . . . . . . 3 2.1 Protocol trailer format . . . . . . . . . . . . . . . . . . 4 2.2 Protocol header format (Extended UDP header) . . . . . . . . 6 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Sender operation . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Receiver operation . . . . . . . . . . . . . . . . . . . . . 8 3.2.1 Error handling . . . . . . . . . . . . . . . . . . . . . 9 4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A: Checksum processing . . . . . . . . . . . . . . . . . 12 A.1 Transmit Checksum processing . . . . . . . . . . . . . . . . 12 A.1.1 TX checksum for USH trailer . . . . . . . . . . . . . . 12 A.1.2 TX checksum for USH header . . . . . . . . . . . . . . . 13 A.2 Receive Checksum handling . . . . . . . . . . . . . . . . . 13 A.2.1 Simultaneous verification . . . . . . . . . . . . . . . 13 A.2.2 RX checksum for USH trailer . . . . . . . . . . . . . . 14 A.2.3 RX checksum for USH header . . . . . . . . . . . . . . . 14 Appendix B: Protocol headers versus versus protocol trailers . . . 15 Appendix C: Protocol field alignment . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 T. Herbert Expires January 9, 2020 [Page 2] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 1 Introduction As defined in [RFC768], the UDP header contains a UDP Length field. The UDP Length is not required to correlate with the IP payload length of a packet such that there may be bytes between the end of the UDP datagram and the end of the IP packet. This space is referred to as the UDP surplus space. This specification defines the UDP Surplus Header (USH) to provide a common format for the UDP surplus space. The USH is comprised of a four byte base header and some variable amount of data. The base header contains a type field that determines how the header data is interpreted. This allows different formats and uses of the UDP surplus space. UDP options [UDPOPT] are one example of a type where the header data contains a list of options. There are two use cases of USH: 1) Protocol trailer (section 2.1) 2) Protocol header or Extended UDP Header (section 2.2) The motivations for USH, include the motivations for protocol header format in USH, are described in section 4. 2 UDP Surplus Header format The common format of the UDP Surplus Header (USH) is shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (0 to 3 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | TSLength | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Type Specific Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are: o Padding: Aligns the UDP Surplus Header to four bytes. The number of padding bytes required is: 3 - ((udp_length - 1) % 4), where the udp_length is the length of the UDP datagram as specified in the UDP Length field. Padding bytes MUST be set to zero on transmission, and MUST be verified to be zero when received. T. Herbert Expires January 9, 2020 [Page 3] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 o Type: Indicates the format of the UDP surplus space and how the Type Specific Data is interpreted. Defined Type values are: o 0: Reserved o 1: UDP options o 2-127: Reserved o 128-255: Available for private use or experimentation o TSLength: Length of the type specific data in units of four byte words. The length of the type specific data is thus zero to 1020 bytes. o Checksum: The standard one's complement checksum that covers the UDP surplus area. The coverage starts from the first byte of Padding, or the Type field if no padding is present, through the end of the IP packet. If the number of Padding bytes is odd then a zero byte is logically prepended to surplus area for the checksum calculation. o Type Specific Data: Variable length data that is considered part of the UDP Surplus Header. This data is interpreted per the value of the Type field. 2.1 Protocol trailer format When used as a protocol trailer, the UDP Surplus Header immediately follows the UDP data. The logical protocol layering is: +-+-+-+-+-+-+-+-+-+-+-+ | UDP header | +-+-+-+-+-+-+-+-+-+-+-+ | UDP data | / +-+-+-+-+-+-+-+-+-+-+-+ \ Surplus | | USH base header | | space | +-+-+-+-+-+-+-+-+-+-+-+ | USH | | Type specific data | | \ +-+-+-+-+-+-+-+-+-+-+-+ / T. Herbert Expires January 9, 2020 [Page 4] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 The packet format of UDP Surplus Header as a protocol trailer is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source port | Destination port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | Length | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | | ~ UDP data ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | TSLength | Checksum |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ Type Specific Data ~ USH | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Notes: - The offset of the UDP Surplus Header from the start of the UDP header, including possible padding for the USH, is equal the UDP Length. - The number of padding bytes is 3 - ((udp_length - 1) % 4), where udp_length is equal to the UDP Length field. The offset of the Type field of the USH is 4 * ((udp_length - 1) / 4 + 1). - If the size of the USH header (four plus four times TSLength) is less than the size of the UDP surplus space in a packet, then the USH is considered to be malformed (see section 3.2). - The UDP checksum covers the UDP header and UDP data. The USH checksum covers the entire UDP surplus space. - A legacy receiver, one that does not understand the UDP Surplus Header, will ignore the contents of the UDP surplus space and process the UDP data as normal. Protocol data that cannot correctly be ignored by a receiver, such as the fragmentation option in the [UDPOPT], MUST NOT be in a surplus space trailer. T. Herbert Expires January 9, 2020 [Page 5] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 2.2 Protocol header format (Extended UDP header) The UDP Surplus Header can be used as a protocol header. Effectively, this creates an extended UDP header format. The logical protocol layering is: +-+-+-+-+-+-+-+-+-+-+-+ \ | UDP header | | / +-+-+-+-+-+-+-+-+-+-+-+ | Extended | | UDP space header | | UDP header Surplus | +-+-+-+-+-+-+-+-+-+-+-+ | space | | Type specific data | | | +-+-+-+-+-+-+-+-+-+-+-+ / | | UDP data | \ +-+-+-+-+-+-+-+-+-+-+-+ The packet format containing an extended UDP header is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source port | Destination port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | Length | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | Type | TSLength | Checksum |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ Type Specific Data ~ USH | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | | ~ UDP data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes: - Since the UDP header is aligned and a multiple of four bytes, no padding for USH is necessary. - The UDP length is fixed to be eight so that all bytes beyond the UDP header are contained in the surplus space. - The UDP checksum covers the eight bytes of UDP header and the checksum pseudo header. The USH checksum covers the entire surplus space which includes the UDP Surplus Header and UDP data. T. Herbert Expires January 9, 2020 [Page 6] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 - The UDP data length is the IP payload length minus the size of the UDP header and the size of the UDP Surplus Header. That is: UDP_data_length = IP_payload_length - 12 - (4 * TSLength) - If a legacy receiver, one that does not understand the UDP Surplus Header, receives a packet in protocol header format it will process it as a UDP datagram containing zero length data. Presumably, most applications will ignore such packets, however if an application applies semantics to zero length datagrams then a sender MUST NOT send packets with an extended UDP header to legacy receivers. 3 Operation 3.1 Sender operation A sender sets a UDP Surplus Header in the surplus space when sending an IP packet. The UDP surplus header immediately follows the UDP packet at the offset of UDP Length from the start of the UDP header. The sender MUST insert up to three bytes of padding to align the offset of the Type field in the UDP Surplus Header to four bytes. Padding bytes MUST be set to zero. If the USH is being used as a protocol trailer then the UDP Surplus Header follows the UDP data. If a protocol header is being set then the UDP Surplus Header follows the eight byte UDP header and the UDP data follows the UDP Surplus Header. The IP Length field in the IPv4 header or Total Length field in the IPv6 header MUST be set to include the UDP datagram and the UDP surplus space. The UDP Length field MUST be set to size of the UDP header (eight) plus the size of the UDP data in the protocol trailer use case, and MUST be set to the size of the UDP header (eight) in the protocol header use case. The TSLength field MUST be set to reflect the length of the Type Specific Data. The Type Specific Data MUST be padded if necessary to align its length to four bytes. The USH Checksum MUST be set. To compute the checksum: 1) Set the Checksum field to zero. Compute the standard one's complement two byte checksum starting from the Type field through the end of the IP packet (end of the surplus space). If the length of the surplus space is odd then a zero byte is logically appended for the purposes of the calculation. T. Herbert Expires January 9, 2020 [Page 7] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 2) Set the value of the Checksum field to the bitwise "not" of the checksum computed in the previous step. 3.2 Receiver operation The processing for a UDP packet with surplus space is: 1) Check for minimum length to contain a UDP Surplus Header. If the UDP surplus space length is less than 3 - ((udp_length - 1) % 4) + 4, then the UDP Surplus Header is considered invalid. 2) Check padding bytes. If the UDP Length is not a multiple of four bytes then verify that the padding bytes following the UDP payload are set to zero. The required number of padding bytes is 3 - ((udp_length - 1) % 4). If the padding bytes are not zero, the UDP Surplus Header is considered invalid. 3) Check the TSLength field. If the length determined from the TSLength field plus the starting offset of the Type Specific Data exceeds the length of the IP packet then the UDP Surplus Header is considered invalid. 4) Verify the checksum. Compute the one's complement checksum starting from the Type field through the end of the IP packet (the end of the surplus area). If the result of the computation is checksum zero (~0 or -0) then the checksum is verified. If the checksum is not verified then the UDP Surplus Header is considered invalid. 5) Check the Type. If the Type is unknown to the receiver then the surplus header is considered invalid. 6) Process the Type Specific Data per the Type in the UDP Surplus Header. If an error condition is encountered in the course of processing the Type Specific Data then the receiver SHOULD consider that the UDP Surplus Header is invalid. 7) In the protocol trailer use case, if there are additional bytes beyond the UDP Surplus Header, a receiver SHOULD ignore those bytes (with the exception that the excess bytes MUST be included in the USH Checksum computation). 8) If the UDP Surplus Header is validated and processed, deliver the UDP data to the application. In the case of a protocol trailer, the surplus area is discarded and the UDP data, which follows the UDP header and has length of UDP Length minus eight, is delivered to the T. Herbert Expires January 9, 2020 [Page 8] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 application. In the case of protocol header, the UDP data delivered to the application immediately follows the UDP Surplus Header and has length of IP_payload_length - 12 - (4 * TSLength). 3.2.1 Error handling If an error is encountered when processing the UDP space or UDP Surplus Header such that the UDP Surplus Header is considered invalid, then the following actions should be taken: - In the protocol trailer case (UDP Length greater than eight), the UDP surplus area SHOULD be ignored per protocol processing convention. An implementation MAY allow configuration that would discard such packets. An implementation MUST either process the surplus space or ignore the whole space. In particular, the UDP Surplus Header MUST NOT be partially processed lest that leads to indeterminate results of processing an accepted packet. - In the case of a protocol header (a UDP packet having exactly a length of eight), the receiver SHOULD discard packets with malformed UDP surplus space or UDP Surplus Header. A receiver MAY deliver the packet to the application in the unlikely scenario that the application applies semantics to zero length UDP datagrams and there is the possibility that the surplus space is a legacy use case (i.e. the sender set surplus space but doesn't use the UDP Surplus Header format). 4 Motivation This section describes the motivations for the UDP Surplus Header and motivation for protocol headers. o While the UDP surplus area was implicitly created by [RFC768], the space was never specifically reserved by IETF action. Prescribing a format enables interoperable and backwards compatible use of this space within the context of defined protocol specifications. o A common header allows different uses and extensibility of the UDP surplus space within a common framework. This is achieved by inclusion of a Type field and Type Specific Data in the UDP Surplus Header. For instance, legacy uses of surplus space could be adapted to use the format and brought into conformance. o Since the UDP surplus space was never reserved, there is a possibility that the UDP surplus space is already being used by T. Herbert Expires January 9, 2020 [Page 9] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 some implementations. Disambiguating these "legacy" use cases from a newly defined standard format is essential. The required Checksum field, and to a lesser extent the Type and TSLength fields, help disambiguate uses of the surplus area from legacy or accidental uses of the surplus area. Use of the extended UDP header format also reduces the chances of misinterpreting legacy uses. o The USH checksum is checksum offload friendly. See appendix A for discussion on checksum offload and USH. o The required checksum in the UDP Surplus Header properly compensates for those devices that incorrectly compute UDP checksum over the length of the IP payload as opposed to just the UDP length. o A fixed checksum, as opposed to placing a checksum in options, avoids the problem that a checksum can't protect against corruption of the type field for the option containing the checksum. o Protocols headers, such as those used in the Extended UDP Header format, are more implementation friendly than protocol trailers. See Appendix B for more discussion. o Maintaining four byte alignment, as is common in IP protocols, is beneficial to implementations on several hardware architectures. See Appendix C for more discussion. T. Herbert Expires January 9, 2020 [Page 10] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 5 Security Considerations The UDP Surplus Header does not address nor introduce any new security considerations. The Type Specific Data in a UDP Surplus Header may contain security protocol mechanisms or require additional security considerations. Security considerations for Type Specific Data is out of scope for this document. 6 IANA Considerations IANA is requested to create a registry for the UDP Surplus Header Types. 7 References 7.1 Normative References 7.2 Informative References [UDPOPT] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- udp-options-07 T. Herbert Expires January 9, 2020 [Page 11] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 Appendix A: Checksum processing This appendix is informational and does not constitute a normative part of this document. Checksum offload is a ubiquitous feature of Network Interface Cards (NICs) that offloads checksum computation to hardware for performance. This section suggests some implementation techniques to best leverage checksum offload when UDP surplus space is being used. Note that the USH checksum ensures that the checksum computed over the UDP surplus space sums to zero in one's complement arithmetic. This has the intended consequence that the UDP checksum calculation over just the UDP length results in the same value when the UDP checksum is computed over the UDP length and surplus space as well. This property can be exploited for efficient and interoperable processing. A.1 Transmit Checksum processing A UDP packet with a UDP Surplus Header has two checksum that may need to be set on transmission: the UDP checksum and the USH checksum. The UDP checksum is optional for IPv4 and is required for IPv6 except in very narrow circumstances described in [RFC6936]. The USH checksum is always required to be set. Most devices only offload one checksum on transmit, so a design objective is to offload the checksum that covers the most bytes and hence provides the most benefit to offload. The checksum that is not offloaded is computed by the host CPU. Generally, the checksum that covers the UDP data is the one covers the most data and should be offloaded. That is, when USH is a protocol trailer the UDP checksum should be offloaded, and when the USH is a protocol header (i.e. extended UDP header) the USH checksum should be offloaded. In generic checksum offload, for each packet the host indicates to the device the starting offset where the checksum calculation begins and the offset of the field to write the resultant checksum. The extent of the checksum coverage is assumed to be the end of the packet. In particular, this means that even if the UDP checksum is being offloaded, the UDP surplus space is included in the device's computation. Ensuring that the surplus space sums to zero in one's complement arithmetic avoids any ambiguity with checksum offload. A.1.1 TX checksum for USH trailer The recommended procedure for setting checksums when the UDP Surplus Header is a trailer is: T. Herbert Expires January 9, 2020 [Page 12] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 1) On the host set the USH checksum using the normal procedures for setting the checksum (section 3.1). 2) Arrange for the UDP checksum to be offloaded to the device. This is done by indicating the checksum start offset to be the first byte of UDP header, indicating the checksum field offset to be the offset of the UDP checksum field, and initializing the UDP checksum field to the "bitwise not" of the appropriate IP pseudo header. Step 1) ensures that the surplus area sums to zero in one's complement arithmetic, so that in step 2) the value that the device sets in the UDP checksum field will be correct regardless of whether the device includes the surplus area in its computation or not. Note that the USH padding must be set to zero so it does not affect the checksum computed in step 1). The USH checksum on transmission can be correctly computed by starting the checksum computation from the offset of USH Type field. A.1.2 TX checksum for USH header The recommended procedure for setting checksums when the UDP Surplus Header is a header is: 1) Set the UDP checksum on the host. This is normal procedures to set the UDP checksum for a UDP datagram with length of eight. 2) Arrange to offload the USH checksum. The USH checksum field is initialized to zero, the offset to start the checksum calculation is set to the offset of the Type field in the USH, and the checksum field offset is set to the offset of the USH checksum field. A.2 Receive Checksum handling In the most generic form of receive checksum offload, a device performs a running checksum calculation across a packet as it is received. That is, it performs a running ones complement addition over two byte words as they are received. The device then provides the computed value, referred to as the "checksum complete" value, to the host in the meta data (receive descriptor) for the packet. The host can use this value to verify one or more packet checksums contained in the packet. A.2.1 Simultaneous verification If a device provides a checksum complete value and the UDP checksum T. Herbert Expires January 9, 2020 [Page 13] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 is set, then both the UDP checksum and USH checksum can be simultaneously verified: 1) Pull up checksum to start of the UDP header. That is the checksum complete value is computed from the start of the UDP header through the end of the IP packet. 2) Verify the UDP checksum taking into account the pseudo header. If the UDP checksum is verified, then the USH checksum is also verified. If the simultaneous verification fails then further work might be needed if checksum failure of the surplus space does not result in the packet being dropped. For instance, if the surplus space is to be ignored in the trailer use case. A.2.2 RX checksum for USH trailer The recommended procedure for independently verifying the UDP and USH checksums when the UDP Surplus Header is a protocol trailer is: 1) Compute the one's complement checksum across the UDP surplus space. If checksum zero is the result, then the USH checksum is verified. 2) Perform one's complement subtraction of the value derived in step 1) from the checksum complete value. The result is the checksum complete value across just the UDP header and UDP data. 3) Compute the IP pseudo header for the UDP checksum and one's complement add the result to that of step 2). If the result is checksum zero then the UDP checksum is verified. If the UDP checksum is zero (unset) then only the USH checksum needs to be verified so steps 2) and 3) can be omitted. A.2.3 RX checksum for USH header The recommended procedure for independently verifying the UDP and USH checksums when the UDP Surplus Header is a protocol header is: 1) Compute the one's complement checksum across the UDP header. 2) Compute the IP pseudo header for the UDP checksum and one's complement add the result to that of step 1). If the result is checksum zero then the checksum of the UDP header (zero length datagram) is verified. T. Herbert Expires January 9, 2020 [Page 14] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 3) Perform one's complement subtraction of the value derived in step 1) from the checksum complete value. The result is the checksum complete value across just the UDP surplus space. If zero is the result, then the USH checksum is valid. If the UDP checksum is zero (unset) then only the USH checksum needs to be verified, so step 2) can be omitted. Appendix B: Protocol headers versus versus protocol trailers This appendix is informational and does not constitute a normative part of this document. Protocol headers by definition are data at the precede the payload of a packet, whereas protocol trailers follow the payload. By nearly universal convention, IP protocols specify protocol headers (e.g. IP, TCP, UDP, Extension headers) and not protocol trailers. A notable exception to this is ESP where the integrity check value is placed after the payload data. Both software and hardware implementations are designed and optimized for processing protocol headers. A common technique in software implementations is to "pull up" all the headers in a packet into a contiguous buffer as various protocol layers are processed. To process a protocol trailer, such as a UDP Surplus Header in the trailer use case, an alternate mechanism is needed. This may result in copying data from the end of the packet into a contiguous buffer. Another disadvantage of protocol trailers is that when they are processed a cache miss is almost certain. This will be especially noticeable with hardware techniques that attempt to pre-populate the CPU data cache with some number of header bytes (such as data Direct Data I/O). High performance hardware devices that perform Deep Packet Inspection (DPI) will be even more sensitive to protocol trailers. Often such devices have a fixed length parsing buffer of X bytes (where X is commonly 64, 128, or 256 bytes). When a device receives a packet, the first X bytes of the packet are preloaded into the parsing buffer before processing commences. Protocol processing is performed on the bytes in the parsing buffer. If the protocol headers extend beyond the parsing buffer then either the device won't process the headers (which may mean they drop the packet) or the packet is relegated to a slow path. Neither behavior is desirable. Given that protocol trailers follow packet payload, it will be common that the protocol trailers for a packet are not contained with parsing buffer. Appendix C: Protocol field alignment T. Herbert Expires January 9, 2020 [Page 15] INTERNET DRAFT draft-herbert-udp-opt-hdr-01 July 8, 2019 This appendix is informational and does not constitute a normative part of this document. It is often convenient to access multi-byte protocol fields in a protocol header in memory using CPU instructions to access a field as a word (two bytes) or double word (four bytes). When such accesses are done, the data being accessed can be "aligned" or "unaligned". An aligned data access happens when the address of the operation modulo the size of the operand is zero, and conversely an unaligned access occurs when the when the address of the operation modulo the size of the operand is non-zero. On certain CPU architectures including SPARC, older versions of ARM, some cases of RISC-V, and even a corner case in x86, an unaligned access may incur a substantial performance penalty compared to an aligned access. For instance, an unaligned access may result in a software trap and handling the memory access in software. By convention, most IETF protocols are structured to ensure that multi-byte fields have an offset within the respective protocol header that is properly aligned per their field size. Additionally, most IP protocols are defined to have length that is a multiple of four bytes. These conventions, along with some implementation techniques, have mostly allowed software implementations to be reusable across different architectures without the sustaining performance hit of unaligned accesses. The Padding field in UDP Surplus Header is important to maintain the benefits of aligned protocol headers. Author's Address Tom Herbert Intel Santa Clara, CA USA Email: tom@quantonium.net T. Herbert Expires January 9, 2020 [Page 16]