idnits 2.17.1 draft-ietf-rtcweb-transports-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2016) is 2731 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-06 == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mmusic-ice-dualstack-fairness (ref. 'I-D.ietf-mmusic-ice-dualstack-fairness') == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-07 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-06 ** Downref: Normative reference to an Informational draft: draft-ietf-rmcat-cc-requirements (ref. 'I-D.ietf-rmcat-cc-requirements') == Outdated reference: A later version (-04) exists of draft-ietf-rtcweb-alpn-00 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-12 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-08 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-11 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-17 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-07 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-10 == Outdated reference: A later version (-18) exists of draft-ietf-tsvwg-rtcweb-qos-02 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-05 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-01 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 4594 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 7656 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-coupled-cc-03 == Outdated reference: A later version (-02) exists of draft-ietf-rtcweb-return-01 == Outdated reference: A later version (-12) exists of draft-ietf-tram-turn-server-discovery-00 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Standards Track October 26, 2016 5 Expires: April 29, 2017 7 Transports for WebRTC 8 draft-ietf-rtcweb-transports-17 10 Abstract 12 This document describes the data transport protocols used by WebRTC, 13 including the protocols used for interaction with intermediate boxes 14 such as firewalls, relays and NAT boxes. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 29, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 52 3. Transport and Middlebox specification . . . . . . . . . . . . 3 53 3.1. System-provided interfaces . . . . . . . . . . . . . . . 3 54 3.2. Ability to use IPv4 and IPv6 . . . . . . . . . . . . . . 4 55 3.3. Usage of temporary IPv6 addresses . . . . . . . . . . . . 4 56 3.4. Middle box related functions . . . . . . . . . . . . . . 5 57 3.5. Transport protocols implemented . . . . . . . . . . . . . 6 58 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Local prioritization . . . . . . . . . . . . . . . . . . 8 60 4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 66 8.2. Informative References . . . . . . . . . . . . . . . . . 15 67 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 68 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 16 69 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 16 70 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 17 71 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 17 72 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 17 73 A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17 74 A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 18 75 A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 18 76 A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 18 77 A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18 78 A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18 79 A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 19 80 A.13. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 19 81 A.14. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 19 82 A.15. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 19 83 A.16. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 19 84 A.17. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 WebRTC is a protocol suite aimed at real time multimedia exchange 90 between browsers, and between browsers and other entities. 92 WebRTC is described in the WebRTC overview document, 93 [I-D.ietf-rtcweb-overview], which also defines terminology used in 94 this document, including the terms "WebRTC endpoint" and "WebRTC 95 browser". 97 Terminology for RTP sources is taken from[RFC7656] . 99 This document focuses on the data transport protocols that are used 100 by conforming implementations, including the protocols used for 101 interaction with intermediate boxes such as firewalls, relays and NAT 102 boxes. 104 This protocol suite intends to satisfy the security considerations 105 described in the WebRTC security documents, 106 [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. 108 This document describes requirements that apply to all WebRTC 109 endpoints. When there are requirements that apply only to WebRTC 110 browsers, this is called out explicitly. 112 2. Requirements language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Transport and Middlebox specification 120 3.1. System-provided interfaces 122 The protocol specifications used here assume that the following 123 protocols are available to the implementations of the WebRTC 124 protocols: 126 o UDP [RFC0768]. This is the protocol assumed by most protocol 127 elements described. 129 o TCP [RFC0793]. This is used for HTTP/WebSockets, as well as for 130 TURN/TLS and ICE-TCP. 132 For both protocols, IPv4 and IPv6 support is assumed. 134 For UDP, this specification assumes the ability to set the DSCP code 135 point of the sockets opened on a per-packet basis, in order to 136 achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos] 137 (see Section 4.2) when multiple media types are multiplexed. It does 138 not assume that the DSCP codepoints will be honored, and does assume 139 that they may be zeroed or changed, since this is a local 140 configuration issue. 142 Platforms that do not give access to these interfaces will not be 143 able to support a conforming WebRTC endpoint. 145 This specification does not assume that the implementation will have 146 access to ICMP or raw IP. 148 The following protocols may be used, but can be implemented by a 149 WebRTC endpoint, and are therefore not defined as "system-provided 150 interfaces": 152 o TURN - Traversal Using Relays Around NAT, [RFC5766] 154 o STUN - Session Traversal Utilities for NAT, [RFC5389] 156 o ICE - Interactive Connectivity Establishment, 157 [I-D.ietf-ice-rfc5245bis] 159 o TLS - Transport Layer Security, [RFC5246] 161 o DTLS - Datagram Transport Layer Security, [RFC6347]. 163 3.2. Ability to use IPv4 and IPv6 165 Web applications running in a WebRTC browser MUST be able to utilize 166 both IPv4 and IPv6 where available - that is, when two peers have 167 only IPv4 connectivity to each other, or they have only IPv6 168 connectivity to each other, applications running in the WebRTC 169 browser MUST be able to communicate. 171 When TURN is used, and the TURN server has IPv4 or IPv6 connectivity 172 to the peer or the peer's TURN server, candidates of the appropriate 173 types MUST be supported. The "Happy Eyeballs" specification for ICE 174 [I-D.ietf-mmusic-ice-dualstack-fairness] SHOULD be supported. 176 3.3. Usage of temporary IPv6 addresses 178 The IPv6 default address selection specification [RFC6724] specifies 179 that temporary addresses [RFC4941] are to be preferred over permanent 180 addresses. This is a change from the rules specified by [RFC3484]. 181 For applications that select a single address, this is usually done 182 by the IPV6_PREFER_SRC_TMP preference flag specified in [RFC5014]. 183 However, this rule, which is intended to ensure that privacy-enhanced 184 addresses are used in preference to static addresses, doesn't have 185 the right effect in ICE, where all addresses are gathered and 186 therefore revealed to the application. Therefore, the following rule 187 is applied instead: 189 When a WebRTC endpoint gathers all IPv6 addresses on its host, and 190 both non-deprecated temporary addresses and permanent addresses of 191 the same scope are present, the WebRTC endpoint SHOULD discard the 192 permanent addresses before exposing addresses to the application or 193 using them in ICE. This is consistent with the default policy 194 described in [RFC6724]. 196 If some of the temporary IPv6 addresses, but not all, are marked 197 deprecated, the WebRTC endpoint SHOULD discard the deprecated 198 addresses, unless they are used by an ongoing connection. In an ICE 199 restart, deprecated addresses that are currently in use MAY be 200 retained. 202 3.4. Middle box related functions 204 The primary mechanism to deal with middle boxes is ICE, which is an 205 appropriate way to deal with NAT boxes and firewalls that accept 206 traffic from the inside, but only from the outside if it is in 207 response to inside traffic (simple stateful firewalls). 209 ICE [I-D.ietf-ice-rfc5245bis] MUST be supported. The implementation 210 MUST be a full ICE implementation, not ICE-Lite. A full ICE 211 implementation allows interworking with both ICE and ICE-Lite 212 implementations when they are deployed appropriately. 214 In order to deal with situations where both parties are behind NATs 215 of the type that perform endpoint-dependent mapping (as defined in 216 [RFC5128] section 2.4), TURN [RFC5766] MUST be supported. 218 WebRTC browsers MUST support configuration of STUN and TURN servers, 219 both from browser configuration and from an application. 221 Note that there is other work around STUN and TURN sever discovery 222 and management, including [I-D.ietf-tram-turn-server-discovery] for 223 server discovery, as well as [I-D.ietf-rtcweb-return]. 225 In order to deal with firewalls that block all UDP traffic, the mode 226 of TURN that uses TCP between the WebRTC endpoint and the TURN server 227 MUST be supported, and the mode of TURN that uses TLS over TCP 228 between the WebRTC endpoint and the TURN server MUST be supported. 229 See [RFC5766] section 2.1 for details. 231 In order to deal with situations where one party is on an IPv4 232 network and the other party is on an IPv6 network, TURN extensions 233 for IPv6 [RFC6156] MUST be supported. 235 TURN TCP candidates, where the connection from the WebRTC endpoint's 236 TURN server to the peer is a TCP connection, [RFC6062] MAY be 237 supported. 239 However, such candidates are not seen as providing any significant 240 benefit, for the following reasons. 242 First, use of TURN TCP candidates would only be relevant in cases 243 which both peers are required to use TCP to establish a 244 PeerConnection. 246 Second, that use case is supported in a different way by both sides 247 establishing UDP relay candidates using TURN over TCP to connect to 248 their respective relay servers. 250 Third, using TCP between the WebRTC endpoint's TURN server and the 251 peer may result in more performance problems than using UDP, e.g. due 252 to head of line blocking. 254 ICE-TCP candidates [RFC6544] MUST be supported; this may allow 255 applications to communicate to peers with public IP addresses across 256 UDP-blocking firewalls without using a TURN server. 258 If TCP connections are used, RTP framing according to [RFC4571] MUST 259 be used for all packets. This includes the RTP packets, DTLS packets 260 used to carry data channels, and STUN connectivity check packets. 262 The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section 263 11 (300 Try Alternate) MUST be supported. 265 The WebRTC endpoint MAY support accessing the Internet through an 266 HTTP proxy. If it does so, it MUST include the "ALPN" header as 267 specified in [RFC7639], and proxy authentication as described in 268 Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported. 270 3.5. Transport protocols implemented 272 For transport of media, secure RTP is used. The details of the 273 profile of RTP used are described in "RTP Usage" 274 [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit 275 breaker [I-D.ietf-avtcore-rtp-circuit-breakers] and congstion control 276 (see [I-D.ietf-rmcat-cc-requirements] for further guidance). 278 Key exchange MUST be done using DTLS-SRTP, as described in 279 [I-D.ietf-rtcweb-security-arch]. 281 For data transport over the WebRTC data channel 282 [I-D.ietf-rtcweb-data-channel], WebRTC endpoints MUST support SCTP 283 over DTLS over ICE. This encapsulation is specified in 284 [I-D.ietf-tsvwg-sctp-dtls-encaps]. Negotiation of this transport in 285 SDP is defined in [I-D.ietf-mmusic-sctp-sdp]. The SCTP extension for 286 NDATA, [I-D.ietf-tsvwg-sctp-ndata], MUST be supported. 288 The setup protocol for WebRTC data channels described in 289 [I-D.ietf-rtcweb-data-protocol] MUST be supported. 291 Note: DTLS-SRTP as defined in [RFC5764] section 6.7.1 defines the 292 interaction between DTLS and ICE ( [I-D.ietf-ice-rfc5245bis]). The 293 effect of this specification is that all ICE candidate pairs 294 associated with a single component are part of the same DTLS 295 association. Thus, there will only be one DTLS handshake even if 296 there are multiple valid candidate pairs. 298 WebRTC endpoints MUST support multiplexing of DTLS and RTP over the 299 same port pair, as described in the DTLS-SRTP specification 300 [RFC5764], section 5.1.2, with clarifications in 301 [I-D.ietf-avtcore-rfc5764-mux-fixes]. All application layer protocol 302 payloads over this DTLS connection are SCTP packets. 304 Protocol identification MUST be supplied as part of the DTLS 305 handshake, as specified in [I-D.ietf-rtcweb-alpn]. 307 4. Media Prioritization 309 The WebRTC prioritization model is that the application tells the 310 WebRTC endpoint about the priority of media and data that is 311 controlled from the API. 313 In this context, a "flow" is used for the units that are given a 314 specific priority through the WebRTC API. 316 For media, a "media flow", which can be an "audio flow" or a "video 317 flow", is what [RFC7656] calls a "media source", which results in a 318 "source RTP stream" and one or more "redundancy RTP streams". This 319 specification does not describe prioritization between the RTP 320 streams that come from a single "media source". 322 All media flows in WebRTC are assumed to be interactive, as defined 323 in [RFC4594]; there is no browser API support for indicating whether 324 media is interactive or non-interactive. 326 A "data flow" is the outgoing data on a single WebRTC data channel. 328 The priority associated with a media flow or data flow is classified 329 as "very-low", "low", "medium or "high". There are only four 330 priority levels at the API. 332 The priority settings affect two pieces of behavior: Packet send 333 sequence decisions and packet markings. Each is described in its own 334 section below. 336 4.1. Local prioritization 338 Local prioritization is applied at the local node, before the packet 339 is sent. This means that the prioritization has full access to the 340 data about the individual packets, and can choose differing treatment 341 based on the stream a packet belongs to. 343 When an WebRTC endpoint has packets to send on multiple streams that 344 are congestion-controlled under the same congestion control regime, 345 the WebRTC endpoint SHOULD cause data to be emitted in such a way 346 that each stream at each level of priority is being given 347 approximately twice the transmission capacity (measured in payload 348 bytes) of the level below. 350 Thus, when congestion occurs, a "high" priority flow will have the 351 ability to send 8 times as much data as a "very-low" priority flow if 352 both have data to send. This prioritization is independent of the 353 media type. The details of which packet to send first are 354 implementation defined. 356 For example: If there is a high priority audio flow sending 100 byte 357 packets, and a low priority video flow sending 1000 byte packets, and 358 outgoing capacity exists for sending >5000 payload bytes, it would be 359 appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes 360 (one packet) of video as the result of a single pass of sending 361 decisions. 363 Conversely, if the audio flow is marked low priority and the video 364 flow is marked high priority, the scheduler may decide to send 2 365 video packets (2000 bytes) and 5 audio packets (500 bytes) when 366 outgoing capacity exists for sending > 2500 payload bytes. 368 If there are two high priority audio flows, each will be able to send 369 4000 bytes in the same period where a low priority video flow is able 370 to send 1000 bytes. 372 Two example implementation strategies are: 374 o When the available bandwidth is known from the congestion control 375 algorithm, configure each codec and each data channel with a 376 target send rate that is appropriate to its share of the available 377 bandwidth. 379 o When congestion control indicates that a specified number of 380 packets can be sent, send packets that are available to send using 381 a weighted round robin scheme across the connections. 383 Any combination of these, or other schemes that have the same effect, 384 is valid, as long as the distribution of transmission capacity is 385 approximately correct. 387 For media, it is usually inappropriate to use deep queues for 388 sending; it is more useful to, for instance, skip intermediate frames 389 that have no dependencies on them in order to achieve a lower 390 bitrate. For reliable data, queues are useful. 392 Note that this specification doesn't dictate when disparate streams 393 are to be "congestion controlled under the same congestion control 394 regime". The issue of coupling congestion controllers is explored 395 further in [I-D.ietf-rmcat-coupled-cc]. 397 4.2. Usage of Quality of Service - DSCP and Multiplexing 399 When the packet is sent, the network will make decisions about 400 queueing and/or discarding the packet that can affect the quality of 401 the communication. The sender can attempt to set the DSCP field of 402 the packet to influence these decisions. 404 Implementations SHOULD attempt to set QoS on the packets sent, 405 according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. It is 406 appropriate to depart from this recommendation when running on 407 platforms where QoS marking is not implemented. 409 The implementation MAY turn off use of DSCP markings if it detects 410 symptoms of unexpected behaviour like priority inversion or blocking 411 of packets with certain DSCP markings. Some examples of such 412 behaviors are described in [ANRW16]. The detection of these 413 conditions is implementation dependent. 415 A particularly hard problem is when one media transport uses multiple 416 DSCP code points, where one may be blocked and another may be 417 allowed. This is allowed even within a single media flow for video 418 in [I-D.ietf-tsvwg-rtcweb-qos]. Implementations need to diagnose 419 this scenario; one possible implementation is to send initial ICE 420 probes with DSCP 0, and send ICE probes on all the DSCP code points 421 that are intended to be used once a candidate pair has been selected. 422 If one or more of the DSCP-marked probes fail, the sender will switch 423 the media type to using DSCP 0. This can be carried out 424 simultaneously with the initial media traffic; on failure, the 425 initial data may need to be resent. This switch will of course 426 invalidate any congestion information gathered up to that point. 428 Failures can also start happening during the lifetime of the call; 429 this case is expected to be rarer, and can be handled by the normal 430 mechanisms for transport failure, which may involve an ICE restart. 432 Note that when a DSCP code point causes non-delivery, one has to 433 switch the whole media flow to DSCP 0, since all traffic for a single 434 media flow needs to be on the same queue for congestion control 435 purposes. Other flows on the same transport, using different DSCP 436 code points, don't need to change. 438 All packets carrying data from the SCTP association supporting the 439 data channels MUST use a single DSCP code point. The code point used 440 SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the 441 highest priority data channel carried. Note that this means that all 442 data packets, no matter what their relative priority is, will be 443 treated the same by the network. 445 All packets on one TCP connection, no matter what it carries, MUST 446 use a single DSCP code point. 448 More advice on the use of DSCP code points with RTP and on the 449 relationship between DSCP and congestion control is given in 450 [RFC7657]. 452 There exist a number of schemes for achieving quality of service that 453 do not depend solely on DSCP code points. Some of these schemes 454 depend on classifying the traffic into flows based on 5-tuple (source 455 address, source port, protocol, destination address, destination 456 port) or 6-tuple (5-tuple + DSCP code point). Under differing 457 conditions, it may therefore make sense for a sending application to 458 choose any of the configurations: 460 o Each media stream carried on its own 5-tuple 462 o Media streams grouped by media type into 5-tuples (such as 463 carrying all audio on one 5-tuple) 465 o All media sent over a single 5-tuple, with or without 466 differentiation into 6-tuples based on DSCP code points 468 In each of the configurations mentioned, data channels may be carried 469 in its own 5-tuple, or multiplexed together with one of the media 470 flows. 472 More complex configurations, such as sending a high priority video 473 stream on one 5-tuple and sending all other video streams multiplexed 474 together over another 5-tuple, can also be envisioned. More 475 information on mapping media flows to 5-tuples can be found in 476 [I-D.ietf-rtcweb-rtp-usage]. 478 A sending implementation MUST be able to support the following 479 configurations: 481 o Multiplex all media and data on a single 5-tuple (fully bundled) 483 o Send each media stream on its own 5-tuple and data on its own 484 5-tuple (fully unbundled) 486 It MAY choose to support other configurations, such as bundling each 487 media type (audio, video or data) into its own 5-tuple (bundling by 488 media type). 490 Sending data channel data over multiple 5-tuples is not supported. 492 A receiving implementation MUST be able to receive media and data in 493 all these configurations. 495 5. IANA Considerations 497 This document makes no request of IANA. 499 Note to RFC Editor: this section may be removed on publication as an 500 RFC. 502 6. Security Considerations 504 RTCWEB security considerations are enumerated in 505 [I-D.ietf-rtcweb-security]. 507 Security considerations pertaining to the use of DSCP are enumerated 508 in [I-D.ietf-tsvwg-rtcweb-qos]. 510 7. Acknowledgements 512 This document is based on earlier versions embedded in 513 [I-D.ietf-rtcweb-overview], which were the results of contributions 514 from many RTCWEB WG members. 516 Special thanks for reviews of earlier versions of this draft go to 517 Eduardo Gueiros, Magnus Westerlund, Markus Isomaki and Dan Wing; the 518 contributions from Andrew Hutton also deserve special mention. 520 8. References 522 8.1. Normative References 524 [I-D.ietf-avtcore-rfc5764-mux-fixes] 525 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 526 Updates for Secure Real-time Transport Protocol (SRTP) 527 Extension for Datagram Transport Layer Security (DTLS)", 528 draft-ietf-avtcore-rfc5764-mux-fixes-11 (work in 529 progress), September 2016. 531 [I-D.ietf-avtcore-rtp-circuit-breakers] 532 Perkins, C. and V. Singh, "Multimedia Congestion Control: 533 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 534 avtcore-rtp-circuit-breakers-06 (work in progress), July 535 2014. 537 [I-D.ietf-ice-rfc5245bis] 538 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 539 Connectivity Establishment (ICE): A Protocol for Network 540 Address Translator (NAT) Traversal", draft-ietf-ice- 541 rfc5245bis-04 (work in progress), June 2016. 543 [I-D.ietf-mmusic-ice-dualstack-fairness] 544 Martinsen, P., Reddy, T., and P. Patil, "ICE Multihomed 545 and IPv4/IPv6 Dual Stack Fairness", draft-ietf-mmusic-ice- 546 dualstack-fairness-02 (work in progress), September 2015. 548 [I-D.ietf-mmusic-sctp-sdp] 549 Loreto, S. and G. Camarillo, "Stream Control Transmission 550 Protocol (SCTP)-Based Media Transport in the Session 551 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-07 552 (work in progress), July 2014. 554 [I-D.ietf-rmcat-cc-requirements] 555 Jesup, R., "Congestion Control Requirements For RMCAT", 556 draft-ietf-rmcat-cc-requirements-06 (work in progress), 557 October 2014. 559 [I-D.ietf-rtcweb-alpn] 560 Thomson, M., "Application Layer Protocol Negotiation for 561 Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- 562 alpn-00 (work in progress), July 2014. 564 [I-D.ietf-rtcweb-data-channel] 565 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 566 Channels", draft-ietf-rtcweb-data-channel-12 (work in 567 progress), September 2014. 569 [I-D.ietf-rtcweb-data-protocol] 570 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 571 Establishment Protocol", draft-ietf-rtcweb-data- 572 protocol-08 (work in progress), September 2014. 574 [I-D.ietf-rtcweb-overview] 575 Alvestrand, H., "Overview: Real Time Protocols for 576 Browser-based Applications", draft-ietf-rtcweb-overview-11 577 (work in progress), August 2014. 579 [I-D.ietf-rtcweb-rtp-usage] 580 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 581 Communication (WebRTC): Media Transport and Use of RTP", 582 draft-ietf-rtcweb-rtp-usage-17 (work in progress), August 583 2014. 585 [I-D.ietf-rtcweb-security] 586 Rescorla, E., "Security Considerations for WebRTC", draft- 587 ietf-rtcweb-security-07 (work in progress), July 2014. 589 [I-D.ietf-rtcweb-security-arch] 590 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 591 rtcweb-security-arch-10 (work in progress), July 2014. 593 [I-D.ietf-tsvwg-rtcweb-qos] 594 Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. 595 Polk, "DSCP and other packet markings for RTCWeb QoS", 596 draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June 597 2014. 599 [I-D.ietf-tsvwg-sctp-dtls-encaps] 600 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 601 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 602 dtls-encaps-05 (work in progress), July 2014. 604 [I-D.ietf-tsvwg-sctp-ndata] 605 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 606 "Stream Schedulers and a New Data Chunk for the Stream 607 Control Transmission Protocol", draft-ietf-tsvwg-sctp- 608 ndata-01 (work in progress), July 2014. 610 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 611 August 1980. 613 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 614 793, September 1981. 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 620 and RTP Control Protocol (RTCP) Packets over Connection- 621 Oriented Transport", RFC 4571, July 2006. 623 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 624 Guidelines for DiffServ Service Classes", RFC 4594, August 625 2006. 627 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 628 Extensions for Stateless Address Autoconfiguration in 629 IPv6", RFC 4941, September 2007. 631 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 632 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 634 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 635 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 636 October 2008. 638 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 639 Security (DTLS) Extension to Establish Keys for the Secure 640 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 642 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 643 Relays around NAT (TURN): Relay Extensions to Session 644 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 646 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 647 around NAT (TURN) Extensions for TCP Allocations", RFC 648 6062, November 2010. 650 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 651 Using Relays around NAT (TURN) Extension for IPv6", RFC 652 6156, April 2011. 654 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 655 Security Version 1.2", RFC 6347, January 2012. 657 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 658 "TCP Candidates with Interactive Connectivity 659 Establishment (ICE)", RFC 6544, March 2012. 661 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 662 "Default Address Selection for Internet Protocol Version 6 663 (IPv6)", RFC 6724, September 2012. 665 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 666 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 668 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 669 (HTTP/1.1): Authentication", RFC 7235, June 2014. 671 [RFC7639] Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP 672 Header Field", RFC 7639, DOI 10.17487/RFC7639, August 673 2015, . 675 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 676 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 677 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 678 DOI 10.17487/RFC7656, November 2015, 679 . 681 8.2. Informative References 683 [ANRW16] Barik, R., Welzl, M., and A. Elmokashfi, "How to say that 684 you're special: Can we use bits in the IPv4 header?", ACM, 685 IRTF, ISOC Applied Networking Research Workshop (ANRW 686 2016), Berlin , July 2016. 688 [I-D.ietf-rmcat-coupled-cc] 689 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 690 control for RTP media", draft-ietf-rmcat-coupled-cc-03 691 (work in progress), July 2016. 693 [I-D.ietf-rtcweb-return] 694 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 695 (RETURN) for Connectivity and Privacy in WebRTC", draft- 696 ietf-rtcweb-return-01 (work in progress), January 2016. 698 [I-D.ietf-tram-turn-server-discovery] 699 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 700 Discovery", draft-ietf-tram-turn-server-discovery-00 (work 701 in progress), July 2014. 703 [RFC3484] Draves, R., "Default Address Selection for Internet 704 Protocol version 6 (IPv6)", RFC 3484, February 2003. 706 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 707 Socket API for Source Address Selection", RFC 5014, 708 September 2007. 710 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 711 Peer (P2P) Communication across Network Address 712 Translators (NATs)", RFC 5128, March 2008. 714 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 715 (Diffserv) and Real-Time Communication", RFC 7657, DOI 10 716 .17487/RFC7657, November 2015, 717 . 719 Appendix A. Change log 721 This section should be removed before publication as an RFC. 723 A.1. Changes from -00 to -01 725 o Clarified DSCP requirements, with reference to -qos- 727 o Clarified "symmetric NAT" -> "NATs which perform endpoint- 728 dependent mapping" 730 o Made support of TURN over TCP mandatory 732 o Made support of TURN over TLS a MAY, and added open question 734 o Added an informative reference to -firewalls- 736 o Called out that we don't make requirements on HTTP proxy 737 interaction (yet 739 A.2. Changes from -01 to -02 741 o Required support for 300 Alternate Server from STUN. 743 o Separated the ICE-TCP candidate requirement from the TURN-TCP 744 requirement. 746 o Added new sections on using QoS functions, and on multiplexing 747 considerations. 749 o Removed all mention of RTP profiles. Those are the business of 750 the RTP usage draft, not this one. 752 o Required support for TURN IPv6 extensions. 754 o Removed reference to the TURN URI scheme, as it was unnecessary. 756 o Made an explicit statement that multiplexing (or not) is an 757 application matter. 759 . 761 A.3. Changes from -02 to -03 763 o Added required support for draft-ietf-tsvwg-sctp-ndata 765 o Removed discussion of multiplexing, since this is present in rtp- 766 usage. 768 o Added RFC 4571 reference for framing RTP packets over TCP. 770 o Downgraded TURN TCP candidates from SHOULD to MAY, and added more 771 language discussing TCP usage. 773 o Added language on IPv6 temporary addresses. 775 o Added language describing multiplexing choices. 777 o Added a separate section detailing what it means when we say that 778 an WebRTC implementation MUST support both IPv4 and IPv6. 780 A.4. Changes from -03 to -04 782 o Added a section on prioritization, moved the DSCP section into it, 783 and added a section on local prioritization, giving a specific 784 algorithm for interpreting "priority" in local prioritization. 786 o ICE-TCP candidates was changed from MAY to MUST, in recognition of 787 the sense of the room at the London IETF. 789 A.5. Changes from -04 to -05 791 o Reworded introduction 793 o Removed all references to "WebRTC". It now uses only the term 794 RTCWEB. 796 o Addressed a number of clarity / language comments 798 o Rewrote the prioritization to cover data channels and to describe 799 multiple ways of prioritizing flows 801 o Made explicit reference to "MUST do DTLS-SRTP", and referred to 802 security-arch for details 804 A.6. Changes from -05 to -06 806 o Changed all references to "RTCWEB" to "WebRTC", except one 807 reference to the working group 809 o Added reference to the httpbis "connect" protocol (being adopted 810 by HTTPBIS) 812 o Added reference to the ALPN header (being adopted by RTCWEB) 814 o Added reference to the DART RTP document 816 o Said explicitly that SCTP for data channels has a single DSCP 817 codepoint 819 A.7. Changes from -06 to -07 821 o Updated references 823 o Removed reference to draft-hutton-rtcweb-nat-firewall- 824 considerations 826 A.8. Changes from -07 to -08 828 o Updated references 830 o Deleted "bundle each media type (audio, video or data) into its 831 own 5-tuple (bundling by media type)" from MUST support 832 configuration, since JSEP does not have a means to negotiate this 833 configuration 835 A.9. Changes from -08 to -09 837 o Added a clarifying note about DTLS-SRTP and ICE interaction. 839 A.10. Changes from -09 to -10 841 o Re-added references to proxy authentication lost in 07-08 842 transition (Bug #5) 844 o Rearranged and rephrased text in section 4 about prioritization to 845 reflect discussions in TSVWG. 847 o Changed the "Connect" header to "ALPN", and updated reference. 848 (Bug #6) 850 A.11. Changes from -10 to -11 852 o Added a definition of the term "flow" used in the prioritization 853 chapter 855 o Changed the names of the four priority levels to conform to other 856 specs. 858 A.12. Changes from -11 to -12 860 o Added a SHOULD NOT about using deprecated temporary IPv6 861 addresses. 863 o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657 865 A.13. Changes from -12 to -13 867 o Clarify that the ALPN header needs to be sent. 869 o Mentioned that RFC 7657 also talks about congestion control 871 A.14. Changes from -13 to -14 873 o Add note about non-support for marking flows as interactive or 874 non-interactive. 876 A.15. Changes from -14 to -15 878 o Various text clarifications based on comments in Last Call and 879 IESG review 881 o Clarified that only non-deprecated IPv6 addresses are used 883 o Described handling of downgrading of DSCP markings when blackholes 884 are detected 886 o Expanded acronyms in a new protocol list 888 A.16. Changes from -15 to -16 890 These changes are done post IESG approval, and address IESG comments 891 and other late comments. Issue numbers refer to https://github.com/ 892 rtcweb-wg/rtcweb-transport/issues. 894 o Moved RFC 4594, 7656 and -overview to normative (issue #28) 896 o Changed the terms "client", "WebRTC implementation" and "WebRTC 897 device" to consistently be "WebRTC endpoint", as defined in 898 -overview. (issue #40) 900 o Added a note mentioning TURN service discovery and RETURN (issue 901 #42) 903 o Added a note mentioning that rtp-usage requires circut breaker and 904 congestion control (issue #43) 906 o Added mention of the "don't discard temporary IPv6 addresses that 907 are in use" (issue #44) 909 o Added a reference to draft-ietf-rmcat-coupled-cc (issue #46) 911 A.17. Changes from -16 to -17 913 o Added an informative reference to the "DSCP blackholing" paper 915 o Changed the reference for ICE from RFC 5245 to draft-ietf-ice- 916 rfc5245bis 918 Author's Address 920 Harald Alvestrand 921 Google 923 Email: harald@alvestrand.no