draft-ietf-tsvwg-udp-options-01.txt   draft-ietf-tsvwg-udp-options-02.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft
Intended status: Standards Track June 27, 2017 Intended status: Standards Track January 19, 2018
Intended updates: 768 Intended updates: 768
Expires: December 2017 Expires: July 2018
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-01.txt draft-ietf-tsvwg-udp-options-02.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 December 27, 2017. This Internet-Draft will expire on July 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
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
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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
particular environments or in ways unforeseen by the original particular environments or in ways unforeseen by the original
designers. Examples include TCP's Maximum Segment Size, Window designers. Examples include TCP's Maximum Segment Size, Window
Scale, Timestamp, and Authentication Options Scale, Timestamp, and Authentication Options
[RFC793][RFC5925][RFC7323]. [RFC793][RFC5925][RFC7323].
These options are used both in stateful (connection-oriented, e.g., These options are used both in stateful (connection-oriented, e.g.,
TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless
(connectionless, e.g., IPv4 [RFC791], IPv6 [RFC2460] protocols. In (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC8200] protocols. In
stateful protocols they can help extend the way in which state is stateful protocols they can help extend the way in which state is
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) [Tr15], 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 experimentally extends UDP to provide a
trailer area for options located after the UDP data payload. trailer area for options located after the UDP data payload.
4. The UDP Option Area 4. The UDP Option Area
skipping to change at page 4, line 28 skipping to change at page 4, line 28
length (including IP header), and the size of the IP options is length (including IP header), and the size of the IP options is
indicated in the IP header (in 4-byte words) as the "Internet Header indicated in the IP header (in 4-byte words) as the "Internet Header
Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the
typical (and largest valid) value for UDP Length is: typical (and largest valid) value for UDP Length is:
UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4
For IPv6, the IP Payload Length field indicates the datagram after For IPv6, the IP Payload Length field indicates the datagram after
the base IPv6 header, which includes the IPv6 extension headers and the base IPv6 header, which includes the IPv6 extension headers and
space available for the transport protocol, as shown in Figure 2 space available for the transport protocol, as shown in Figure 2
[RFC2460]. Note that the Next HDR field in IPv6 might not indicate [RFC8200]. Note that the Next HDR field in IPv6 might not indicate
UDP (i.e., 17), e.g., when intervening IP extension headers are UDP (i.e., 17), e.g., when intervening IP extension headers are
present. For IPv6, the lengths of any additional IP extensions are present. For IPv6, the lengths of any additional IP extensions are
indicated within each extension [RFC2460], so the typical (and indicated within each extension [RFC8200], so the typical (and
largest valid) value for UDP Length is: largest valid) value for UDP Length is:
UDP_Length = IPv6_Payload_Length - sum(extension header lengths) UDP_Length = IPv6_Payload_Length - sum(extension header lengths)
In both cases, the space available for the UDP transport protocol In both cases, the space available for the UDP transport protocol
data unit is indicated by IP, either completely in the base header data unit is indicated by IP, either completely in the base header
(for IPv4) or adding information in the extensions (for IPv6). In (for IPv4) or adding information in the extensions (for IPv6). In
either case, this document will refer to this available space as the either case, this document will refer to this available space as the
"IP transport payload". "IP transport payload".
skipping to change at page 13, line 12 skipping to change at page 13, line 12
largest IP datagram that can be received (i.e., reassembled at the largest IP datagram that can be received (i.e., reassembled at the
receiver) [RFC1122]. receiver) [RFC1122].
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=5 | Len=4 | MSS size | | Kind=5 | Len=4 | MSS size |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
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][RFC1981], 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 [RFC2460]). [RFC791] and 1500 for IPv6 [RFC8200]).
5.7. Timestamps (TIME) 5.7. Timestamps (TIME)
The UDP Timestamp option (TIME) exchanges two four-byte timestamp The UDP Timestamp option (TIME) 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].
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
skipping to change at page 14, line 6 skipping to change at page 14, line 6
>> UDP SHOULD make this RTT estimate available to the user >> UDP SHOULD make this RTT estimate available to the user
application. application.
5.8. Fragmentation (FRAG) 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 [RFC2460], 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=8 | Len=8 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 14, line 29 skipping to change at page 14, line 29
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, 12-byte variant, which includes an is indicated as a longer, 12-byte variant, which includes an
Internet checksum over the reassembled payload (omitting the IP Internet checksum over the reassembled payload (omitting the IP
pseudoheader and UDP header, as well as UDP options), as shown in pseudoheader and UDP header, as well as UDP options), as shown in
Figure 16. 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
[RFC2460]), 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=8 | Len=12 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Checksum | | Checksum |
+--------+--------+ +--------+--------+
Figure 16 UDP terminal FRAG option format Figure 16 UDP terminal FRAG option format
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
payload fragment in bytes from the beginning of the original payload fragment in bytes from the beginning of the original
unfragmented payload. The Len field indicates whether there are more unfragmented payload. The Len field indicates whether there are more
fragments (Len=8) or no more fragments (Len=12). fragments (Len=8) or no more fragments (Len=12).
>> 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 [RFC2460]. 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.8.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),
skipping to change at page 16, line 47 skipping to change at page 16, line 47
continues, as with the non-LITE FRAG variant. continues, as with the non-LITE FRAG variant.
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 [To17ao]. 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.
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
skipping to change at page 21, line 11 skipping to change at page 21, line 11
The above requirements prevent using any option that cannot be The above requirements prevent using any option that cannot be
safely ignored unless that capability has been negotiated with an safely ignored unless that capability has been negotiated with an
endpoint in advance for a socket pair. Legacy systems would need to endpoint in advance for a socket pair. Legacy systems would need to
be able to interpret the transport payload fragments as individual be able to interpret the transport payload fragments as individual
transport datagrams. transport datagrams.
11. UDP Option State Caching 11. UDP Option State Caching
Some TCP connection parameters, stored in the TCP Control Block, can Some TCP connection parameters, stored in the TCP Control Block, can
be usefully shared either among concurrent connections or between be usefully shared either among concurrent connections or between
connections in sequence, known as TCP Sharing [RFC2140][To17cb]. connections in sequence, known as TCP Sharing [RFC2140][To18cb].
Although UDP is stateless, some of the options proposed herein may Although UDP is stateless, some of the options proposed herein may
have similar benefit in being shared or cached. We call this UCB have similar benefit in being shared or cached. We call this UCB
Sharing, or UDP Control Block Sharing, by analogy. Sharing, or UDP Control Block Sharing, by analogy.
[TBD: extend this section to indicate which options MAY vs. MUST NOT [TBD: extend this section to indicate which options MAY vs. MUST NOT
be shared and how, e.g., along the lines of To17cb] be shared and how, e.g., along the lines of To18cb]
Updates to RFC 768 Updates to RFC 768
This document updates RFC 768 as follows: This document updates RFC 768 as follows:
o This document defines the meaning of the IP payload area beyond o This document defines the meaning of the IP payload area beyond
the UDP length but within the IP length. the UDP length but within the IP length.
o This document extends the UDP API to support the use of options. o This document extends the UDP API to support the use of options.
skipping to change at page 23, line 20 skipping to change at page 23, line 20
[RFC793] Postel, J., "Transmission Control Protocol" RFC 793, [RFC793] Postel, J., "Transmission Control Protocol" RFC 793,
September 1981. September 1981.
[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.
[RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191,
November 1990. November 1990.
[RFC1981] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery for
IP version 6," RFC 1981, Aug. 1996.
[RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140,
Apr. 1997. Apr. 1997.
[RFC2460] Deering, S., R. Hinden, "Internet Protocol Version 6
(IPv6) Specification," RFC 2460, Dec. 1998.
[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.
[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",
skipping to change at page 24, line 31 skipping to change at page 24, line 25
(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.
[To17ao] Touch, J., "A TCP Authentication Option Extension for [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6
Payload Encryption", draft-touch-tcp-ao-encrypt, Apr. (IPv6) Specification," RFC 8200, Jul. 2017.
2017.
[To17cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path
Interdependence," draft-touch-tcpm-2140bis, Jan. 2017. MTU Discovery for IP version 6," RFC 8201, Jul. 2017.
[Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for [To18ao] Touch, J., "A TCP Authentication Option Extension for
Payload Encryption", draft-touch-tcp-ao-encrypt, Jan.
2018.
[To18cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block
Interdependence," draft-touch-tcpm-2140bis, Jan. 2018.
[Tr16] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for
the design of a Substrate Protocol for User Datagrams the design of a Substrate Protocol for User Datagrams
(SPUD)," draft-trammell-spud-req-04, May 2016. (SPUD)," draft-trammell-spud-req-04, May 2016.
16. Acknowledgments 16. Acknowledgments
This work benefitted from feedback from Bob Briscoe, Ken Calvert, This work benefitted from feedback from Bob Briscoe, Ken Calvert,
Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE
combination), Tom Herbert, and Mark Smith, as well as discussions on combination), Tom Herbert, and Mark Smith, as well as discussions on
the IETF TSVWG and SPUD email lists. the IETF TSVWG and SPUD email lists.
This work is partly supported by USC/ISI's Postel Center. This work is 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
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292 USA
Phone: +1 (310) 448-9151 Manhattan Beach, CA 90266 USA
Email: touch@isi.edu
Appendix A. Implementation Information Phone: +1 (310) 560-0334
Email: touch@strayalpha.com
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. 25 change blocks. 
36 lines changed or deleted 35 lines changed or added

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