draft-ietf-tsvwg-udp-options-03.txt   draft-ietf-tsvwg-udp-options-04.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Internet Draft
Intended status: Standards Track July 1, 2018 Intended status: Standards Track July 1, 2018
Intended updates: 768 Intended updates: 768
Expires: January 2019 Expires: January 2019
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-03.txt draft-ietf-tsvwg-udp-options-04.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 January 1, 2017. This Internet-Draft will expire on January 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 28 skipping to change at page 2, line 28
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).................................8
5.2. No Operation (NOP)........................................9 5.2. No Operation (NOP)........................................9
5.3. Option Checksum (OCS).....................................9 5.3. Option Checksum (OCS).....................................9
5.4. Alternate Checksum (ACS).................................10 5.4. Alternate Checksum (ACS).................................10
5.5. Lite (LITE)..............................................11 5.5. Lite (LITE)..............................................11
5.6. Maximum Segment Size (MSS)...............................13 5.6. Maximum Segment Size (MSS)...............................13
5.7. Timestamps (TIME)........................................13 5.7. Fragmentation (FRAG).....................................14
5.8. Fragmentation (FRAG).....................................14 5.7.1. Coupling FRAG with LITE.............................16
5.8.1. Coupling FRAG with LITE.............................16 5.8. Timestamps (TIME)........................................17
5.9. Authentication and Encryption (AE).......................17 5.9. Authentication and Encryption (AE).......................17
5.10. Experimental (EXP)......................................18 5.10. Experimental (EXP)......................................18
6. UDP API Extensions............................................18 6. UDP API Extensions............................................19
7. Whose options are these?......................................19 7. Whose options are these?......................................19
8. UDP options vs. UDP-Lite......................................19 8. UDP options LITE option vs. UDP-Lite..........................20
9. Interactions with Legacy Devices..............................20 9. Interactions with Legacy Devices..............................21
10. Options in a Stateless, Unreliable Transport Protocol........21 10. Options in a Stateless, Unreliable Transport Protocol........21
11. UDP Option State Caching.....................................21 11. UDP Option State Caching.....................................22
12. Multicast Considerations.....................................22 12. Updates to RFC 768...........................................22
13. Security Considerations......................................22 13. Multicast Considerations.....................................22
14. IANA Considerations..........................................22 14. Security Considerations......................................22
15. References...................................................23 15. IANA Considerations..........................................23
15.1. Normative References....................................23 16. References...................................................24
15.2. Informative References..................................23 16.1. Normative References....................................24
16. Acknowledgments..............................................25 16.2. Informative References..................................24
Appendix A. Implementation Information...........................27 17. Acknowledgments..............................................26
Appendix A. Implementation Information...........................28
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 experimental extension to UDP that provides
space for transport options including their generic syntax and space for transport options including their generic syntax and
semantics for their use in UDP's stateless, unreliable message semantics for their use in UDP's stateless, unreliable message
protocol. protocol.
skipping to change at page 7, line 27 skipping to change at page 7, line 27
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* 2 Option checksum (OCS)
3* 4 Alternate checksum (ACS) 3* 4 Alternate checksum (ACS)
4* 4 Lite (LITE) 4* 4 Lite (LITE)
5* 8/10 Fragmentation (FRAG) 5* 4 Maximum segment size (MSS)
6* 4 Maximum segment size (MSS) 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-126 (varies) UNASSIGNED (assignable by IANA) 9-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. These options are defined in the following subsections.
>> 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 11, line 27 skipping to change at page 11, line 27
LITE is intended to support the same API as for UDP Lite to allow LITE is intended to support the same API as for UDP Lite to allow
applications to send and receive data that has a marker indicating applications to send and receive data that has a marker indicating
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=5 | Len=4 | Offset | | Kind=4 | Len=4 | Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 9 UDP LITE option format Figure 9 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). 10).
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
skipping to change at page 12, line 45 skipping to change at page 13, line 6
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.
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 swap the four bytes there with start of the LITE data area and (if the LITE offset indicates a
the four bytes at the location indicated inside the LITE option, LITE data length of at least 4 bytes) swap the four bytes there
which indicates the start of all of the options, including the with the four bytes at the location indicated inside the LITE
LITE one (one past the end of the lite data area). This restores option, which indicates the start of all of the options,
the format of the option as per Figure 10. 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
slide the LITE option forward that amount and slide the
corresponding bytes after the LITE option to where the LITE
option originally began. In either case, this restores the format
of the option as it was prior to being sent, as per Figure 10.
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 11.
The purpose of this swap is to support the equivalent of UDP Lite The purpose of this swap (or slide) is to support the equivalent of
operation together with other UDP options without requiring the UDP Lite operation together with other UDP options without requiring
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) is a 16-bit indicator of
the largest UDP segment that can be received. As with the TCP MSS the largest UDP segment that can be received. As with the TCP MSS
option [RFC793], the size indicated is the IP layer MTU decreased by option [RFC793], the size indicated is the IP layer MTU decreased by
the fixed IP and UDP headers only [RFC6691]. The space needed for IP the 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 and UDP options need to be adjusted by the sender when using the
value indicated. The value transmitted is based on EMTU_R, the value indicated. The value transmitted is based on EMTU_R, the
largest IP datagram that can be received (i.e., reassembled at the largest IP datagram that can be received (i.e., reassembled at the
skipping to change at page 13, line 37 skipping to change at page 14, line 5
Figure 13 UDP MSS option format Figure 13 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. Timestamps (TIME) 5.7. Fragmentation (FRAG)
The UDP Timestamp option (TIME) exchanges two four-byte timestamp
fields. It serves a similar purpose to TCP's TS option [RFC7323],
enabling UDP to estimate the round trip time (RTT) between hosts.
For UDP, this RTT can be useful for establishing UDP fragment
reassembly timeouts or transport-layer rate-limiting [RFC8085].
+--------+--------+------------------+------------------+
| Kind=6 | Len=10 | TS Value | TS Echo Reply |
+--------+--------+------------------+------------------+
1 byte 1 byte 4 bytes 4 bytes
Figure 14 UDP TIME option format
TS Value (TSval) and TS Echo (TSecr) are used in a similar manner to
the TCP TS option [RFC7323]. A host using the Timestamp option sets
TS Value on all UDP segments issued. Received TSval values are
provided to the application, which passes this value as TSecr on UDP
messages sent in response to such a message.
>> UDP MAY use an RTT estimate based on nonzero Timestamp values as
a hint for fragmentation reassembly, rate limiting, or other
mechanisms that benefit from such an estimate.
>> UDP SHOULD make this RTT estimate available to the user
application.
5.8. Fragmentation (FRAG)
The Fragmentation option (FRAG) supports UDP fragmentation and The Fragmentation option (FRAG) 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=8 | Len=8 | Frag. Offset | | Kind=6 | Len=8 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 15 UDP non-terminal FRAG option format Figure 14 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 16. shown in Figure 15.
>> 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=8 | Len=12 | Frag. Offset | | Kind=6 | Len=10 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Checksum | | Checksum |
+--------+--------+ +--------+--------+
Figure 16 UDP terminal FRAG option format Figure 15 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 15, line 38 skipping to change at page 15, line 22
>> The Identification field is a 32-bit value that MUST be unique >> The Identification field is a 32-bit value that MUST be unique
over the expected fragment reassembly timeout. over the expected fragment reassembly timeout.
>> The Identification field SHOULD be generated in a manner similar >> The Identification field SHOULD be generated in a manner similar
to that of the IPv6 Fragment ID [RFC8200]. to that of the IPv6 Fragment ID [RFC8200].
>> UDP fragments MUST NOT overlap. >> UDP fragments MUST NOT overlap.
FRAG needs to be used with extreme care because it will present FRAG needs to be used with extreme care because it will present
incorrect datagram boundaries to a legacy receiver, unless encoded incorrect datagram boundaries to a legacy receiver, unless encoded
as LITE data (see Section 5.8.1). as LITE data (see Section 5.7.1).
>> A host SHOULD indicate FRAG support by transmitting an >> A host SHOULD indicate FRAG support by transmitting an
unfragmented datagram using the Fragmentation option (e.g., with unfragmented datagram using the Fragmentation option (e.g., with
Offset zero and length 12, i.e., including the checksum area), Offset zero and length 12, i.e., including the checksum area),
except when encoded as LITE. except when encoded as LITE.
>> A host MUST NOT transmit a UDP fragment before receiving recent >> A host MUST NOT transmit a UDP fragment before receiving recent
confirmation from the remote host, except when FRAG is encoded as confirmation from the remote host, except when FRAG is encoded as
LITE. LITE.
skipping to change at page 16, line 31 skipping to change at page 16, line 17
Any additional UDP options would follow the FRAG option in the final Any additional UDP options would follow the FRAG option in the final
fragment, and would be included in the reassembled packet. fragment, and would be included in the reassembled packet.
Processing of those options would commence after reassembly. Processing of those options would commence after reassembly.
>> UDP options MUST NOT follow the FRAG header in non-terminal >> UDP options MUST NOT follow the FRAG header in non-terminal
fragments. Any data following the FRAG header in non-terminal fragments. Any data following the FRAG header in non-terminal
fragments MUST be silently dropped. All other options that apply to fragments MUST be silently dropped. All other options that apply to
a reassembled packet MUST follow the FRAG header in the terminal a reassembled packet MUST follow the FRAG header in the terminal
fragment. fragment.
5.8.1. Coupling FRAG with LITE 5.7.1. 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-payload packets, which would not affect the interpret these as zero-payload packets, which would not affect the
receiver unless the presence of the packet itself were a signal. The receiver unless the presence of the packet itself were a signal. The
header of such a packet would appear as shown in Figure 17 and header of such a packet would appear as shown in Figure 16 and
Figure 18. Figure 17.
+---------+--------------+---------+ +---------+--------------+---------+
| UDP Hdr | LiteFrag |LITE|FRAG| | UDP Hdr | LiteFrag |LITE|FRAG|
+---------+--------------+----+----+ +---------+--------------+----+----+
<-------> ^^^^ ^^^^ <-------> ^^^^ ^^^^
Zero UDP Length | | Zero UDP Length | |
+--------------+ +--------------+
Figure 17 Preparing FRAG as Lite data Figure 16 Preparing FRAG as Lite data
+---------+--------------+----+ +---------+--------------+----+
| UDP Hdr |LITE|LiteFrag |FRAG| | UDP Hdr |LITE|LiteFrag |FRAG|
+---------+--------------+----+ +---------+--------------+----+
<-------> | ^ <-------> | ^
Zero UDP Length | | Zero UDP Length | |
+-------------+ +-------------+
Figure 18 Lite option before transmission Figure 17 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.8. Timestamps (TIME)
The UDP Timestamp option (TIME) exchanges two four-byte timestamp
fields. It serves a similar purpose to TCP's TS option [RFC7323],
enabling UDP to estimate the round trip time (RTT) between hosts.
For UDP, this RTT can be useful for establishing UDP fragment
reassembly timeouts or transport-layer rate-limiting [RFC8085].
+--------+--------+------------------+------------------+
| Kind=7 | Len=10 | TS Value | TS Echo Reply |
+--------+--------+------------------+------------------+
1 byte 1 byte 4 bytes 4 bytes
Figure 18 UDP TIME option format
TS Value (TSval) and TS Echo (TSecr) are used in a similar manner to
the TCP TS option [RFC7323]. A host using the Timestamp option sets
TS Value on all UDP segments issued. Received TSval values are
provided to the application, which passes this value as TSecr on UDP
messages sent in response to such a message.
>> UDP MAY use an RTT estimate based on nonzero Timestamp values as
a hint for fragmentation reassembly, rate limiting, or other
mechanisms that benefit from such an estimate.
>> UDP SHOULD make this RTT estimate available to the user
application.
5.9. Authentication and Encryption (AE) 5.9. Authentication and Encryption (AE)
The Authentication and Encryption option (AE) is intended to allow The Authentication and Encryption option (AE) 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. UDP-AO specified for TCP-AO, except that it uses a Kind of 8. UDP-AO
supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP- supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP-
AO can also be extended to provide a similar encryption capability AO can also be extended to provide a similar encryption capability
as TCP-AO-ENC, in a similar manner [To18ao]. For these reasons, the as TCP-AO-ENC, in a similar manner [To18ao]. For these reasons, the
option is known as UDP-AE. option is known as UDP-AE.
+--------+--------+--------+--------+
| Kind=8 | Len | Digest... |
+--------+--------+--------+--------+
| Digest (con't)... |
+--------+--------+--------+--------+
Figure 19 UDP non-terminal FRAG option format
Like TCP-AO, UDP-AE is not negotiated in-band. Its use assumes both Like TCP-AO, UDP-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 UDP-AE's Key Derivation Function (KDF) uses (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses
zeroes as the value for both ISNs. This means that the UDP-AE reuses zeroes as the value for both ISNs. This means that the UDP-AE reuses
keys when socket pairs are reused, unlike TCP-AO. keys when socket pairs are reused, unlike TCP-AO.
skipping to change at page 18, line 11 skipping to change at page 18, line 31
as supported, e.g., if they were to contain other hashes or as supported, e.g., if they were to contain other hashes or
checksums that depend on the option area contents. This is why such checksums that depend on the option area contents. This is why such
dependencies are not permitted except as defined for OCS and UDP-AE. dependencies are not permitted except as defined for OCS and UDP-AE.
Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT Similar to TCP-AO-NAT, UDP-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].
5.10. Experimental (EXP) 5.10. Experimental (EXP)
The Experimental option (EXP) is reserved for experiments [RFC3692]. The Experimental option (EXP) is reserved for experiments [RFC3692].
Only one such value is reserved because experiments are expected to It uses a Kind value of 254. Only one such value is reserved because
use an Experimental ID (ExIDs) to differentiate concurrent use for experiments are expected to use an Experimental ID (ExIDs) to
different purposes, using UDP ExIDs registered with IANA according differentiate concurrent use for different purposes, using UDP ExIDs
to the approach developed for TCP experimental options [RFC6994]. registered with IANA according to the approach developed for TCP
experimental options [RFC6994].
+----------+----------+----------+----------+
| Kind=254 | Len | UDP ExID |
+----------+----------+----------+----------+
| (option contents, as defined)... |
+----------+----------+----------+----------+
Figure 20 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]).
6. UDP API Extensions 6. UDP API Extensions
UDP currently specifies an application programmer interface (API), UDP currently specifies an application programmer interface (API),
summarized as follows (with Unix-style command as an example) summarized as follows (with Unix-style command as an example)
[RFC768]: [RFC768]:
 End of changes. 24 change blocks. 
72 lines changed or deleted 96 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/