Internet Engineering Task Force G. Fairhurst Internet-Draft T. Jones Intended status: Informational University of Aberdeen Expires: August 26, 2016 February 23, 2016 Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols draft-fairhurst-taps-transports-usage-udp-00 Abstract This document describes how the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols expose services to applications and how an application can configure and use the features offered by the transport service. The document is intended as a contribution to the TAPS working group to assist in analysis of the UDP and UDP-Lite transport interface. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 26, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Fairhurst & Jones Expires August 26, 2016 [Page 1] Internet-Draft UDP Transport Features February 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . 4 3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 8 3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 8 4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. CONNECTION-Related Primitives . . . . . . . . . . . . . . 9 4.2. DATA Related Primitives . . . . . . . . . . . . . . . . . 12 5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. CONNECTION-Related Transport Service Features . . . . . . 13 5.2. DATA Transfer Related Transport Service Features . . . . 14 5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 14 5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 18 Appendix B. Notes Based on Typical Usage . . . . . . . . . . . . 18 Appendix C. UDP Multicast . . . . . . . . . . . . . . . . . . . 19 C.1. Multicast Primitives . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Terminology This document uses common terminology defined in [I-D.ietf-taps-transports-usage]. This document also refers to the terminology of [RFC2119], but does not itself define new terms using this terminology. 2. Introduction This document presents defined interactions between transport protocols and applications in the form of 'primitives' (function calls). Primitives can be invoked by an application or a transport protocol; the latter type is called an "event". The list of transport service features and primitives in this document is strictly based on the parts of protocol specifications that relate to what the protocol provides to an application using it and how the Fairhurst & Jones Expires August 26, 2016 [Page 2] Internet-Draft UDP Transport Features February 2016 application interacts with it. It does not cover parts of a protocol that are explicitly stated as optional to implement. This follows the methodology defined in [I-D.ietf-taps-transports-usage], specifically: "The document presents a three-pass process to arrive at a list of transport service features. In the first pass, the relevant RFC text is discussed for each protocol. In the second pass, this discussion is used to derive a list of primitives that are uniformly categorized across protocols. Here, an attempt is made to present or -- where text describing primitives does not yet exist -- construct primitives in a slightly generalized form to highlight similarities. This is, for example, achieved by renaming primitives of protocols or by avoiding a strict 1:1-mapping between the primitives in the protocol specification and primitives in the list. Finally, the third pass presents transport service features based on pass 2, identifying which protocols implement them. In the list resulting from the second pass, some transport service features are missing because they are implicit in some protocols, and they only become explicit when we consider the superset of all features offered by all protocols. For example, TCP's reliability includes integrity via a checksum, but we have to include a protocol like UDP-Lite as specified in [RFC3828] (which has a configurable checksum) in the list before we can consider an always-on checksum as a transport service feature. Similar arguments apply to other protocol functions (e.g., congestion control). The complete list of features across all protocols is therefore only available after pass 3. 3. Pass 1 This first iteration summarizes the relevant text parts of the RFCs describing the UDP and UDP-Lite protocols, focusing on what the transport protocols provide to the application and how the transport is used (based on abstract API descriptions, where they are available). Fairhurst & Jones Expires August 26, 2016 [Page 3] Internet-Draft UDP Transport Features February 2016 3.1. Primitives Provided by UDP The User Datagram Protocol (UDP) [RFC0768] States: "This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks." It "provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism (..)". The User Interface section of [RFC0768] specifies that the user interface to an application should be able to create receive ports, source and destination ports and addresses, and provide operations to receive data based on ports with an indication of source port and address. Operations should be provided that allows datagrams be sent specifying the source and destination ports and addresses to be sent. UDP for IPv6 is defined by [RFC2460], and API extensions to support this in [RFC3493]. [RFC6935] and [RFC6936] defines an update to the UDP transport specified in RFC 2460. This enables use of a zero UDP checksum mode with a tunnel protocol, providing that the method satisfies the requirements in [RFC6936]. UDP offers only a basic transport interface. UDP datagrams may be directly sent and received, without any connection setup. Using the sockets API, applications can receive packets from more than one IP source address on a single UDP socket. It does not provide congestion control, retransmission, nor support to optimise fragmentation etc. This means that applications using UDP need to provide additional functions on top of the UDP transport API. This requires parameters to be passed through the API and complicates the analysis of the API. [I-D.ietf-tsvwg-rfc5405bis] also states "many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/ receive functions and to filter the traffic for the specified addresses and ports. Binding a UDP socket does not establish a connection - UDP does not notify the remote end when a local UDP socket is bound. Binding a socket also allows configuring options that affect the UDP or IP layers, for example, use of the UDP checksum or the IP Timestamp option. On some stacks, a bound socket also allows an application to be notified when ICMP error messages are received for its transmissions [RFC1122]." Guidance on the use of services provided by UDP is provided in [I-D.ietf-tsvwg-rfc5405bis]. Fairhurst & Jones Expires August 26, 2016 [Page 4] Internet-Draft UDP Transport Features February 2016 The following primitives are specified: CONNECT: The CONNECT primitive allows the association of source and port sets to a socket to enable creation of a 'connection' for UDP traffic. This UDP connection allows an application to be notified of errors received from the network stack and provides a shorthand access to the send and receive primitives. Since UDP is itself connectionless, no datagrams are sent because this primitive is executed. A further connect call can be used to change the association to a source/port pair. 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 datagram. The primitive can be used by an application to directly send datagrams to an endpoint defined by an address/port pair. If a connection has been created, then the address/port pair is inferred from the current connection for the socket. A connection created on the socket will allow network errors to be returned to the application as a notification on the send primitive. Messages passed to the send primitive that cannot be sent atomically in a datagram will not be sent by the network layer, generating an error. RECEIVE: The RECEIVE primitive allocates a receiving buffer to accommodate a received datagram. The primitive returns the number of bytes provided from a received UDP datagram. Section 4.1.3.5 of [RFC1122] states "When a UDP datagram is received, its specific-destination address MUST be passed up to the application layer." DISABLE_CHECKSUM: The CHECKSUM function controls the optional usage of UDP checksums for sending datagrams. [RFC0768] and IPv6 [RFC6935] [RFC6936] [I-D.ietf-tsvwg-rfc5405bis]. When set it overrides the default UDP behaviour disabling the checksum on sending. Section 4.1.3.4 of [RFC1122] states "An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on." SET_IP_OPTIONS: The SET_IP_OPTIONS function enables a datagram to be sent with the specified IP options. Section 4.1.3.2 of[RFC1122] states that an "application MUST be able to specify IP options to be sent in its UDP datagrams, and UDP MUST pass these options to the IP layer." GET_IP_OPTIONS: The GET_IP_OPTIONS function enables a receiver to read the IP options of a received datagram. Section 4.1.3.2 of[RFC1122] states that a UDP receiver "MUST pass any IP option Fairhurst & Jones Expires August 26, 2016 [Page 5] Internet-Draft UDP Transport Features February 2016 that it receives from the IP layer transparently to the application layer". SET_DF: The SET_DF function sets the Don't Fragment (DF) flag to be used in the field of an IP header of a packet that carries a UDP datagram. A UDP application should implement a method that avoids IP fragmentation ( section 4 of [I-D.ietf-tsvwg-rfc5405bis]). It can use Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path MTU Discovery [RFC1191]. GET_INTERFACE_MTU: The GET_INTERFACE_MTU function indicates the largest unfragmented IP packet that may be sent. A UDP endpoint can subtract the size of all network and transport headers to determine the maximum size of unfragmented UDP payload. UDP applications should use this value as part of a method to avoid sending UDP datagrams that would result in IP packets that exceed the effective path maximum transmission unit (PMTU) allowed on the network path. The effective PMTU specified in Section 1 of [RFC1191] is equivalent to the "effective MTU for sending" specified in [RFC1122]. [RFC4821] states: "If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described in Section 5.2) SHOULD be notified to make use of the new MTU and make the required congestion control adjustments." SET_TTL: The SET_TTL function sets the hop limit (TTL field) to be used in the field of an IPv4 header of a packet that carries an UDP datagram. This is used to limit the scope of unicast datagrams. Section 3.2.2.4 of [RFC1122] states an "incoming Time Exceeded message MUST be passed to the transport layer". GET_TTL: The GET_TTL function reads the value of the TTL field from the IPv4 header of a received UDP datagram. Section 3.2.2.4 of [RFC1122] states that a UDP receiver "MAY pass the received TOS up to the application layer" When used for applications such as the Generalized TTL Security Mechanism (GTSM) [RFC5082], this needs the UDP receiver API to pass the received value of this field to the application. SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS function sets the hop limit field to be used in the field of an IPv4 header of a packet that carries an UDP datagram. For IPv6 unicast datagrams, this is functionally equivalent to the SET_TTL IPv4 function. GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS function reads the value from the hop count field in the IPv6 header of a received UDP datagram. For IPv6 unicast datagrams, this is functionally equivalent to GET_TTL IPv4 function. Fairhurst & Jones Expires August 26, 2016 [Page 6] Internet-Draft UDP Transport Features February 2016 SET_DSCP: The SET_DSCP function sets the DSCP (or legacy TOS) value to be used in the field of an IP header of a packet that carries a UDP Datagram. Section 2.4 of [RFC1123] states that "Applications MUST select appropriate TOS values when they invoke transport layer services, and these values MUST be configurable.". The application should be able to change the TOS during the connection lifetime, and the TOS value should be passed to the IP layer unchanged. Section 4.1.4 of [RFC1122] also states that on reception the "UDP MAY pass the received TOS value up to the application layer". [RFC2475] [RFC3260] replaces this field in the IP Header assigning the six most significant bits to carry the Differentiated Services Code Point (DSCP) field. Preserving the intention of [RFC1122] to allow the application to specify the "Type of Service", this should be interpreted to mean that an API should allow the application to set the DSCP. Section 3.1.6 of [I-D.ietf-tsvwg-rfc5405bis] describes the way UDP applications should use this field. Normally a UDP socket will assign a single DSCP value to all Datagrams in a flow, but it is allowed to use different DSCP values for datagrams within the same flow in some cases, as described in [I-D.ietf-tsvwg-rfc5405bis]. SET_ECN: The SET_ECN function sets the ECN field in the IP Header of a UDP Datagram. When use of the TOS field was redefined [RFC3260], 2 bits of the field were assigned to support Explicit Congestion Notification (ECN) [RFC3168]. Section 3.1.5 [I-D.ietf-tsvwg-rfc5405bis] describes the way UDP applications should use this field. GET_ECN: The GET_ECN function returns the value of the ECN field in the IP Header of a received UDP Datagram. Section 3.1.5 [I-D.ietf-tsvwg-rfc5405bis] states that a UDP receiver "MUST check the ECN field at the receiver for each UDP datagram that it receives on this port", requiring the UDP receiver API to pass to pass the received ECN field up to the application layer to enable appropriate congestion feedback. ERROR_REPORT The ERROR_REPORT event informs an application of "soft errors", including the arrival of an ICMP or ICMPv6 error message. Section 4.1.4 of [RFC1122] states "UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer." For example, this event is required to implement ICMP-based Path MTU Discovery [RFC1191] [RFC1981]. CLOSE: The close primitive closes a connection. No further datagrams may be sent/received. Since UDP is itself connectionless, no datagrams are sent because this command is executed. Fairhurst & Jones Expires August 26, 2016 [Page 7] Internet-Draft UDP Transport Features February 2016 3.1.1. Excluded Primitives Section 3.4 of [RFC1122] also describes "GET_MAXSIZES: - replaced, GET_SRCADDR (Section 3.3.4.3) and ADVISE_DELIVPROB:". These mechanisms are no longer used. It also specifies use of the Source Quench ICMP message, which has since been deprecated [RFC6633]. The IPV6_V6ONLY function defined in Section 5.3 of [RFC3493] restricts the use of information from the name resolver to only allow communication of AF_INET6 sockets to use IPv6 only. This is not considered part of the transport service. 3.2. Primitives Provided by UDP-Lite The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] provides similar services to UDP. It changed the semantics of the UDP "payload length" field to that of a "checksum coverage length" field. UDP-Lite requires the pseudo-header checksum to be computed at the sender and checked at a receiver. Otherwise, UDP-Lite is semantically identical to UDP. The sending interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates the checksum coverage length. This specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error- insensitive part". The receiving interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that specifies the minimum acceptable checksum coverage. The UDP-Lite MIB further defines the checksum coverage method [RFC5097]. Guidance on the use of services provided by UDP-Lite is provided in [I-D.ietf-tsvwg-rfc5405bis]. UDP-Lite requires use of the UDP or UDP-Lite checksum, and hence "Checksum Enable" function is not permitted. All other primitives and functions for UDP are permitted, in addition the following are defined: SET_CHECKSUM_COVERAGE: The SET_CHECKSUM_COVERAGE function sets the coverage area for a sent datagram. UDP-Lite traffic uses this primitive to set the coverage length provided by the UDP checksum. Section 3.3 of [RFC5097] states that "Applications that wish to define the payload as partially insensitive to bit errors ... should do this by an explicit system call on the sender side." The default is to provide the same coverage as for UDP. Fairhurst & Jones Expires August 26, 2016 [Page 8] Internet-Draft UDP Transport Features February 2016 SET_MIN_COVERAGE The SET_MIN_COVERAGE function sets the minimum acceptable coverage protection for received datagrams. UDP-Lite traffic uses this primitive to set the coverage length that is checked on receive (section 1.1 of [RFC5097] describes the corresponding MIB entry as udpliteEndpointMinCoverage). Section 3.3 of [RFC3828] states that "applications that wish to receive payloads that were only partially covered by a checksum should inform the receiving system by an explicit system call". The default is to require only minimal coverage of the datagram payload. 4. Pass 2 Here we categorize the services from pass 1 based on whether they relate to a connection or to data transmission. Services are presented following the nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL". We present "connection" as a general protocol-independent concept and use it to refer to UDP and UDP-Lite connections (identifiable by a unique socket pair, where a socket is defined as an IP address and port). We define the "transport address" as "the combination of an IP address, transport protocol and the port number used by the transport protocol". The "application" is the user of the protocol [I-D.ietf-tsvwg-rfc5405bis]. 4.1. CONNECTION-Related Primitives ESTABLISHMENT: Active creation of a connection from one transport address to one or more transport addresses. Interfaces to UDP and UDP-Lite allow both connection-oriented and connection-less usage of the API [I-D.ietf-tsvwg-rfc5405bis]. o CONNECT.UDP: Pass 1 primitive event: 'connect' followed by 'send'. Parameters: 1 local IP address (optional); 1 destination transport address. Comments: Associates a transport address creating a UDP socket connection. This can be called again with a new transport address to create a new connection. The CONNECT function allows an application to receive errors from messages sent to a transport address. o CONNECT.UDP-Lite: Pass 1 primitive event: 'connect' followed by 'send'. Parameters: 1 local IP address (optional); 1 destination transport address. Comments: Associates the transport address creating a UDP-Lite socket connection. This can be called again with a new transport Fairhurst & Jones Expires August 26, 2016 [Page 9] Internet-Draft UDP Transport Features February 2016 address to create a new connection. The CONNECT function allows an application to receive errors from messages sent to a transport address. AVAILABILITY o LISTEN.UDP: Pass 1 primitive: 'receive'. Parameters: 1 local IP address (optional); 1 destination transport address. Comments: The receive function registers the application to listen for in-coming UDP datagrams at an endpoint. o LISTEN.UDP-Lite: Pass 1 primitive: 'receive' Parameters: 1 local IP address (optional); 1 destination transport address. Comments: The receive function registers the application to listen for in-coming UDP-Lite datagrams at an endpoint. MAINTENANCE o CHECKSUM.UDP: pass 1 primitive event: 'send' or 'connect' followed by 'send'. Parameter: 0 when no checksum is used, 1 for checksum (default). Comments: Only possible for UDP. o SET_CHECKSUM_COVERAGE.UDP-Lite: Parameters: Coverage length at sender (default maximum coverage) Comments: Only possible for UDP-Lite. o SET_MIN_CHECKSUM_COVERAGE.UDP-Lite: Parameter: Coverage length at receiver (default minimum coverage) Comments: Only possible for UDP-Lite. o SET_DF.UDP: Pass 1 primitive event: 'send' or 'open' followed by 'send'. Parameter: 0 when DF is not set (default), 1 when DF is set. o SET_DF.UDP-Lite: Pass 1 primitive event: 'send' or 'open' followed by 'send'. Fairhurst & Jones Expires August 26, 2016 [Page 10] Internet-Draft UDP Transport Features February 2016 Parameter: 0 when DF is not set (default), 1 when DF is set. o GET_INTERFACE_MTU Pass 1 primitive / event: GET_INTERFACE_MTU Parameters: MTU value set at sending interface. Comments: This allows an application to determine the local MTU for sending. o SET_TTL.UDP (IPV6_UNICAST_HOPS): Pass 1 primitive / event: SET_TTL/IPV6_UNICAST_HOPS Parameter: IPv4 TTL value or IPv6 Hop Count value Comments: This allows an application to change the IPv4 TTL of IPv6 Hop count value for outgoing UDP datagrams. o SET_TTL.UDP-Lite (IPV6_UNICAST_HOPS): Pass 1 primitive / event: TTL/IPV6_UNICAST_HOPS Parameter: IPv4 TTL value or IPv6 Hop Count value Comments: This allows an application to change the IPv4 TTL of IPv6 Hop count value for outgoing UDP datagrams. o SET_DSCP.UDP: Parameter: DSCP value Comments: This allows a UDP application to change the DSCP value for outgoing UDP datagrams. o SET_DSCP.UDP-Lite: Parameter: DSCP value Comments: This allows a UDP-Lite application to change the DSCP value. o ERROR.UDP: Pass 1 primitive event: 'ERROR_REPORT'. Parameters: Error report Comments: This returns soft errors that may be ignored without harm by many applications; An application must connect to be able receive these notifications. o ERROR.UDP-Lite: Pass 1 primitive event: 'ERROR_REPORT'. Parameters: Error report Comments: This returns soft errors that may be ignored without harm by many applications; An application must connect to be able receive these notifications. TERMINATION Fairhurst & Jones Expires August 26, 2016 [Page 11] Internet-Draft UDP Transport Features February 2016 o CLOSE.UDP: Pass 1 primitive event: Close Comments: No further UDP datagrams are sent/received. o CLOSE.UDP-Lite: Pass 1 primitive event: Close Comments: No further UDP-Lite datagrams are sent/received. 4.2. DATA Related Primitives All functions in this section refer to an existing connection, i.e. a connection that was either established or made available for receiving data. In addition to the listed parameters, all sending commands contain a reference to a data block and all receiving commands contain a reference to available buffer space for the data. o SEND.UDP: Pass 1 primitive / event: 'send' Parameters: IP Address and Port Number of the destination endpoint (optional if connected). Comments: This provides a message for unreliable transmission using UDP to the specified transport address. IP address and Port may be omitted for connected UDP sockets. o SEND.UDP-Lite: Pass 1 primitive / event: 'send' Parameters: IP Address and Port Number of the destination endpoint (optional if connected). Comments: This provides a message for unreliable transmission using UDP-Lite to the specified transport address. IP address and Port may be omitted for connected UDP sockets. o RECEIVE.UDP: Pass 1 primitive / event: 'receive' Parameters: Buffer for received datagram. Comments: The datagram received TTL/Hop count field, received ECN field, and IP options can be read per message on receive. o RECEIVE.UDP-Lite: Pass 1 primitive / event: 'receive' Parameters: Buffer for received datagram. Comments: The datagram received TTL/Hop count field, received ECN field, and IP options can be read per message on receive. o SEND_FAILURE.UDP: Pass 1 primitive / event: 'send' Fairhurst & Jones Expires August 26, 2016 [Page 12] Internet-Draft UDP Transport Features February 2016 Comment: This may be used to probe effective PMTU when using in combination with the 'set-DF' function. o SEND_FAILURE.UDP-Lite: Pass 1 primitive / event: 'send' Comment: This may be used to probe effective PMTU when using in combination with the 'set-DF' function. 5. Pass 3 This section presents the superset of all transport service features in all protocols that were discussed in the preceding sections, based on the list of primitives in pass 2, but also on text in pass 1 to include features that can be configured in one protocol and are static properties in another. Some minor details are omitted for the sake of generalization. [AUTHOR'S NOTE: the list here looks pretty similar to the list in pass 2 for now. This will change as more protocols are integrated. For example, when we merge with TCP and SCTP. In pass 3, we can derive "no congestion control" as a transport service feature of UDP; however, since it would be strange to call the lack of congestion control a feature, the natural outcome is then to list "congestion control" as a feature of TCP and SCTP.] 5.1. CONNECTION-Related Transport Service Features ESTABLISHMENT: Active creation of a connection from one transport endpoint to one or more transport endpoints. AVAILABILITY: Prepare to receive incoming requests o Listen, 1 specified interface Protocols: UDP, UDP-Lite o Listen, N specified interfaces Protocols: UDP, UDP-Lite o Listen, All local interfaces (unspecified) Protocols: UDP, UDP-Lite MAINTENANCE: Make adjustments to an open connection or notifications from the connection. Fairhurst & Jones Expires August 26, 2016 [Page 13] Internet-Draft UDP Transport Features February 2016 o Specify IP options Protocols: UDP, UDP-Lite o Specify Checksum enabled Protocols: UDP o Specify Checksum_Coverage Protocols: UDP-Lite o Specify Checksum_Coverage Protocols: UDP-Lite o Specify DF field Protocols: UDP, UDP-Lite o Specify TTL/Hop count field Protocols: UDP, UDP-Lite o Specify DSCP Field Protocols: UDP, UDP-Lite o Specify ECN field Protocols: UDP, UDP-Lite 5.2. DATA Transfer Related Transport Service Features All features in the this section relate to DATA.SEND and DATA.RECEIVE in Pass 2. 5.2.1. Sending Data All features in this section are provided by DATA.SEND from pass 2. DATA.SEND is given a data block from the application, which we here call a "message". o Send data Protocols: UDP, UDP-Lite o Send data on a connection Protocols: UDP, UDP-Lite Fairhurst & Jones Expires August 26, 2016 [Page 14] Internet-Draft UDP Transport Features February 2016 5.2.2. Receiving Data All features in this section are provided by DATA.RECEIVE from pass 2. DATA.RECEIVE is given a data block from the application, which we here call a "message". o Receive data Protocols: UDP, UDP-Lite o Receive data on a connection Protocols: UDP, UDP-Lite 6. Acknowledgements This work was partially funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s). 7. IANA Considerations This memo includes no request to IANA. If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 8. Security Considerations Security considerations for the use of UDP and UDP-Lire are provided in the referenced RFCs. Security guidance for application usage is provide in the UDP-Guidelines [I-D.ietf-tsvwg-rfc5405bis]. 9. References 9.1. Normative References [I-D.ietf-taps-transports-usage] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Service Features Provided by IETF Transport Protocols", draft-ietf-taps-transports-usage-00 (work in progress), January 2016. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . Fairhurst & Jones Expires August 26, 2016 [Page 15] Internet-Draft UDP Transport Features February 2016 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, DOI 10.17487/RFC2553, March 1999, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, . [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . Fairhurst & Jones Expires August 26, 2016 [Page 16] Internet-Draft UDP Transport Features February 2016 9.2. Informative References [I-D.ietf-tsvwg-rfc5405bis] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", draft-ietf-tsvwg-rfc5405bis-07 (work in progress), November 2015. [POSIX] "IEEE Std. 1003.1-2001, , "Standard for Information Technology - Portable Operating System Interface (POSIX)", Open Group Technical Standard: Base Specifications Issue 6, ISO/IEC 9945:2002", December 2001. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, . [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, DOI 10.17487/RFC3678, January 2004, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, . [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, . Fairhurst & Jones Expires August 26, 2016 [Page 17] Internet-Draft UDP Transport Features February 2016 [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, May 2012, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [STEVENS] "Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network Programming, The sockets Networking API", Addison- Wesley.", 2004. Appendix A. Revision Notes Note to RFC-Editor: please remove this entire section prior to publication. Individual draft -00: o This is the first version. Comments and corrections are welcome directly to the authors or via the IETF TAPS working group mailing list. Appendix B. Notes Based on Typical Usage This appendix contains notes to assist in a later revision. The de facto standard application programming interface (API) for TCP/IP applications is the "sockets" interface[POSIX]. Some platforms also offer applications the ability to directly assemble and transmit IP packets through "raw sockets" or similar facilities. This is a second, more cumbersome method of using UDP. The use of this API is discussed in the RFC series in [I-D.ietf-tsvwg-rfc5405bis]. The UDP sockets API differs from that for TCP in several key ways. Because application programmers are typically more familiar with the TCP sockets API, this section discusses these differences. [STEVENS] provides usage examples of the UDP sockets API. This section provides notes on some topics relating to implemented UDP APIs. A UDP application can use the recv() and send() POSIX functions as well as the recvfrom() and sendto() and recvmsg and sendmsg() functions. Fairhurst & Jones Expires August 26, 2016 [Page 18] Internet-Draft UDP Transport Features February 2016 SO_REUSEADDR specifies that the rules used in validating addresses supplied to bind() should allow reuse of local addresses. SO_REUSEPORT specifies that the rules used in validating ports supplied to bind() should allow reuse of a local port Accessing TTL From applications: If the IP_RECVTTL option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return the IP TTL (time to live) field for a UDP datagram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the TTL. Appendix C. UDP Multicast UDP and UDP-Lite Multicast may be considered in later versions of this document. This appendix contains notes to assist in this later revision. A host must request the ability to broadcast before it can send/ receive ipv4 broadcast traffic. A host must become a member of a multicast group before it can receive datagrams sent to the group. C.1. Multicast Primitives UDP and UDP-Lite support IPv4 broadcast and IPv4/IPv6 Multicast. Use of multicast requires additional functions at the transport API that must be called to coordinate operation of the IPv4 and IPv6 network layer protocols. Guidance on the use of UDP and UDP-Lite for multicast services is provided in [I-D.ietf-tsvwg-rfc5405bis]. The following are defined: JoinLocalGroup: 1 of [RFC3493] provides a function that allows joining of a local IPv4 multicast group. IPV6_MULTICAST_IF: Section 5.2 of [RFC2553] states that this sets the interface to use for outgoing multicast packets. IP_MULTICAST_TTL: This sets the hop limit to use for outgoing multicast packets. This is used to limit scope of multicast datagrams. When used for applications such as GSTM, this needs the UDP receiver API to pass the received value of this field to the application. (This is equivalent to IPV6_MULTICAST_HOPS for IPv6 multicast and TTL/IPV6_UNICAST_HOPS for unicast datagrams). Fairhurst & Jones Expires August 26, 2016 [Page 19] Internet-Draft UDP Transport Features February 2016 IPV6_MULTICAST_HOPS: Section 5.2 of [RFC2553] states that this sets the hop limit to use for outgoing multicast packets. When used for applications such as GSTM, this needs the UDP receiver API to pass the received value of this field to the application. (This is equivalent to IP_MULTICAST_TTL for IPv4 multicast and TTL/ IPV6_UNICAST_HOPS for unicast datagrams). IPV6_MULTICAST_LOOP: Section 5.2 of [RFC2553] states that this sets whether a copy of a datagram is looped back by the IP layer for local delivery when the datagram is sent to a group to which the sending host itself belongs). IPV6_JOIN_GROUP: Section 5.2 of [RFC2553] provides a function that allows joining of an IPv6 multicast group. SIOCGIPMSFILTER: Section 8.1 of [RFC0768] provides a function that allows reading the multicast source filters. SIOCSIPMSFILTER: Section 8.1 of [RFC0768] provides a function that allows setting/modifying the multicast source filters. IPV6_LEAVE_GROUP: Section 5.2 of [RFC2553] provides a function that allows leaving of a multicast group. LeaveHostGroup: Section 7.1 of [RFC3493] provides a function that allows joining of an IPv4 multicast group. LeaveLocalGroup: Section 7.1 of [RFC3493] provides a function that allows joining of a local IPv4 multicast group. Section 4.1.1 of [RFC3678] updates the interface to add support for IGMPv3 with Any Source Multicast (ASM) using IPv4: P_ADD_MEMBERSHIP: This is used to join an ASM group. IP_BLOCK_SOURCE: This is used to leave an ASM group. IP_UNBLOCK_SOURCE: This can be used to block data from a given source to a given group. IP_DROP_MEMBERSHIP: This can be used to undo a previous call to IP_UNBLOCK_SOURCE. Section 4.1.2 of [RFC3678] updates the interface to add support for IGMPv3 with Any Source Multicast (ASM) using IPv4: IP_ADD_SOURCE_MEMBERSHIP: This is used to join an SSM group. Fairhurst & Jones Expires August 26, 2016 [Page 20] Internet-Draft UDP Transport Features February 2016 IP_DROP_SOURCE_MEMBERSHIP: This is used to leave an SSM group. IP_DROP_MEMBERSHIP: This is supported, as a convenience, to drop all sources which have been joined for a particular group and interface. The operations are the same as if the socket had been closed. Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Fraser Noble Building Aberdeen AB24 3UE UK Email: gorry@erg.abdn.ac.uk Tom Jones University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE UK Email: tom@erg.abdn.ac.uk Fairhurst & Jones Expires August 26, 2016 [Page 21]