idnits 2.17.1 draft-ietf-taps-transports-usage-udp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 17, 2017) is 2475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2553' is defined on line 634, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-6man-rfc1981bis-06 == Outdated reference: A later version (-09) exists of draft-ietf-taps-transports-usage-04 -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Fairhurst 3 Internet-Draft T. Jones 4 Intended status: Informational University of Aberdeen 5 Expires: January 16, 2018 July 17, 2017 7 Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- 8 Lite) Transport Protocols 9 draft-ietf-taps-transports-usage-udp-04 11 Abstract 13 This is an informational document that describes the transport 14 protocol interface primitives provided by the User Datagram Protocol 15 (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport 16 protocols. It identifies the datagram services exposed to 17 applications and how an application can configure and use the 18 features offered by the Internet datagram transport service. The 19 resulting road map to documentation may be of help to users of the 20 UDP and UDP-Lite protocols. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 16, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . . 3 58 3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . . 4 59 3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 10 60 3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 10 61 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 67 Appendix A. Multicast Primitives . . . . . . . . . . . . . . . . . 15 68 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 71 1. Introduction 73 This document presents defined interactions between transport 74 protocols and applications in the form of 'primitives' (function 75 calls) for the User Datagram Protocol (UDP) [RFC0768] and the 76 Lightweight User Datagram Protocol (UDP-Lite) [RFC3828]. In this 77 usage, the word application refers to any program built on the 78 datagram interface, and including tunnels and other upper layer 79 protocols that use UDP and UDP-LIte. 81 The de facto standard application programming interface (API) for TCP 82 /IP applications is the "socket" interface [POSIX]. An application 83 can use the recv() and send() POSIX functions as well as the 84 recvfrom() and sendto() and recvmsg() and sendmsg() functions. The 85 UDP and UDP-Lite sockets API differs from that for TCP in several key 86 ways. (Examples of usage of this API are provided in [STEVENS].) 88 Additional functions in the sockets API are provided by socket 89 options, examples include: 91 o SO_REUSEADDR specifies the rules for validating addresses supplied 92 to bind() should allow reuse of local addresses. 94 o SO_REUSEPORT specifies that the rules for validating ports 95 supplied to bind() should allow reuse of a local port. 97 o IP_RECVTTL returns the IP Time To Live (TTL) field from IP header 98 of a received datagram. 100 Some platforms also offer applications the ability to directly 101 assemble and transmit IP packets through "raw sockets" or similar 102 facilities. The raw socket API is a second, more cumbersome method 103 of using UDP. The use of this API is discussed in the RFC series in 104 the UDP Guidelines [RFC8085]. 106 The list of transport service features and primitives in this 107 document is strictly based on the parts of protocol specifications in 108 RFC-series that relate to what the transport protocol provides to an 109 application that uses it and how the application interacts with the 110 transport protocol. Primitives can be invoked by an application or a 111 transport protocol; the latter type is called an "event". 113 The description in Section 3 follows the methodology defined by the 114 IETF TAPS working group [I-D.ietf-taps-transports-usage]. 115 Specifically, it provides the first pass of this process, which 116 discusses the relevant RFC text describing primitives for each 117 protocol. 119 The presented road map to documentation of the transport interface 120 may also help developers working with UDP and UDP-Lite. 122 2. Terminology 124 This document is intended as a contribution to the Transport Services 125 (TAPS) working group to assist in analysis of the UDP and UDP-Lite 126 transport interface. It uses common terminology defined in "Usage of 127 Transport Features Provided by IETF Transport Protocols" [I-D.ietf- 128 taps-transports-usage]. This document also refers to the terminology 129 of RFC 2119 [RFC2119], but does not itself define new terms using 130 this terminology. 132 3. UDP and UDP-Lite Primitives 134 The User Datagram Protocol (UDP) [RFC0768][RFC8200] and UDP-Lite 135 protocols [RFC3828] are IETF standards track transport protocols. 136 These protocols provide unidirectional, datagram services that 137 preserve message boundaries. 139 This section summarizes the relevant text parts of the RFCs 140 describing the UDP and UDP-Lite protocols, focusing on what the 141 transport protocols provide to the application and how the transport 142 is used (based on abstract API descriptions, where they are 143 available). It describes how UDP is used with IPv4 or IPv6 to send 144 unicast or anycast datagrams and use to send broadcast datagrams for 145 IPv4. A set of network-layer primitives required to use UDP or UDP- 146 Lite with IP multicast (for IPv4 and IPv6) have been specified in the 147 RFC series. Appendix A describes where to find documentation for 148 network-layer primitives required to use UDP or UDP-Lite with IP 149 multicast (for IPv4 and IPv6). 151 3.1. Primitives Provided by UDP 153 The User Datagram Protocol (UDP) [RFC0768] States: "This User 154 Datagram Protocol (UDP) is defined to make available a datagram mode 155 of packet-switched computer communication in the environment of an 156 interconnected set of computer networks." It "provides a procedure 157 for application programs to send messages to other programs with a 158 minimum of protocol mechanism (..)". 160 The User Interface section of RFC768 states that the user interface 161 to an application should be able to create receive, source, and 162 destination ports and addresses (setting the source and destination 163 ports and addresses), and provide operations to receive data based on 164 ports (with an indication of source port and address). Operations 165 should be provided that allows datagrams be sent, specifying the 166 source and destination ports and addresses to be used. 168 UDP has been defined for IPv6 [RFC8200], together with API extensions 169 for a Basic Socket Interface Extensions for IPv6 [RFC3493]. 170 [RFC6935] and [RFC6936] defines an update to the UDP transport 171 specified in RFC 8200. This enables use of a zero UDP checksum mode 172 with a tunnel protocol, providing that the method satisfies the 173 requirements in the corresponding applicability statement [RFC6936]. 175 UDP offers only a basic transport interface. UDP datagrams may be 176 directly sent and received, without exchanging messages between the 177 endpoints to setup a connection (i.e., no handshake is performed by 178 the transport protocol prior to communication). Using the sockets 179 API, applications can receive packets from more than one IP source 180 address on a single UDP socket. Common support allows specification 181 of the local IP address, destination IP address, local port and 182 destination port values. Any or all of these can be indicated, with 183 defaults supplied by the local system when these are not specified. 184 The local endpoint is set using the BIND call and set on the remote 185 endpoint using the CONNECT call. The CLOSE function has local 186 significance only. It does not impact the status of the remote 187 endpoint. 189 Neither UDP nor UDP-Lite provide congestion control, retransmission, 190 nor do they have support to optimise fragmentation and other 191 transport functions. This means that applications using UDP need to 192 provide additional functions on top of the UDP transport API 193 [RFC8085]. Some transport functions require parameters to be passed 194 through the API to control the network layer (IPv4 or IPv6). These 195 additional primitives could be considered a part of the network layer 196 (e.g., control of the setting of the Don't Fragment (DF) flag on a 197 transmitted IPv4 datagram), but are nonetheless essential to allow a 198 user of the UDP API to implement functions that are normally 199 associated with the transport layer (such as probing for the path 200 maximum transmission size). This document includes such primitives. 202 Guidance on the use of the services provided by UDP is provided in 203 the UDP Guidelines [RFC8085]. This also states "many operating 204 systems also allow a UDP socket to be connected, i.e., to bind a UDP 205 socket to a specific pair of addresses and ports. This is similar to 206 the corresponding TCP sockets API functionality. However, for UDP, 207 this is only a local operation that serves to simplify the local send 208 /receive functions and to filter the traffic for the specified 209 addresses and ports. Binding a UDP socket does not establish a 210 connection - UDP does not notify the remote endpoint when a local UDP 211 socket is bound. Binding a socket also allows configuring options 212 that affect the UDP or IP layers, for example, use of the UDP 213 checksum or the IP Timestamp Option. On some stacks, a bound socket 214 also allows an application to be notified when Internet Control 215 Message (ICMP) error messages are received for its transmissions 216 [RFC1122]." 218 The POSIX Base Specifications [POSIX] define an API that offers 219 mechanisms for an application to receive asynchronous data events at 220 the socket layer. Calls such as "poll", "select" or "queue" allow an 221 application to be notified when data has arrived at a socket or when 222 a socket has flushed its buffers. 224 A callback-driven API to the network interface can be structured on 225 top of these calls. Implicit connection setup allows an application 226 to delegate connection life management to the transport API. The 227 transport API uses protocol primitives to offer the automated service 228 to the application via the sockets API. By combining UDP primitives 229 (CONNECT.UDP, SEND.UDP), a higher level API could offer a similar 230 service. 232 The following datagram primitives are specified: 234 CONNECT: The CONNECT primitive allows the association of source and 235 destination port sets to a socket to enable creation of a 236 'connection' for UDP traffic. This UDP connection allows an 237 application to be notified of errors received from the network 238 stack and provides a shorthand access to the send and receive 239 primitives. Since UDP is itself connectionless, no datagrams are 240 sent because this primitive is executed. A further connect call 241 can be used to change the association. 243 Two forms of usage may be identified for the CONNECT primitive: 245 1. bind(): A bind operation sets the local port, either 246 implicitly, triggered by a "sendto" operation on an unbound 247 unconnected socket using an ephemeral port. Or by an explicit 248 "bind" to use a configured or well-known port. 250 2. bind(); connect(): A bind operation that is followed by a 251 CONNECT primitive. The bind operation establishes the use of 252 a known local port for datagrams, rather than using an 253 ephemeral port. The connect operation specifies a known 254 address port combination to be used by default for future 255 datagrams. This form is used either after receiving a 256 datagram from an endpoint that causes the creation of a 257 connection, or can be triggered by third party configuration 258 or a protocol trigger (such as reception of a UDP Service 259 Description Protocol, SDP [RFC4566], record). 261 LISTEN: The roles of a client and a server are often not appropriate 262 for UDP, where connections can be peer-to-peer. The listening 263 functions are performed using one of the forms of the CONNECT 264 primitive described above. 266 SEND: The SEND primitive hands over a provided number of bytes that 267 UDP should send to the other side of a UDP connection in a UDP 268 datagram. The primitive can be used by an application to directly 269 send datagrams to an endpoint defined by an address/port pair. If 270 a connection has been created, then the address/port pair is 271 inferred from the current connection for the socket. Connecting a 272 socket allows network errors to be returned to the application as 273 a notification on the send primitive. Messages passed to the send 274 primitive that cannot be sent atomically in a datagram will not be 275 sent by the network layer, generating an error. 277 RECEIVE: The RECEIVE primitive allocates a receiving buffer to 278 accommodate a received datagram. The primitive returns the number 279 of bytes provided from a received UDP datagram. Section 4.1.3.5 280 of the requirements of Internet hosts [RFC1122] states "When a UDP 281 datagram is received, its specific-destination address MUST be 282 passed up to the application layer." 284 CHECKSUM_ENABLED: The optional CHECKSUM_ENABLED primitive controls 285 whether a sender enables the UDP checksum when sending datagrams ( 286 [RFC0768] and [RFC6935] [RFC6936] [RFC8085]). When unset, this 287 overrides the default UDP behaviour, disabling the checksum on 288 sending. Section 4.1.3.4 of the requirements for Internet hosts 289 [RFC1122] states "An application MAY optionally be able to control 290 whether a UDP checksum will be generated, but it MUST default to 291 checksumming on." 293 REQUIRE_CHECKSUM: The optional REQUIRE_CHECKSUM primitive determines 294 whether UDP datagrams received with a zero checksum are permitted 295 or discarded, UDP defaults to requiring checksums. Section 296 4.1.3.4 of the requirements for Internet hosts [RFC1122] states 297 "An application MAY optionally be able to control whether UDP 298 datagrams without checksums should be discarded or passed to the 299 application." Section 3.1 of the specification for UDP-Lite 300 [RFC3828] requires that the checksum field is non-zero, and hence 301 the UDP-Lite API must discard all datagrams received with a zero 302 checksum. 304 SET_IP_OPTIONS: The SET_IP_OPTIONS primitive requests the network- 305 layer to send a datagram with the specified IP options. Section 306 4.1.3.2 of the requirements for Internet hosts[RFC1122] states 307 that an "application MUST be able to specify IP options to be sent 308 in its UDP datagrams, and UDP MUST pass these options to the IP 309 layer." 311 GET_IP_OPTIONS: The GET_IP_OPTIONS primitive retrieves the IP options 312 of a datagram received at the network-layer. Section 4.1.3.2 of 313 the requirements for Internet hosts[RFC1122] states that a UDP 314 receiver "MUST pass any IP option that it receives from the IP 315 layer transparently to the application layer". 317 SET_DF: The SET_DF primitive allows the network-layer to fragment 318 packets using the Fragment Offset in IPv4 [RFC6864] and a host to 319 use Fragment Headers in IPv6 [RFC8200]. The SET_DF primitive sets 320 the Don't Fragment (DF) flag in the IPv4 packet header that 321 carries a UDP datagram, which allows routers to fragment IPv4 322 packets. Although some specific applications rely on 323 fragmentation support, in general, a UDP application should 324 implement a method that avoids IP fragmentation (section 4 of 325 [RFC8085]). NOTE: In many other IETF transports (e.g., TCP, SCTP) 326 the transport provides the support needed to use DF. However, when 327 using UDP, the application is responsible for the techniques 328 needed to discover the effective Path Maximum Transmission Unit 329 (PMTU) allowed on the network path, coordinating with the network 330 layer. The acceptable maximum packet size can be determined using 331 Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path 332 MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis]. 334 GET_MMS_S: The GET_MMS_S primitive retrieves a network-layer value 335 that indicates the maximum message size (MMS) that may be sent at 336 the transport layer using a non-fragmented IP packet from the 337 configured interface. This value is specified in section 6.1 of 338 [RFC1191] and section 5.1 of [I-D.ietf-6man-rfc1981bis]. It is 339 calculated from Effective Maximum Transmit Unit for Sending 340 (EMTU_S), and the link MTU for the given source IP address. This 341 takes into account the size of the IP header plus space reserved 342 by the IP layer for additional headers (if any). UDP applications 343 should use this value as part of a method to avoid sending UDP 344 datagrams that would result in IP packets that exceed the 345 effective PMTU allowed across the network path. The effective 346 PMTU (specified in Section 1 of [RFC1191]) is equivalent to the 347 EMTU_S (specified in [RFC1122]). The specification of PLPMTUD 348 [RFC4821] states: "If PLPMTUD updates the MTU for a particular 349 path, all Packetization Layer sessions that share the path 350 representation (as described in Section 5.2) SHOULD be notified to 351 make use of the new MTU and make the required congestion control 352 adjustments". 354 GET_MMS_R: The GET_MMS_R primitive retrieves a network-layer value 355 that indicates the maximum message size (MMS) that may be received 356 at the transport layer from the configured interface. This value 357 is specified in section 3.1 of [RFC1191]. It is calculated from 358 Effective Maximum Transmit Unit for Receiving (EMTU_R), and the 359 link MTU for the given source IP address, and takes into account 360 the size of the IP header plus space reserved by the IP layer for 361 additional headers (if any). 363 SET_TTL: The SET_TTL primitive sets the hop limit (TTL field) in the 364 network-layer that is used in the IPv4 header of a packet that 365 carries an UDP datagram. This is used to limit the scope of 366 unicast datagrams. Section 3.2.2.4 of the requirements for 367 Internet hosts [RFC1122] states an "incoming Time Exceeded message 368 MUST be passed to the transport layer". 370 GET_TTL: The GET_TTL primitive retrieves the value of the TTL field 371 in a network packet received at the network-layer. Section 372 3.2.2.4 of the requirements for Internet hosts [RFC1122] states 373 that a UDP receiver "MAY pass the received ToS up to the 374 application layer" When used for applications such as the 375 Generalized TTL Security Mechanism (GTSM) [RFC5082], this needs 376 the UDP receiver API to pass the received value of this field to 377 the application. 379 SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS primitive sets the 380 network-layer hop limit field in an IPv6 packet header [RFC8200] 381 carrying a UDP datagram. For IPv6 unicast datagrams, this is 382 functionally equivalent to the SET_TTL IPv4 function. 384 GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS primitive is a 385 network-layer function that reads the hop count in the IPv6 header 386 [RFC8200] information of a received UDP datagram. For IPv6 387 unicast datagrams, this is functionally equivalent to the GET_TTL 388 IPv4 function. 390 SET_DSCP: The SET_DSCP primitive is a network-layer function that 391 sets the Differentiated Services (DiffServ) Code Point, DSCP, (or 392 the legacy Type of Service, ToS) value [RFC2474] to be used in the 393 field of an IP header of a packet that carries a UDP datagram. 394 Section 2.4 of the requirements for Internet hosts[RFC1123] states 395 that "Applications MUST select appropriate ToS values when they 396 invoke transport layer services, and these values MUST be 397 configurable.". The application should be able to change the ToS 398 during the connection lifetime, and the ToS value should be passed 399 to the IP layer unchanged. Section 4.1.4 of [RFC1122] also states 400 that on reception the "UDP MAY pass the received ToS value up to 401 the application layer". The DiffServ model [RFC2475] [RFC3260] 402 replaces this field in the IP Header assigning the six most 403 significant bits to carry the DSCP field [RFC2474]. Preserving 404 the intention of the host requirements [RFC1122] to allow the 405 application to specify the "Type of Service", this should be 406 interpreted to mean that an API should allow the application to 407 set the DSCP. Section 3.1.6 of the UDP Guidelines [RFC8085] 408 describes the way UDP applications should use this field. 409 Normally a UDP socket will assign a single DSCP value to all 410 datagrams in a flow, but a sender is allowed to use different DSCP 411 values for datagrams within the same flow in certain 412 cases[RFC8085]. There are guidelines for WebRTC that illustrate 413 this use [RFC7657]. 415 SET_ECN: The SET_ECN primitive is a network-layer function that sets 416 the Explicit Congestion Notification (ECN) field in the IP Header 417 of a UDP datagram. The ECN field defaults to a value of 00. When 418 the use of the ToS field was redefined by DiffsServ [RFC3260], 2 419 bits of the field were assigned to support ECN [RFC3168]. Section 420 3.1.5 of the UDP Guidelines [RFC8085] describes the way UDP 421 applications should use this field. NOTE: In many other IETF 422 transports (e.g., TCP) the transport provides the support needed 423 to use ECN, when using UDP, the application or higher layer 424 protocol is itself responsible for the techniques needed to use 425 ECN. 427 GET_ECN: The GET_ECN primitive is a network-layer function that 428 returns the value of the ECN field in the IP Header of a received 429 UDP datagram. Section 3.1.5 of the UDP Guidelines [RFC8085] 430 states that a UDP receiver "MUST check the ECN field at the 431 receiver for each UDP datagram that it receives on this port", 432 requiring the UDP receiver API to pass to pass the received ECN 433 field up to the application layer to enable appropriate congestion 434 feedback. 436 ERROR_REPORT The ERROR_REPORT event informs an application of "soft 437 errors", including the arrival of an ICMP or ICMPv6 error message. 438 Section 4.1.4 of the host requirements [RFC1122] states "UDP MUST 439 pass to the application layer all ICMP error messages that it 440 receives from the IP layer." For example, this event is required 441 to implement ICMP-based Path MTU Discovery [RFC1191] [I-D.ietf- 442 6man-rfc1981bis]. UDP applications must perform a CONNECT to 443 receive ICMP errors. 445 CLOSE: The close primitive closes a connection. No further datagrams 446 can be sent or received. Since UDP is itself connectionless, no 447 datagrams are sent when this primitive is executed. 449 3.1.1. Excluded Primitives 451 Section 3.4 of the host requirements [RFC1122] also describes 452 "GET_MAXSIZES, GET_SRCADDR (Section 3.3.4.3) and ADVISE_DELIVPROB:". 453 These mechanisms are no longer used. It also specifies use of the 454 Source Quench ICMP message, which has since been deprecated 455 [RFC6633]. 457 The IPV6_V6ONLY function is a network-layer primitive that applies to 458 all transport services, defined in Section 5.3 of the basic socket 459 interface for IPv6 [RFC3493]. This restricts the use of information 460 from the name resolver to only allow communication of AF_INET6 461 sockets to use IPv6 only. This is not considered part of the 462 transport service. 464 3.2. Primitives Provided by UDP-Lite 466 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] provides 467 similar services to UDP. It changed the semantics of the UDP "payload 468 length" field to that of a "checksum coverage length" field. UDP- 469 Lite requires the pseudo-header checksum to be computed at the sender 470 and checked at a receiver. Apart from the length and coverage 471 changes, UDP-Lite is semantically identical to UDP. 473 The sending interface of UDP-Lite differs from that of UDP by the 474 addition of a single (socket) option that communicates the checksum 475 coverage length. This specifies the intended checksum coverage, with 476 the remaining unprotected part of the payload called the "error- 477 insensitive part". 479 The receiving interface of UDP-Lite differs from that of UDP by the 480 addition of a single (socket) option that specifies the minimum 481 acceptable checksum coverage. The UDP-Lite Management Information 482 Base (MIB) [RFC5097] further defines the checksum coverage method. 483 Guidance on the use of services provided by UDP-Lite is provided in 484 the UDP Guidelines [RFC8085]. 486 UDP-Lite requires use of the UDP or UDP-Lite checksum, and hence it 487 is not permitted to use the "DISABLE_CHECKSUM:" function to disable 488 use of a checksum, nor is it possible to disable receiver checksum 489 processing using the "REQUIRE_CHECKSUM:" function . All other 490 primitives and functions for UDP are permitted. 492 In addition, the following are defined: 494 SET_CHECKSUM_COVERAGE: The SET_CHECKSUM_COVERAGE primitive sets the 495 coverage area for a sent datagram. UDP-Lite traffic uses this 496 primitive to set the coverage length provided by the UDP checksum. 497 Section 3.3 of the UDP-Lite MIB [RFC5097] states that 498 "Applications that wish to define the payload as partially 499 insensitive to bit errors ... Should do this by an explicit 500 system call on the sender side." The default is to provide the 501 same coverage as for UDP. 503 SET_MIN_COVERAGE The SET_MIN_COVERAGE primitive sets the minimum 504 acceptable coverage protection for received datagrams. UDP-Lite 505 traffic uses this primitive to set the coverage length that is 506 checked on receive. (Section 1.1 of the UDP-Lite MIB [RFC5097] 507 describes the corresponding MIB entry as 508 udpliteEndpointMinCoverage.) Section 3.3 of the UDP-Lite 509 specification [RFC3828] states that "applications that wish to 510 receive payloads that were only partially covered by a checksum 511 should inform the receiving system by an explicit system call". 512 The default is to require only minimal coverage of the datagram 513 payload. 515 4. Acknowledgements 517 This work was partially funded by the European Union's Horizon 2020 518 research and innovation programme under grant agreement No. 644334 519 (NEAT). The views expressed are solely those of the author(s). Thanks 520 to all who have commented or contributed, including Joe Touch, Ted 521 Hardie and Aaron Falk, Tommy Pauly. 523 5. IANA Considerations 525 This memo includes no request to IANA. 527 The authors request the section to be removed during conversion into 528 an RFC by the RFC Editor. 530 6. Security Considerations 532 Security considerations for the use of UDP and UDP-Lite are provided 533 in the referenced RFCs. Security guidance for application usage is 534 provided in the UDP-Guidelines [RFC8085]. 536 7. References 538 7.1. Normative References 540 [I-D.ietf-6man-rfc1981bis] 541 <>, J., <>, S., <>, J. and R. Hinden, "Path MTU Discovery 542 for IP version 6", Internet-Draft draft-ietf-6man- 543 rfc1981bis-06, April 2017. 545 [I-D.ietf-taps-transports-usage] 546 Welzl, M., Tuexen, M. and N. Khademi, "On the Usage of 547 Transport Features Provided by IETF Transport Protocols", 548 Internet-Draft draft-ietf-taps-transports-usage-04, April 549 2017. 551 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 552 10.17487/RFC0768, August 1980, . 555 [RFC1112] Deering, S.E., "Host extensions for IP multicasting", STD 556 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . 559 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 560 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 561 RFC1122, October 1989, . 564 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 565 Application and Support", STD 3, RFC 1123, DOI 10.17487/ 566 RFC1123, October 1989, . 569 [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", RFC 570 1191, DOI 10.17487/RFC1191, November 1990, . 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 575 RFC2119, March 1997, . 578 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 579 Explicit Congestion Notification (ECN) to IP", RFC 3168, 580 DOI 10.17487/RFC3168, September 2001, . 583 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. 584 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 585 3493, DOI 10.17487/RFC3493, February 2003, . 588 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.Ed., 589 and G. Fairhurst, Ed., "The Lightweight User Datagram 590 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 591 2004, . 593 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 594 RFC 6864, DOI 10.17487/RFC6864, February 2013, . 597 [RFC6935] Eubanks, M., Chimento, P. and M. Westerlund, "IPv6 and UDP 598 Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/ 599 RFC6935, April 2013, . 602 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 603 for the Use of IPv6 UDP Datagrams with Zero Checksums", 604 RFC 6936, DOI 10.17487/RFC6936, April 2013, . 607 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 608 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 609 March 2017, . 611 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 612 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/ 613 RFC8200, July 2017, . 616 7.2. Informative References 618 [POSIX] "IEEE Std. 1003.1-2001, , "Standard for Information 619 Technology - Portable Operating System Interface (POSIX)", 620 Open Group Technical Standard: Base Specifications Issue 621 6, ISO/IEC 9945:2002", December 2001. 623 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 624 "Definition of the Differentiated Services Field (DS 625 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 626 10.17487/RFC2474, December 1998, . 629 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 630 and W. Weiss, "An Architecture for Differentiated 631 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 632 . 634 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, 635 "Basic Socket Interface Extensions for IPv6", RFC 2553, 636 DOI 10.17487/RFC2553, March 1999, . 639 [RFC3260] Grossman, D., "New Terminology and Clarifications for 640 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 641 . 643 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 644 Thyagarajan, "Internet Group Management Protocol, Version 645 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . 648 [RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface 649 Extensions for Multicast Source Filters", RFC 3678, DOI 650 10.17487/RFC3678, January 2004, . 653 [RFC3810] Vida, R.Ed., and L. Costa, Ed., "Multicast Listener 654 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 655 10.17487/RFC3810, June 2004, . 658 [RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session 659 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 660 July 2006, . 662 [RFC4604] Holbrook, H., Cain, B. and B. Haberman, "Using Internet 663 Group Management Protocol Version 3 (IGMPv3) and Multicast 664 Listener Discovery Protocol Version 2 (MLDv2) for Source- 665 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 666 August 2006, . 668 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 669 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 670 . 672 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P.Ed., and C. 673 Pignataro, "The Generalized TTL Security Mechanism 674 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 675 . 677 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 678 protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, 679 . 681 [RFC5790] Liu, H., Cao, W. and H. Asaeda, "Lightweight Internet 682 Group Management Protocol Version 3 (IGMPv3) and Multicast 683 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 684 DOI 10.17487/RFC5790, February 2010, . 687 [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", 688 RFC 6633, DOI 10.17487/RFC6633, May 2012, . 691 [RFC7657] Black, D.Ed., and P. Jones, "Differentiated Services 692 (Diffserv) and Real-Time Communication", RFC 7657, DOI 693 10.17487/RFC7657, November 2015, . 696 [STEVENS] "Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 697 Programming, The sockets Networking API", Addison- 698 Wesley.", 2004. 700 Appendix A. Multicast Primitives 702 This appendix describes primitives that are used when UDP and UDP- 703 Lite support IPv4/IPv6 Multicast. Multicast services are not 704 considered by the IETF TAPS WG, but the currently specified 705 primitives are included for completeness in this appendix. Guidance 706 on the use of UDP and UDP-Lite for multicast services is provided in 707 the UDP Guidelines[RFC8085]. 709 IP multicast may be supported using the Any Source Multicast (ASM) 710 model or by the Source-Specific Multicast (SSM) model. The latter 711 requires use of a Multicast Source Filter (MSF) when specifying an IP 712 multicast group destination address. 714 Use of multicast requires additional primitives at the transport API 715 that need to be called to coordinate operation of the IPv4 and IPv6 716 network layer protocols. For example, to receive datagrams sent to a 717 group, an endpoint must first become a member of a multicast group at 718 the network layer. Local multicast reception is signalled for IPv4 719 by the Internet Group Management Protocol (IGMP) [RFC3376] [RFC4604]. 720 IPv6 uses the equivalent Multicast Listener Discovery (MLD) protocol 721 [RFC3810] [RFC5790], carried over ICMPv6. A lightweight version of 722 these protocols has also been specified [RFC5790]. 724 The following are defined: 726 JoinGroup: Section 7.1 of the Host Extensions for IP Multicasting 727 [RFC1112] provides a function that allows receiving traffic from 728 an IP multicast group. 730 JoinLocalGroup: Section 7.2 of the Host Extensions for IP 731 Multicasting [RFC1112] provides a function that allows receiving 732 traffic from a local IP multicast group. 734 LeaveHostGroup: Section 7.1 of the Host Extensions for IP 735 Multicasting [RFC1112] provides a function that allows leaving an 736 IP multicast group. 738 LeaveLocalGroup: Section 7.2 of the Host Extensions for IP 739 Multicasting [RFC1112] provides a function that allows leaving a 740 local IP multicast group. 742 IPV6_MULTICAST_IF: Section 5.2 of the basic socket extensions for 743 IPv6 [RFC3493] states that this sets the interface that will be 744 used for outgoing multicast packets. 746 IP_MULTICAST_TTL: This sets the time to live field t to use for 747 outgoing IPv4 multicast packets. This is used to limit scope of 748 multicast datagrams. Methods such as The Generalized TTL Security 749 Mechanism (GTSM) [RFC5082], set this value to ensure link-local 750 transmission. GTSM also requires the UDP receiver API to pass the 751 received value of this field to the application. 753 IPV6_MULTICAST_HOPS: Section 5.2 of the basic socket extensions for 754 IPv6 [RFC3493] states that sets the hop count to use for outgoing 755 multicast IPv6 packets. (This is equivalent to IP_MULTICAST_TTL 756 used for IPv4 multicast). 758 IPV6_MULTICAST_LOOP: Section 5.2 of the basic socket extensions for 759 IPv6 [RFC3493] states that this sets whether a copy of a datagram 760 is looped back by the IP layer for local delivery when the 761 datagram is sent to a group to which the sending host itself 762 belongs). 764 IPV6_JOIN_GROUP: Section 5.2 of the basic socket extensions for IPv6 765 [RFC3493] provides a function that allows an endpoint to join an 766 IPv6 multicast group. 768 SIOCGIPMSFILTER: Section 8.1 of the socket interface for MSF 769 [RFC3678] provides a function that allows reading the multicast 770 source filters. 772 SIOCSIPMSFILTER: Section 8.1 of the socket interface for MSF 773 [RFC3678] provides a function that allows setting/modifying the 774 multicast source filters. 776 IPV6_LEAVE_GROUP: Section 5.2 of the basic socket extensions for IPv6 777 [RFC3493] provides a function that allows leaving an IPv6 778 multicast group. 780 Section 4.1.1 of the Socket Interface Extensions for MSF [RFC3678] 781 updates the multicast interface to add support for MSF for IPv4 and 782 IPv6 required by IGMPv3. Three sets of API functionality are defined: 784 1. IPv4 Basic (Delta-based) API. "Each function call specifies a 785 single source address which should be added to or removed from 786 the existing filter for a given multicast group address on which 787 to listen." 789 2. IPv4 Advanced (Full-state) API. "This API allows an application 790 to define a complete source-filter comprised of zero or more 791 source addresses, and replace the previous filter with a new 792 one." 794 3. Protocol-Independent Basic MSF (Delta-based) API. 796 4. Protocol-Independent Advanced MSF (Full-state) API. 798 It specifies the following primitives: 800 IP_ADD_MEMBERSHIP: This is used to join an ASM group. 802 IP_BLOCK_SOURCE: This MSF can block data from a given multicast 803 source to a given ASM or SSM group. 805 IP_UNBLOCK_SOURCE: This updates an MSF to undo a previous call to 806 IP_UNBLOCK_SOURCE for an ASM or SSM group. 808 IP_DROP_MEMBERSHIP: This is used to leave an ASM or SSM group. (In 809 SSM, this drops all sources that have been joined for a particular 810 group and interface. The operations are the same as if the socket 811 had been closed.) 813 Section 4.1.2 of the socket interface for MSF [RFC3678] updates the 814 interface to add IPv4 MSF support to IGMPv3 using ASM: 816 IP_ADD_SOURCE_MEMBERSHIP: This is used to join an SSM group. 818 IP_DROP_SOURCE_MEMBERSHIP: This is used to leave an SSM group. 820 Section 4.1.2 of the socket interface for MSF [RFC3678] defines the 821 Advanced (Full-state) API: 823 setipv4sourcefilter This is used to join an IPv4 multicast group, or 824 to enable multicast from a specified source. 826 getipv4sourcefilter: This is used to leave an IPv4 multicast group, 827 or to filter multicast from a specified source. 829 Section 5.1 of the socket interface for MSF [RFC3678] specifies 830 Protocol-Independent Multicast API functions: 832 MCAST_JOIN_GROUP This is used to join an ASM group. 834 MCAST_JOIN_SOURCE_GROUP This is used to join an SSM group. 836 MCAST_BLOCK_SOURCE: This is used to block a source in an ASM group. 838 MCAST_UNBLOCK_SOURCE: This removes a previous MSF set by 839 MCAST_BLOCK_SOURCE. 841 MCAST_LEAVE_GROUP: This leaves a SSM group. 843 MCAST_LEAVE_GROUP: This leaves an ASM or SSM group. 845 Section 5.2 of the socket interface for MSF [RFC3678] specifies the 846 Protocol-Independent Advanced MSF (Full-state) API applicable for 847 both IPv4 and IPv6: 849 setsourcefilter This is used to join an IPv4 or IPv6 multicast group, 850 or to enable multicast from a specified source. 852 getsourcefilter: This is used to leave an IPv4 or IPv6 multicast 853 group, or to filter multicast from a specified source. 855 The Lightweight IGMPv3 (LW_IGMPv3) and MLDv2 protocol [RFC5790] 856 updates this interface (in Section 7.2 of RFC5790). 858 Appendix B. Revision Notes 860 Note to RFC-Editor: please remove this entire section prior to 861 publication. 863 Individual draft -00: 865 o This is the first version. Comments and corrections are welcome 866 directly to the authors or via the IETF TAPS working group mailing 867 list. 869 Individual draft -01: 871 o Includes ability of a UDP receiver to disallow zero checksum 872 datagrams. 874 o Fixes to references and some connect on UDP usage. 876 Individual draft -02: 878 o Fixes to address issues noted by WG. 880 o Completed Multicast section to specify modern APIs. 882 o Noted comments on API usage for UDP. 884 o Feedback from various reviewers. 886 Individual draft -03: 888 o Removes pass 2 and 3 of the TAPS analysis from this revision. 889 These are expected to be incorporated into a combined draft of the 890 TAPS WG. 892 o Fixed Typos. 894 TAPS WG draft -00: 896 o Expected to progress with draft-ietf-taps-transports-usage of the 897 TAPS WG. 899 TAPS WG draft -01: 901 o No intentional changes were made to the specification of 902 primitives, this update is editorial 904 o Reorganised text to eliminate the appendices. 906 o Editorial changes were make to complete the document for a WGLC. 908 o Rephrasing to eliminate using references as nouns, and to make 909 text more consistent. 911 o One appendix was incorporated. 913 o This appendix was moved to the end (for later deletion by the RFC- 914 Ed). 916 TAPS WG draft -02: 918 o Updated to align with latest taps-transport-usage ID. 920 o Revised to clarify MTU usage and track work in IPv6 PMTU 922 o Usage of DF clarified. 924 TAPS WG draft -03 926 o edit to MMS entries. 928 TAPS WG draft -04 930 o Typos noted by Tommy Pauly 4/6/2017 and corrected here. 932 o Checked and corrected parenthesis and use of period. 934 o Document Shepherd review 7/2017. 936 o Fixed citations and abbreviations. 938 Authors' Addresses 940 Godred Fairhurst 941 University of Aberdeen 942 School of Engineering 943 Fraser Noble Building 944 Fraser Noble Building Aberdeen, AB24 3UE 945 UK 947 Email: gorry@erg.abdn.ac.uk 948 Tom Jones 949 University of Aberdeen 950 School of Engineering 951 Fraser Noble Building 952 Aberdeen, AB24 3UE 953 UK 955 Email: tom@erg.abdn.ac.uk