< draft-herbert-udp-space-hdr-00.txt   draft-herbert-udp-space-hdr-01.txt >
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Standard Quantonium Intended Status: Standard Intel
Expires: September 2019 Expires: January 2020
March 11, 2019 July 8, 2019
UDP Surplus Space Header UDP Surplus Header
draft-herbert-udp-space-hdr-00 draft-herbert-udp-space-hdr-01
Abstract Abstract
This draft defines a header for surplus space in UDP. The UDP surplus This specification defines the UDP Surplus Header that is an
space is bytes between the end of the UDP payload and the end of the extensible and generic format applied to the UDP surplus space. The
IP packet. The purpose of the header is to disambiguate uses of the UDP surplus space comprises the bytes between the end of the UDP
surplus space. The UDP surplus space header includes a type, length, datagram, as indicated by the UDP Length field, and the end of the IP
and checksum field that covers the space. 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 18
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 UDP surplus space header format . . . . . . . . . . . . . . . . 3 2 UDP Surplus Header format . . . . . . . . . . . . . . . . . . . 3
3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Protocol trailer format . . . . . . . . . . . . . . . . . . 4
3.1 Sender operation . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Protocol header format (Extended UDP header) . . . . . . . . 6
3.2 Receiver operation . . . . . . . . . . . . . . . . . . . . . 6 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 3.1 Sender operation . . . . . . . . . . . . . . . . . . . . . . 7
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Receiver operation . . . . . . . . . . . . . . . . . . . . . 8
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Error handling . . . . . . . . . . . . . . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2 Informative References . . . . . . . . . . . . . . . . . . 7 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 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
1 Introduction 1 Introduction
This specification defines a UDP surplus header to provide an As defined in [RFC768], the UDP header contains a UDP Length field.
extensible and generic format of the UDP surplus space. The UDP The UDP Length is not required to correlate with the IP payload
surplus space is bytes between the end of the UDP payload and the end length of a packet such that there may be bytes between the end of
of the IP packet. The UDP surplus space is possible since UDP the UDP datagram and the end of the IP packet. This space is referred
contains its own length field for the UDP datagram that is not to as the UDP surplus space.
required to coincide with the end of the IP packet.
The UDP surplus space header includes a type, length, and checksum This specification defines the UDP Surplus Header (USH) to provide a
field that covers the space. UDP options [UDPOPT] are being defined common format for the UDP surplus space. The USH is comprised of a
as the first standard use of the UDP surplus space. This draft four byte base header and some variable amount of data. The base
permits other uses, including private uses of the space. 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.
2 UDP surplus space header format There are two use cases of USH:
The format of the UDP surplus space header is shown below. 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
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 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) | | Padding (0 to 3 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Checksum | | Type | TSLength | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Type Specific Data ~ ~ Type Specific Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are: The fields are:
o Padding: Aligns the header to four bytes. The number of padding o Padding: Aligns the UDP Surplus Header to four bytes. The number
bytes required is: 3 - ((udp_length - 1) % 4) where the of padding bytes required is: 3 - ((udp_length - 1) % 4), where
udp_length is the length of the UDP header and UDP payload. the udp_length is the length of the UDP datagram as specified in
Padding bytes MUST be set to zero on transmission, and MUST be the UDP Length field. Padding bytes MUST be set to zero on
verified to be zero when received. transmission, and MUST be verified to be zero when received.
o Type: The type of the UDP surplus space. One type is defined for o Type: Indicates the format of the UDP surplus space and how the
UDP options. Type Specific Data is interpreted. Defined Type values are:
o Length: Length of the Type Specific Data in units of four byte o 0: Reserved
words. The length of the Type Specific Data is thus zero to 1020
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. bytes.
o Checksum: The standard one's complement checksum that covers the o Checksum: The standard one's complement checksum that covers the
UDP surplus space starting from the Type field through the end UDP surplus area. The coverage starts from the first byte of
of the Type Specific Data as indicated in the Length field. 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.
Preceding Padding Bytes are not included in the checksum o Type Specific Data: Variable length data that is considered part
coverage. of the UDP Surplus Header. This data is interpreted per the
value of the Type field.
o Type specific data: Data corresponding to the Type of the 2.1 Protocol trailer format
surplus data. For instance, in the case of UDP options, the Type
specific data would contain the UDP options including any
padding options to align the length of the Type Specific Data to
four bytes.
Defined Type values are: When used as a protocol trailer, the UDP Surplus Header immediately
follows the UDP data. The logical protocol layering is:
o 0: Reserved +-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
+-+-+-+-+-+-+-+-+-+-+-+
| UDP data |
/ +-+-+-+-+-+-+-+-+-+-+-+ \
Surplus | | USH base header | |
space | +-+-+-+-+-+-+-+-+-+-+-+ | USH
| | Type specific data | |
\ +-+-+-+-+-+-+-+-+-+-+-+ /
o 1: UDP options The packet format of UDP Surplus Header as a protocol trailer is:
0 2-127: Reserved 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
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
0 128-255: Available for private use or experimentation 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.
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.
- 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 Operation
3.1 Sender operation 3.1 Sender operation
A sender MAY set a UDP surplus space header and data in the surplus A sender sets a UDP Surplus Header in the surplus space when sending
space when sending a UDP packet. The UDP surplus header immediately an IP packet. The UDP surplus header immediately follows the UDP
follows the UDP payload at the offset of UDP Length from the start of packet at the offset of UDP Length from the start of the UDP header.
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.
The sender MUST insert up to three bytes of padding to align the UDP If the USH is being used as a protocol trailer then the UDP Surplus
surplus header to four bytes. 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 sender MUST set the Type field to the type of the data to be The IP Length field in the IPv4 header or Total Length field in the
processed. 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 Length field MUST be set to reflect the length of the Type The TSLength field MUST be set to reflect the length of the Type
Specific Data. Specific Data. The Type Specific Data MUST be padded if necessary to
align its length to four bytes.
The Checksum MUST be set. To compute the checksum: The USH Checksum MUST be set. To compute the checksum:
1) Set the Checksum field to zero. Compute the standard one's 1) Set the Checksum field to zero. Compute the standard one's
complement two byte checksum starting from the Type field complement two byte checksum starting from the Type field
through the end of the Type Specific Data. 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.
2) Set the value of the Checksum field to the bitwise "not" of the 2) Set the value of the Checksum field to the bitwise "not" of the
checksum computed in the previous step. checksum computed in the previous step.
Note that a sender MAY set multiple UDP surplus area headers in a
packet. If more than one is set, then they are consecutive where one
immediately follows another.
3.2 Receiver operation 3.2 Receiver operation
The following steps are for processing a UDP packet with surplus The processing for a UDP packet with surplus space is:
space:
1) Check for minimum length to contain a surplus option header. If 1) Check for minimum length to contain a UDP Surplus Header. If
the surplus space length is less than 3 - ((udp_length - 1) % the UDP surplus space length is less than 3 - ((udp_length - 1)
4) + 4, then the UDP surplus space header is not present. % 4) + 4, then the UDP Surplus Header is considered invalid.
2) Check padding bytes. If the UDP Length is not a multiple of 2) Check padding bytes. If the UDP Length is not a multiple of
four bytes then verify that the padding bytes following the UDP four bytes then verify that the padding bytes following the UDP
payload are set to zero. Then expected number of padding bytes payload are set to zero. The required number of padding bytes
is 3 - ((udp_length - 1) % 4). is 3 - ((udp_length - 1) % 4). If the padding bytes are not
zero, the UDP Surplus Header is considered invalid.
3) Check the Length field. If the length determined from the 3) Check the TSLength field. If the length determined from the
Length field plus the starting offset of the Type specific data TSLength field plus the starting offset of the Type Specific
exceeds the length of the packet then the surplus area header Data exceeds the length of the IP packet then the UDP Surplus
is considered invalid. Header is considered invalid.
4) Verify the checksum. Compute the one's complement checksum 4) Verify the checksum. Compute the one's complement checksum
starting from the Type field through the end of the Type starting from the Type field through the end of the IP packet
specific data as indicated by the Length field. If the result (the end of the surplus area). If the result of the computation
of the computation ~0 (-0 checksum value) then the checksum is is checksum zero (~0 or -0) then the checksum is verified. If
verified. If the checksum is not verified then the surplus area the checksum is not verified then the UDP Surplus Header is
header is invalid. considered invalid.
5) Check the Type. If the Type is unknown to the receiver then the 5) Check the Type. If the Type is unknown to the receiver then the
surplus header is considered invalid. surplus header is considered invalid.
6) Process the Type Specific Data per the Type in the UDP surplus 6) Process the Type Specific Data per the Type in the UDP Surplus
space header. In the course of processing the Type specific Header. If an error condition is encountered in the course of
data, the receiver may determine that the surplus data is processing the Type Specific Data then the receiver SHOULD
invalid. consider that the UDP Surplus Header is invalid.
7) If there are additional bytes beyond the surplus header, a 7) In the protocol trailer use case, if there are additional bytes
receiver MAY attempt to process those bytes as an additional beyond the UDP Surplus Header, a receiver SHOULD ignore those
surplus header. Processing would the same as how the first bytes (with the exception that the excess bytes MUST be
header was processed (although note that subsequent UDP surplus included in the USH Checksum computation).
headers would not need Padding bytes since they would already
be aligned to four bytes).
If the number surplus bytes in a UDP packet are non-zero and 8) If the UDP Surplus Header is validated and processed, deliver
determined to not contain a valid UDP surplus header, the surplus the UDP data to the application.
bytes SHOULD be ignored following existing protocol processing
convention. An implementation MAY allow configuration that would
discard such packets.
4 Security Considerations 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
application.
The UDP surplus space header does not address nor introduce any new In the case of protocol header, the UDP data delivered to the
security considerations. application immediately follows the UDP Surplus Header and has
length of IP_payload_length - 12 - (4 * TSLength).
5 IANA Considerations 3.2.1 Error handling
IANA is requested to create a registry for the Type of UDP surplus If an error is encountered when processing the UDP space or UDP
options. Surplus Header such that the UDP Surplus Header is considered
invalid, then the following actions should be taken:
6 References - 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.
6.1 Normative References - 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).
6.2 Informative References 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
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.
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- [UDPOPT] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-07 udp-options-07
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:
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
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.
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
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 Author's Address
Tom Herbert Tom Herbert
Quantonium Intel
Santa Clara, CA Santa Clara, CA
USA USA
Email: tom@quantonium.net Email: tom@quantonium.net
 End of changes. 45 change blocks. 
113 lines changed or deleted 566 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/