draft-ietf-taps-transports-usage-udp-06.txt   draft-ietf-taps-transports-usage-udp-07.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Intended status: Informational University of Aberdeen Intended status: Informational University of Aberdeen
Expires: March 5, 2018 September 1, 2017 Expires: March 23, 2018 September 19, 2017
Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite) Transport Protocols Lite) Transport Protocols
draft-ietf-taps-transports-usage-udp-06 draft-ietf-taps-transports-usage-udp-07
Abstract Abstract
This is an informational document that describes the transport This is an informational document that describes the transport
protocol interface primitives provided by the User Datagram Protocol protocol interface primitives provided by the User Datagram Protocol
(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport
protocols. It identifies the datagram services exposed to protocols. It identifies the datagram services exposed to
applications and how an application can configure and use the applications and how an application can configure and use the
features offered by the Internet datagram transport service. RFCxxxx features offered by the Internet datagram transport service. RFCxxxx
documents the usage of transport features provided by IETF transport documents the usage of transport features provided by IETF transport
skipping to change at page 1, line 40 skipping to change at page 1, line 40
both published XXX. both published XXX.
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. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 5, 2018. This Internet-Draft will expire on March 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . . 4 3. UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . . 4
3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . 4 3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . 4
3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 11 3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 11
3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 11 3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 11
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Multicast Primitives . . . . . . . . . . . . . . . . 16 Appendix A. Multicast Primitives . . . . . . . . . . . . . . . . 16
Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 19 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document presents defined interactions between transport This document presents defined interactions between transport
protocols and applications in the form of 'primitives' (function protocols and applications in the form of 'primitives' (function
calls) for the User Datagram Protocol (UDP) [RFC0768] and the calls) for the User Datagram Protocol (UDP) [RFC0768] and the
Lightweight User Datagram Protocol (UDP-Lite) [RFC3828]. In this Lightweight User Datagram Protocol (UDP-Lite) [RFC3828]. In this
usage, the word application refers to any program built on the usage, the word application refers to any program built on the
datagram interface, and including tunnels and other upper layer datagram interface, and including tunnels and other upper layer
protocols that use UDP and UDP-LIte. protocols that use UDP and UDP-LIte.
The de facto standard application programming interface (API) for UDP is widely implemented and deployed. It is used for a wide range
TCP/IP applications is the "socket" interface [POSIX]. An of applicatons. A special class of applications can derive benefit
application can use the recv() and send() POSIX functions as well as from having partially damaged payloads delivered, rather than
the recvfrom() and sendto() and recvmsg() and sendmsg() functions. discarded, when using paths that include error-prone links.
Applications that can tolerate payload corruption can choose to use
The UDP and UDP-Lite sockets API differs from that for TCP in several UDP-Lite instead of UDP and use the application programming interface
key ways. (Examples of usage of this API are provided in [STEVENS].) (API) to control checksum protection. Conversely, UDP applications
could choose to use UDP-Lite, but this is currently less widely
Additional functions in the sockets API are provided by socket deployed and users could encounter paths that do not support UDP-
options, examples include: LIte. These topics are discussed more in section 3.4 of the UDP
Usage Guidelines [RFC8085].
o SO_REUSEADDR specifies the rules for validating addresses supplied
to bind() should allow reuse of local addresses.
o SO_REUSEPORT specifies that the rules for validating ports The IEEE standard API for TCP/IP applications is the "socket"
supplied to bind() should allow reuse of a local port. interface [POSIX]. An application can use the recv() and send()
POSIX functions as well as the recvfrom() and sendto() and recvmsg()
and sendmsg() functions. The UDP and UDP-Lite sockets API differs
from that for TCP in several key ways. (Examples of usage of this
API are provided in [STEVENS].) In UDP and UDP-Lite, each datagram
is a self-contained message of a specified length, and options at the
transport layer can be used to set properties for all subsequent
datagrams sent using a socket or changed for each datagram. For
datagrams, this can require the application to use the API to set IP-
level information (the IP Time To Live (TTL), Differentiated Services
(DiffServ) Code Point, IP fragmentation, etc) for the datagrams it
sends and receives. In contrast, when using TCP and other
connection-oriented transports, the IP-level information normally
either remains the same for the duration of a connection or is
controlled by the transport protocol rather than the application.
o IP_RECVTTL returns the IP Time To Live (TTL) field from IP header Socket options are used in the socket API to provide additional
of a received datagram. functions For example, the IP_RECVTTL socket option is used by some
UDP multicast applications to return the IP TTL field from IP header
of a received datagram.
Some platforms also offer applications the ability to directly Some platforms also offer applications the ability to directly
assemble and transmit IP packets through "raw sockets" or similar assemble and transmit IP packets through "raw sockets" or similar
facilities. The raw socket API is a second, more cumbersome method facilities. The raw socket API is a second, more cumbersome, method
of using UDP. The use of this API is discussed in the RFC series in to send UDP datagrams. The use of this API is discussed in the RFC
the UDP Guidelines [RFC8085]. series in the UDP Guidelines [RFC8085].
The list of transport service features and primitives in this The list of transport service features and primitives in this
document is strictly based on the parts of protocol specifications in document is strictly based on the parts of protocol specifications in
RFC-series that relate to what the transport protocol provides to an RFC-series that relate to what the transport protocol provides to an
application that uses it and how the application interacts with the application that uses it and how the application interacts with the
transport protocol. Primitives can be invoked by an application or a transport protocol. Primitives can be invoked by an application or a
transport protocol; the latter type is called an "event". transport protocol; the latter type is called an "event".
The description in Section 3 follows the methodology defined by the The description in Section 3 follows the methodology defined by the
IETF TAPS working group in[I-D.ietf-taps-transports-usage]. IETF TAPS working group in [I-D.ietf-taps-transports-usage].
Specifically, this document provides the first pass of this process, Specifically, this document provides the first pass of this process,
which discusses the relevant RFC text describing primitives for each which discusses the relevant RFC text describing primitives for each
protocol. [I-D.ietf-taps-transports-usage] uses this input to protocol. [I-D.ietf-taps-transports-usage] uses this input to
document the usage of transport features provided by IETF transport document the usage of transport features provided by IETF transport
protocols, describing the way UDP, UDP-Lite and other transport protocols, describing the way UDP, UDP-Lite and other transport
protocols expose their services to applications and how an protocols expose their services to applications and how an
application can configure and use the features that make up these application can configure and use the features that make up these
services. services.
The presented road map to documentation of the transport interface The presented road map to documentation of the transport interface
may also help developers working with UDP and UDP-Lite. may also help developers working with UDP and UDP-Lite.
2. Terminology 2. Terminology
This document provides details for the Pass 1 analysis of UDP and This document provides details for the Pass 1 analysis of UDP and
UDP-Lite that is used in "Usage of Transport Features Provided by UDP-Lite that is used in "Usage of Transport Features Provided by
IETF Transport Protocols" [I-D.ietf-taps-transports-usage]. It uses IETF Transport Protocols" [I-D.ietf-taps-transports-usage]. It uses
common terminology defined in that document and also refers to the common terminology defined in that document and also quotes RFCs that
terminology of RFC 2119 [RFC2119], but does not itself define new use the terminology of RFC 2119 [RFC2119].
terms.
3. UDP and UDP-Lite Primitives 3. UDP and UDP-Lite Primitives
The User Datagram Protocol (UDP) [RFC0768][RFC8200] and UDP-Lite The User Datagram Protocol (UDP) [RFC0768][RFC8200] and UDP-Lite
protocols [RFC3828] are IETF standards track transport protocols. protocols [RFC3828] are IETF standards track transport protocols.
These protocols provide unidirectional, datagram services that These protocols provide unidirectional, datagram services, supporting
preserve message boundaries. transmit and receive operations that preserve message boundaries.
This section summarizes the relevant text parts of the RFCs This section summarises the relevant text parts of the RFCs
describing the UDP and UDP-Lite protocols, focusing on what the describing the UDP and UDP-Lite protocols, focusing on what the
transport protocols provide to the application and how the transport transport protocols provide to the application and how the transport
is used (based on abstract API descriptions, where they are is used (based on abstract API descriptions, where they are
available). It describes how UDP is used with IPv4 or IPv6 to send available). It describes how UDP is used with IPv4 or IPv6 to send
unicast or anycast datagrams and the use to send broadcast datagrams unicast or anycast datagrams and the use to send broadcast datagrams
for IPv4. A set of network-layer primitives required to use UDP or for IPv4. A set of network-layer primitives required to use UDP or
UDP-Lite with IP multicast (for IPv4 and IPv6) have been specified in UDP-Lite with IP multicast (for IPv4 and IPv6) have been specified in
the RFC series. Appendix A describes where to find documentation for the RFC series. Appendix A describes where to find documentation for
network-layer primitives required to use UDP or UDP-Lite with IP network-layer primitives required to use UDP or UDP-Lite with IP
multicast (for IPv4 and IPv6). multicast (for IPv4 and IPv6).
skipping to change at page 4, line 36 skipping to change at page 4, line 49
3.1. Primitives Provided by UDP 3.1. Primitives Provided by UDP
The User Datagram Protocol (UDP) [RFC0768] States: "This User The User Datagram Protocol (UDP) [RFC0768] States: "This User
Datagram Protocol (UDP) is defined to make available a datagram mode Datagram Protocol (UDP) is defined to make available a datagram mode
of packet-switched computer communication in the environment of an of packet-switched computer communication in the environment of an
interconnected set of computer networks." It "provides a procedure interconnected set of computer networks." It "provides a procedure
for application programs to send messages to other programs with a for application programs to send messages to other programs with a
minimum of protocol mechanism (..)". minimum of protocol mechanism (..)".
The User Interface section of RFC768 states that the user interface The User Interface section of RFC768 states that the user interface
to an application should be able to create receive, source, and to an application should allow "the creation of new receive ports,
destination ports and addresses (setting the source and destination receive operations on the receive ports that return the data octets
ports and addresses), and provide operations to receive data based on and an indication of source port and source address, and an operation
ports (with an indication of source port and address). Operations that allows a datagram to be sent, specifying the data, source and
should be provided that allows datagrams be sent, specifying the destination ports and addresses to be sent".
source and destination ports and addresses to be used.
UDP has been defined for IPv6 [RFC8200], together with API extensions UDP has been defined for IPv6 [RFC8200], together with API extensions
for a Basic Socket Interface Extensions for IPv6 [RFC3493]. for a Basic Socket Interface Extensions for IPv6 [RFC3493].
[RFC6935] and [RFC6936] defines an update to the UDP transport [RFC6935] and [RFC6936] define an update to the UDP transport
originally specified in RFC2460. This enables use of a zero UDP originally specified in RFC2460. This enables use of a zero UDP
checksum mode with a tunnel protocol, providing that the method checksum mode with a tunnel protocol, providing that the method
satisfies the requirements in the corresponding applicability satisfies the requirements in the corresponding applicability
statement [RFC6936]. statement [RFC6936].
UDP offers only a basic transport interface. UDP datagrams may be UDP offers only a basic transport interface. UDP datagrams may be
directly sent and received, without exchanging messages between the directly sent and received, without exchanging messages between the
endpoints to setup a connection (i.e., no handshake is performed by endpoints to setup a connection (i.e., no handshake is performed by
the transport protocol prior to communication). Using the sockets the transport protocol prior to communication). Using the sockets
API, applications can receive packets from more than one IP source API, applications can receive packets from more than one IP source
address on a single UDP socket. Common support allows specification address on a single UDP socket. Common support allows specification
of the local IP address, destination IP address, local port and of the local IP address, destination IP address, local port and
destination port values. Any or all of these can be indicated, with destination port values. Any or all of these can be indicated, with
defaults supplied by the local system when these are not specified. defaults supplied by the local system when these are not specified.
The local endpoint is set using the BIND call and set on the remote The local endpoint is set using the BIND call and set on the remote
endpoint using the CONNECT call. The CLOSE function has local endpoint using the CONNECT call. The CLOSE function has local
significance only. It does not impact the status of the remote significance only. It does not impact the status of the remote
endpoint. endpoint.
Neither UDP nor UDP-Lite provide congestion control, retransmission, Neither UDP nor UDP-Lite provide congestion control, retransmission,
nor do they provide mechanisms for application-level packetization nor do they provide mechanisms for application-level packetisation
that would avoid IP fragmentation and other transport functions. that would avoid IP fragmentation and other transport functions.
This means that applications using UDP need to provide additional This means that applications using UDP need to provide additional
functions on top of the UDP transport API [RFC8085]. Some transport functions on top of the UDP transport API [RFC8085]. Some transport
functions require parameters to be passed through the API to control functions require parameters to be passed through the API to control
the network layer (IPv4 or IPv6). These additional primitives could the network layer (IPv4 or IPv6). These additional primitives could
be considered a part of the network layer (e.g., control of the be considered a part of the network layer (e.g., control of the
setting of the Don't Fragment (DF) flag on a transmitted IPv4 setting of the Don't Fragment (DF) flag on a transmitted IPv4
datagram), but are nonetheless essential to allow a user of the UDP datagram), but are nonetheless essential to allow a user of the UDP
API to implement functions that are normally associated with the API to implement functions that are normally associated with the
transport layer (such as probing for the path maximum transmission transport layer (such as probing for the path maximum transmission
skipping to change at page 6, line 26 skipping to change at page 6, line 36
CONNECT: The CONNECT primitive allows the association of source and CONNECT: The CONNECT primitive allows the association of source and
destination port sets to a socket to enable creation of a destination port sets to a socket to enable creation of a
'connection' for UDP traffic. This UDP connection allows an 'connection' for UDP traffic. This UDP connection allows an
application to be notified of errors received from the network application to be notified of errors received from the network
stack and provides a shorthand access to the send and receive stack and provides a shorthand access to the send and receive
primitives. Since UDP is itself connectionless, no datagrams are primitives. Since UDP is itself connectionless, no datagrams are
sent because this primitive is executed. A further connect call sent because this primitive is executed. A further connect call
can be used to change the association. can be used to change the association.
Two forms of usage may be identified for the CONNECT primitive: The roles of a client and a server are often not appropriate for
UDP, where connections can be peer-to-peer. The listening
functions are performed using one of the forms of the CONNECT
primitive:
1. bind(): A bind operation sets the local port, either 1. bind(): A bind operation sets the local port, either
implicitly, triggered by a "sendto" operation on an unbound implicitly, triggered by a "sendto" operation on an unbound
unconnected socket using an ephemeral port. Or by an explicit unconnected socket using an ephemeral port. Or by an explicit
"bind" to use a configured or well-known port. "bind" to use a configured or well-known port.
2. bind(); connect(): A bind operation that is followed by a 2. bind(); connect(): A bind operation that is followed by a
CONNECT primitive. The bind operation establishes the use of CONNECT primitive. The bind operation establishes the use of
a known local port for datagrams, rather than using an a known local port for datagrams, rather than using an
ephemeral port. The connect operation specifies a known ephemeral port. The connect operation specifies a known
address port combination to be used by default for future address port combination to be used by default for future
datagrams. This form is used either after receiving a datagrams. This form is used either after receiving a
datagram from an endpoint that causes the creation of a datagram from an endpoint that causes the creation of a
connection, or can be triggered by third party configuration connection, or can be triggered by third party configuration
or a protocol trigger (such as reception of a UDP Service or a protocol trigger (such as reception of a UDP Service
Description Protocol, SDP [RFC4566], record). Description Protocol, SDP [RFC4566], record).
LISTEN: The roles of a client and a server are often not appropriate
for UDP, where connections can be peer-to-peer. The listening
functions are performed using one of the forms of the CONNECT
primitive described above.
SEND: The SEND primitive hands over a provided number of bytes that SEND: The SEND primitive hands over a provided number of bytes that
UDP should send to the other side of a UDP connection in a UDP UDP should send to the other side of a UDP connection in a UDP
datagram. The primitive can be used by an application to directly datagram. The primitive can be used by an application to directly
send datagrams to an endpoint defined by an address/port pair. If send datagrams to an endpoint defined by an address/port pair. If
a connection has been created, then the address/port pair is a connection has been created, then the address/port pair is
inferred from the current connection for the socket. Connecting a inferred from the current connection for the socket. Connecting a
socket allows network errors to be returned to the application as socket allows network errors to be returned to the application as
a notification on the send primitive. Messages passed to the send a notification on the send primitive. Messages passed to the send
primitive that cannot be sent atomically in an IP packet will not primitive that cannot be sent atomically in an IP packet will not
be sent by the network layer, generating an error. be sent by the network layer, generating an error.
skipping to change at page 9, line 46 skipping to change at page 9, line 52
carrying a UDP datagram. For IPv6 unicast datagrams, this is carrying a UDP datagram. For IPv6 unicast datagrams, this is
functionally equivalent to the SET_TTL IPv4 function. functionally equivalent to the SET_TTL IPv4 function.
GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS primitive is a GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS primitive is a
network-layer function that reads the hop count in the IPv6 header network-layer function that reads the hop count in the IPv6 header
[RFC8200] information of a received UDP datagram. This is [RFC8200] information of a received UDP datagram. This is
specified in section 6.3 of RFC3542. For IPv6 unicast datagrams, specified in section 6.3 of RFC3542. For IPv6 unicast datagrams,
this is functionally equivalent to the GET_TTL IPv4 function. this is functionally equivalent to the GET_TTL IPv4 function.
SET_DSCP: The SET_DSCP primitive is a network-layer function that SET_DSCP: The SET_DSCP primitive is a network-layer function that
sets the Differentiated Services (DiffServ) Code Point, DSCP, (or sets the DSCP, (or the legacy Type of Service, ToS) value
the legacy Type of Service, ToS) value [RFC2474] to be used in the
field of an IP header of a packet that carries a UDP datagram. [RFC2474] to be used in the field of an IP header of a packet that
Section 2.4 of the requirements for Internet hosts[RFC1123] states carries a UDP datagram. Section 2.4 of the requirements for
that "Applications MUST select appropriate ToS values when they Internet hosts[RFC1123] states that "Applications MUST select
invoke transport layer services, and these values MUST be appropriate ToS values when they invoke transport layer services,
configurable.". The application should be able to change the ToS and these values MUST be configurable.". The application should
during the connection lifetime, and the ToS value should be passed be able to change the ToS during the connection lifetime, and the
to the IP layer unchanged. Section 4.1.4 of [RFC1122] also states ToS value should be passed to the IP layer unchanged.
that on reception the "UDP MAY pass the received ToS value up to Section 4.1.4 of [RFC1122] also states that on reception the "UDP
the application layer". The DiffServ model [RFC2475] [RFC3260] MAY pass the received ToS value up to the application layer". The
replaces this field in the IP Header assigning the six most DiffServ model [RFC2475] [RFC3260] replaces this field in the IP
significant bits to carry the DSCP field [RFC2474]. Preserving Header assigning the six most significant bits to carry the DSCP
the intention of the host requirements [RFC1122] to allow the field [RFC2474]. Preserving the intention of the host
application to specify the "Type of Service", this should be requirements [RFC1122] to allow the application to specify the
interpreted to mean that an API should allow the application to "Type of Service", this should be interpreted to mean that an API
set the DSCP. Section 3.1.6 of the UDP Guidelines [RFC8085] should allow the application to set the DSCP. Section 3.1.6 of
describes the way UDP applications should use this field. the UDP Guidelines [RFC8085] describes the way UDP applications
Normally a UDP socket will assign a single DSCP value to all should use this field. Normally a UDP socket will assign a single
datagrams in a flow, but a sender is allowed to use different DSCP DSCP value to all datagrams in a flow, but a sender is allowed to
values for datagrams within the same flow in certain use different DSCP values for datagrams within the same flow in
cases[RFC8085]. There are guidelines for WebRTC that illustrate certain cases[RFC8085]. There are guidelines for WebRTC that
this use [RFC7657]. illustrate this use [RFC7657].
SET_ECN: The SET_ECN primitive is a network-layer function that sets SET_ECN: The SET_ECN primitive is a network-layer function that sets
the Explicit Congestion Notification (ECN) field in the IP Header the Explicit Congestion Notification (ECN) field in the IP Header
of a UDP datagram. The ECN field defaults to a value of 00. When of a UDP datagram. The ECN field defaults to a value of 00. When
the use of the ToS field was redefined by DiffServ [RFC3260], 2 the use of the ToS field was redefined by DiffServ [RFC3260], 2
bits of the field were assigned to support ECN [RFC3168]. bits of the field were assigned to support ECN [RFC3168].
Section 3.1.5 of the UDP Guidelines [RFC8085] describes the way Section 3.1.5 of the UDP Guidelines [RFC8085] describes the way
UDP applications should use this field. NOTE: In many other IETF UDP applications should use this field. NOTE: In many other IETF
transports (e.g., TCP) the transport provides the support needed transports (e.g., TCP) the transport provides the support needed
to use ECN, when using UDP, the application or higher layer to use ECN, when using UDP, the application or higher layer
skipping to change at page 12, line 30 skipping to change at page 12, line 34
specification [RFC3828] states that "applications that wish to specification [RFC3828] states that "applications that wish to
receive payloads that were only partially covered by a checksum receive payloads that were only partially covered by a checksum
should inform the receiving system by an explicit system call". should inform the receiving system by an explicit system call".
The default is to require only minimal coverage of the datagram The default is to require only minimal coverage of the datagram
payload. payload.
4. Acknowledgements 4. Acknowledgements
This work was partially funded by the European Union's Horizon 2020 This work was partially funded by the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334 research and innovation programme under grant agreement No. 644334
(NEAT). The views expressed are solely those of the author(s). (NEAT). Thanks to all who have commented or contributed, including
Thanks to all who have commented or contributed, including Joe Touch, Joe Touch, Ted Hardie, Aaron Falk, Tommy Pauly, and Francis Dupont.
Ted Hardie and Aaron Falk, Tommy Pauly.
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
The authors request the section to be removed during conversion into The authors request the section to be removed during conversion into
an RFC by the RFC Editor. an RFC by the RFC Editor.
6. Security Considerations 6. Security Considerations
skipping to change at page 13, line 4 skipping to change at page 13, line 6
The authors request the section to be removed during conversion into The authors request the section to be removed during conversion into
an RFC by the RFC Editor. an RFC by the RFC Editor.
6. Security Considerations 6. Security Considerations
Security considerations for the use of UDP and UDP-Lite are provided Security considerations for the use of UDP and UDP-Lite are provided
in the referenced RFCs. Security guidance for application usage is in the referenced RFCs. Security guidance for application usage is
provided in the UDP-Guidelines [RFC8085]. provided in the UDP-Guidelines [RFC8085].
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-taps-transports-usage] [I-D.ietf-taps-transports-usage]
Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols", Transport Features Provided by IETF Transport Protocols",
draft-ietf-taps-transports-usage-08 (work in progress), draft-ietf-taps-transports-usage-08 (work in progress),
August 2017. August 2017.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, <https://www.rfc- DOI 10.17487/RFC0768, August 1980,
editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, <https://www.rfc- DOI 10.17487/RFC1122, October 1989,
editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, <https://www.rfc- DOI 10.17487/RFC1123, October 1989,
editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, <https://www.rfc- DOI 10.17487/RFC1191, November 1990,
editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003, RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>. <https://www.rfc-editor.org/info/rfc3493>.
skipping to change at page 14, line 16 skipping to change at page 14, line 16
and G. Fairhurst, Ed., "The Lightweight User Datagram and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
2004, <https://www.rfc-editor.org/info/rfc3828>. 2004, <https://www.rfc-editor.org/info/rfc3828>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013, RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>. <https://www.rfc-editor.org/info/rfc6864>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013, <https://www.rfc- DOI 10.17487/RFC6935, April 2013,
editor.org/info/rfc6935>. <https://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013, RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>. <https://www.rfc-editor.org/info/rfc6936>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, <https://www.rfc- DOI 10.17487/RFC8200, July 2017,
editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, <https://www.rfc- DOI 10.17487/RFC8201, July 2017,
editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
7.2. Informative References 7.2. Informative References
[POSIX] "IEEE Std. 1003.1-2001, , "Standard for Information [POSIX] "IEEE Std. 1003.1-2001, , "Standard for Information
Technology - Portable Operating System Interface (POSIX)", Technology - Portable Operating System Interface (POSIX)",
Open Group Technical Standard: Base Specifications Issue Open Group Technical Standard: Base Specifications Issue
6, ISO/IEC 9945:2002", December 2001. 6, ISO/IEC 9945:2002", December 2001.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, <https://www.rfc- DOI 10.17487/RFC2474, December 1998,
editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<https://www.rfc-editor.org/info/rfc3260>. <https://www.rfc-editor.org/info/rfc3260>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678, Extensions for Multicast Source Filters", RFC 3678,
DOI 10.17487/RFC3678, January 2004, <https://www.rfc- DOI 10.17487/RFC3678, January 2004,
editor.org/info/rfc3678>. <https://www.rfc-editor.org/info/rfc3678>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, <https://www.rfc- DOI 10.17487/RFC3810, June 2004,
editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>. August 2006, <https://www.rfc-editor.org/info/rfc4604>.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>. <https://www.rfc-editor.org/info/rfc5082>.
[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite
protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008,
<https://www.rfc-editor.org/info/rfc5097>. <https://www.rfc-editor.org/info/rfc5097>.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
DOI 10.17487/RFC5790, February 2010, <https://www.rfc- DOI 10.17487/RFC5790, February 2010,
editor.org/info/rfc5790>. <https://www.rfc-editor.org/info/rfc5790>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, DOI 10.17487/RFC6633, May 2012, RFC 6633, DOI 10.17487/RFC6633, May 2012,
<https://www.rfc-editor.org/info/rfc6633>. <https://www.rfc-editor.org/info/rfc6633>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, <https://www.rfc- DOI 10.17487/RFC7657, November 2015,
editor.org/info/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
[STEVENS] "Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network [STEVENS] "Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network
Programming, The sockets Networking API", Addison- Programming, The sockets Networking API", Addison-
Wesley.", 2004. Wesley.", 2004.
Appendix A. Multicast Primitives Appendix A. Multicast Primitives
This appendix describes primitives that are used when UDP and UDP- This appendix describes primitives that are used when UDP and UDP-
Lite support IPv4/IPv6 Multicast. Multicast services are not Lite support IPv4/IPv6 Multicast. Multicast services are not
considered by the IETF TAPS WG, but the currently specified considered by the IETF TAPS WG, but the currently specified
skipping to change at page 19, line 23 skipping to change at page 19, line 23
MCAST_JOIN_GROUP This is used to join an ASM group. MCAST_JOIN_GROUP This is used to join an ASM group.
MCAST_JOIN_SOURCE_GROUP This is used to join an SSM group. MCAST_JOIN_SOURCE_GROUP This is used to join an SSM group.
MCAST_BLOCK_SOURCE: This is used to block a source in an ASM group. MCAST_BLOCK_SOURCE: This is used to block a source in an ASM group.
MCAST_UNBLOCK_SOURCE: This removes a previous MSF set by MCAST_UNBLOCK_SOURCE: This removes a previous MSF set by
MCAST_BLOCK_SOURCE. MCAST_BLOCK_SOURCE.
MCAST_LEAVE_GROUP: This leaves a SSM group.
MCAST_LEAVE_GROUP: This leaves an ASM or SSM group. MCAST_LEAVE_GROUP: This leaves an ASM or SSM group.
MCAST_LEAVE_SOURCE_GROUP: This leaves a SSM group.
Section 5.2 of the socket interface for MSF [RFC3678] specifies the Section 5.2 of the socket interface for MSF [RFC3678] specifies the
Protocol-Independent Advanced MSF (Full-state) API applicable for Protocol-Independent Advanced MSF (Full-state) API applicable for
both IPv4 and IPv6: both IPv4 and IPv6:
setsourcefilter This is used to join an IPv4 or IPv6 multicast setsourcefilter This is used to join an IPv4 or IPv6 multicast
group, or to enable multicast from a specified source. group, or to enable multicast from a specified source.
getsourcefilter: This is used to leave an IPv4 or IPv6 multicast getsourcefilter: This is used to leave an IPv4 or IPv6 multicast
group, or to filter multicast from a specified source. group, or to filter multicast from a specified source.
skipping to change at page 20, line 40 skipping to change at page 20, line 40
o Expected to progress with draft-ietf-taps-transports-usage of the o Expected to progress with draft-ietf-taps-transports-usage of the
TAPS WG. TAPS WG.
TAPS WG draft -01: TAPS WG draft -01:
o No intentional changes were made to the specification of o No intentional changes were made to the specification of
primitives, this update is editorial primitives, this update is editorial
o Reorganised text to eliminate the appendices. o Reorganised text to eliminate the appendices.
o Editorial changes were make to complete the document for a WGLC. o Editorial changes were make to complete the document for a WGLSeC.
o Rephrasing to eliminate using references as nouns, and to make o Rephrasing to eliminate using references as nouns, and to make
text more consistent. text more consistent.
o One appendix was incorporated. o One appendix was incorporated.
o This appendix was moved to the end (for later deletion by the RFC- o This appendix was moved to the end (for later deletion by the RFC-
Ed). Ed).
TAPS WG draft -02: TAPS WG draft -02:
skipping to change at page 21, line 37 skipping to change at page 21, line 37
o AD review 8/2017. o AD review 8/2017.
o Updates to reflect published RFCs and refer to PMTUD for IPv6. o Updates to reflect published RFCs and refer to PMTUD for IPv6.
o Aligned to latest TAPS transport usage ID. o Aligned to latest TAPS transport usage ID.
TAPS WG draft -06 TAPS WG draft -06
o Fix to text for get TTL and IPv6 Hop Count o Fix to text for get TTL and IPv6 Hop Count
TAPS WG draft -07
o Edit after secdir review - text on how a sender knows how to
request UDP-Lite - added a para;
o Abstract query about citing TAPS-transports;
o Secdir editorial/format fixes have been applied.
o Moved the note about "LISTEN:" to the text on "CONNECT:", Mirja
suggested clarity that there is no LISTEN primitive for UDP.
o Ben Campbell: Clarified the socket options were common examples
used by multicast sockets.
o Ben Campbell: Clarified that RFC 2119 is being cited, and not used
to create new terms.
o Ben Campbell: Added a direct copy of the text in RFC 768
describing the User Interface.
o Francis Dupont: Many technical corrections.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Fraser Noble Building Aberdeen AB24 3UE Fraser Noble Building Aberdeen AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 41 change blocks. 
104 lines changed or deleted 137 lines changed or added

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