doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc8841.txt b/doc/rfc/rfc8841.txt
new file mode 100644
index 0000000..01029e2
--- /dev/null
+++ b/doc/rfc/rfc8841.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Holmberg
+Request for Comments: 8841                                      Ericsson
+Category: Standards Track                                     R. Shpount
+ISSN: 2070-1721                                              TurboBridge
+                                                               S. Loreto
+                                                            G. Camarillo
+                                                                Ericsson
+                                                            January 2021
+
+
+ Session Description Protocol (SDP) Offer/Answer Procedures for Stream
+   Control Transmission Protocol (SCTP) over Datagram Transport Layer
+                       Security (DTLS) Transport
+
+Abstract
+
+   The Stream Control Transmission Protocol (SCTP) is a transport
+   protocol used to establish associations between two endpoints.  RFC
+   8261 specifies how SCTP can be used on top of the Datagram Transport
+   Layer Security (DTLS) protocol, which is referred to as SCTP-over-
+   DTLS.
+
+   This specification defines the following new Session Description
+   Protocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP"
+   and "TCP/DTLS/SCTP".  This specification also specifies how to use
+   the new proto values with the SDP offer/answer mechanism for
+   negotiating SCTP-over-DTLS associations.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8841.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions
+   3.  SCTP Terminology
+   4.  SDP Media Descriptions
+     4.1.  General
+     4.2.  Protocol Identifiers
+     4.3.  Media-Format Management
+     4.4.  Syntax
+       4.4.1.  General
+       4.4.2.  SDP Media Description Values
+     4.5.  Example
+   5.  SDP "sctp-port" Attribute
+     5.1.  General
+     5.2.  Syntax
+     5.3.  Mux Category
+   6.  SDP "max-message-size" Attribute
+     6.1.  General
+     6.2.  Syntax
+     6.3.  Mux Category
+   7.  UDP/DTLS/SCTP Transport Realization
+   8.  TCP/DTLS/SCTP Transport Realization
+   9.  Association and Connection Management
+     9.1.  General
+     9.2.  SDP "sendrecv"/"sendonly"/"recvonly"/"inactive" Attributes
+     9.3.  SCTP Association
+     9.4.  DTLS Association (UDP/DTLS/SCTP and TCP/DTLS/SCTP)
+     9.5.  TCP Connection (TCP/DTLS/SCTP)
+   10. SDP Offer/Answer Procedures
+     10.1.  General
+     10.2.  Generating the Initial SDP Offer
+     10.3.  Generating the SDP Answer
+     10.4.  Offerer Processing of the SDP Answer
+     10.5.  Modifying the Session
+   11. Multihoming Considerations
+   12. NAT Considerations
+     12.1.  General
+     12.2.  ICE Considerations
+   13. Examples
+     13.1.  Establishment of UDP/DTLS/SCTP Association
+   14. Security Considerations
+   15. IANA Considerations
+     15.1.  New SDP Proto Values
+     15.2.  New SDP Attributes
+       15.2.1.  sctp-port
+       15.2.2.  max-message-size
+     15.3.  association-usage Name Registry
+   16. References
+     16.1.  Normative References
+     16.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The Session Description Protocol (SDP) [RFC4566] provides a general-
+   purpose format for describing multimedia sessions in announcements or
+   invitations.  "TCP-Based Media Transport in the Session Description
+   Protocol (SDP)" [RFC4145] specifies a general mechanism for
+   describing and establishing TCP [RFC0793] streams.  "Connection-
+   Oriented Media Transport over the Transport Layer Security (TLS)
+   Protocol in the Session Description Protocol (SDP)" [RFC8122] extends
+   [RFC4145] to describe TCP-based media streams that are protected
+   using TLS.
+
+   The Stream Control Transmission Protocol (SCTP) [RFC4960] is a
+   reliable transport protocol used to transport data between two
+   endpoints using SCTP associations.
+
+   [RFC8261] specifies how SCTP can be used on top of the Datagram
+   Transport Layer Security (DTLS) protocol, an arrangement referred to
+   as SCTP-over-DTLS.
+
+   This specification defines the following new SDP [RFC4566] protocol
+   identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP".
+   This document also specifies how to use the new proto values with the
+   SDP offer/answer mechanism [RFC3264] for negotiating SCTP-over-DTLS
+   associations.
+
+      |  NOTE: Due to the characteristics of TCP, while multiple SCTP
+      |  streams can still be used, usage of "TCP/DTLS/SCTP" will always
+      |  force ordered and reliable delivery of the SCTP packets, which
+      |  limits the usage of the SCTP options.  Therefore, it is
+      |  RECOMMENDED that TCP is only used in situations where UDP
+      |  traffic is blocked.
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  SCTP Terminology
+
+   SCTP association:  A protocol relationship between SCTP endpoints,
+      composed of the two SCTP endpoints and protocol state information
+      including verification tags and the currently active set of
+      Transmission Sequence Numbers (TSNs), etc.  An association can be
+      uniquely identified by the transport addresses used by the
+      endpoints in the association.
+
+   SCTP stream:  A unidirectional logical channel established from one
+      associated SCTP endpoint to another, within which all user
+      messages are delivered in sequence except for those submitted to
+      the unordered delivery service.
+
+   SCTP-over-DTLS:  SCTP used on top of DTLS, as specified in [RFC8261].
+
+4.  SDP Media Descriptions
+
+4.1.  General
+
+   This section defines the following new SDP media description ("m="
+   line) protocol identifiers (proto values) for describing an SCTP
+   association: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP".  The section also
+   describes how an "m=" line associated with the proto values is
+   created.
+
+   The following is the format for an "m=" line, as specified in
+   [RFC4566]:
+
+   m=<media> <port> <proto> <fmt> ...
+
+   The "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values are similar to
+   both the "UDP" and "TCP" proto values in that they only describe the
+   transport-layer protocol and not the upper-layer protocol.
+
+      |  NOTE: When the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values
+      |  are used, the underlying transport protocol is, respectively,
+      |  UDP and TCP; SCTP is carried on top of DTLS, which is on top of
+      |  those transport-layer protocols.
+
+4.2.  Protocol Identifiers
+
+   The new proto values are defined as below:
+
+   *  The "UDP/DTLS/SCTP" proto value describes an SCTP association on
+      top of a DTLS association on top of UDP, as defined in Section 7.
+
+   *  The "TCP/DTLS/SCTP" proto value describes an SCTP association on
+      top of a DTLS association on top of TCP, as defined in Section 8.
+
+4.3.  Media-Format Management
+
+   [RFC4566] states that specifications defining new proto values must
+   define the rules by which their media format (fmt) namespace is
+   managed.
+
+   An "m=" line with a proto value of "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP"
+   always describes a single SCTP association.
+
+   In addition, such an "m=" line MUST further indicate the application-
+   layer protocol using an "fmt" identifier.  There MUST be exactly one
+   fmt value per "m=" line associated with the proto values defined in
+   this specification.  The "fmt" namespace associated with those proto
+   values describes the generic application usage of the entire SCTP
+   association, including the associated SCTP streams.
+
+   When the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values are used,
+   the "m=" line fmt value, which identifies the application-layer
+   protocol, MUST be registered by IANA.  Section 15.3 defines the IANA
+   registry for the media-format namespace.
+
+      |  NOTE: A mechanism for how to describe and manage individual
+      |  SCTP streams within an SCTP association is outside the scope of
+      |  this specification.  [RFC8864] defines a mechanism for
+      |  negotiating individual SCTP streams used to realize WebRTC data
+      |  channels [RFC8831].
+
+4.4.  Syntax
+
+4.4.1.  General
+
+   This section defines the values that can be used within an SDP media
+   description ("m=" line) associated with an SCTP-over-DTLS
+   association.
+
+   This specification creates an IANA registry for "association-usage"
+   values.
+
+4.4.2.  SDP Media Description Values
+
+   When the SCTP association is used to realize a WebRTC data channel
+   [RFC8832], the <fmt> parameter value is 'webrtc-datachannel'.
+
+     +===========+===================================================+
+     | "m=" line | parameter value(s)                                |
+     | parameter |                                                   |
+     +===========+===================================================+
+     | <media>   | "application"                                     |
+     +-----------+---------------------------------------------------+
+     | <proto>   | "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP"                |
+     +-----------+---------------------------------------------------+
+     | <port>    | UDP port number (for "UDP/DTLS/SCTP")             |
+     |           | TCP port number (for "TCP/DTLS/SCTP")             |
+     +-----------+---------------------------------------------------+
+     | <fmt>     | A string denoting the association-usage, limited  |
+     |           | to the syntax of a "token" as defined in RFC 4566 |
+     +-----------+---------------------------------------------------+
+
+                   Table 1: SDP Media Description Values
+
+4.5.  Example
+
+    m=application 12345 UDP/DTLS/SCTP webrtc-datachannel
+    a=sctp-port:5000
+    a=max-message-size:100000
+
+      |  NOTE: "webrtc-datachannel" indicates the WebRTC Data Channel
+      |  Establishment Protocol defined in [RFC8832].
+
+5.  SDP "sctp-port" Attribute
+
+5.1.  General
+
+   This section defines a new SDP media-level attribute, "sctp-port".
+   The attribute can be associated with an SDP media description ("m="
+   line) with a "UDP/DTLS/SCTP" or a "TCP/DTLS/SCTP" proto value.  In
+   that case, the "m=" line port value indicates the port of the
+   underlying transport-layer protocol (UDP or TCP), and the "sctp-port"
+   value indicates the SCTP port.
+
+   No default value is defined for the SDP "sctp-port" attribute.
+   Therefore, if the attribute is not present, the associated "m=" line
+   MUST be considered invalid.
+
+      |  NOTE: This specification only defines the usage of the SDP
+      |  "sctp-port" attribute when associated with an "m=" line
+      |  containing one of the following proto values: "UDP/DTLS/SCTP"
+      |  or "TCP/DTLS/SCTP".  Usage of the attribute with other proto
+      |  values needs to be defined in a separate specification.
+
+5.2.  Syntax
+
+   The definition of the SDP "sctp-port" attribute is:
+
+   Attribute name:  sctp-port
+
+   Type of attribute:  media
+
+   Mux category:  CAUTION
+
+   Subject to charset:  No
+
+   Purpose:  Indicate the SCTP port value associated with the SDP media
+      description.
+
+   Appropriate values:  Integer
+
+   Contact name:  Christer Holmberg
+
+   Contact e-mail:  christer.holmberg@ericsson.com
+
+   Reference:  RFC 8841
+
+   Syntax:
+      sctp-port-value = 1*5(DIGIT) ; DIGIT defined in RFC 4566
+
+   The SCTP port range is between 0 and 65535 (both included).  Leading
+   zeroes MUST NOT be used.
+
+   Example:
+
+      a=sctp-port:5000
+
+5.3.  Mux Category
+
+   The mux category [RFC8859] for the SDP "sctp-port" attribute is
+   CAUTION.
+
+   As the usage of multiple SCTP associations on top of a single DTLS
+   association is outside the scope of this specification, no mux rules
+   are specified for the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto
+   values.  Future extensions that define how to negotiate multiplexing
+   of multiple SCTP associations of top of a single DTLS association
+   need to also define the mux rules for the attribute.
+
+6.  SDP "max-message-size" Attribute
+
+6.1.  General
+
+   This section defines a new SDP media-level attribute, "max-message-
+   size".  The attribute can be associated with an "m=" line to indicate
+   the maximum SCTP user message size (indicated in bytes) that an SCTP
+   endpoint is willing to receive on the SCTP association associated
+   with the "m=" line.  Different attribute values can be used in each
+   direction.
+
+   An SCTP endpoint MUST NOT send a SCTP user message with a message
+   size that is larger than the maximum size indicated by the peer, as
+   it cannot be assumed that the peer would accept such a message.
+
+   If the SDP "max-message-size" attribute contains a maximum message
+   size value of zero, it indicates that the SCTP endpoint will handle
+   messages of any size, subject to memory capacity, etc.
+
+   If the SDP "max-message-size" attribute is not present, the default
+   value is 64K.
+
+      |  NOTE: This specification only defines the usage of the SDP
+      |  "max-message-size" attribute when associated with an "m=" line
+      |  containing one of the following proto values: "UDP/DTLS/SCTP"
+      |  or "TCP/DTLS/SCTP".  Usage of the attribute with other proto
+      |  values needs to be defined in a separate specification.
+
+6.2.  Syntax
+
+   The definition of the SDP "max-message-size" attribute is:
+
+   Attribute name:  max-message-size
+
+   Type of attribute:  media
+
+   Mux category:  CAUTION
+
+   Subject to charset:  No
+
+   Purpose:  Indicate the maximum message size (indicated in bytes) that
+      an SCTP endpoint is willing to receive on the SCTP association
+      associated with the SDP media description.
+
+   Appropriate values:  Integer
+
+   Contact name:  Christer Holmberg
+
+   Contact e-mail:  christer.holmberg@ericsson.com
+
+   Reference:  RFC 8841
+
+   Syntax:
+      max-message-size-value = 1*DIGIT ; DIGIT defined in RFC 4566
+
+   Leading zeroes MUST NOT be used.
+
+   Example:
+
+      a=max-message-size:100000
+
+6.3.  Mux Category
+
+   The mux category for the SDP "max-message-size" attribute is CAUTION.
+
+   As the usage of multiple SCTP associations on top of a single DTLS
+   association is outside the scope of this specification, no mux rules
+   are specified for the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto
+   values.
+
+7.  UDP/DTLS/SCTP Transport Realization
+
+   The UDP/DTLS/SCTP transport is realized as described below:
+
+   *  SCTP on top of DTLS is realized according to the procedures
+      defined in [RFC8261]; and
+
+   *  DTLS on top of UDP is realized according to the procedures in
+      defined in [RFC6347].
+
+      |  NOTE: While [RFC8261] allows multiple SCTP associations on top
+      |  of a single DTLS association, the procedures in this
+      |  specification only support the negotiation of a single SCTP
+      |  association on top of any given DTLS association.
+
+8.  TCP/DTLS/SCTP Transport Realization
+
+   The TCP/DTLS/SCTP transport is realized as described below:
+
+   *  SCTP on top of DTLS is realized according to the procedures
+      defined in [RFC8261]; and
+
+   *  DTLS on top of TCP is realized using the framing method defined in
+      [RFC4571], with DTLS packets being sent and received instead of
+      RTP/RTCP packets using the shim defined in [RFC4571].  The length
+      field defined in [RFC4571] precedes each DTLS message, and SDP
+      signaling is done according to the procedures defined in this
+      specification.
+
+      |  NOTE: TLS on top of TCP, without using the framing method
+      |  defined in [RFC4571], is outside the scope of this
+      |  specification.  A separate proto value would need to be
+      |  registered for such transport realization.
+
+9.  Association and Connection Management
+
+9.1.  General
+
+   This section describes how to manage an SCTP association, DTLS
+   association, and TCP connection using SDP attributes.
+
+   The SCTP association, the DTLS association, and the TCP connection
+   are managed independently from each other.  Each can be established
+   and closed without impacting others.
+
+   The detailed SDP offer/answer [RFC3264] procedures for the SDP
+   attributes are described in Section 10.
+
+9.2.  SDP "sendrecv"/"sendonly"/"recvonly"/"inactive" Attributes
+
+   This specification does not define semantics for the SDP direction
+   attributes [RFC4566].  Unless the semantics of these attributes for
+   an SCTP association usage have been defined, SDP direction attributes
+   MUST be ignored if present.
+
+9.3.  SCTP Association
+
+   When an SCTP association is established, both SCTP endpoints MUST
+   initiate the SCTP association (i.e., both SCTP endpoints take the
+   "active" role).  In addition, both endpoints MUST use the same SCTP
+   port as client port and server port, in order to prevent two separate
+   SCTP associations from being established.
+
+   As both SCTP endpoints take the "active" role, the SDP "setup"
+   attribute [RFC4145] does not apply to SCTP association establishment.
+   However, the "setup" attribute does apply to establishment of the
+   underlying DTLS association and TCP connection.
+
+      |  NOTE: The procedure above is different from TCP, where one
+      |  endpoint takes the "active" role, the other endpoint takes the
+      |  "passive" role, and only the "active" endpoint initiates the
+      |  TCP connection [RFC4145].
+
+      |  NOTE: When the SCTP association is established, it is assumed
+      |  that any NAT traversal procedures for the underlying transport
+      |  protocol (UDP or TCP) have successfully been performed.
+
+   The SDP "connection" attribute [RFC4145] does not apply to the SCTP
+   association.  In order to trigger the closure of an existing SCTP
+   association and establishment of a new SCTP association, the SDP
+   "sctp-port" attribute (Section 5) is used to indicate a new
+   (different than the ones currently used) SCTP port.  The existing
+   SCTP association is closed, and the new SCTP association is
+   established, if one or both endpoints signal a new SCTP port.  The
+   "connection" attribute does apply to establishment of underlying TCP
+   connections.
+
+   Alternatively, an SCTP association can be closed using the SDP "sctp-
+   port" attribute with an attribute value of zero.  Later, a new SCTP
+   association can be established using the procedures in this section
+   for establishing an SCTP association.
+
+   SCTP associations might be closed without SDP signaling -- for
+   example, in case of a failure.  The procedures in this section MUST
+   be followed to establish a new SCTP association.  This requires a new
+   SDP offer/answer exchange.  New (different than the ones currently
+   used) SCTP ports MUST be used by both endpoints.
+
+      |  NOTE: Closing and establishing a new SCTP association using the
+      |  SDP "sctp-port" attribute will not affect the state of the
+      |  underlying DTLS association.
+
+9.4.  DTLS Association (UDP/DTLS/SCTP and TCP/DTLS/SCTP)
+
+   A DTLS association is managed according to the procedures in
+   [RFC8842].  Hence, the SDP "setup" attribute is used to negotiate the
+   (D)TLS roles ("client" and "server") [RFC8122].
+
+      |  NOTE: The SDP "setup" attribute is used to negotiate both the
+      |  DTLS roles and the TCP roles (Section 9.5).
+
+      |  NOTE: As described in [RFC8445], if the Interactive
+      |  Connectivity Establishment (ICE) mechanism [RFC8445] is used,
+      |  all ICE candidates associated with a DTLS association are
+      |  considered part of the same DTLS association.  Thus, a switch
+      |  from one candidate pair to another candidate pair will not
+      |  trigger the establishment of a new DTLS association.
+
+9.5.  TCP Connection (TCP/DTLS/SCTP)
+
+   The TCP connection is managed according to the procedures in
+   [RFC4145].  Hence, the SDP "setup" attribute is used to negotiate the
+   TCP roles ("active" and "passive"), and the SDP "connection"
+   attribute is used to indicate whether to use an existing TCP
+   connection or create a new one.  The SDP "setup" attribute "holdconn"
+   value MUST NOT be used.
+
+      |  NOTE: A change of the TCP roles will also trigger a closure of
+      |  the DTLS association and establishment of a new DTLS
+      |  association, according to the procedures in [RFC8842].
+
+      |  NOTE: As specified in [RFC8842], usage of the SDP "setup"
+      |  attribute "holdconn" value is not allowed.  Therefore, this
+      |  specification also forbids usage of the attribute value for
+      |  TCP, as DTLS is transported on top of TCP.
+
+10.  SDP Offer/Answer Procedures
+
+10.1.  General
+
+   This section defines the SDP Offer/Answer [RFC3264] procedures for
+   negotiating and establishing an SCTP-over-DTLS association.  Unless
+   explicitly stated, the procedures apply to both the "UDP/DTLS/SCTP"
+   and "TCP/DTLS/SCTP" "m=" line proto values.
+
+   Each endpoint MUST associate one or more certificate fingerprints
+   using the SDP "fingerprint" attribute with the "m=" line, following
+   the procedures in [RFC8122].
+
+   The authentication certificates are interpreted and validated as
+   defined in [RFC8122].  Self-signed certificates can be used securely,
+   provided that the integrity of the SDP description is assured, as
+   defined in [RFC8122].
+
+   Each endpoint MUST associate an SDP "tls-id" attribute with the "m="
+   line, following the procedures in [RFC8842].
+
+10.2.  Generating the Initial SDP Offer
+
+   When the offerer creates an initial offer, the offerer:
+
+   *  MUST associate an SDP "setup" attribute with the "m=" line;
+
+   *  MUST associate an SDP "sctp-port" attribute with the "m=" line;
+
+   *  MUST, in the case of TCP/DTLS/SCTP, associate an SDP "connection"
+      attribute, with a "new" attribute value, with the "m=" line; and
+
+   *  MAY associate an SDP "max-message-size" attribute (Section 6) with
+      the "m=" line.
+
+10.3.  Generating the SDP Answer
+
+   When the answerer receives an offer that contains an "m=" line
+   describing an SCTP-over-DTLS association, if the answerer accepts the
+   association, the answerer:
+
+   *  MUST insert a corresponding "m=" line in the answer, with an "m="
+      line proto value [RFC3264] identical to the value in the offer;
+
+   *  MUST associate an SDP "setup" attribute with the "m=" line;
+
+   *  MUST associate an SDP "sctp-port" attribute with the "m=" line.
+      If the offer contained a new (different than the one currently
+      used) SCTP port value, the answerer MUST also associate a new SCTP
+      port value.  If the offer contained a zero SCTP port value, or if
+      the answerer does not accept the SCTP association, the answerer
+      MUST also associate a zero SCTP port value; and
+
+   *  MAY associate an SDP "max-message-size" attribute (Section 6) with
+      the "m=" line.  The attribute value in the answer is independent
+      of the value (if present) in the corresponding "m=" line of the
+      offer.
+
+   Once the answerer has sent the answer:
+
+   *  in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been
+      established or an existing TCP connection is to be closed and
+      replaced by a new one, the answerer MUST follow the procedures in
+      [RFC4145] for closing and establishing a TCP connection;
+
+   *  if a DTLS association has not yet been established or an existing
+      DTLS association is to be closed and replaced by a new one, the
+      answerer MUST follow the procedures in [RFC8842] for closing the
+      currently used DTLS association and establishing a new one; and
+
+   *  if an SCTP association has not yet been established or an existing
+      SCTP association is to be closed and replaced by a new one, the
+      answerer MUST initiate the closing of the existing SCTP
+      association (if applicable) and establishment of the new
+      association.
+
+   If the SDP "sctp-port" attribute in the answer contains an attribute
+   value of zero, the answerer MUST NOT establish an SCTP association.
+   If an SCTP association exists, the offerer MUST close it.
+
+   If the answerer does not accept the "m=" line in the offer, it MUST
+   assign a zero port value to the corresponding "m=" line in the
+   answer, following the procedures in [RFC3264].  In addition, the
+   answerer MUST NOT initiate the establishment of a TCP connection, a
+   DTLS association, or a DTLS association associated with the "m="
+   line.
+
+10.4.  Offerer Processing of the SDP Answer
+
+   Once the offerer has received the answer:
+
+   *  in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been
+      established or an existing TCP connection is to be closed and
+      replaced by a new one, the offerer MUST follow the procedures in
+      [RFC4145] for closing and establishing a TCP connection;
+
+   *  if a DTLS association has not yet been established or an existing
+      DTLS association is to be closed and replaced by a new one, the
+      offerer MUST follow the procedures in [RFC8842] for closing and
+      establishing a DTLS association; and
+
+   *  if an SCTP association has not yet been established or an existing
+      SCTP association is to be closed and replaced by a new one, the
+      offerer MUST initiate the closing of the existing SCTP association
+      (if applicable) and establishment of the new association.
+
+   If the SDP "sctp-port" attribute in the answer contains an attribute
+   value of zero, the offerer MUST NOT establish an SCTP association.
+   If, in addition, an SCTP association exists, the offerer MUST close
+   it.
+
+   If the "m=" line in the answer contains a zero port value, the
+   offerer MUST NOT initiate the establishment of a TCP connection, a
+   DTLS association, or an SCTP association associated with the "m="
+   line.  If, in addition, a TCP connection, DTLS association, or SCTP
+   association exists, the offerer MUST close it.
+
+10.5.  Modifying the Session
+
+   When an offerer sends an updated offer, in order to modify a
+   previously established SCTP association, it follows the procedures in
+   Section 10.2, with the following exceptions:
+
+   *  If the offerer wants to close an SCTP association and immediately
+      establish a new SCTP association, it MUST associate an SDP "sctp-
+      port" attribute with a new (different than the one currently used)
+      attribute value.  This will not impact the underlying DTLS
+      association (or TCP connection, in the case of TCP/DTLS/SCTP).
+
+   *  If the offerer wants to close an SCTP association without
+      immediately establishing a new SCTP association, it MUST associate
+      an SDP "sctp-port" attribute with an attribute value of zero.
+      This will not impact the underlying DTLS association (or TCP
+      connection, in the case of TCP/DTLS/SCTP).
+
+   *  If the offerer wants to establish an SCTP association, and another
+      SCTP association was previously closed, the offerer MUST associate
+      an SDP "sctp-port" attribute with a new attribute value (different
+      than the value associated with the previous SCTP association).  If
+      the previous SCTP association was closed successfully following
+      use of an SDP "sctp-port" attribute with an attribute value of
+      zero, the offerer MAY use the same attribute value for the new
+      SCTP association that was used with the previous SCTP association
+      before it was closed.  This will not impact the underlying DTLS
+      association (or TCP connection, in the case of TCP/DTLS/SCTP).
+
+   *  If the offerer wants to close an existing SCTP association and the
+      underlying DTLS association (and the underlying TCP connection, in
+      the case of TCP/DTLS/SCTP), it MUST assign a zero port value to
+      the "m=" line associated with the SCTP and DTLS associations (and
+      TCP connection, in the case of TCP/DTLS/SCTP), following the
+      procedures in [RFC3264].
+
+   *  NOTE: This specification does not define a mechanism for
+      explicitly closing a DTLS association while maintaining the
+      overlying SCTP association.  However, if a DTLS association is
+      closed and replaced with a new DTLS association as a result of
+      some other action [RFC8842], the state of the SCTP association is
+      not affected.
+
+   The offerer follows the procedures in [RFC8842] regarding the DTLS
+   association impacts when modifying a session.
+
+   In the case of TCP/DTLS/SCTP, the offerer follows the procedures in
+   [RFC4145] regarding the TCP connection impacts when modifying a
+   session.
+
+11.  Multihoming Considerations
+
+   Multihoming is not supported when sending SCTP on top of DTLS, as
+   DTLS does not expose address management of the underlying transport
+   protocols (UDP or TCP) to its upper layer.
+
+12.  NAT Considerations
+
+12.1.  General
+
+   When SCTP-over-DTLS is used in a NAT environment, it relies on the
+   NAT traversal procedures for the underlying transport protocol (UDP
+   or TCP).
+
+12.2.  ICE Considerations
+
+   When SCTP-over-DTLS is used with UDP-based ICE candidates [RFC8445],
+   then the procedures for UDP/DTLS/SCTP (Section 7) are used.
+
+   When SCTP-over-DTLS is used with TCP-based ICE candidates [RFC6544],
+   then the procedures for TCP/DTLS/SCTP (Section 8) are used.
+
+   In ICE environments, during the nomination process, endpoints go
+   through multiple ICE candidate pairs until the most preferred
+   candidate pair is found.  During the nomination process, data can be
+   sent as soon as the first working candidate pair is found, but the
+   nomination process still continues, and selected candidate pairs can
+   still change while data is sent.  Furthermore, if endpoints roam
+   between networks -- for instance, when a mobile endpoint switches
+   from mobile connection to WiFi -- endpoints will initiate an ICE
+   restart.  This will trigger a new nomination process between the new
+   set of candidates, which will likely result in the new nominated
+   candidate pair.
+
+   Implementations MUST treat all ICE candidate pairs associated with an
+   SCTP association on top of a DTLS association as part of the same
+   DTLS association.  Thus, there will only be one SCTP handshake and
+   one DTLS handshake even if there are multiple valid candidate pairs;
+   shifting from one candidate pair to another, including switching
+   between UDP and TCP candidate pairs, will not impact the SCTP or DTLS
+   associations.  If new candidates are added, they will also be part of
+   the same SCTP and DTLS associations.  When transitioning between
+   candidate pairs, different candidate pairs can be currently active in
+   different directions, and implementations MUST be ready to receive
+   data on any of the candidates, even if this means sending and
+   receiving data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time
+   in different directions.
+
+   In order to maximize the likelihood of interoperability between the
+   endpoints, all ICE-enabled SCTP-over-DTLS endpoints SHOULD implement
+   support for UDP/DTLS/SCTP.
+
+   When an SDP offer or answer is sent with multiple ICE candidates
+   during initial connection negotiation or after ICE restart, UDP-based
+   candidates SHOULD be included, and the default candidate SHOULD be
+   chosen from one of those UDP candidates.  The proto value MUST match
+   the transport protocol associated with the default candidate.  If UDP
+   transport is used for the default candidate, then the "UDP/DTLS/SCTP"
+   proto value MUST be used.  If TCP transport is used for the default
+   candidate, then the "TCP/DTLS/SCTP" proto value MUST be used.  Note
+   that under normal circumstances, the proto value for offers and
+   answers sent during ICE nomination SHOULD be "UDP/DTLS/SCTP".
+
+   When a subsequent SDP offer or answer is sent after ICE nomination is
+   complete, and it does not initiate ICE restart, it will contain only
+   the nominated ICE candidate pair.  In this case, the proto value MUST
+   match the transport protocol associated with the nominated ICE
+   candidate pair.  If UDP transport is used for the nominated pair,
+   then the "UDP/DTLS/SCTP" proto value MUST be used.  If TCP transport
+   is used for the nominated pair, then the "TCP/DTLS/SCTP" proto value
+   MUST be used.  Please note that if an endpoint switches between TCP-
+   based and UDP-based candidates during the nomination process, the
+   endpoint is not required to send an SDP offer for the sole purpose of
+   keeping the proto value of the associated "m=" line in sync.
+
+      |  NOTE: The text in the paragraph above only applies when the
+      |  usage of ICE has been negotiated.  If ICE is not used, the
+      |  proto value MUST always reflect the transport protocol used at
+      |  any given time.
+
+13.  Examples
+
+13.1.  Establishment of UDP/DTLS/SCTP Association
+
+   SDP Offer:
+
+   m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
+   c=IN IP6 2001:DB8::A8FD
+   a=tls-id:abc3de65cddef001be82
+   a=setup:actpass
+   a=fingerprint:SHA-256 \
+   12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
+   3E:5D:49:6B:19:E5:7C:AB:4A:AD
+   a=sctp-port:5000
+   a=max-message-size:100000
+
+   *  The offerer indicates that the usage of the UDP/DTLS/SCTP
+      association will be as defined for the "webrtc-datachannel" format
+      value.
+
+   *  The offerer UDP port value is 54111.
+
+   *  The offerer SCTP port value is 5000.
+
+   *  The offerer indicates that it can take either the client or the
+      server DTLS role.
+
+   SDP Answer:
+
+   m=application 64300 UDP/DTLS/SCTP webrtc-datachannel
+   c=IN IP6 2001:DB8::001D
+   a=tls-id:dbc8de77cddef001be90
+   a=setup:passive
+   a=fingerprint:SHA-256 \
+   3F:82:18:3B:49:6B:19:E5:7C:AB:4A:AD:B9:B1:12:DF:3E:5D:12:DF:54:02: \
+   49:6B:3E:5D:7C:AB:19:E5:AD:4A
+   a=sctp-port:6000
+   a=max-message-size:100000
+
+   Note that due to RFC formatting conventions, this document splits SDP
+   across lines whose content would exceed 72 characters.  A backslash
+   character marks where this line folding has taken place.  This
+   backslash and its trailing CRLF and whitespace would not appear in
+   actual SDP content.
+
+   *  The answerer UDP port value is 64300.
+
+   *  The answerer SCTP port value is 6000.
+
+   *  The answerer takes the server DTLS role.
+
+14.  Security Considerations
+
+   [RFC4566] defines general SDP security considerations, while
+   [RFC3264], [RFC4145], and [RFC8122] define security considerations
+   when using the SDP offer/answer mechanism to negotiate media streams.
+
+   [RFC4960] defines general SCTP security considerations, and [RFC8261]
+   defines security considerations when using SCTP on top of DTLS.
+
+   This specification does not introduce new security considerations in
+   addition to those defined in the specifications listed above.
+
+15.  IANA Considerations
+
+15.1.  New SDP Proto Values
+
+   This document updates the "Session Description Protocol (SDP)
+   Parameters" registry, following the procedures in [RFC4566], by
+   adding the following values to the table in the SDP "proto" field
+   registry:
+
+                   +=======+===============+===========+
+                   |  Type |    SDP Name   | Reference |
+                   +=======+===============+===========+
+                   | proto | UDP/DTLS/SCTP |  RFC 8841 |
+                   +-------+---------------+-----------+
+                   | proto | TCP/DTLS/SCTP |  RFC 8841 |
+                   +-------+---------------+-----------+
+
+                     Table 2: SDP "proto" Field Values
+
+15.2.  New SDP Attributes
+
+15.2.1.  sctp-port
+
+   This document defines a new SDP media-level attribute,"sctp-port".
+   The details of the attribute are defined in Section 5.2.
+
+15.2.2.  max-message-size
+
+   This document defines a new SDP media-level attribute,"max-message-
+   size".  The details of the attribute are defined in Section 6.2.
+
+15.3.  association-usage Name Registry
+
+   Per this specification, a new IANA registry has been created,
+   following the procedures in [RFC8126], for the namespace associated
+   with the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" protocol identifiers.
+   Each fmt value describes the usage of an entire SCTP association,
+   including all SCTP streams associated with the SCTP association.
+
+      |  NOTE: Usage indication of individual SCTP streams is outside
+      |  the scope of this specification.
+
+   The fmt value "association-usage" used with these "proto" values is
+   required.  It is defined in Section 4.
+
+   As part of this registry, IANA maintains the following information:
+
+   association-usage name:  The identifier of the subprotocol, as will
+      be used as the fmt value.
+
+   association-usage reference:  A reference to the document in which
+      the association-usage is defined.
+
+   association-usage names are to be subject to the "First Come First
+   Served" IANA registration policy [RFC8126].
+
+   IANA has added the following initial values to the registry.
+
+                +====================+====================+
+                | Name               | Reference          |
+                +====================+====================+
+                | webrtc-datachannel | RFC 8832, RFC 8841 |
+                +--------------------+--------------------+
+                +--------------------+--------------------+
+
+                        Table 3: IANA Initial Values
+
+16.  References
+
+16.1.  Normative References
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <https://www.rfc-editor.org/info/rfc793>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <https://www.rfc-editor.org/info/rfc3264>.
+
+   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
+              the Session Description Protocol (SDP)", RFC 4145,
+              DOI 10.17487/RFC4145, September 2005,
+              <https://www.rfc-editor.org/info/rfc4145>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <https://www.rfc-editor.org/info/rfc4566>.
+
+   [RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
+              and RTP Control Protocol (RTCP) Packets over Connection-
+              Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
+              2006, <https://www.rfc-editor.org/info/rfc4571>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <https://www.rfc-editor.org/info/rfc4960>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+              January 2012, <https://www.rfc-editor.org/info/rfc6347>.
+
+   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B.
+              Roach, "TCP Candidates with Interactive Connectivity
+              Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
+              March 2012, <https://www.rfc-editor.org/info/rfc6544>.
+
+   [RFC8122]  Lennox, J. and C. Holmberg, "Connection-Oriented Media
+              Transport over the Transport Layer Security (TLS) Protocol
+              in the Session Description Protocol (SDP)", RFC 8122,
+              DOI 10.17487/RFC8122, March 2017,
+              <https://www.rfc-editor.org/info/rfc8122>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8261]  Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
+              "Datagram Transport Layer Security (DTLS) Encapsulation of
+              SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
+              2017, <https://www.rfc-editor.org/info/rfc8261>.
+
+   [RFC8842]  Holmberg, C. and R. Shpount, "Session Description Protocol
+              (SDP) Offer/Answer Considerations for Datagram Transport
+              Layer Security (DTLS) and Transport Layer Security (TLS)",
+              RFC 8842, DOI 10.17487/RFC8842, January 2021,
+              <https://www.rfc-editor.org/info/rfc8842>.
+
+   [RFC8859]  Nandakumar, S., "A Framework for Session Description
+              Protocol (SDP) Attributes When Multiplexing", RFC 8859,
+              DOI 10.17487/RFC8859, January 2021,
+              <https://www.rfc-editor.org/info/rfc8859>.
+
+16.2.  Informative References
+
+   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
+              Connectivity Establishment (ICE): A Protocol for Network
+              Address Translator (NAT) Traversal", RFC 8445,
+              DOI 10.17487/RFC8445, July 2018,
+              <https://www.rfc-editor.org/info/rfc8445>.
+
+   [RFC8831]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
+              Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
+              <https://www.rfc-editor.org/info/rfc8831>.
+
+   [RFC8832]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel
+              Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
+              January 2021, <https://www.rfc-editor.org/info/rfc8832>.
+
+   [RFC8864]  Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
+              Even, Ed., "Negotiation Data Channels Using the Session
+              Description Protocol (SDP)", RFC 8864,
+              DOI 10.17487/RFC8864, January 2021,
+              <https://www.rfc-editor.org/info/rfc8864>.
+
+Acknowledgements
+
+   The authors wish to thank Harald Alvestrand, Randell Jesup, Paul
+   Kyzivat, Michael Tüxen, Juergen Stoetzer-Bradler, Flemming Andreasen,
+   and Ari Keränen for their comments and useful feedback.  Ben Campbell
+   provided comments as part of his Area Director review.  Brian
+   Carpenter performed the Gen-ART review.
+
+Authors' Addresses
+
+   Christer Holmberg
+   Ericsson
+   Hirsalantie 11
+   FI-02420 Jorvas
+   Finland
+
+   Email: christer.holmberg@ericsson.com
+
+
+   Roman Shpount
+   TurboBridge
+   4905 Del Ray Avenue, Suite 300
+   Bethesda, MD 20814
+   United States of America
+
+   Phone: +1 (240) 292-6632
+   Email: rshpount@turbobridge.com
+
+
+   Salvatore Loreto
+   Ericsson
+   Grönlandsgatan 31
+   Kista
+   Sweden
+
+   Email: Salvatore.Loreto@ericsson.com
+
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   FI-02420 Jorvas
+   Finland
+
+   Email: Gonzalo.Camarillo@ericsson.com