idnits 2.17.1 draft-ietf-rtcweb-data-channel-06.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 21, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 527, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-00 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-02 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-05 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-04 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-12 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWeb Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Loreto 5 Expires: April 24, 2014 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 October 21, 2013 10 RTCWeb Data Channels 11 draft-ietf-rtcweb-data-channel-06.txt 13 Abstract 15 The Real-Time Communication in WEB-browsers (RTCWeb) working group is 16 charged to provide protocol support for direct interactive rich 17 communication using audio, video, and data between two peers' web- 18 browsers. This document specifies the non-media data transport 19 aspects of the RTCWeb framework. It provides an architectural 20 overview of how the Stream Control Transmission Protocol (SCTP) is 21 used in the RTCWeb context as a generic transport service allowing 22 WEB-browsers to exchange generic data from peer to peer. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 24, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 3 62 3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 3 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5 65 6. The Usage of SCTP in the RTCWeb Context . . . . . . . . . . . 8 66 6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8 67 6.2. Association Setup . . . . . . . . . . . . . . . . . . . . 9 68 6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9 69 6.4. Channel Definition . . . . . . . . . . . . . . . . . . . 10 70 6.5. Opening a Channel . . . . . . . . . . . . . . . . . . . . 10 71 6.6. Transferring User Data on a Channel . . . . . . . . . . . 10 72 6.7. Closing a Channel . . . . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Non-media data types in the context of RTCWeb are handled by using 84 SCTP [RFC4960] encapsulated in DTLS [RFC6347]. 86 +----------+ 87 | SCTP | 88 +----------+ 89 | DTLS | 90 +----------+ 91 | ICE/UDP | 92 +----------+ 94 Figure 1: Basic stack diagram 96 The encapsulation of SCTP over DTLS (see 97 [I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245]) 98 provides a NAT traversal solution together with confidentiality, 99 source authentication, and integrity protected transfers. This data 100 transport service operates in parallel to the media transports, and 101 all of them can eventually share a single transport-layer port 102 number. 104 SCTP as specified in [RFC4960] with the partial reliability extension 105 defined in [RFC3758] provides multiple streams natively with 106 reliable, and partially-reliable delivery modes for user messages. 107 Using the reconfiguration extension defined in [RFC6525] allows to 108 increase the number of streams during the lifetime of an SCTP 109 association and to reset individual SCTP streams. 111 The remainder of this document is organized as follows: Section 3 and 112 Section 4 provide use cases and requirements for both unreliable and 113 reliable peer to peer data channels; Section 5 arguments SCTP over 114 DTLS over UDP; Section 6 provides the specification of how SCTP 115 should be used by the RTCWeb protocol framework for transporting non- 116 media data between WEB-browsers. 118 2. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Use Cases 126 This section defined use cases specific to data channels. For 127 general use cases see [I-D.ietf-rtcweb-use-cases-and-requirements]. 129 3.1. Use Cases for Unreliable Data Channels 131 U-C 1: A real-time game where position and object state information 132 is sent via one or more unreliable data channels. Note that at 133 any time there may be no media channels, or all media channels may 134 be inactive, and that there may also be reliable data channels in 135 use. 137 U-C 2: Providing non-critical information to a user about the reason 138 for a state update in a video chat or conference, such as mute 139 state. 141 3.2. Use Cases for Reliable Data Channels 142 U-C 3: A real-time game where critical state information needs to be 143 transferred, such as control information. Such a game may have no 144 media channels, or they may be inactive at any given time, or may 145 only be added due to in-game actions. 147 U-C 4: Non-realtime file transfers between people chatting. Note 148 that this may involve a large number of files to transfer 149 sequentially or in parallel, such as when sharing a folder of 150 images or a directory of files. 152 U-C 5: Realtime text chat during an audio and/or video call with an 153 individual or with multiple people in a conference. 155 U-C 6: Renegotiation of the set of media streams in the 156 PeerConnection. 158 U-C 7: Proxy browsing, where a browser uses data channels of a 159 PeerConnection to send and receive HTTP/HTTPS requests and data, 160 for example to avoid local internet filtering or monitoring. 162 4. Requirements 164 This section lists the requirements for P2P data channels between two 165 browsers. 167 Req. 1: Multiple simultaneous data channels MUST be supported. 168 Note that there may 0 or more media streams in parallel with the 169 data channels, and the number and state (active/inactive) of the 170 media streams may change at any time. 172 Req. 2: Both reliable and unreliable data channels MUST be 173 supported. 175 Req. 3: Data channels MUST be congestion controlled; either 176 individually, as a class, or in conjunction with the media 177 streams, to ensure that data channels don't cause congestion 178 problems for the media streams, and that the RTCWeb PeerConnection 179 as a whole is fair with competing traffic such as TCP. 181 Req. 4: The application SHOULD be able to provide guidance as to 182 the relative priority of each data channel relative to each other, 183 and relative to the media streams. [ TBD: how this is encoded and 184 what the impact of this is. ] This will interact with the 185 congestion control algorithms. 187 Req. 5: Data channels MUST be secured; allowing for 188 confidentiality, integrity and source authentication. See 189 [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch] for 190 detailed info. 192 Req. 6: Data channels MUST provide message fragmentation support 193 such that IP-layer fragmentation can be avoided no matter how 194 large a message the JavaScript application passes to be sent. It 195 also MUST ensure that large data channel transfers don't unduly 196 delay traffic on other data channels. 198 Req. 7: The data channel transport protocol MUST NOT encode local 199 IP addresses inside its protocol fields; doing so reveals 200 potentially private information, and leads to failure if the 201 address is depended upon. 203 Req. 8: The data channel transport protocol SHOULD support 204 unbounded-length "messages" (i.e., a virtual socket stream) at the 205 application layer, for such things as image-file-transfer; 206 Implementations might enforce a reasonable message size limit. 208 Req. 9: The data channel transport protocol SHOULD avoid IP 209 fragmentation. It MUST support PMTU (Path MTU) discovery and MUST 210 NOT rely on ICMP or ICMPv6 being generated or being passed back, 211 especially for PMTU discovery. 213 Req. 10: It MUST be possible to implement the protocol stack in the 214 user application space. 216 5. SCTP over DTLS over UDP Considerations 218 The important features of SCTP in the RTCWeb context are: 220 o Usage of a TCP-friendly congestion control. 222 o The congestion control is modifiable for integration with media 223 stream congestion control. 225 o Support of multiple unidirectional streams, each providing its own 226 notion of ordered message delivery. 228 o Support of ordered and out-of-order message delivery. 230 o Supporting arbitrary large user message by providing fragmentation 231 and reassembly. 233 o Support of PMTU-discovery. 235 o Support of reliable or partially reliable message transport. 237 SCTP multihoming will not be used in RTCWeb. The SCTP layer will 238 simply act as if it were running on a single-homed host, since that 239 is the abstraction that the lower layer (a connection oriented, 240 unreliable datagram service) exposes. 242 The encapsulation of SCTP over DTLS defined in 243 [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source 244 authenticated, and integrity protected transfers. Using DTLS over 245 UDP in combination with ICE enables NAT traversal in IPv4 based 246 networks. SCTP as specified in [RFC4960] MUST be used in combination 247 with the extension defined in [RFC3758] and provides the following 248 interesting features for transporting non-media data between 249 browsers: 251 o Support of multiple unidirectional streams. 253 o Ordered and unordered delivery of user messages. 255 o Reliable and partial-reliable transport of user messages. 257 Each SCTP user message contains a so called Payload Protocol 258 Identifier (PPID) that is passed to SCTP by its upper layer and sent 259 to its peer. This value can be used to multiplex multiple protocols 260 over a single SCTP association. The sender provides for each 261 protocol a specific PPID and the receiver can demultiplex the 262 messages based on the received PPID. 264 The encapsulation of SCTP over DTLS, together with the SCTP features 265 listed above satisfies all the requirements listed in Section 4. 267 The layering of protocols for WebRTC is shown in the following Figure 268 2. 270 +------+ 271 |RTCWEB| 272 | DATA | 273 +------+ 274 | SCTP | 275 +--------------------+ 276 | STUN | SRTP | DTLS | 277 +--------------------+ 278 | ICE | 279 +--------------------+ 280 | UDP1 | UDP2 | ... | 281 +--------------------+ 283 Figure 2: WebRTC protocol layers 285 This stack (especially in contrast to DTLS over SCTP [RFC6083] in 286 combination with SCTP over UDP [RFC6951]) has been chosen because it 288 o supports the transmission of arbitrary large user messages. 290 o shares the DTLS connection with the media channels. 292 o provides privacy for the SCTP control information. 294 Considering the protocol stack of Figure 2 the usage of DTLS over UDP 295 is specified in [RFC6347], while the usage of SCTP on top of DTLS is 296 specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. 298 Since DTLS is typically implemented in user-land, the SCTP stack also 299 needs to be a user-land stack. 301 When using DTLS as the lower layer, only single homed SCTP 302 associations MUST be used, since DTLS does not expose any address 303 management to its upper layer. The ICE/UDP layer can handle IP 304 address changes during a session without needing to notify the DTLS 305 and SCTP layers, though it would be advantageous to retest Path MTU 306 on an IP address change. 308 DTLS implementations used for this stack SHOULD support controlling 309 fields of the IP layer like the Don't Fragment (DF)-bit in case of 310 IPv4 and the Differentiated Services Code Point (DSCP) field required 311 for supporting [I-D.ietf-rtcweb-qos]. Being able to set the (DF)-bit 312 in case of IPv4 is required for performing path MTU discovery. The 313 DTLS implementation SHOULD also support sending user messages 314 exceeding the Path MTU. 316 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP 317 layer, since there is no way to identify the corresponding 318 association. Therefore SCTP MUST support performing Path MTU 319 discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] 320 using probing messages specified in [RFC4820]. The initial Path MTU 321 at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 for 322 IPv6. Taking an overhead of 20 bytes for IPv4, 40 bytes for IPv6, 8 323 bytes for UDP, 13 + X for DTLS and 28 bytes for SCTP into account, 324 this results in an SCTP payload of 1131 - X when IPv4 is used and 325 1192 - X bytes when IPv6 is used. 327 In general, the lower layer interface of an SCTP implementation 328 SHOULD be adapted to address the differences between IPv4 and IPv6 329 (being connection-less) or DTLS (being connection-oriented). 331 When protocol stack of Figure 2 is used, DTLS protects the complete 332 SCTP packet, so it provides confidentiality, integrity and source 333 authentication of the complete SCTP packet. 335 This protocol stack MUST support the usage of multiple SCTP streams. 336 A user message can be sent ordered or unordered and with partial or 337 full reliability. The partial reliability extension MUST support 338 policies to limit 340 o the transmission and retransmission by time. 342 o the number of retransmissions. 344 Limiting the number of retransmissions to zero combined with 345 unordered delivery provides a UDP-like service where each user 346 message is sent exactly once and delivered in the order received. 348 SCTP provides congestion control on a per-association base. This 349 means that all SCTP streams within a single SCTP association share 350 the same congestion window. Traffic not being sent over SCTP is not 351 covered by the SCTP congestion control. Using a congestion control 352 different from the standard one might improve the impact on the 353 parallel SRTP media streams. Since SCTP does not support the 354 negotiation of a congestion control algorithm, alternate congestion 355 controls SHOULD only require a different sender side behavior using 356 existing information carried in the association. 358 6. The Usage of SCTP in the RTCWeb Context 360 6.1. SCTP Protocol Considerations 362 The DTLS encapsulation of SCTP packets as described in 363 [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. 365 The following SCTP protocol extensions are required: 367 o The stream reset extension defined in [RFC6525] MUST be supported. 368 It is used for closing channels. 370 o The dynamic address reconfiguration extension defined in [RFC5061] 371 MUST be used to signal the support of the stream reset extension 372 defined in [RFC6525], other features of [RFC5061] MUST NOT be 373 used. 375 o The partial reliability extension defined in [RFC3758] MUST be 376 supported. In addition to the timed reliability PR-SCTP policy 377 defined in [RFC3758], the limited retransmission policy defined in 378 [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. 380 Once support for message interleaving as currently being discussed in 381 [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. 383 6.2. Association Setup 385 The SCTP association will be set up when the two endpoints of the 386 WebRTC PeerConnection agree on opening it, as negotiated by JSEP 387 (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally, 388 the negotiation SHOULD include some type of congestion control 389 selection. It will use the DTLS connection selected via SDP; 390 typically this will be shared via BUNDLE or equivalent with DTLS 391 connections used to key the DTLS-SRTP media streams. 393 The application SHOULD indicate the initial number of streams 394 required when opening the association, and if no value is supplied, 395 the implementation SHOULD provide an appropriate default. If more 396 simultaneous streams are needed, [RFC6525] allows adding additional 397 (but not removing) streams to an existing association. Note there 398 can be up to 65536 SCTP streams per SCTP association in each 399 direction. 401 6.3. SCTP Streams 403 SCTP defines a stream as a unidirectional logical channel existing 404 within an SCTP association one to another SCTP endpoint. The streams 405 are used to provide the notion of in-sequence delivery and for 406 multiplexing. Each user message is sent on a particular stream, 407 either order or unordered. Ordering is preserved only for ordered 408 messages sent on the same stream. 410 6.4. Channel Definition 412 The W3C has consensus on defining the application API for WebRTC 413 DataChannels to be bidirectional. They also consider the notions of 414 in-sequence, out-of-sequence, reliable and unreliable as properties 415 of Channels. One strong wish is for the application-level API to be 416 close to the API for WebSockets, which implies bidirectional streams 417 of data and waiting for onopen to fire before sending, a textual 418 label used to identify the meaning of the stream, among other things. 419 Each data channel also has a priority. These priorities MUST NOT be 420 strict priorities. 422 The realization of a bidirectional Data Channel is a pair of one 423 incoming stream and one outgoing SCTP stream. 425 Note that there's no requirement for the SCTP streams used to create 426 a bidirectional channel have the same number in each direction. How 427 stream values are selected is protocol and implementation dependent. 429 6.5. Opening a Channel 431 Data channels can be opened by using internal or external 432 negotiation. The details are out of scope of this document. 434 A simple protocol for internal negotiation is specified in 435 [I-D.ietf-rtcweb-data-protocol] and MUST be supported. 437 When one side wants to open a channel using external negotiation, it 438 picks a Stream. This can be based on the DTLS role (the client picks 439 even stream identifiers, the server odd stream identifiers) or done 440 in a different way. However, the application is responsible for 441 avoiding collisions with existing Streams. If it attempts to re-use 442 a Stream which is part of an existing Channel, the addition SHOULD 443 fail. In addition to choosing a Stream, the application SHOULD also 444 inform the protocol of the options to use for sending messages. The 445 application MUST ensure in an application-specific manner that the 446 other side will also inform the protocol that the selected Stream is 447 to be used, and the parameters for sending data from that side. 449 6.6. Transferring User Data on a Channel 451 All data sent on a Channel in both directions MUST be sent over the 452 underlying Stream using the reliability defined when the Channel was 453 opened unless the options are changed, or per-message options are 454 specified by a higher level. 456 No more than one message should be put into an SCTP user message. 458 The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the 459 interpretation of the "Payload data". For identifying a JavaScript 460 string the PPID "DOMString Last" MUST be used, for JavaScript binary 461 data (ArrayBuffer or Blob) the PPID "Binary Data Last" MUST be used 462 (see Section 8). 464 The SCTP base protocol specified in [RFC4960] does not support the 465 interleaving of user messages. Therefore sending a large user 466 message can monopolize the SCTP association. To overcome this 467 limitation, [I-D.stewart-tsvwg-sctp-ndata] defines an extension to 468 support message interleaving. Once such an extension is available, 469 it SHOULD be used. 471 As long as message interleaving is not supported, the sending 472 application SHOULD fragment large user messages for reliable and 473 ordered data channels. For sending large JavaScript strings, it uses 474 the PPID "DOMString Partial" for all but the last fragments and the 475 PPID "DOMString Last" for the last one. For JavaScript binary data 476 the PPIDs "Binary Data Partial" and "Binary Data Last" are used. The 477 reassembly based on the PPID MUST be supported. For data channel 478 which are not reliable and ordered, the sender MAY limit the maximum 479 message size to avoid monopolization. 481 It is recommended that message size be kept within certain size 482 bounds (TBD) as applications will not be able to support arbitrarily- 483 large single messages. 485 The sender MAY disable the Nagle algorithm to minimize the latency. 487 6.7. Closing a Channel 489 Closing of a Data Channel MUST be signaled by resetting the 490 corresponding outgoing streams [RFC6525]. Resetting a stream set the 491 Stream Sequence Numbers (SSNs) of the stream back to 'zero' with a 492 corresponding notification to the application layer that the reset 493 has been performed. Streams are available to reuse after a reset has 494 been performed. 496 [RFC6525] also guarantees that all the messages are delivered (or 497 abandoned) before resetting the stream. 499 7. Security Considerations 501 This document does not add any additional considerations to the ones 502 given in [I-D.ietf-rtcweb-security] and 503 [I-D.ietf-rtcweb-security-arch]. 505 8. IANA Considerations 507 [NOTE to RFC-Editor: 509 "RFCXXXX" is to be replaced by the RFC number you assign this 510 document. 512 ] 514 This document uses four already registered SCTP Payload Protocol 515 Identifiers (PPIDs). [RFC4960] creates the registry "SCTP Payload 516 Protocol Identifiers" from which these identifiers were assigned. 517 IANA is requested to update the reference of these four assignments 518 to point to this document. Therefore these four assignments should 519 be updated to read: 521 +---------------------+-----------+-----------+ 522 | Value | SCTP PPID | Reference | 523 +---------------------+-----------+-----------+ 524 | DOMString Last | 51 | [RFCXXXX] | 525 | Binary Data Partial | 52 | [RFCXXXX] | 526 | Binary Data Last | 53 | [RFCXXXX] | 527 | DOMString Partial | 54 | [RFCXXXX] | 528 +---------------------+-----------+-----------+ 530 9. Acknowledgments 532 Many thanks for comments, ideas, and text from Harald Alvestrand, 533 Adam Bergkvist, Cullen Jennings, Eric Rescorla, Randall Stewart, 534 Justin Uberti, and Magnus Westerlund. 536 10. References 538 10.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 544 Conrad, "Stream Control Transmission Protocol (SCTP) 545 Partial Reliability Extension", RFC 3758, May 2004. 547 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 548 Parameter for the Stream Control Transmission Protocol 549 (SCTP)", RFC 4820, March 2007. 551 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 552 Discovery", RFC 4821, March 2007. 554 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 555 4960, September 2007. 557 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 558 Kozuka, "Stream Control Transmission Protocol (SCTP) 559 Dynamic Address Reconfiguration", RFC 5061, September 560 2007. 562 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 563 (ICE): A Protocol for Network Address Translator (NAT) 564 Traversal for Offer/Answer Protocols", RFC 5245, April 565 2010. 567 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 568 Security Version 1.2", RFC 6347, January 2012. 570 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 571 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 572 6525, February 2012. 574 [I-D.stewart-tsvwg-sctp-ndata] 575 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A 576 New Data Chunk for Stream Control Transmission Protocol", 577 draft-stewart-tsvwg-sctp-ndata-03 (work in progress), 578 October 2013. 580 [I-D.ietf-rtcweb-data-protocol] 581 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 582 Protocol", draft-ietf-rtcweb-data-protocol-00 (work in 583 progress), July 2013. 585 [I-D.ietf-tsvwg-sctp-dtls-encaps] 586 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 587 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 588 dtls-encaps-02 (work in progress), October 2013. 590 [I-D.ietf-rtcweb-security] 591 Rescorla, E., "Security Considerations for WebRTC", draft- 592 ietf-rtcweb-security-05 (work in progress), July 2013. 594 [I-D.ietf-rtcweb-security-arch] 595 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 596 rtcweb-security-arch-07 (work in progress), July 2013. 598 [I-D.ietf-rtcweb-jsep] 599 Uberti, J. and C. Jennings, "Javascript Session 600 Establishment Protocol", draft-ietf-rtcweb-jsep-04 (work 601 in progress), September 2013. 603 [I-D.ietf-rtcweb-qos] 604 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 605 other packet markings for RTCWeb QoS", draft-ietf-rtcweb- 606 qos-00 (work in progress), October 2012. 608 10.2. Informative References 610 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 611 Transport Layer Security (DTLS) for Stream Control 612 Transmission Protocol (SCTP)", RFC 6083, January 2011. 614 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 615 Control Transmission Protocol (SCTP) Packets for End-Host 616 to End-Host Communication", RFC 6951, May 2013. 618 [I-D.ietf-rtcweb-use-cases-and-requirements] 619 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 620 Time Communication Use-cases and Requirements", draft- 621 ietf-rtcweb-use-cases-and-requirements-12 (work in 622 progress), October 2013. 624 [I-D.tuexen-tsvwg-sctp-prpolicies] 625 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 626 "Additional Policies for the Partial Delivery Extension of 627 the Stream Control Transmission Protocol", draft-tuexen- 628 tsvwg-sctp-prpolicies-03 (work in progress), October 2013. 630 Authors' Addresses 632 Randell Jesup 633 Mozilla 634 US 636 Email: randell-ietf@jesup.org 638 Salvatore Loreto 639 Ericsson 640 Hirsalantie 11 641 Jorvas 02420 642 FI 644 Email: salvatore.loreto@ericsson.com 645 Michael Tuexen 646 Muenster University of Applied Sciences 647 Stegerwaldstrasse 39 648 Steinfurt 48565 649 DE 651 Email: tuexen@fh-muenster.de