draft-ietf-taps-transports-usage-udp-03.txt   draft-ietf-taps-transports-usage-udp-04.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: November 23, 2017 May 24, 2017 Expires: January 16, 2018 July 17, 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-03 draft-ietf-taps-transports-usage-udp-04
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. The features offered by the Internet datagram transport service. The
resulting road map to documentation may be of help to users of the resulting road map to documentation may be of help to users of the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://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 November 23, 2017. This Internet-Draft will expire on January 16, 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 (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . . 3 3. UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . . 3
3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . . 3 3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . . 4
3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 10 3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 10
3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 10 3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 10
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Multicast Primitives . . . . . . . . . . . . . . . . . 14 Appendix A. Multicast Primitives . . . . . . . . . . . . . . . . . 15
Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 2, line 48 skipping to change at page 2, line 48
/IP applications is the "socket" interface [POSIX]. An application /IP applications is the "socket" interface [POSIX]. An application
can use the recv() and send() POSIX functions as well as the can use the recv() and send() POSIX functions as well as the
recvfrom() and sendto() and recvmsg() and sendmsg() functions. The recvfrom() and sendto() and recvmsg() and sendmsg() functions. The
UDP and UDP-Lite sockets API differs from that for TCP in several key 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].) ways. (Examples of usage of this API are provided in [STEVENS].)
Additional functions in the sockets API are provided by socket Additional functions in the sockets API are provided by socket
options, examples include: options, examples include:
o SO_REUSEADDR specifies the rules for validating addresses supplied o SO_REUSEADDR specifies the rules for validating addresses supplied
to bind() should allow reuse of local addresses to bind() should allow reuse of local addresses.
o SO_REUSEPORT specifies that the rules for validating ports o SO_REUSEPORT specifies that the rules for validating ports
supplied to bind() should allow reuse of a local port supplied to bind() should allow reuse of a local port.
o IP_RECVTTL returns the IP Time To Live (TTL) field from IP header o IP_RECVTTL returns the IP Time To Live (TTL) field from IP header
of a received datagram. 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 of using UDP. The use of this API is discussed in the RFC series in
the UDP Guidelines [RFC8085]. 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 the next section follows the methodology defined The description in Section 3 follows the methodology defined by the
by the IETF TAPS working group [I-D.ietf-taps-transports-usage]. IETF TAPS working group [I-D.ietf-taps-transports-usage].
Specifically, it provides the first pass of this process, which Specifically, it provides the first pass of this process, which
discusses the relevant RFC text describing primitives for each discusses the relevant RFC text describing primitives for each
protocol. protocol.
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 is intended as a contribution to the Transport Services This document is intended as a contribution to the Transport Services
(TAPS) working group to assist in analysis of the UDP and UDP-Lite (TAPS) working group to assist in analysis of the UDP and UDP-Lite
transport interface. It uses common terminology defined in "Usage of transport interface. It uses common terminology defined in "Usage of
Transport Features Provided by IETF Transport Protocols" [I-D.ietf- Transport Features Provided by IETF Transport Protocols" [I-D.ietf-
taps-transports-usage]. This document also refers to the terminology taps-transports-usage]. This document also refers to the terminology
of RFC 2119 [RFC2119], but does not itself define new terms using of RFC 2119 [RFC2119], but does not itself define new terms using
this terminology. this terminology.
3. UDP and UDP-Lite Primitives 3. UDP and UDP-Lite Primitives
The User Datagram Protocol (UDP) [RFC0768][RFC8200] and UDP-Lite
protocols [RFC3828] are IETF standards track transport protocols.
These protocols provide unidirectional, datagram services that
preserve message boundaries.
This section summarizes the relevant text parts of the RFCs This section summarizes 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 (in and how the transport protocols provide to the application and how the transport
transport is used (based on abstract API descriptions, where they are is used (based on abstract API descriptions, where they are
available). available). It describes how UDP is used with IPv4 or IPv6 to send
unicast or anycast datagrams and use to send broadcast datagrams for
This section describes unicast usage, but UDP and UDP-Lite also IPv4. A set of network-layer primitives required to use UDP or UDP-
support IPv4 broadcast and IPv4/IPv6 multicast [RFC8085]. Many Lite with IP multicast (for IPv4 and IPv6) have been specified in the
primitives also apply when the transports are used with IP broadcast RFC series. Appendix A describes where to find documentation for
and multicast. Appendix 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 multicast (for IPv4 and IPv6).
or UDP-Lite with IP multicast.
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 be able to create receive, source, and
destination ports and addresses, and provide operations to receive destination ports and addresses (setting the source and destination
data based on ports with an indication of source port and address. ports and addresses), and provide operations to receive data based on
Operations should be provided that allows datagrams be sent ports (with an indication of source port and address). Operations
specifying the source and destination ports and addresses to be sent. should be provided that allows datagrams be sent, specifying the
source and destination ports and addresses to be used.
UDP has been defined for IPv6 [RFC2460], 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] defines an update to the UDP transport
specified in RFC 2460. This enables use of a zero UDP checksum mode specified in RFC 8200. This enables use of a zero UDP checksum mode
with a tunnel protocol, providing that the method satisfies the with a tunnel protocol, providing that the method satisfies the
requirements in the corresponding applicability statement [RFC6936]. requirements in the corresponding applicability 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
skipping to change at page 5, line 49 skipping to change at page 6, line 8
'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: Two forms of usage may be identified for 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
skipping to change at page 6, line 39 skipping to change at page 6, line 46
primitive that cannot be sent atomically in a datagram will not be primitive that cannot be sent atomically in a datagram will not be
sent by the network layer, generating an error. sent by the network layer, generating an error.
RECEIVE: The RECEIVE primitive allocates a receiving buffer to RECEIVE: The RECEIVE primitive allocates a receiving buffer to
accommodate a received datagram. The primitive returns the number accommodate a received datagram. The primitive returns the number
of bytes provided from a received UDP datagram. Section 4.1.3.5 of bytes provided from a received UDP datagram. Section 4.1.3.5
of the requirements of Internet hosts [RFC1122] states "When a UDP of the requirements of Internet hosts [RFC1122] states "When a UDP
datagram is received, its specific-destination address MUST be datagram is received, its specific-destination address MUST be
passed up to the application layer." passed up to the application layer."
CHECKSUM_ENABLED: The optional CHECKSUM primitive controls whether a CHECKSUM_ENABLED: The optional CHECKSUM_ENABLED primitive controls
sender enables the UDP checksum when sending datagrams ( [RFC0768] whether a sender enables the UDP checksum when sending datagrams (
and [RFC6935] [RFC6936] [RFC8085]). When unset, this overrides the [RFC0768] and [RFC6935] [RFC6936] [RFC8085]). When unset, this
default UDP behaviour, disabling the checksum on sending. Section overrides the default UDP behaviour, disabling the checksum on
4.1.3.4 of the requirements for Internet hosts [RFC1122] states sending. Section 4.1.3.4 of the requirements for Internet hosts
"An application MAY optionally be able to control whether a UDP [RFC1122] states "An application MAY optionally be able to control
checksum will be generated, but it MUST default to checksumming whether a UDP checksum will be generated, but it MUST default to
on." checksumming on."
REQUIRE_CHECKSUM: The optional REQUIRE_CHECKSUM primitive determines REQUIRE_CHECKSUM: The optional REQUIRE_CHECKSUM primitive determines
whether UDP datagrams received with a zero checksum are permitted whether UDP datagrams received with a zero checksum are permitted
or discarded, UDP defaults to requiring checksums. Section or discarded, UDP defaults to requiring checksums. Section
4.1.3.4 of the requirements for Internet hosts [RFC1122] states 4.1.3.4 of the requirements for Internet hosts [RFC1122] states
"An application MAY optionally be able to control whether UDP "An application MAY optionally be able to control whether UDP
datagrams without checksums should be discarded or passed to the datagrams without checksums should be discarded or passed to the
application." Section 3.1 of the specification for UDP-Lite application." Section 3.1 of the specification for UDP-Lite
[RFC3828] requires that the checksum field is non-zero, and hence [RFC3828] requires that the checksum field is non-zero, and hence
the UDP-Lite API must discard all datagrams received with a zero the UDP-Lite API must discard all datagrams received with a zero
checksum. checksum.
SET_IP_OPTIONS: The SET_IP_OPTIONS primitive request the network- SET_IP_OPTIONS: The SET_IP_OPTIONS primitive requests the network-
layer to send a datagram with the specified IP options. Section layer to send a datagram with the specified IP options. Section
4.1.3.2 of the requirements for Internet hosts[RFC1122] states 4.1.3.2 of the requirements for Internet hosts[RFC1122] states
that an "application MUST be able to specify IP options to be sent 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 in its UDP datagrams, and UDP MUST pass these options to the IP
layer." layer."
GET_IP_OPTIONS: The GET_IP_OPTIONS primitive retrieves the IP options GET_IP_OPTIONS: The GET_IP_OPTIONS primitive retrieves the IP options
of a datagram received at the network-layer. Section 4.1.3.2 of of a datagram received at the network-layer. Section 4.1.3.2 of
the requirements for Internet hosts[RFC1122] states that a UDP the requirements for Internet hosts[RFC1122] states that a UDP
receiver "MUST pass any IP option that it receives from the IP receiver "MUST pass any IP option that it receives from the IP
layer transparently to the application layer". layer transparently to the application layer".
SET_DF: The SET_DF primitive allows the network-layer to fragment SET_DF: The SET_DF primitive allows the network-layer to fragment
packets using the Fragment Offset in IPv4 [RFC6864] and a host to packets using the Fragment Offset in IPv4 [RFC6864] and a host to
use Fragment Headers in IPv6 [RFC2460]. The SET_DF primitive sets use Fragment Headers in IPv6 [RFC8200]. The SET_DF primitive sets
the Don't Fragment (DF) flag in the IPv4 packet header that the Don't Fragment (DF) flag in the IPv4 packet header that
carries a UDP datagram, which allows routers to fragment IPv4 carries a UDP datagram, which allows routers to fragment IPv4
packets. Although some specific applications rely on packets. Although some specific applications rely on
fragmentation support, in general, a UDP application should fragmentation support, in general, a UDP application should
implement a method that avoids IP fragmentation (section 4 of implement a method that avoids IP fragmentation (section 4 of
[RFC8085]). NOTE: In many other IETF transports (e.g., TCP, SCTP) [RFC8085]). NOTE: In many other IETF transports (e.g., TCP, SCTP)
the transport provides the support needed to use DF. However, when the transport provides the support needed to use DF. However, when
using UDP, the application is responsible for the techniques using UDP, the application is responsible for the techniques
needed to discover the effective path maximum transmission unit needed to discover the effective Path Maximum Transmission Unit
(PMTU) allowed on the network path, coordinating with the network (PMTU) allowed on the network path, coordinating with the network
layer. The acceptable maximum packet size can be determined using layer. The acceptable maximum packet size can be determined using
Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path
MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis]. MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis].
GET_MMS_S: The GET_MMS_S primitive retrieves a network-layer value GET_MMS_S: The GET_MMS_S primitive retrieves a network-layer value
that indicates the maximum message size (MMS) that may be sent at that indicates the maximum message size (MMS) that may be sent at
the transport layer using a non-fragmented IP packet from the the transport layer using a non-fragmented IP packet from the
configured interface. This value is specified in section 6.1 of configured interface. This value is specified in section 6.1 of
[RFC1191] and section 5.1 of [I-D.ietf-6man-rfc1981bis]. It is [RFC1191] and section 5.1 of [I-D.ietf-6man-rfc1981bis]. It is
skipping to change at page 8, line 31 skipping to change at page 9, line 10
GET_TTL: The GET_TTL primitive retrieves the value of the TTL field GET_TTL: The GET_TTL primitive retrieves the value of the TTL field
in a network packet received at the network-layer. Section in a network packet received at the network-layer. Section
3.2.2.4 of the requirements for Internet hosts [RFC1122] states 3.2.2.4 of the requirements for Internet hosts [RFC1122] states
that a UDP receiver "MAY pass the received ToS up to the that a UDP receiver "MAY pass the received ToS up to the
application layer" When used for applications such as the application layer" When used for applications such as the
Generalized TTL Security Mechanism (GTSM) [RFC5082], this needs Generalized TTL Security Mechanism (GTSM) [RFC5082], this needs
the UDP receiver API to pass the received value of this field to the UDP receiver API to pass the received value of this field to
the application. the application.
SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS primitive sets the SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS primitive sets the
network-layer hop limit field in an IPv6 packet header [RFC2460] network-layer hop limit field in an IPv6 packet header [RFC8200]
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
[RFC2460] information of a received UDP datagram. For IPv6 [RFC8200] information of a received UDP datagram. For IPv6
unicast datagrams, this is functionally equivalent to the GET_TTL unicast datagrams, this is functionally equivalent to the GET_TTL
IPv4 function. 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 Differentiated Services (DiffServ) Code Point, DSCP, (or
the legacy Type of Service, ToS) value [RFC2474] to be used in the 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. field of an IP header of a packet that carries a UDP datagram.
Section 2.4 of the requirements for Internet hosts[RFC1123] states Section 2.4 of the requirements for Internet hosts[RFC1123] states
that "Applications MUST select appropriate ToS values when they that "Applications MUST select appropriate ToS values when they
invoke transport layer services, and these values MUST be invoke transport layer services, and these values MUST be
configurable.". The application should be able to change the ToS configurable.". The application should be able to change the ToS
during the connection lifetime, and the ToS value should be passed during the connection lifetime, and the ToS value should be passed
to the IP layer unchanged. Section 4.1.4 of [RFC1122] also states 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 that on reception the "UDP MAY pass the received ToS value up to
the application layer". The Differentiated Services (diffuser) the application layer". The DiffServ model [RFC2475] [RFC3260]
model [RFC2475] [RFC3260] replaces this field in the IP Header replaces this field in the IP Header assigning the six most
assigning the six most significant bits to carry the significant bits to carry the DSCP field [RFC2474]. Preserving
Differentiated Services Code Point (DSCP) field [RFC2474]. the intention of the host requirements [RFC1122] to allow the
Preserving the intention of the hist requirements [RFC1122] to application to specify the "Type of Service", this should be
allow the application to specify the "Type of Service", this interpreted to mean that an API should allow the application to
should be interpreted to mean that an API should allow the set the DSCP. Section 3.1.6 of the UDP Guidelines [RFC8085]
application to set the DSCP. Section 3.1.6 of the UDP Guidelines describes the way UDP applications should use this field.
[RFC8085] describes the way UDP applications should use this Normally a UDP socket will assign a single DSCP value to all
field. Normally a UDP socket will assign a single DSCP value to datagrams in a flow, but a sender is allowed to use different DSCP
all datagrams in a flow, but a sender is allowed to use different values for datagrams within the same flow in certain
DSCP values for datagrams within the same flow in certain
cases[RFC8085]. There are guidelines for WebRTC that illustrate cases[RFC8085]. There are guidelines for WebRTC that illustrate
this use [RFC7657]. 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 ECN field in the IP Header of a UDP datagram. The ECN field the Explicit Congestion Notification (ECN) field in the IP Header
defaults to a value of 00. When the use of the ToS field was of a UDP datagram. The ECN field defaults to a value of 00. When
redefined by diffserv [RFC3260], 2 bits of the field were assigned the use of the ToS field was redefined by DiffsServ [RFC3260], 2
to support Explicit Congestion Notification (ECN) [RFC3168]. bits of the field were assigned to support ECN [RFC3168]. Section
Section 3.1.5 of the UDP Guidelines [RFC8085] describes the way 3.1.5 of the UDP Guidelines [RFC8085] describes the way UDP
UDP applications should use this field. NOTE: In many other IETF 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
protocol is itself responsible for the techniques needed to use protocol is itself responsible for the techniques needed to use
ECN. ECN.
GET_ECN: The GET_ECN primitive is a network-layer function that GET_ECN: The GET_ECN primitive is a network-layer function that
returns the value of the ECN field in the IP Header of a received returns the value of the ECN field in the IP Header of a received
UDP datagram. Section 3.1.5 of the UDP Guidelines [RFC8085] UDP datagram. Section 3.1.5 of the UDP Guidelines [RFC8085]
states that a UDP receiver "MUST check the ECN field at the states that a UDP receiver "MUST check the ECN field at the
receiver for each UDP datagram that it receives on this port", receiver for each UDP datagram that it receives on this port",
skipping to change at page 10, line 26 skipping to change at page 10, line 35
datagrams are sent when this primitive is executed. datagrams are sent when this primitive is executed.
3.1.1. Excluded Primitives 3.1.1. Excluded Primitives
Section 3.4 of the host requirements [RFC1122] also describes Section 3.4 of the host requirements [RFC1122] also describes
"GET_MAXSIZES, GET_SRCADDR (Section 3.3.4.3) and ADVISE_DELIVPROB:". "GET_MAXSIZES, GET_SRCADDR (Section 3.3.4.3) and ADVISE_DELIVPROB:".
These mechanisms are no longer used. It also specifies use of the These mechanisms are no longer used. It also specifies use of the
Source Quench ICMP message, which has since been deprecated Source Quench ICMP message, which has since been deprecated
[RFC6633]. [RFC6633].
The IPV6_V6ONLY function defined in Section 5.3 of the basic socket The IPV6_V6ONLY function is a network-layer primitive that applies to
interface for IPv6 [RFC3493] restricts the use of information from all transport services, defined in Section 5.3 of the basic socket
the name resolver to only allow communication of AF_INET6 sockets to interface for IPv6 [RFC3493]. This restricts the use of information
use IPv6 only. This is not considered part of the transport service. 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 3.2. Primitives Provided by UDP-Lite
The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] provides The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] provides
similar services to UDP. It changed the semantics of the UDP "payload similar services to UDP. It changed the semantics of the UDP "payload
length" field to that of a "checksum coverage length" field. UDP- length" field to that of a "checksum coverage length" field. UDP-
Lite requires the pseudo-header checksum to be computed at the sender Lite requires the pseudo-header checksum to be computed at the sender
and checked at a receiver. Apart from the length and coverage and checked at a receiver. Apart from the length and coverage
changes, UDP-Lite is semantically identical to UDP. changes, UDP-Lite is semantically identical to UDP.
skipping to change at page 11, line 20 skipping to change at page 11, line 34
primitive to set the coverage length provided by the UDP checksum. primitive to set the coverage length provided by the UDP checksum.
Section 3.3 of the UDP-Lite MIB [RFC5097] states that Section 3.3 of the UDP-Lite MIB [RFC5097] states that
"Applications that wish to define the payload as partially "Applications that wish to define the payload as partially
insensitive to bit errors ... Should do this by an explicit insensitive to bit errors ... Should do this by an explicit
system call on the sender side." The default is to provide the system call on the sender side." The default is to provide the
same coverage as for UDP. same coverage as for UDP.
SET_MIN_COVERAGE The SET_MIN_COVERAGE primitive sets the minimum SET_MIN_COVERAGE The SET_MIN_COVERAGE primitive sets the minimum
acceptable coverage protection for received datagrams. UDP-Lite acceptable coverage protection for received datagrams. UDP-Lite
traffic uses this primitive to set the coverage length that is traffic uses this primitive to set the coverage length that is
checked on receive (section 1.1 of the UDP-Lite MIB [RFC5097] checked on receive. (Section 1.1 of the UDP-Lite MIB [RFC5097]
describes the corresponding MIB entry as describes the corresponding MIB entry as
udpliteEndpointMinCoverage). Section 3.3 of the UDP-Lite udpliteEndpointMinCoverage.) Section 3.3 of the UDP-Lite
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). Thanks (NEAT). The views expressed are solely those of the author(s). Thanks
to all who have commented or contributed, including Joe Touch, Ted to all who have commented or contributed, including Joe Touch, Ted
Hardie and Aaron Falk. 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 12, line 20 skipping to change at page 12, line 30
[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",
Internet-Draft draft-ietf-taps-transports-usage-04, April Internet-Draft draft-ietf-taps-transports-usage-04, April
2017. 2017.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/ 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/
info/rfc768>. info/rfc768>.
[RFC1112] Deering, S.E., "Host extensions for IP multicasting", STD
5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://
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, DOI 10.17487/ Communication Layers", STD 3, RFC 1122, DOI 10.17487/
RFC1122, October 1989, <http://www.rfc-editor.org/info/ RFC1122, October 1989, <http://www.rfc-editor.org/info/
rfc1122>. rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, DOI 10.17487/ Application and Support", STD 3, RFC 1123, DOI 10.17487/
RFC1123, October 1989, <http://www.rfc-editor.org/info/ RFC1123, October 1989, <http://www.rfc-editor.org/info/
rfc1123>. rfc1123>.
[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", RFC [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", RFC
1191, DOI 10.17487/RFC1191, November 1990, <http://www 1191, DOI 10.17487/RFC1191, November 1990, <http://www
.rfc-editor.org/info/rfc1191>. .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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, <http://www.rfc-editor.org/info/ RFC2119, March 1997, <http://www.rfc-editor.org/info/
rfc2119>. rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2553,
DOI 10.17487/RFC2553, March 1999, <http://www.rfc-
editor.org/info/rfc2553>.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
DOI 10.17487/RFC3168, September 2001, <http://www.rfc- DOI 10.17487/RFC3168, September 2001, <http://www.rfc-
editor.org/info/rfc3168>. 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", RFC Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, DOI 10.17487/RFC3493, February 2003, <http://www 3493, DOI 10.17487/RFC3493, February 2003, <http://www
.rfc-editor.org/info/rfc3493>. .rfc-editor.org/info/rfc3493>.
skipping to change at page 13, line 28 skipping to change at page 13, line 33
[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, <http://www RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www
.rfc-editor.org/info/rfc6936>. .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, <http://www.rfc-editor.org/info/rfc8085>. March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/
RFC8200, July 2017, <http://www.rfc-editor.org/info/
rfc8200>.
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, DOI Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
10.17487/RFC2474, December 1998, <http://www.rfc- 10.17487/RFC2474, December 1998, <http://www.rfc-
editor.org/info/rfc2474>. 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,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2553,
DOI 10.17487/RFC2553, March 1999, <http://www.rfc-
editor.org/info/rfc2553>.
[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,
<http://www.rfc-editor.org/info/rfc3260>. <http://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, <http:// 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <http://
www.rfc-editor.org/info/rfc3376>. 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
skipping to change at page 15, line 4 skipping to change at page 15, line 19
[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, DOI (Diffserv) and Real-Time Communication", RFC 7657, DOI
10.17487/RFC7657, November 2015, <http://www.rfc- 10.17487/RFC7657, November 2015, <http://www.rfc-
editor.org/info/rfc7657>. 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. Guidance on the use of UDP and Lite support IPv4/IPv6 Multicast. Multicast services are not
UDP-Lite for multicast services is provided in the UDP considered by the IETF TAPS WG, but the currently specified
Guidelines[RFC8085]. primitives are included for completeness in this appendix. Guidance
on the use of UDP and UDP-Lite for multicast services is provided in
the UDP Guidelines[RFC8085].
IP multicast may be supported using the Any Source Multicast (ASM) IP multicast may be supported using the Any Source Multicast (ASM)
model or by the Source-Specific Multicast (SSM) model. The latter model or by the Source-Specific Multicast (SSM) model. The latter
requires use of a Multicast Source Filter (MSF) when specifying an IP requires use of a Multicast Source Filter (MSF) when specifying an IP
multicast group destination address. multicast group destination address.
Use of multicast requires additional primitives at the transport API Use of multicast requires additional primitives at the transport API
that need to be called to coordinate operation of the IPv4 and IPv6 that need to be called to coordinate operation of the IPv4 and IPv6
network layer protocols. For example, to receive datagrams sent to a network layer protocols. For example, to receive datagrams sent to a
group, an endpoint must first become a member of a multicast group at group, an endpoint must first become a member of a multicast group at
the network layer. Local multicast reception is signalled for IPv4 the network layer. Local multicast reception is signalled for IPv4
by the Internet Group Management Protocol (IGMP) [RFC3376] [RFC4604]. by the Internet Group Management Protocol (IGMP) [RFC3376] [RFC4604].
IPv6 uses the equivalent Multicast Listener Discovery (MLD) protocol IPv6 uses the equivalent Multicast Listener Discovery (MLD) protocol
[RFC3810] [RFC5790], carried over ICMPv6. A lightweight version of [RFC3810] [RFC5790], carried over ICMPv6. A lightweight version of
these protocols has also been specified [RFC5790]. these protocols has also been specified [RFC5790].
The following are defined: The following are defined:
JoinLocalGroup: 1 of the basic socket extensions for IPv6 [RFC3493] JoinGroup: Section 7.1 of the Host Extensions for IP Multicasting
provides a function that allows receivi9ng traffic from a local [RFC1112] provides a function that allows receiving traffic from
IPv4 multicast group. an IP multicast group.
JoinLocalGroup: Section 7.2 of the Host Extensions for IP
Multicasting [RFC1112] provides a function that allows receiving
traffic from a local IP multicast group.
LeaveHostGroup: Section 7.1 of the Host Extensions for IP
Multicasting [RFC1112] provides a function that allows leaving an
IP multicast group.
LeaveLocalGroup: Section 7.2 of the Host Extensions for IP
Multicasting [RFC1112] provides a function that allows leaving a
local IP multicast group.
IPV6_MULTICAST_IF: Section 5.2 of the basic socket extensions for IPV6_MULTICAST_IF: Section 5.2 of the basic socket extensions for
IPv6 [RFC2553] states that this sets the interface that will be IPv6 [RFC3493] states that this sets the interface that will be
used for outgoing multicast packets. used for outgoing multicast packets.
IP_MULTICAST_TTL: This sets the time to live field t to use for IP_MULTICAST_TTL: This sets the time to live field t to use for
outgoing IPv4 multicast packets. This is used to limit scope of outgoing IPv4 multicast packets. This is used to limit scope of
multicast datagrams. Methods such as GTSM [RFC5082], set this multicast datagrams. Methods such as The Generalized TTL Security
value to ensure link-local transmission. GTSM also requires the Mechanism (GTSM) [RFC5082], set this value to ensure link-local
UDP receiver API to pass the received value of this field to the transmission. GTSM also requires the UDP receiver API to pass the
application. received value of this field to the application.
IPV6_MULTICAST_HOPS: Section 5.2 of the basic socket extensions for IPV6_MULTICAST_HOPS: Section 5.2 of the basic socket extensions for
IPv6 [RFC2553] states that sets the hop count to use for outgoing IPv6 [RFC3493] states that sets the hop count to use for outgoing
multicast IPv6 packets. (This is equivalent to IP_MULTICAST_TTL multicast IPv6 packets. (This is equivalent to IP_MULTICAST_TTL
used for IPv4 multicast). used for IPv4 multicast).
IPV6_MULTICAST_LOOP: Section 5.2 of the basic socket extensions for IPV6_MULTICAST_LOOP: Section 5.2 of the basic socket extensions for
IPv6 [RFC2553] states that this sets whether a copy of a datagram IPv6 [RFC3493] states that this sets whether a copy of a datagram
is looped back by the IP layer for local delivery when the is looped back by the IP layer for local delivery when the
datagram is sent to a group to which the sending host itself datagram is sent to a group to which the sending host itself
belongs). belongs).
IPV6_JOIN_GROUP: Section 5.2 of the basic socket extensions for IPv6 IPV6_JOIN_GROUP: Section 5.2 of the basic socket extensions for IPv6
[RFC2553] provides a function that allows an endpoint to join an [RFC3493] provides a function that allows an endpoint to join an
IPv6 multicast group. IPv6 multicast group.
SIOCGIPMSFILTER: Section 8.1 of the socket interface for MSF SIOCGIPMSFILTER: Section 8.1 of the socket interface for MSF
[RFC3678] provides a function that allows reading the multicast [RFC3678] provides a function that allows reading the multicast
source filters. source filters.
SIOCSIPMSFILTER: Section 8.1 of the socket interface for MSF SIOCSIPMSFILTER: Section 8.1 of the socket interface for MSF
[RFC3678] provides a function that allows setting/modifying the [RFC3678] provides a function that allows setting/modifying the
multicast source filters. multicast source filters.
IPV6_LEAVE_GROUP: Section 5.2 of the basic socket extensions for IPv6 IPV6_LEAVE_GROUP: Section 5.2 of the basic socket extensions for IPv6
[RFC2553] provides a function that allows leaving an IPv6 [RFC3493] provides a function that allows leaving an IPv6
multicast group.
LeaveHostGroup: Section 7.1 of the basic socket extensions for IPv6
[RFC3493] provides a function that allows leaving an IPv4
multicast group.
LeaveLocalGroup: Section 7.1 of the basic socket extensions for IPv6
[RFC3493] provides a function that allows leaving a local IPv4
multicast group. multicast group.
Section 4.1.1 of the Socket Interface Extensions for MSF [RFC3678] Section 4.1.1 of the Socket Interface Extensions for MSF [RFC3678]
updates the multicast interface to add support for MSF for IPv4 and updates the multicast interface to add support for MSF for IPv4 and
IPv6 required by IGMPv3. Three sets of API functionality are defined: IPv6 required by IGMPv3. Three sets of API functionality are defined:
1. IPv4 Basic (Delta-based) API. "Each function call specifies a 1. IPv4 Basic (Delta-based) API. "Each function call specifies a
single source address which should be added to or removed from single source address which should be added to or removed from
the existing filter for a given multicast group address on which the existing filter for a given multicast group address on which
to listen." to listen."
2. IPv4 Advanced (Full-state) API. "This API allows an application 2. IPv4 Advanced (Full-state) API. "This API allows an application
to define a complete source-filter comprised of zero or more to define a complete source-filter comprised of zero or more
source addresses, and replace the previous filter with a new source addresses, and replace the previous filter with a new
one." one."
3. Protocol-Independent Basic MSF (Delta-based) API 3. Protocol-Independent Basic MSF (Delta-based) API.
4. Protocol-Independent Advanced MSF (Full-state) API 4. Protocol-Independent Advanced MSF (Full-state) API.
It specifies the following primitives: It specifies the following primitives:
IP_ADD_MEMBERSHIP: This is used to join an ASM group. IP_ADD_MEMBERSHIP: This is used to join an ASM group.
IP_BLOCK_SOURCE: This MSF can block data from a given multicast IP_BLOCK_SOURCE: This MSF can block data from a given multicast
source to a given ASM or SSM group. source to a given ASM or SSM group.
IP_UNBLOCK_SOURCE: This updates an MSF to undo a previous call to IP_UNBLOCK_SOURCE: This updates an MSF to undo a previous call to
IP_UNBLOCK_SOURCE for an ASM or SSM group. IP_UNBLOCK_SOURCE for an ASM or SSM group.
skipping to change at page 19, line 15 skipping to change at page 19, line 37
o Updated to align with latest taps-transport-usage ID. o Updated to align with latest taps-transport-usage ID.
o Revised to clarify MTU usage and track work in IPv6 PMTU o Revised to clarify MTU usage and track work in IPv6 PMTU
o Usage of DF clarified. o Usage of DF clarified.
TAPS WG draft -03 TAPS WG draft -03
o edit to MMS entries. o edit to MMS entries.
TAPS WG draft -04
o Typos noted by Tommy Pauly 4/6/2017 and corrected here.
o Checked and corrected parenthesis and use of period.
o Document Shepherd review 7/2017.
o Fixed citations and abbreviations.
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. 45 change blocks. 
104 lines changed or deleted 133 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/