draft-ietf-tsvwg-udp-options-07.txt   draft-ietf-tsvwg-udp-options-08.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Independent consultant Internet Draft Independent consultant
Intended status: Standards Track March 8, 2019 Intended status: Standards Track September 12, 2019
Intended updates: 768 Intended updates: 768
Expires: September 2019 Expires: March 2020
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-07.txt draft-ietf-tsvwg-udp-options-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 8, 2019. This Internet-Draft will expire on March 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Transport protocols are extended through the use of transport header Transport protocols are extended through the use of transport header
options. This document experimentally extends UDP by indicating the options. This document extends UDP by indicating the location,
location, syntax, and semantics for UDP transport layer options. syntax, and semantics for UDP transport layer options.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. Background.....................................................3 3. Background.....................................................3
4. The UDP Option Area............................................4 4. The UDP Option Area............................................4
5. UDP Options....................................................7 5. UDP Options....................................................7
5.1. End of Options List (EOL).................................8 5.1. End of Options List (EOL).................................9
5.2. No Operation (NOP)........................................9 5.2. No Operation (NOP).......................................10
5.3. Option Checksum (OCS).....................................9 5.3. Option Checksum (OCS)....................................10
5.4. Alternate Checksum (ACS).................................11 5.4. Alternate Checksum (ACS).................................11
5.5. Lite (LITE)..............................................11 5.5. Lite (LITE)..............................................12
5.6. Maximum Segment Size (MSS)...............................13 5.6. Maximum Segment Size (MSS)...............................14
5.7. Fragmentation (FRAG).....................................14 5.7. Fragmentation (FRAG).....................................15
5.8. Coupling FRAG with LITE..................................16 5.8. Coupling FRAG with LITE..................................17
5.9. Timestamps (TIME)........................................17 5.9. Timestamps (TIME)........................................18
5.10. Authentication and Encryption (AE)......................18 5.10. Authentication and Encryption (AE)......................19
6. Echo request (REQ) and echo response (RES)....................19 6. Echo request (REQ) and echo response (RES)....................20
6.1. Experimental (EXP).......................................19 6.1. Experimental (EXP).......................................20
7. Rules for designing new options...............................20 7. Rules for designing new options...............................21
8. Option inclusion and processing...............................21 8. Option inclusion and processing...............................22
9. UDP API Extensions............................................23 9. UDP API Extensions............................................24
10. Whose options are these?.....................................23 10. Whose options are these?.....................................24
11. UDP options LITE option vs. UDP-Lite.........................24 11. UDP options LITE option vs. UDP-Lite.........................25
12. Interactions with Legacy Devices.............................25 12. Interactions with Legacy Devices.............................26
13. Options in a Stateless, Unreliable Transport Protocol........25 13. Options in a Stateless, Unreliable Transport Protocol........26
14. UDP Option State Caching.....................................26 14. UDP Option State Caching.....................................27
15. Updates to RFC 768...........................................26 15. Updates to RFC 768...........................................27
16. Multicast Considerations.....................................26 16. Multicast Considerations.....................................27
17. Security Considerations......................................27 17. Security Considerations......................................28
18. IANA Considerations..........................................27 18. IANA Considerations..........................................28
19. References...................................................28 19. References...................................................29
19.1. Normative References....................................28 19.1. Normative References....................................29
19.2. Informative References..................................28 19.2. Informative References..................................29
20. Acknowledgments..............................................30 20. Acknowledgments..............................................31
Appendix A. Implementation Information...........................31 Appendix A. Implementation Information...........................32
1. Introduction 1. Introduction
Transport protocols use options as a way to extend their Transport protocols use options as a way to extend their
capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340]
include space for these options but UDP [RFC768] currently does not. include space for these options but UDP [RFC768] currently does not.
This document defines an experimental extension to UDP that provides This document defines an extension to UDP that provides space for
space for transport options including their generic syntax and transport options including their generic syntax and semantics for
semantics for their use in UDP's stateless, unreliable message their use in UDP's stateless, unreliable message protocol.
protocol.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
In this document, these words will appear with that interpretation capitals, as shown here.
only when in ALL CAPS. Lowercase uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
In this document, the characters ">>" preceding an indented line(s) In this document, the characters ">>" preceding an indented line(s)
indicates a statement using the key words listed above. This indicates a statement using the key words listed above. This
convention aids reviewers in quickly identifying or finding the convention aids reviewers in quickly identifying or finding the
portions of this RFC covered by these key words. portions of this RFC covered by these key words.
3. Background 3. Background
Many protocols include a default header and an area for header Many protocols include a default header and an area for header
options. These options enable the protocol to be extended for use in options. These options enable the protocol to be extended for use in
skipping to change at page 4, line 8 skipping to change at page 4, line 4
managed. In stateless protocols their effect is often limited to managed. In stateless protocols their effect is often limited to
individual packets, but they can have an aggregate effect on a individual packets, but they can have an aggregate effect on a
sequence as well. One example of such uses is Substrate Protocol for sequence as well. One example of such uses is Substrate Protocol for
User Datagrams (SPUD) [Tr16], and this document is intended to User Datagrams (SPUD) [Tr16], and this document is intended to
provide an out-of-band option area as an alternative to the in-band provide an out-of-band option area as an alternative to the in-band
mechanism currently proposed [Hi15]. mechanism currently proposed [Hi15].
UDP is one of the most popular protocols that lacks space for UDP is one of the most popular protocols that lacks space for
options [RFC768]. The UDP header was intended to be a minimal options [RFC768]. The UDP header was intended to be a minimal
addition to IP, providing only ports and a data checksum for addition to IP, providing only ports and a data checksum for
protection. This document experimentally extends UDP to provide a protection. This document extends UDP to provide a trailer area for
trailer area for options located after the UDP data payload. options located after the UDP data payload.
4. The UDP Option Area 4. The UDP Option Area
The UDP transport header includes demultiplexing and service The UDP transport header includes demultiplexing and service
identification (port numbers), a checksum, and a field that identification (port numbers), a checksum, and a field that
indicates the UDP datagram length (including UDP header). The UDP indicates the UDP datagram length (including UDP header). The UDP
Length field is typically redundant with the size of the maximum Length field is typically redundant with the size of the maximum
space available as a transport protocol payload (see also discussion space available as a transport protocol payload (see also discussion
in Section 12). in Section 12).
skipping to change at page 6, line 43 skipping to change at page 6, line 43
minimum of two bytes in length as shown in Figure 4, excepting only minimum of two bytes in length as shown in Figure 4, excepting only
the one byte options "No Operation" (NOP) and "End of Options List" the one byte options "No Operation" (NOP) and "End of Options List"
(EOL) described below. (EOL) described below.
+--------+--------+ +--------+--------+
| Kind | Length | | Kind | Length |
+--------+--------+ +--------+--------+
Figure 4 UDP option default format Figure 4 UDP option default format
>> UDP options MAY occur at any UDP length offset. The Kind field is always one byte. The Length field is one byte for
all lengths below 255 (including the Kind and Length bytes). A
Length of 255 indicates use of the UDP option extended format shown
in Figure 5. The Extended Length field is a 16-bit field in network
standard byte order.
+--------+--------+--------+--------+
| Kind | 255 | Extended Length |
+--------+--------+--------+--------+
Figure 5 UDP option extended default format
>> UDP options MAY begin at any UDP length offset.
>> The UDP length MUST be at least as large as the UDP header (8) >> The UDP length MUST be at least as large as the UDP header (8)
and no larger than the IP transport payload. Values outside this and no larger than the IP transport payload. Values outside this
range MUST be silently discarded as invalid and logged where rate- range MUST be silently discarded as invalid and logged where rate-
limiting permits. limiting permits.
>> Option Lengths (or Extended Lengths, where applicable) smaller
than the minimum for the corresponding Kind and default format MUST
be treated as an error.
Others have considered using values of the UDP Length that is larger Others have considered using values of the UDP Length that is larger
than the IP transport payload as an additional type of signal. Using than the IP transport payload as an additional type of signal. Using
a value smaller than the IP transport payload is expected to be a value smaller than the IP transport payload is expected to be
backward compatible with existing UDP implementations, i.e., to backward compatible with existing UDP implementations, i.e., to
deliver the UDP Length of user data to the application and silently deliver the UDP Length of user data to the application and silently
ignore the additional surplus area data. Using a value larger than ignore the additional surplus area data. Using a value larger than
the IP transport payload would either be considered malformed (and the IP transport payload would either be considered malformed (and
be silently dropped) or could cause buffer overruns, and so is not be silently dropped) or could cause buffer overruns, and so is not
considered silently and safely backward compatible. Its use is thus considered silently and safely backward compatible. Its use is thus
out of scope for the extension described in this document. out of scope for the extension described in this document.
skipping to change at page 7, line 24 skipping to change at page 8, line 9
in the UDP option area. in the UDP option area.
5. UDP Options 5. UDP Options
The following UDP options are currently defined: The following UDP options are currently defined:
Kind Length Meaning Kind Length Meaning
---------------------------------------------- ----------------------------------------------
0* - End of Options List (EOL) 0* - End of Options List (EOL)
1* - No operation (NOP) 1* - No operation (NOP)
2* 2 Option checksum (OCS) 2* 3 Option checksum (OCS)
3* 4 Alternate checksum (ACS) 3* 6 Alternate checksum (ACS)
4* 4 Lite (LITE) 4* 4 Lite (LITE)
5* 4 Maximum segment size (MSS) 5* 4 Maximum segment size (MSS)
6* 8/10 Fragmentation (FRAG) 6* 8/10 Fragmentation (FRAG)
7 10 Timestamps (TIME) 7 10 Timestamps (TIME)
8 (varies) Authentication and Encryption (AE) 8 (varies) Authentication and Encryption (AE)
9 6 Request (REQ) 9 6 Request (REQ)
10 6 Response (RES) 10 6 Response (RES)
11-126 (varies) UNASSIGNED (assignable by IANA) 11-126 (varies) UNASSIGNED (assignable by IANA)
127-253 RESERVED 127-253 RESERVED
254 N(>=4) RFC 3692-style experiments (EXP) 254 N(>=4) RFC 3692-style experiments (EXP)
255 RESERVED 255 Reserved
These options are defined in the following subsections. Options 0 These options are defined in the following subsections. Options 0
and 1 use the same values as for TCP. and 1 use the same values as for TCP.
>> An endpoint supporting UDP options MUST support those marked with >> An endpoint supporting UDP options MUST support those marked with
a "*" above: EOL, NOP, OCS, ACS, LITE, FRAG, and MSS. This includes a "*" above: EOL, NOP, OCS, ACS, LITE, FRAG, and MSS. This includes
both recognizing and being able to generate these options if both recognizing and being able to generate these options if
configured to do so. configured to do so.
>> All other options (without a "*") MAY be implemented, and their >> All other options (without a "*") MAY be implemented, and their
skipping to change at page 8, line 27 skipping to change at page 9, line 14
Receivers cannot treat unexpected option lengths as invalid, as this Receivers cannot treat unexpected option lengths as invalid, as this
would unnecessarily limit future revision of options (e.g., defining would unnecessarily limit future revision of options (e.g., defining
a new ACS that is defined by having a different length). a new ACS that is defined by having a different length).
>> Option lengths MUST NOT exceed the IP length of the packet. If >> Option lengths MUST NOT exceed the IP length of the packet. If
this occurs, the packet MUST be treated as malformed and dropped, this occurs, the packet MUST be treated as malformed and dropped,
and the event MAY be logged for diagnostics (logging SHOULD be rate and the event MAY be logged for diagnostics (logging SHOULD be rate
limited). limited).
>> Options with fixed lengths MUST use the default option format.
>> Options with variable lengths MUST use the default option format
where their total length is 254 bytes or less.
>> Options using the extended option format MUST indicate extended
lengths of 255 or higher; smaller extended length values MUST be
treated as an error.
>> Required options MUST come before other options. Each required >> Required options MUST come before other options. Each required
option MUST NOT occur more than once (if they are repeated in a option MUST NOT occur more than once (if they are repeated in a
received segment, all except the first MUST be silently ignored). received segment, all except the first MUST be silently ignored).
The requirement that required options come before others is intended The requirement that required options come before others is intended
to allow for endpoints to implement DOS protection, as discussed to allow for endpoints to implement DOS protection, as discussed
further in Section 17. further in Section 17.
5.1. End of Options List (EOL) 5.1. End of Options List (EOL)
The End of Options List (EOL) option indicates that there are no The End of Options List (EOL) option indicates that there are no
more options. It is used to indicate the end of the list of options more options. It is used to indicate the end of the list of options
without needing to pad the options to fill all available option without needing to pad the options to fill all available option
space. space.
+--------+ +--------+
| Kind=0 | | Kind=0 |
+--------+ +--------+
Figure 5 UDP EOL option format Figure 6 UDP EOL option format
>> When the UDP options do not consume the entire option area, the >> When the UDP options do not consume the entire option area, the
last non-NOP option SHOULD be EOL (vs. filling the entire option last non-NOP option MUST be EOL.
area with NOP values).
>> All bytes after EOL MUST be ignored by UDP option processing. As >> All bytes in the surplus area after EOL MUST be zero.
a result, there can only ever be one EOL option (even if other bytes
were zero, they are ignored). Requiring the post-option surplus area to be zero prevents side-
channel uses of this area, requiring instead that all use of the
surplus area be UDP options supported by both endpoints. It is
useful to allow for such padding to increase the packet length
without affecting the payload length, e.g., for UDP PLPMTUD [Fa19].
5.2. No Operation (NOP) 5.2. No Operation (NOP)
The No Operation (NOP) option is a one byte placeholder, intended to The No Operation (NOP) option is a one byte placeholder, intended to
be used as padding, e.g., to align multi-byte options along 16-bit be used as padding, e.g., to align multi-byte options along 16-bit
or 32-bit boundaries. or 32-bit boundaries.
+--------+ +--------+
| Kind=1 | | Kind=1 |
+--------+ +--------+
Figure 6 UDP NOP option format Figure 7 UDP NOP option format
>> If options longer than one byte are used, NOP options SHOULD be >> If options longer than one byte are used, NOP options SHOULD be
used at the beginning of the UDP options area to achieve alignment used at the beginning of the UDP options area to achieve alignment
as would be more efficient for active (i.e., non-NOP) options. as would be more efficient for active (i.e., non-NOP) options.
>> Segments SHOULD NOT use more than three consecutive NOPs. NOPs >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs
are intended to assist with alignment, not other padding or fill. are intended to assist with alignment, not other padding or fill.
[NOTE: Tom Herbert suggested we declare "more than 3 consecutive [NOTE: Tom Herbert suggested we declare "more than 3 consecutive
NOPs" a fatal error to reduce the potential of using NOPs as a DOS NOPs" a fatal error to reduce the potential of using NOPs as a DOS
attack, but IMO there are other equivalent ways (e.g., using attack, but IMO there are other equivalent ways (e.g., using
RESERVED or other UNASSIGNED values) and the "no more than 3" RESERVED or other UNASSIGNED values) and the "no more than 3"
creates its own DOS vulnerability) creates its own DOS vulnerability)
5.3. Option Checksum (OCS) 5.3. Option Checksum (OCS)
The Option Checksum (OCS) is conventional Internet checksum that The Option Checksum (OCS) option is conventional Internet checksum
covers all of the UDP options. The primary purpose of OCS is to [RFC791] that covers all of the surplus area. The primary purpose of
detect non-standard (i.e., non-option) uses of the options area. OCS is to detect non-standard (i.e., non-option) uses of that area.
OCS is calculated by computing the Internet checksum options area OCS is calculated by computing the Internet checksum over the
[RFC1071]. OCS protects the option area from errors in a similar way surplus area. OCS protects the option area from errors in a similar
that the UDP checksum protects the UDP user data (when not zero). way that the UDP checksum protects the UDP user data (when not
zero).
+--------+--------+ +--------+--------+--------+
| Kind=2 |checksum| | Kind=2 | checksum |
+--------+--------+ +--------+--------+--------+
Figure 7 UDP OCS option format Figure 8 UDP OCS option format
>> When present, the option checksum SHOULD occur as early as >> OCS is REQUIRED when the UDP checksum is nonzero and UDP options
possible, preceded by only NOP options for alignment and the LITE are present.
option if present.
>> The OCS checksum MUST be half-word coordinated with the start of >> When present, OCS SHOULD occur as early as possible, preceded by
the UDP options area. only NOP options for alignment and the LITE option if present.
>> OCS MUST be half-word coordinated with the start of the UDP
options area.
This coordination is accomplished by computing the Internet checksum This coordination is accomplished by computing the Internet checksum
over the UDP options area (including EOL, if present) and then over the surplus area (including EOL, if present) and then adjusting
adjusting the result before storing it into the OCS checksum field. the result before storing it into the OCS checksum field. If that
If that field is aligned to the start of the options area, then the field is aligned to the start of the options area, then the checksum
checksum is inserted as-is, otherwise the checksum bytes are swapped is inserted as-is, otherwise the checksum bytes are swapped before
before inserting them into the field. inserting them into the field.
The adjustment above helps enable that OCS, together with the other The adjustment above helps enable that OCS, together with the other
options, result in an overall zero ones-complement sum. This feature options, result in an overall zero ones-complement sum. This feature
is intended to potentially help the UDP options traverse devices is intended to potentially help the UDP options traverse devices
that incorrectly attempt to checksum the surplus area (as originally that incorrectly attempt to checksum the surplus area (as originally
proposed as the Checksum Compensation Option, i.e., CCO [Fa18]). proposed as the Checksum Compensation Option, i.e., CCO [Fa18]).
Note that this incorrect checksum traversal feature is defeated by Note that this incorrect checksum traversal feature is defeated by
the use of LITE, whether alone or with FRAG, because the LITE area the use of LITE, whether alone or with FRAG, because the LITE area
is deliberately not covered by OCS. It also is defeated by the use is deliberately not covered by OCS. It also is defeated by the use
of a zero UDP checksum (i.e., UDP checksum disabled). of a zero UDP checksum (i.e., UDP checksum disabled).
skipping to change at page 10, line 43 skipping to change at page 11, line 42
original (prior to rearrangement for transmission) or restored original (prior to rearrangement for transmission) or restored
(after rearrangement upon reception) UDP option area. (after rearrangement upon reception) UDP option area.
>> If OCS fails, all options MUST be ignored and any trailing >> If OCS fails, all options MUST be ignored and any trailing
surplus data (and Lite data, if used) silently discarded. surplus data (and Lite data, if used) silently discarded.
>> UDP data that is validated by a correct UDP checksum MUST be >> UDP data that is validated by a correct UDP checksum MUST be
delivered to the application layer, even if OCS fails, unless the delivered to the application layer, even if OCS fails, unless the
endpoints have negotiated otherwise for this segment's socket pair. endpoints have negotiated otherwise for this segment's socket pair.
As a reminder, use of the UDP checksum is optional. When not used, As a reminder, use of the UDP checksum is optional when the UDP
i.e., when the field is zero, that checksum is assumed to be checksum is zero. When not used, OCS is assumed to be "correct" for
"correct" for the purpose of accepting UDP packets at a receiver. the purpose of accepting UDP packets at a receiver (see Section 8).
OCS is intended to check for accidental errors, not for attacks. OCS is intended to check for accidental errors, not for attacks.
5.4. Alternate Checksum (ACS) 5.4. Alternate Checksum (ACS)
The Alternate Checksum (ACS) provides a stronger alternative to the The Alternate Checksum (ACS) option provides a stronger alternative
checksum in the UDP header, using a 16-bit CRC of the conventional to the checksum in the UDP header, using a 32-bit CRC of the
UDP payload only (excluding the IP pseudoheader, UDP header, and UDP conventional UDP payload only (excluding the IP pseudoheader, UDP
options, and not include the LITE area). Because it does not include header, and UDP options, and not include the LITE area). Because it
the IP pseudoheader or UDP header, it need not be updated by NATs does not include the IP pseudoheader or UDP header, it need not be
when IP addresses or UDP ports are rewritten. Its purpose is to updated by NATs when IP addresses or UDP ports are rewritten. Its
detect errors that the UDP checksum, when used, might not detect. purpose is to detect errors that the UDP checksum, when used, might
not detect.
CRC-CCITT (polynomial x^16 + x^12 + x^5 + 1) has been chosen because CRC32c has been chosen because of its ubiquity and use in other
of its ubiquity and use in other packet protocols, such as X.25, Internet protocols, including iSCSI and SCTP. The option contains
HDLC, and Bluetooth. The option contains FCS-16 as defined in CRC32c in network standard byte order, as described in [RFC3385].
Appendix C of [RFC1662], except that it is not inverted in the final
step and that it is stored in the ACS option in network byte order.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=3 | Len=4 | CRC16sum | | Kind=3 | Len=6 | CRC32c... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| CRC32c (cont.) |
+--------+--------+
Figure 8 UDP ACS option format Figure 9 UDP ACS option format
When present, the ACS always contains a valid CRC checksum. There When present, the ACS always contains a valid CRC checksum. There
are no reserved values, including the value of zero. If the CRC is are no reserved values, including the value of zero. If the CRC is
zero, this must indicate a valid checksum (i.e., it does not zero, this must indicate a valid checksum (i.e., it does not
indicate that the ACS is not used; instead, the option would simply indicate that the ACS is not used; instead, the option would simply
not be included if that were the desired effect). not be included if that were the desired effect).
ACS does not protect the UDP pseudoheader; only the current UDP ACS does not protect the UDP pseudoheader; only the current UDP
checksum provides that protection (when used). ACS cannot provide checksum provides that protection (when used). ACS cannot provide
that protection because it would need to be updated whenever the UDP that protection because it would need to be updated whenever the UDP
skipping to change at page 12, line 17 skipping to change at page 13, line 14
the portion protected by the UDP checksum and the portion not the portion protected by the UDP checksum and the portion not
protected by the UDP checksum. protected by the UDP checksum.
LITE includes a 2-byte offset that indicates the length of the LITE includes a 2-byte offset that indicates the length of the
portion of the UDP data that is not covered by the UDP checksum. portion of the UDP data that is not covered by the UDP checksum.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=4 | Len=4 | Offset | | Kind=4 | Len=4 | Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 9 UDP LITE option format Figure 10 UDP LITE option format
At the sender, the option is formed using the following steps: At the sender, the option is formed using the following steps:
1. Create a LITE option, ordered as the first UDP option (Figure 1. Create a LITE option, ordered as the first UDP option (Figure
10). 11).
2. Calculate the location of the start of the options as an absolute 2. Calculate the location of the start of the options as an absolute
offset from the start of the UDP header and place that length in offset from the start of the UDP header and place that length in
the last two bytes of the LITE option. the last two bytes of the LITE option.
3. If the LITE data area is 4 bytes or longer, swap all four bytes 3. If the LITE data area is 4 bytes or longer, swap all four bytes
of the LITE option with the first 4 bytes of the LITE data area of the LITE option with the first 4 bytes of the LITE data area
(Figure 11). If the LITE data area is 0-3 bytes long, slide the (Figure 12). If the LITE data area is 0-3 bytes long, slide the
LITE option to the front of the LITE data area (i.e., placing the LITE option to the front of the LITE data area (i.e., placing the
0-3 bytes of LITE data after the LITE option). 0-3 bytes of LITE data after the LITE option).
+---------+--------------+--------------+------------------+ +---------+--------------+--------------+------------------+
| UDP Hdr | user data | LITE data |LITE| other opts | | UDP Hdr | user data | LITE data |LITE| other opts |
+---------+--------------+--------------+------------------+ +---------+--------------+--------------+------------------+
<----------------------> <---------------------->
UDP Length UDP Length
Figure 10 LITE option formation - LITE goes first Figure 11 LITE option formation - LITE goes first
+---------+--------------+--------------+------------------+ +---------+--------------+--------------+------------------+
| UDP Hdr | user data | LITE data |LITE| other opts | | UDP Hdr | user data | LITE data |LITE| other opts |
+---------+--------------+--------------+------------------+ +---------+--------------+--------------+------------------+
^^^^ ^^^^ ^^^^ ^^^^
| | | |
+--------------+ +--------------+
Figure 11 Before sending swap LITE option and front of LITE data Figure 12 Before sending swap LITE option and front of LITE data
The resulting packet has the format shown in Figure 12. Note that The resulting packet has the format shown in Figure 13. Note that
the UDP length now points to the LITE option, and the LITE option the UDP length now points to the LITE option, and the LITE option
points to the start of the option area. points to the start of the option area.
+---------+--------------+----------------+------------------+ +---------+--------------+----------------+------------------+
| UDP Hdr | user data |LITE| LITE data |Ldat| other opts | | UDP Hdr | user data |LITE| LITE data |Ldat| other opts |
+---------+--------------+----------------+------------------+ +---------+--------------+----------------+------------------+
<----------------------> | ^ <----------------------> | ^
UDP Length +-------------+ UDP Length +-------------+
Figure 12 Lite option as sent Figure 13 Lite option as sent
A legacy endpoint receiving this packet will discard the LITE option A legacy endpoint receiving this packet will discard the LITE option
and everything that follows, including the lite data and remainder and everything that follows, including the lite data and remainder
of the UDP options. The UDP checksum will protect only the user of the UDP options. The UDP checksum will protect only the user
data, not the LITE option or lite data. data, not the LITE option or lite data.
Receiving endpoints capable of processing UDP options will do the Receiving endpoints capable of processing UDP options will do the
following: following:
1. Process options as usual. This will start at the LITE option. 1. Process options as usual. This will start at the LITE option.
skipping to change at page 13, line 37 skipping to change at page 14, line 37
2. When the LITE option is encountered, record its location as the 2. When the LITE option is encountered, record its location as the
start of the LITE data area and (if the LITE offset indicates a start of the LITE data area and (if the LITE offset indicates a
LITE data length of at least 4 bytes) swap the four bytes there LITE data length of at least 4 bytes) swap the four bytes there
with the four bytes at the location indicated inside the LITE with the four bytes at the location indicated inside the LITE
option, which indicates the start of all of the options, option, which indicates the start of all of the options,
including the LITE one (one past the end of the lite data area). including the LITE one (one past the end of the lite data area).
If the LITE offset indicates a LITE data area of 0-3 bytes, then If the LITE offset indicates a LITE data area of 0-3 bytes, then
slide the LITE option forward that amount and slide the slide the LITE option forward that amount and slide the
corresponding bytes after the LITE option to where the LITE corresponding bytes after the LITE option to where the LITE
option originally began. In either case, this restores the format option originally began. In either case, this restores the format
of the option as it was prior to being sent, as per Figure 10. of the option as it was prior to being sent, as per Figure 11.
3. Continue processing the remainder of the options, which are now 3. Continue processing the remainder of the options, which are now
in the format shown in Figure 11. in the format shown in Figure 12.
The purpose of this swap (or slide) is to support the equivalent of The purpose of this swap (or slide) is to support the equivalent of
UDP Lite operation together with other UDP options without requiring UDP Lite operation together with other UDP options without requiring
the entire LITE data area to be moved after the UDP option area. the entire LITE data area to be moved after the UDP option area.
5.6. Maximum Segment Size (MSS) 5.6. Maximum Segment Size (MSS)
The Maximum Segment Size (MSS, Kind = 3) is a 16-bit indicator of The Maximum Segment Size (MSS, Kind = 3) option is a 16-bit
the largest UDP segment that can be received. As with the TCP MSS indicator of the largest UDP segment that can be received. As with
option [RFC793], the size indicated is the IP layer MTU decreased by the TCP MSS option [RFC793], the size indicated is the IP layer MTU
the fixed IP and UDP headers only [RFC6691]. The space needed for IP decreased by the fixed IP and UDP headers only [RFC6691]. The space
and UDP options need to be adjusted by the sender when using the needed for IP and UDP options need to be adjusted by the sender when
value indicated. The value transmitted is based on EMTU_R, the using the value indicated. The value transmitted is based on EMTU_R,
largest IP datagram that can be received (i.e., reassembled at the the largest IP datagram that can be received (i.e., reassembled at
receiver) [RFC1122]. the receiver) [RFC1122].
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=5 | Len=4 | MSS size | | Kind=5 | Len=4 | MSS size |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 13 UDP MSS option format Figure 14 UDP MSS option format
The UDP MSS option MAY be used for path MTU discovery The UDP MSS option MAY be used for path MTU discovery
[RFC1191][RFC8201], but this may be difficult because of known [RFC1191][RFC8201], but this may be difficult because of known
issues with ICMP blocking [RFC2923] as well as UDP lacking automatic issues with ICMP blocking [RFC2923] as well as UDP lacking automatic
retransmission. It is more likely to be useful when coupled with IP retransmission. It is more likely to be useful when coupled with IP
source fragmentation to limit the largest reassembled UDP message, source fragmentation to limit the largest reassembled UDP message,
e.g., when EMTU_R is larger than the required minimums (576 for IPv4 e.g., when EMTU_R is larger than the required minimums (576 for IPv4
[RFC791] and 1500 for IPv6 [RFC8200]). [RFC791] and 1500 for IPv6 [RFC8200]).
5.7. Fragmentation (FRAG) 5.7. Fragmentation (FRAG)
The Fragmentation option (FRAG) supports UDP fragmentation and The Fragmentation (FRAG) option supports UDP fragmentation and
reassembly, which can be used to transfer UDP messages larger than reassembly, which can be used to transfer UDP messages larger than
limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically
used with the UDP MSS option to enable more efficient use of large used with the UDP MSS option to enable more efficient use of large
messages, both at the UDP and IP layers. FRAG is designed similar to messages, both at the UDP and IP layers. FRAG is designed similar to
the IPv6 Fragmentation Header [RFC8200], except that the UDP variant the IPv6 Fragmentation Header [RFC8200], except that the UDP variant
uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit
Fragment Offset measured in 8-byte units. This UDP variant avoids Fragment Offset measured in 8-byte units. This UDP variant avoids
creating reserved fields. creating reserved fields.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=6 | Len=8 | Frag. Offset | | Kind=6 | Len=8 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 14 UDP non-terminal FRAG option format Figure 15 UDP non-terminal FRAG option format
The FRAG option also lacks a "more" bit, zeroed for the terminal The FRAG option also lacks a "more" bit, zeroed for the terminal
fragment of a set. This is possible because the terminal FRAG option fragment of a set. This is possible because the terminal FRAG option
is indicated as a longer, 10-byte variant, which includes an is indicated as a longer, 10-byte variant, which includes an
Internet checksum over the entire reassembled UDP payload (omitting Internet checksum over the entire reassembled UDP payload (omitting
the IP pseudoheader and UDP header, as well as UDP options), as the IP pseudoheader and UDP header, as well as UDP options), as
shown in Figure 15. shown in Figure 16.
>> The reassembly checksum SHOULD be used, but MAY be unused in the >> The reassembly checksum SHOULD be used, but MAY be unused in the
same situations when the UDP checksum is unused (e.g., for transit same situations when the UDP checksum is unused (e.g., for transit
tunnels or applications that have their own integrity checks tunnels or applications that have their own integrity checks
[RFC8200]), and by the same mechanism (set the field to 0x0000). [RFC8200]), and by the same mechanism (set the field to 0x0000).
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=6 | Len=10 | Frag. Offset | | Kind=6 | Len=10 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Checksum | | Checksum |
+--------+--------+ +--------+--------+
Figure 15 UDP terminal FRAG option format Figure 16 UDP terminal FRAG option format
>> During fragmentation, the UDP header checksum of each fragment >> During fragmentation, the UDP header checksum of each fragment
needs to be recomputed based on each datagram's pseudoheader. needs to be recomputed based on each datagram's pseudoheader.
>> After reassembly is complete and validated using the checksum of >> After reassembly is complete and validated using the checksum of
the terminal FRAG option, the UDP header checksum of the resulting the terminal FRAG option, the UDP header checksum of the resulting
datagram needs to be recomputed based on the datagram's datagram needs to be recomputed based on the datagram's
pseudoheader. pseudoheader.
The Fragment Offset is 16 bits and indicates the location of the UDP The Fragment Offset is 16 bits and indicates the location of the UDP
skipping to change at page 16, line 48 skipping to change at page 17, line 48
5.8. Coupling FRAG with LITE 5.8. Coupling FRAG with LITE
FRAG can be coupled with LITE to avoid impacting legacy receivers. FRAG can be coupled with LITE to avoid impacting legacy receivers.
Each fragment is sent as LITE un-checksummed data, where each UDP Each fragment is sent as LITE un-checksummed data, where each UDP
packet contains no legacy-compatible data. Legacy receivers packet contains no legacy-compatible data. Legacy receivers
interpret these as zero-length payload packets (i.e., UDP Length interpret these as zero-length payload packets (i.e., UDP Length
field is 8, the length of just the UDP header), which would not field is 8, the length of just the UDP header), which would not
affect the receiver unless the presence of the packet itself were a affect the receiver unless the presence of the packet itself were a
signal. The header of such a packet would appear as shown in Figure signal. The header of such a packet would appear as shown in Figure
16 and Figure 17. 17 and Figure 18.
+---------+--------------+---------+ +---------+--------------+---------+
| UDP Hdr | LiteFrag |LITE|FRAG| | UDP Hdr | LiteFrag |LITE|FRAG|
+---------+--------------+----+----+ +---------+--------------+----+----+
<-------> ^^^^ ^^^^ <-------> ^^^^ ^^^^
UDP Length=8 | | UDP Length=8 | |
+--------------+ +--------------+
Figure 16 Preparing FRAG as Lite data Figure 17 Preparing FRAG as Lite data
+---------+--------------+----+ +---------+--------------+----+
| UDP Hdr |LITE|LiteFrag |FRAG| | UDP Hdr |LITE|LiteFrag |FRAG|
+---------+--------------+----+ +---------+--------------+----+
<-------> | ^ <-------> | ^
UDP Length=8 | | UDP Length=8 | |
+-------------+ +-------------+
Figure 17 Lite option before transmission Figure 18 Lite option before transmission
When a packet is reassembled, it appears as a complete LITE data When a packet is reassembled, it appears as a complete LITE data
region. The UDP header of the reassembled packet is adjusted region. The UDP header of the reassembled packet is adjusted
accordingly, so that the reassembled region now appears as accordingly, so that the reassembled region now appears as
conventional UDP user data, and processing of the UDP options conventional UDP user data, and processing of the UDP options
continues, as with the non-LITE FRAG variant. continues, as with the non-LITE FRAG variant.
5.9. Timestamps (TIME) 5.9. Timestamps (TIME)
The UDP Timestamp option (TIME) exchanges two four-byte timestamp The Timestamp (TIME) option exchanges two four-byte timestamp
fields. It serves a similar purpose to TCP's TS option [RFC7323], fields. It serves a similar purpose to TCP's TS option [RFC7323],
enabling UDP to estimate the round trip time (RTT) between hosts. enabling UDP to estimate the round trip time (RTT) between hosts.
For UDP, this RTT can be useful for establishing UDP fragment For UDP, this RTT can be useful for establishing UDP fragment
reassembly timeouts or transport-layer rate-limiting [RFC8085]. reassembly timeouts or transport-layer rate-limiting [RFC8085].
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
| Kind=7 | Len=10 | TSval | TSecr | | Kind=7 | Len=10 | TSval | TSecr |
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
1 byte 1 byte 4 bytes 4 bytes 1 byte 1 byte 4 bytes 4 bytes
Figure 18 UDP TIME option format Figure 19 UDP TIME option format
TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar
manner to the TCP TS option [RFC7323]. On transmitted segments using manner to the TCP TS option [RFC7323]. On transmitted segments using
the option, TS Value is always set based on the local "time" value. the option, TS Value is always set based on the local "time" value.
Received TSval and TSecr values are provided to the application, Received TSval and TSecr values are provided to the application,
which can pass the TSval value to be used as TSecr on UDP messages which can pass the TSval value to be used as TSecr on UDP messages
sent in response (i.e., to echo the received TSval). A received sent in response (i.e., to echo the received TSval). A received
TSecr of zero indicates that the TSval was not echoed by the TSecr of zero indicates that the TSval was not echoed by the
transmitter, i.e., from a previously received UDP packet. transmitter, i.e., from a previously received UDP packet.
skipping to change at page 18, line 28 skipping to change at page 19, line 28
o A request is defined as "reply=0" and a reply is defined as both o A request is defined as "reply=0" and a reply is defined as both
fields being non-zero. fields being non-zero.
o A receiver should always respond to a request with the highest o A receiver should always respond to a request with the highest
TSval received, which is not necessarily the most recently TSval received, which is not necessarily the most recently
received. received.
5.10. Authentication and Encryption (AE) 5.10. Authentication and Encryption (AE)
The Authentication and Encryption option (AE) is intended to allow The Authentication and Encryption (AE) option is intended to allow
UDP to provide a similar type of authentication as the TCP UDP to provide a similar type of authentication as the TCP
Authentication Option (TCP-AO) [RFC5925]. It uses the same format as Authentication Option (TCP-AO) [RFC5925]. It uses the same format as
specified for TCP-AO, except that it uses a Kind of 8. AE supports specified for TCP-AO, except that it uses a Kind of 8. AE supports
NAT traversal in a similar manner as TCP-AO [RFC6978]. AE can also NAT traversal in a similar manner as TCP-AO [RFC6978]. AE can also
be extended to provide a similar encryption capability as TCP-AO- be extended to provide a similar encryption capability as TCP-AO-
ENC, in a similar manner [To18ao]. ENC, in a similar manner [To18ao].
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=8 | Len | Digest... | | Kind=8 | Len | Digest... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Digest (con't)... | | Digest (con't)... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 19 UDP AE option format Figure 20 UDP AE option format
Like TCP-AO, AE is not negotiated in-band. Its use assumes both Like TCP-AO, AE is not negotiated in-band. Its use assumes both
endpoints have populated Master Key Tuples (MKTs), used to exclude endpoints have populated Master Key Tuples (MKTs), used to exclude
non-protected traffic. non-protected traffic.
TCP-AO generates unique traffic keys from a hash of TCP connection TCP-AO generates unique traffic keys from a hash of TCP connection
parameters. UDP lacks a three-way handshake to coordinate parameters. UDP lacks a three-way handshake to coordinate
connection-specific values, such as TCP's Initial Sequence Numbers connection-specific values, such as TCP's Initial Sequence Numbers
(ISNs) [RFC793], thus AE's Key Derivation Function (KDF) uses zeroes (ISNs) [RFC793], thus AE's Key Derivation Function (KDF) uses zeroes
as the value for both ISNs. This means that the AE reuses keys when as the value for both ISNs. This means that the AE reuses keys when
skipping to change at page 19, line 25 skipping to change at page 20, line 25
Similar to TCP-AO-NAT, AE can be configured to support NAT Similar to TCP-AO-NAT, AE can be configured to support NAT
traversal, excluding one or both of the UDP ports [RFC6978]. traversal, excluding one or both of the UDP ports [RFC6978].
6. Echo request (REQ) and echo response (RES) 6. Echo request (REQ) and echo response (RES)
The echo request (REQ, kind=9) and echo response (RES, kind=10) The echo request (REQ, kind=9) and echo response (RES, kind=10)
options provide a means for UDP options to be used to provide options provide a means for UDP options to be used to provide
packet-level acknowledgements. Their use is described as part of the packet-level acknowledgements. Their use is described as part of the
UDP variant of packetization layer path MTU discovery (PLPMTUD) UDP variant of packetization layer path MTU discovery (PLPMTUD)
[Fa19]. The options both have the format indicated in Figure 20. [Fa19]. The options both have the format indicated in Figure 21.
+--------+--------+------------------+ +--------+--------+------------------+
| Kind | Len=6 | nonce | | Kind | Len=6 | nonce |
+--------+--------+------------------+ +--------+--------+------------------+
1 byte 1 byte 4 bytes 1 byte 1 byte 4 bytes
Figure 20 UDP REQ and RES options format Figure 21 UDP REQ and RES options format
6.1. Experimental (EXP) 6.1. Experimental (EXP)
The Experimental option (EXP) is reserved for experiments [RFC3692]. The Experimental option (EXP) is reserved for experiments [RFC3692].
It uses a Kind value of 254. Only one such value is reserved because It uses a Kind value of 254. Only one such value is reserved because
experiments are expected to use an Experimental ID (ExIDs) to experiments are expected to use an Experimental ID (ExIDs) to
differentiate concurrent use for different purposes, using UDP ExIDs differentiate concurrent use for different purposes, using UDP ExIDs
registered with IANA according to the approach developed for TCP registered with IANA according to the approach developed for TCP
experimental options [RFC6994]. experimental options [RFC6994].
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind=254 | Len | UDP ExID | | Kind=254 | Len | UDP ExID |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| (option contents, as defined)... | | (option contents, as defined)... |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Figure 21 UDP EXP option format Figure 22 UDP EXP option format
>> The length of the experimental option MUST be at least 4 to >> The length of the experimental option MUST be at least 4 to
account for the Kind, Length, and the minimum 16-bit UDP ExID account for the Kind, Length, and the minimum 16-bit UDP ExID
identifier (similar to TCP ExIDs [RFC6994]). identifier (similar to TCP ExIDs [RFC6994]).
7. Rules for designing new options 7. Rules for designing new options
The UDP option Kind space allows for the definition of new options, The UDP option Kind space allows for the definition of new options,
however the currently defined options do not allow for arbitrary new however the currently defined options do not allow for arbitrary new
options. For example, LITE needs to come first if present; new options. For example, LITE needs to come first if present; new
skipping to change at page 20, line 44 skipping to change at page 21, line 44
>> At the sender, new options MUST NOT modify UDP packet content >> At the sender, new options MUST NOT modify UDP packet content
anywhere except within their option field; areas that need to remain anywhere except within their option field; areas that need to remain
unmodified include the IP header, IP options, the UDP body, the UDP unmodified include the IP header, IP options, the UDP body, the UDP
option area (i.e., other options), and the post-option area. option area (i.e., other options), and the post-option area.
>> Options MUST NOT be modified in transit. This includes those >> Options MUST NOT be modified in transit. This includes those
already defined as well as new options. New options MUST NOT require already defined as well as new options. New options MUST NOT require
or intend optionally for modification of any UDP options, including or intend optionally for modification of any UDP options, including
their new areas, in transit. their new areas, in transit.
>> New options with fixed lengths smaller than 255 or variable
lengths that are always smaller than 255 MUST use only the default
option format.
Note that only certain of the initially defined options violate Note that only certain of the initially defined options violate
these rules: these rules:
o >> LITE MUST be first, if present, and MUST be processed when o >> LITE MUST be first, if present, and MUST be processed when
encountered (e.g., even before security options). encountered (e.g., even before security options).
o >> LITE is the only option that modifies the UDP body or option o >> LITE is the only option that modifies the UDP body or option
areas. areas.
o >> OCS SHOULD be the first option, except in the presence of o >> OCS SHOULD be the first option, except in the presence of
skipping to change at page 28, line 28 skipping to change at page 29, line 28
Feb. 2019. Feb. 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC768] Postel, J., "User Datagram Protocol," RFC 768, August [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August
1980. 1980.
[RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
[RFC1071] Braden, R., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC 1071, Sep. 1988.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989. Communication Layers," RFC 1122, Oct. 1989.
[RFC1662] Simpson, W. Ed., "PPP in HDLC-like Framing," RFC 1662,
Oct. 1994.
19.2. Informative References 19.2. Informative References
[Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation
Options for UDP Options", draft-fairhurst-udp-options-cco, Options for UDP Options", draft-fairhurst-udp-options-cco,
Oct. 2018. Oct. 2018.
[Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User
Datagrams (SPUD) Prototype," draft-hildebrand-spud- Datagrams (SPUD) Prototype," draft-hildebrand-spud-
prototype-03, Mar. 2015. prototype-03, Mar. 2015.
skipping to change at page 29, line 14 skipping to change at page 30, line 8
[RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191,
November 1990. November 1990.
[RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140,
Apr. 1997. Apr. 1997.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC
2923, September 2000. 2923, September 2000.
[RFC3385] Sheinwald, D., J. Satran, P. Thaler, V. Cavanna, "Internet
Protocol Small Computer System Interface (iSCSI) Cyclic
Redundancy Check (CRC)/Checksum Considerations," RFC 3385,
Sep. 2002.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful," RFC 3692, Jan. 2004.
[RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.),
G. Fairhurst (Ed.), "The Lightweight User Datagram
Protocol (UDP-Lite)," RFC 3828, July 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, Dec. 2005. Internet Protocol", RFC 4301, Dec. 2005.
[RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006. Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful," RFC 3692, Jan. 2004.
[RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.),
G. Fairhurst (Ed.), "The Lightweight User Datagram
Protocol (UDP-Lite)," RFC 3828, July 2004.
[RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication
Option," RFC 5925, June 2010. Option," RFC 5925, June 2010.
[RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer
Security Version 1.2," RFC 6347, Jan. 2012. Security Version 1.2," RFC 6347, Jan. 2012.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS),"
RFC 6691, July 2012. RFC 6691, July 2012.
[RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT
skipping to change at page 30, line 9 skipping to change at page 31, line 9
(Ed.), "TCP Extensions for High Performance," RFC 7323, (Ed.), "TCP Extensions for High Performance," RFC 7323,
Sep. 2014. Sep. 2014.
[RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage
Guidelines," RFC 8085, Feb. 2017. Guidelines," RFC 8085, Feb. 2017.
[RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing
an IANA Considerations Section in RFCs," RFC 8126, June an IANA Considerations Section in RFCs," RFC 8126, June
2017. 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words," RFC 2119, May 2017.
[RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6
(IPv6) Specification," RFC 8200, Jul. 2017. (IPv6) Specification," RFC 8200, Jul. 2017.
[RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path
MTU Discovery for IP version 6," RFC 8201, Jul. 2017. MTU Discovery for IP version 6," RFC 8201, Jul. 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3," RFC 8446, Aug. 2018. Version 1.3," RFC 8446, Aug. 2018.
[To18ao] Touch, J., "A TCP Authentication Option Extension for [To18ao] Touch, J., "A TCP Authentication Option Extension for
skipping to change at page 31, line 5 skipping to change at page 32, line 5
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
Manhattan Beach, CA 90266 USA Manhattan Beach, CA 90266 USA
Phone: +1 (310) 560-0334 Phone: +1 (310) 560-0334
Email: touch@strayalpha.com Email: touch@strayalpha.com
Appendix A. Implementation Information Appendix A. Implementation Information
The following information is provided to encourage interoperable API The following information is provided to encourage interoperable API
implementations. implementations.
System-level variables (sysctl): System-level variables (sysctl):
Name default meaning Name default meaning
---------------------------------------------------- ----------------------------------------------------
net.ipv4.udp_opt 0 UDP options available net.ipv4.udp_opt 0 UDP options available
net.ipv4.udp_opt_ocs 1 Default include OCS net.ipv4.udp_opt_ocs 1 Default include OCS
 End of changes. 64 change blocks. 
140 lines changed or deleted 175 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/