| < draft-ietf-tsvwg-udp-options-17.txt | draft-ietf-tsvwg-udp-options-18.txt > | |||
|---|---|---|---|---|
| TSVWG J. Touch | TSVWG J. Touch | |||
| Internet Draft Independent Consultant | Internet Draft Independent Consultant | |||
| Intended status: Standards Track March 24, 2022 | Intended status: Standards Track March 26, 2022 | |||
| Intended updates: 768 | Intended updates: 768 | |||
| Expires: September 2022 | Expires: September 2022 | |||
| Transport Options for UDP | Transport Options for UDP | |||
| draft-ietf-tsvwg-udp-options-17.txt | draft-ietf-tsvwg-udp-options-18.txt | |||
| 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 extends UDP by indicating the location, | options. This document extends UDP by indicating the location, | |||
| syntax, and semantics for UDP transport layer options. | syntax, and semantics for UDP transport layer options. | |||
| 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 | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| 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 | |||
| https://www.ietf.org/shadow.html | https://www.ietf.org/shadow.html | |||
| Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
| 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." | |||
| This Internet-Draft will expire on September 24, 2022. | This Internet-Draft will expire on September 26, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| 3. Terminology....................................................3 | 3. Terminology....................................................3 | |||
| 4. Background.....................................................4 | 4. Background.....................................................4 | |||
| 5. The UDP Option Area............................................5 | 5. The UDP Option Area............................................5 | |||
| 6. The UDP Surplus Area Structure.................................8 | 6. The UDP Surplus Area Structure.................................8 | |||
| 7. The Option Checksum (OCS)......................................8 | 7. The Option Checksum (OCS)......................................8 | |||
| 8. UDP Options...................................................10 | 8. UDP Options...................................................10 | |||
| 9. Safe UDP Options..............................................13 | 9. Safe UDP Options..............................................13 | |||
| 9.1. End of Options List (EOL)................................13 | 9.1. End of Options List (EOL)................................13 | |||
| 9.2. No Operation (NOP).......................................14 | 9.2. No Operation (NOP).......................................14 | |||
| 9.3. Alternate Payload Checksum (APC).........................14 | 9.3. Alternate Payload Checksum (APC).........................14 | |||
| 9.4. Fragmentation (FRAG).....................................15 | 9.4. Fragmentation (FRAG).....................................16 | |||
| 9.5. Maximum Datagram Size (MDS)..............................19 | 9.5. Maximum Datagram Size (MDS)..............................19 | |||
| 9.6. Maximum Reassembled Datagram Size (MRDS).................20 | 9.6. Maximum Reassembled Datagram Size (MRDS).................20 | |||
| 9.7. Echo request (REQ) and echo response (RES)...............21 | 9.7. Echo request (REQ) and echo response (RES)...............21 | |||
| 9.8. Timestamps (TIME)........................................21 | 9.8. Timestamps (TIME)........................................21 | |||
| 9.9. Authentication (AUTH)....................................22 | 9.9. Authentication (AUTH)....................................22 | |||
| 9.10. Experimental (EXP)......................................23 | 9.10. Experimental (EXP)......................................23 | |||
| 10. UNSAFE Options...............................................24 | 10. UNSAFE Options...............................................24 | |||
| 10.1. UNSAFE Encryption (UENC)................................25 | 10.1. UNSAFE Encryption (UENC)................................25 | |||
| 10.2. UNSAFE Experimental (UEXP)..............................25 | 10.2. UNSAFE Experimental (UEXP)..............................25 | |||
| 11. Rules for designing new options..............................25 | 11. Rules for designing new options..............................25 | |||
| skipping to change at page 11, line 29 ¶ | skipping to change at page 11, line 29 ¶ | |||
| 7* 6 Response (RES) | 7* 6 Response (RES) | |||
| 8 10 Timestamps (TIME) | 8 10 Timestamps (TIME) | |||
| 9 (varies) Authentication (AUTH) | 9 (varies) Authentication (AUTH) | |||
| 10-126 (varies) UNASSIGNED (assignable by IANA) | 10-126 (varies) UNASSIGNED (assignable by IANA) | |||
| 127 (varies) RFC 3692-style experiments (EXP) | 127 (varies) RFC 3692-style experiments (EXP) | |||
| 128-191 RESERVED | 128-191 RESERVED | |||
| 192 (varies) Encryption (UENC) | 192 (varies) Encryption (UENC) | |||
| 193-253 UNASSIGNED-UNSAFE (assignable by IANA) | 193-253 UNASSIGNED-UNSAFE (assignable by IANA) | |||
| 254 (varies) RFC 3692-style experiments (UEXP) | 254 (varies) RFC 3692-style experiments (UEXP) | |||
| 255 RESERVED-UNSAFE | 255 RESERVED | |||
| Options indicated by Kind values in the range 0..191 are known as | Options indicated by Kind values in the range 0..127 are known as | |||
| SAFE options because they do not alter the UDP data payload and thus | SAFE options because they do not alter the UDP data payload and thus | |||
| do not interfere with use of that data by legacy endpoints. Options | do not interfere with use of that data by legacy endpoints. Options | |||
| indicated by Kind values in the range 192..254 are known as UNSAFE | indicated by Kind values in the range 192..254 are known as UNSAFE | |||
| options because they do alter the UDP data payload and thus would | options because they do alter the UDP data payload and thus would | |||
| interfere with legacy endpoints. UNSAFE option nicknames are | interfere with legacy endpoints. UNSAFE option nicknames are | |||
| expected to begin with "U", which should be avoided for safe option | expected to begin with "U", which should be avoided for safe option | |||
| nicknames (see Section 23). | nicknames (see Section 23). Kind values 128-191 and 255 are RESERVED | |||
| and not otherwise defined at this time. | ||||
| >> RESERVED Kind values MUST NOT be assumed to be either SAFE nor | ||||
| UNSAFE until defined. | ||||
| Although the FRAG option modifies the original UDP payload contents | Although the FRAG option modifies the original UDP payload contents | |||
| (i.e., is UNSAFE with respect to the original UDP payload), it is | (i.e., is UNSAFE with respect to the original UDP payload), it is | |||
| used only in subsequent fragments with zero UDP payloads, thus is | used only in subsequent fragments with zero UDP payloads, thus is | |||
| SAFE in actual use, as discussed further in Section 9.4. | SAFE in actual use, as discussed further in Section 9.4. | |||
| 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 | |||
| skipping to change at page 13, line 33 ¶ | skipping to change at page 13, line 38 ¶ | |||
| 9. Safe UDP Options | 9. Safe UDP Options | |||
| Safe UDP options can be silently ignored by legacy receivers without | Safe UDP options can be silently ignored by legacy receivers without | |||
| affecting the meaning of the UDP user data. They stand in contrast | affecting the meaning of the UDP user data. They stand in contrast | |||
| to Unsafe options, which modify UDP user data in ways that render it | to Unsafe options, which modify UDP user data in ways that render it | |||
| unusable by legacy receivers (Section 10). The following subsections | unusable by legacy receivers (Section 10). The following subsections | |||
| describe safe options defined in this document. | describe safe options defined in this document. | |||
| 9.1. End of Options List (EOL) | 9.1. End of Options List (EOL) | |||
| The End of Options List (EOL) option indicates that there are no | The End of Options List (EOL, Kind=0) option indicates that there | |||
| more options. It is used to indicate the end of the list of options | are no more options. It is used to indicate the end of the list of | |||
| without needing to use NOP options (see the following section) as | options without needing to use NOP options (see the following | |||
| padding to fill all available option space. | section) as padding to fill all available option space. | |||
| +--------+ | +--------+ | |||
| | Kind=0 | | | Kind=0 | | |||
| +--------+ | +--------+ | |||
| Figure 7 UDP EOL option format | Figure 7 UDP EOL option format | |||
| >> When the UDP options do not consume the entire surplus area, the | >> When the UDP options do not consume the entire surplus area, the | |||
| last non-NOP option MUST be EOL. | last non-NOP option MUST be EOL. | |||
| skipping to change at page 14, line 21 ¶ | skipping to change at page 14, line 24 ¶ | |||
| Requiring the post-option surplus area to be zero prevents side- | Requiring the post-option surplus area to be zero prevents side- | |||
| channel uses of this area, requiring instead that all use of the | channel uses of this area, requiring instead that all use of the | |||
| surplus area be UDP options supported by both endpoints. It is | surplus area be UDP options supported by both endpoints. It is | |||
| useful to allow this area to be used for zero padding to increase | useful to allow this area to be used for zero padding to increase | |||
| the UDP datagram length without affecting the UDP user data length, | the UDP datagram length without affecting the UDP user data length, | |||
| e.g., for UDP DPLPMTUD (Section 4.1 of [Fa22]). | e.g., for UDP DPLPMTUD (Section 4.1 of [Fa22]). | |||
| 9.2. No Operation (NOP) | 9.2. No Operation (NOP) | |||
| The No Operation (NOP) option is a one-byte placeholder, intended to | The No Operation (NOP, Kind=1) option is a one-byte placeholder, | |||
| be used as padding, e.g., to align multi-byte options along 16-bit, | intended to be used as padding, e.g., to align multi-byte options | |||
| 32-bit, or 64-bit boundaries boundaries. | along 16-bit, 32-bit, or 64-bit boundaries. | |||
| +--------+ | +--------+ | |||
| | Kind=1 | | | Kind=1 | | |||
| +--------+ | +--------+ | |||
| Figure 8 UDP NOP option format | Figure 8 UDP NOP option format | |||
| >> UDP packets SHOULD NOT use more than seven consecutive NOPs, | >> UDP packets SHOULD NOT use more than seven consecutive NOPs, | |||
| i.e., to support alignment up to 8-byte boundaries. UDP packets | i.e., to support alignment up to 8-byte boundaries. UDP packets | |||
| SHOULD NOT use NOPs at the end of the options area as a substitute | SHOULD NOT use NOPs at the end of the options area as a substitute | |||
| for EOL followed by zero-fill. NOPs are intended to assist with | for EOL followed by zero-fill. NOPs are intended to assist with | |||
| alignment, not as other padding or fill. | alignment, not as other padding or fill. | |||
| This issue is discussed further in Section 22. | This issue is discussed further in Section 22. | |||
| 9.3. Alternate Payload Checksum (APC) | 9.3. Alternate Payload Checksum (APC) | |||
| The Alternate Payload Checksum (APC) option provides a stronger | The Alternate Payload Checksum (APC, Kind=2) option provides a | |||
| alternative to the checksum in the UDP header, using a 32-bit CRC of | stronger alternative to the checksum in the UDP header, using a 32- | |||
| the conventional UDP user data payload only (excluding the IP | bit CRC of the conventional UDP user data payload only (excluding | |||
| pseudoheader, UDP header, and surplus area). It is an "alternate" to | the IP pseudoheader, UDP header, and surplus area). It is an | |||
| the UDP checksum that covers the user data - not to the OCS (the | "alternate" to the UDP checksum that covers the user data - not to | |||
| latter covers the surplus area only). Unlike the UDP checksum, APC | the OCS (the latter covers the surplus area only). Unlike the UDP | |||
| does not include the IP pseudoheader or UDP header, thus it does not | checksum, APC does not include the IP pseudoheader or UDP header, | |||
| need to be updated by NATs when IP addresses or UDP ports are | thus it does not need to be updated by NATs when IP addresses or UDP | |||
| rewritten. Its purpose is to detect user data errors that the UDP | ports are rewritten. Its purpose is to detect user data errors that | |||
| checksum, when used, might not detect. | the UDP checksum, when used, might not detect. | |||
| A CRC32c has been chosen because of its ubiquity and use in other | A CRC32c has been chosen because of its ubiquity and use in other | |||
| Internet protocols, including iSCSI and SCTP. The option contains | Internet protocols, including iSCSI and SCTP. The option contains | |||
| the CRC32c in network standard byte order, as described in | the CRC32c in network standard byte order, as described in | |||
| [RFC3385]. | [RFC3385]. | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | Kind=2 | Len=6 | CRC32c... | | | Kind=2 | Len=6 | CRC32c... | | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | CRC32c (cont.) | | | CRC32c (cont.) | | |||
| skipping to change at page 15, line 48 ¶ | skipping to change at page 16, line 7 ¶ | |||
| unless overridden. | unless overridden. | |||
| >> UDP packets with unrecognized APC lengths MUST be receive the | >> UDP packets with unrecognized APC lengths MUST be receive the | |||
| same treatment as UDP packets with incorrect APC checksums. | same treatment as UDP packets with incorrect APC checksums. | |||
| Ensuring that unrecognized APC lengths are treated as incorrect | Ensuring that unrecognized APC lengths are treated as incorrect | |||
| checksums enables future variants of APC to be treated as APC-like. | checksums enables future variants of APC to be treated as APC-like. | |||
| 9.4. Fragmentation (FRAG) | 9.4. Fragmentation (FRAG) | |||
| The Fragmentation (FRAG) option supports UDP fragmentation and | The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation | |||
| reassembly, which can be used to transfer UDP messages larger than | and reassembly, which can be used to transfer UDP messages larger | |||
| limited by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes a | than limited by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes | |||
| copy of the same UDP transport ports in each fragment, enabling them | a copy of the same UDP transport ports in each fragment, enabling | |||
| to traverse Network Address (and port) Translation (NAT) devices, in | them to traverse Network Address (and port) Translation (NAT) | |||
| contrast to the behavior of IP fragments. FRAG is typically used | devices, in contrast to the behavior of IP fragments. FRAG is | |||
| with the UDP MDS and MRDS options to enable more efficient use of | typically used with the UDP MDS and MRDS options to enable more | |||
| large messages, both at the UDP and IP layers. FRAG is designed | efficient use of large messages, both at the UDP and IP layers. FRAG | |||
| similar to the IPv6 Fragmentation Header [RFC8200], except that the | is designed similar to the IPv6 Fragmentation Header [RFC8200], | |||
| UDP variant uses a 16-bit Offset measured in bytes, rather than | except that the UDP variant uses a 16-bit Offset measured in bytes, | |||
| IPv6's 13-bit Fragment Offset measured in 8-byte units. This UDP | rather than IPv6's 13-bit Fragment Offset measured in 8-byte units. | |||
| variant avoids creating reserved fields. | This UDP variant avoids creating reserved fields. | |||
| >> When FRAG is present, it SHOULD come as early as possible in the | >> When FRAG is present, it SHOULD come as early as possible in the | |||
| UDP options list. | UDP options list. | |||
| >> When FRAG is present, the UDP user data MUST be empty. If the | >> When FRAG is present, the UDP user data MUST be empty. If the | |||
| user data is not empty, all UDP options MUST be silently ignored and | user data is not empty, all UDP options MUST be silently ignored and | |||
| the user data received sent to the user. | the user data received sent to the user. | |||
| Legacy receivers interpret FRAG messages as zero-length user data | Legacy receivers interpret FRAG messages as zero-length user data | |||
| UDP packets (i.e., UDP Length field is 8, the length of just the UDP | UDP packets (i.e., UDP Length field is 8, the length of just the UDP | |||
| skipping to change at page 17, line 26 ¶ | skipping to change at page 17, line 30 ¶ | |||
| >> Endpoints supporting UDP options MUST be capable of fragmenting | >> Endpoints supporting UDP options MUST be capable of fragmenting | |||
| and reassembling at least 2 fragments, for a total of at least 3,000 | and reassembling at least 2 fragments, for a total of at least 3,000 | |||
| bytes (see MRDS in Section 9.6). | bytes (see MRDS in Section 9.6). | |||
| Use of the single fragment variant can be helpful in supporting use | Use of the single fragment variant can be helpful in supporting use | |||
| of UNSAFE options without undesirable impact to receivers that do | of UNSAFE options without undesirable impact to receivers that do | |||
| not support either UDP options or the specific UNSAFE options. | not support either UDP options or the specific UNSAFE options. | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | Kind=4 | Len=12 | Frag. Start | | | Kind=3 | Len=12 | Frag. Start | | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | Identification | | | Identification | | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | Frag. Offset | Dgram Opt Start | | | Frag. Offset | Dgram Opt Start | | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| Figure 11 UDP terminal FRAG option format | Figure 11 UDP terminal FRAG option format | |||
| The terminal FRAG option format adds a Datagram Option Start | The terminal FRAG option format adds a Datagram Option Start | |||
| pointer, measured from the start of the original UDP datagram | pointer, measured from the start of the original UDP datagram | |||
| skipping to change at page 19, line 46 ¶ | skipping to change at page 19, line 50 ¶ | |||
| 5. Process the pre-reassembly UDP options of each fragment. | 5. Process the pre-reassembly UDP options of each fragment. | |||
| Receivers reverse the above sequence. They process all received | Receivers reverse the above sequence. They process all received | |||
| options in each fragment. When the FRAG option is encountered, the | options in each fragment. When the FRAG option is encountered, the | |||
| FRAG data is used in reassembly. After all fragments are received, | FRAG data is used in reassembly. After all fragments are received, | |||
| the entire UDP packet is processed with any trailing UDP options | the entire UDP packet is processed with any trailing UDP options | |||
| applying to the reassembled user data. | applying to the reassembled user data. | |||
| 9.5. Maximum Datagram Size (MDS) | 9.5. Maximum Datagram Size (MDS) | |||
| The Maximum Datagram Size (MDS, Kind = 5) option is a 16-bit hint of | The Maximum Datagram Size (MDS, Kind=4) option is a 16-bit hint of | |||
| the largest unfragmented UDP packet that an endpoint believes can be | the largest unfragmented UDP packet that an endpoint believes can be | |||
| received. As with the TCP Maximum Segment Size (MSS) option | received. As with the TCP Maximum Segment Size (MSS) option | |||
| [RFC793], the size indicated is the IP layer MTU decreased by the | [RFC793], the size indicated is the IP layer MTU decreased by the | |||
| fixed IP and UDP headers only [RFC6691]. The space needed for IP and | fixed IP and UDP headers only [RFC6691]. The space needed for IP and | |||
| UDP options need to be adjusted by the sender when using the value | UDP options need to be adjusted by the sender when using the value | |||
| indicated. The value transmitted is based on EMTU_R, the largest IP | indicated. The value transmitted is based on EMTU_R, the largest IP | |||
| datagram that can be received (i.e., reassembled at the receiver) | datagram that can be received (i.e., reassembled at the receiver) | |||
| [RFC1122]. However, as with TCP, this value is only a hint at what | [RFC1122]. However, as with TCP, this value is only a hint at what | |||
| the receiver believes; it does not indicate a known path MTU and | the receiver believes; it does not indicate a known path MTU and | |||
| thus MUST NOT be used to limit transmissions. | thus MUST NOT be used to limit transmissions. | |||
| skipping to change at page 20, line 31 ¶ | skipping to change at page 20, line 34 ¶ | |||
| source fragmentation or UDP fragmentation to limit the largest | source fragmentation or UDP fragmentation to limit the largest | |||
| reassembled UDP message as indicated by MRDS (see Section 9.6), | reassembled UDP message as indicated by MRDS (see Section 9.6), | |||
| 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]). It can also be used with | [RFC791] and 1500 for IPv6 [RFC8200]). It can also be used with | |||
| DPLPMTUD [RFC8899] to provide a hint to maximum DPLPMTU, though it | DPLPMTUD [RFC8899] to provide a hint to maximum DPLPMTU, though it | |||
| MUST NOT prohibit transmission of larger UDP packets (or fragments) | MUST NOT prohibit transmission of larger UDP packets (or fragments) | |||
| used as DPLPMTU probes. | used as DPLPMTU probes. | |||
| 9.6. Maximum Reassembled Datagram Size (MRDS) | 9.6. Maximum Reassembled Datagram Size (MRDS) | |||
| The Maximum Reassembled Segment Size (MRDS, Kind=6) option is a 16- | The Maximum Reassembled Segment Size (MRDS, Kind=5) option is a 16- | |||
| bit indicator of the largest reassembled UDP segment that can be | bit indicator of the largest reassembled UDP segment that can be | |||
| received. MRDS is the UDP equivalent of IP's EMTU_R but the two are | received. MRDS is the UDP equivalent of IP's EMTU_R but the two are | |||
| not related [RFC1122]. Using the FRAG option (Section 9.4), UDP | not related [RFC1122]. Using the FRAG option (Section 9.4), UDP | |||
| packets can be transmitted as transport fragments, each in their own | packets can be transmitted as transport fragments, each in their own | |||
| (presumably not fragmented) IP datagram and be reassembled at the | (presumably not fragmented) IP datagram and be reassembled at the | |||
| UDP layer. | UDP layer. | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | Kind=5 | Len=4 | MRDS size | | | Kind=5 | Len=4 | MRDS size | | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| Figure 13 UDP MRDS option format | Figure 13 UDP MRDS option format | |||
| >> Endpoints supporting UDP options MUST support a local MRDS of at | >> Endpoints supporting UDP options MUST support a local MRDS of at | |||
| least 3,000 bytes. | least 3,000 bytes. | |||
| 9.7. Echo request (REQ) and echo response (RES) | 9.7. Echo request (REQ) and echo response (RES) | |||
| The echo request (REQ, kind=6) and echo response (RES, kind=7) | The echo request (REQ, Kind=6) and echo response (RES, Kind=7) | |||
| options provide a means for UDP options to be used to provide UDP | options provide a means for UDP options to be used to provide UDP | |||
| packet-level acknowledgements. One such use is described as part of | packet-level acknowledgements. One such use is described as part of | |||
| the UDP options variant of packetization layer path MTU discovery | the UDP options variant of packetization layer path MTU discovery | |||
| (PLPMTUD) [Fa22]. The options both have the format indicated in | (PLPMTUD) [Fa22]. The options both have the format indicated in | |||
| Figure 14, in which the token has no internal structure or meaning. | Figure 14, in which the token has no internal structure or meaning. | |||
| +--------+--------+------------------+ | +--------+--------+------------------+ | |||
| | Kind | Len=6 | token | | | Kind | Len=6 | token | | |||
| +--------+--------+------------------+ | +--------+--------+------------------+ | |||
| 1 byte 1 byte 4 bytes | 1 byte 1 byte 4 bytes | |||
| Figure 14 UDP REQ and RES options format | Figure 14 UDP REQ and RES options format | |||
| Each of these option kinds appears at most once in each UDP packet, | Each of these option kinds appears at most once in each UDP packet, | |||
| as with other options. Note also that the FRAG option is not used | as with other options. Note also that the FRAG option is not used | |||
| when sending DPLPMTUD probes to determine a PLPMTU [Fa22]. | when sending DPLPMTUD probes to determine a PLPMTU [Fa22]. | |||
| 9.8. Timestamps (TIME) | 9.8. Timestamps (TIME) | |||
| The Timestamp (TIME) option exchanges two four-byte unsigned | The Timestamp (TIME, Kind=8) option exchanges two four-byte unsigned | |||
| timestamp fields. It serves a similar purpose to TCP's TS option | timestamp fields. It serves a similar purpose to TCP's TS option | |||
| [RFC7323], enabling UDP to estimate the round trip time (RTT) | [RFC7323], enabling UDP to estimate the round trip time (RTT) | |||
| between hosts. For UDP, this RTT can be useful for establishing UDP | between hosts. For UDP, this RTT can be useful for establishing UDP | |||
| fragment reassembly timeouts or transport-layer rate-limiting | fragment reassembly timeouts or transport-layer rate-limiting | |||
| [RFC8085]. | [RFC8085]. | |||
| +--------+--------+------------------+------------------+ | +--------+--------+------------------+------------------+ | |||
| | Kind=8 | Len=10 | TSval | TSecr | | | Kind=8 | Len=10 | TSval | TSecr | | |||
| +--------+--------+------------------+------------------+ | +--------+--------+------------------+------------------+ | |||
| 1 byte 1 byte 4 bytes 4 bytes | 1 byte 1 byte 4 bytes 4 bytes | |||
| skipping to change at page 22, line 37 ¶ | skipping to change at page 22, line 37 ¶ | |||
| Rollover can be handled as a special case or more completely using | Rollover can be handled as a special case or more completely using | |||
| sequence number extension [RFC9187], however zero values need to be | sequence number extension [RFC9187], however zero values need to be | |||
| avoided explicitly. | avoided explicitly. | |||
| >> TIME values MUST NOT use zeros as valid time values, because they | >> TIME values MUST NOT use zeros as valid time values, because they | |||
| are used as indicators of requests and responses. | are used as indicators of requests and responses. | |||
| 9.9. Authentication (AUTH) | 9.9. Authentication (AUTH) | |||
| The Authentication (AUTH) option is intended to allow UDP to provide | The Authentication (AUTH, Kind=9) option is intended to allow UDP to | |||
| a similar type of authentication as the TCP Authentication Option | provide a similar type of authentication as the TCP Authentication | |||
| (TCP-AO) [RFC5925]. AUTH covers the UDP user data. It uses the same | Option (TCP-AO) [RFC5925]. AUTH covers the UDP user data. AUTH | |||
| format as specified for TCP-AO, except that it uses a Kind of 10. | supports NAT traversal in a similar manner as TCP-AO [RFC6978]. | |||
| AUTH supports NAT traversal in a similar manner as TCP-AO [RFC6978]. | ||||
| Figure 16 shows the UDP AUTH format, whose contents are identical to | Figure 16 shows the UDP AUTH format, whose contents are identical to | |||
| that of the TCP-AO option. | that of the TCP-AO option. | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | Kind=9 | Len | TCP-AO fields...| | | Kind=9 | Len | TCP-AO fields...| | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| | TCP-AO fields (con't)... | | | TCP-AO fields (con't)... | | |||
| +--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| Figure 16 UDP AUTH option format | Figure 16 UDP AUTH option format | |||
| skipping to change at page 23, line 41 ¶ | skipping to change at page 23, line 41 ¶ | |||
| were to contain other hashes or checksums that depend on the surplus | were to contain other hashes or checksums that depend on the surplus | |||
| area contents. This is why such dependencies are not permitted | area contents. This is why such dependencies are not permitted | |||
| except as defined for the OCS and the AUTH (and later, UENC) option. | except as defined for the OCS and the AUTH (and later, UENC) option. | |||
| Similar to TCP-AO-NAT, AUTH (and later, UENC) can be configured to | Similar to TCP-AO-NAT, AUTH (and later, UENC) can be configured to | |||
| support NAT traversal, excluding (by zeroing out) one or both of the | support NAT traversal, excluding (by zeroing out) one or both of the | |||
| UDP ports and corresponding IP addresses [RFC6978]. | UDP ports and corresponding IP addresses [RFC6978]. | |||
| 9.10. Experimental (EXP) | 9.10. Experimental (EXP) | |||
| The Experimental option (EXP) is reserved for experiments [RFC3692]. | The Experimental option (EXP, Kind=127) is reserved for experiments | |||
| It uses a Kind value of 127. Only one such value is reserved because | [RFC3692]. Only one such value is reserved because experiments are | |||
| experiments are expected to use an Experimental ID (ExIDs) to | expected to use an Experimental ID (ExIDs) to differentiate | |||
| differentiate concurrent use for different purposes, using UDP ExIDs | concurrent use for different purposes, using UDP ExIDs registered | |||
| registered with IANA according to the approach developed for TCP | with IANA according to the approach developed for TCP experimental | |||
| experimental options [RFC6994]. | options [RFC6994]. | |||
| +----------+----------+----------+----------+ | +----------+----------+----------+----------+ | |||
| | Kind=127 | Len | UDP ExID | | | Kind=127 | Len | UDP ExID | | |||
| +----------+----------+----------+----------+ | +----------+----------+----------+----------+ | |||
| | (option contents, as defined)... | | | (option contents, as defined)... | | |||
| +----------+----------+----------+----------+ | +----------+----------+----------+----------+ | |||
| Figure 17 UDP EXP option format | Figure 17 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 | |||
| skipping to change at page 25, line 10 ¶ | skipping to change at page 25, line 10 ¶ | |||
| either per-fragment or after reassembly. | either per-fragment or after reassembly. | |||
| >> Receivers supporting UDP options MUST silently drop the UDP user | >> Receivers supporting UDP options MUST silently drop the UDP user | |||
| data of the reassembled datagram if any fragment or the entire | data of the reassembled datagram if any fragment or the entire | |||
| datagram includes an UNSAFE option whose UKind is not supported. | datagram includes an UNSAFE option whose UKind is not supported. | |||
| Note that this still results in the receipt of a zero-length UDP | Note that this still results in the receipt of a zero-length UDP | |||
| datagram. | datagram. | |||
| 10.1. UNSAFE Encryption (UENC) | 10.1. UNSAFE Encryption (UENC) | |||
| UNSAFE encryption (UENC) has the same format as AUTH (Section 9.9), | UNSAFE encryption (UENC, Kind=192) has the same format as AUTH | |||
| except that it encrypts (modifies) the user data. It provides a | (Section 9.9), except that it encrypts (modifies) the user data. It | |||
| similar encryption capability as TCP-AO-ENC, in a similar manner | provides a similar encryption capability as TCP-AO-ENC, in a similar | |||
| [To18]. Its fields, coverage, and processing are the same as for | manner [To18]. Its fields, coverage, and processing are the same as | |||
| AUTH, except that UENC encrypts only the user data, although it can | for AUTH, except that UENC encrypts only the user data, although it | |||
| (optionally) depend on the surplus area (with certain fields zeroed, | can (optionally) depend on the surplus area (with certain fields | |||
| as per AUTH, e.g., providing authentication over the surplus area). | zeroed, as per AUTH, e.g., providing authentication over the surplus | |||
| Like AUTH, UENC can be configured to be compatible with NAT | area). Like AUTH, UENC can be configured to be compatible with NAT | |||
| traversal. | traversal. | |||
| 10.2. UNSAFE Experimental (UEXP) | 10.2. UNSAFE Experimental (UEXP) | |||
| The UNSAFE Experimental option (EXP) is reserved for experiments | The UNSAFE Experimental option (UEXP, Kind=254) is reserved for | |||
| [RFC3692]. It uses a Kind value of 254. Only one such value is | experiments [RFC3692]. As with EXP, only one such UEXP value is | |||
| reserved because experiments are expected to use an Experimental ID | reserved because experiments are expected to use an Experimental ID | |||
| (ExIDs) to differentiate concurrent use for different purposes, | (ExIDs) to differentiate concurrent use for different purposes, | |||
| using UDP ExIDs registered with IANA according to the approach | using UDP ExIDs registered with IANA according to the approach | |||
| developed for TCP experimental options [RFC6994]. | developed for TCP experimental options [RFC6994]. | |||
| Assigned ExIDs can be used with either the UEXP or EXP options. | Assigned ExIDs can be used with either the UEXP or EXP options. | |||
| 11. Rules for designing new options | 11. 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, | |||
| skipping to change at page 38, line 22 ¶ | skipping to change at page 38, line 22 ¶ | |||
| to Denial of Service,", Vulnerability Note VU 962459, | to Denial of Service,", Vulnerability Note VU 962459, | |||
| Software Engineering Institute, CMU, 2018, | Software Engineering Institute, CMU, 2018, | |||
| https://www.kb.cert.org/vuls/id/962459. | https://www.kb.cert.org/vuls/id/962459. | |||
| [To18] Touch, J., "A TCP Authentication Option Extension for | [To18] Touch, J., "A TCP Authentication Option Extension for | |||
| Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. | Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. | |||
| 2018. | 2018. | |||
| 25. Acknowledgments | 25. Acknowledgments | |||
| This work benefitted from feedback from Bob Briscoe, Ken Calvert, | This work benefitted from feedback from Erik Auerswald, Bob Briscoe, | |||
| Ted Faber, Gorry Fairhurst (including OCS for misbehaving middlebox | Ken Calvert, Ted Faber, Gorry Fairhurst (including OCS for | |||
| traversal), C. M. Heard (including combining previous FRAG and LITE | misbehaving middlebox traversal), C. M. Heard (including combining | |||
| options into the new FRAG), Tom Herbert, Mark Smith, and Raffaele | previous FRAG and LITE options into the new FRAG), Tom Herbert, Mark | |||
| Zullo, as well as discussions on the IETF TSVWG and SPUD email | Smith, and Raffaele Zullo, as well as discussions on the IETF TSVWG | |||
| lists. | and SPUD email lists. | |||
| This work was partly supported by USC/ISI's Postel Center. | This work was partly supported by USC/ISI's Postel Center. | |||
| 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 | |||
| End of changes. 21 change blocks. | ||||
| 68 lines changed or deleted | 71 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||