Internet DRAFT - draft-herbert-udp-space-hdr
draft-herbert-udp-space-hdr
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]
