--- 1/draft-ietf-rtcweb-transports-11.txt 2016-03-21 16:23:22.020252107 -0700 +++ 2/draft-ietf-rtcweb-transports-12.txt 2016-03-21 16:23:22.172255872 -0700 @@ -1,18 +1,18 @@ Network Working Group H. Alvestrand Internet-Draft Google -Intended status: Standards Track January 28, 2016 -Expires: July 31, 2016 +Intended status: Standards Track March 21, 2016 +Expires: September 22, 2016 Transports for WebRTC - draft-ietf-rtcweb-transports-11 + draft-ietf-rtcweb-transports-12 Abstract This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 31, 2016. + This Internet-Draft will expire on September 22, 2016. Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -56,34 +56,35 @@ 3.4. Middle box related functions . . . . . . . . . . . . . . 4 3.5. Transport protocols implemented . . . . . . . . . . . . . 6 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 6 4.1. Local prioritization . . . . . . . . . . . . . . . . . . 7 4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13 - A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 13 - A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 13 + A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 14 + A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 14 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 14 - A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 14 - A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 14 + A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 15 + A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15 A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 - A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15 - A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 15 - A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 15 + A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16 + A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 16 + A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 16 A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 16 A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 + A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction WebRTC is a protocol suite aimed at real time multimedia exchange between browsers, and between browsers and other entities. WebRTC is described in the WebRTC overview document, [I-D.ietf-rtcweb-overview], which also defines terminology used in this document, including the terms "WebRTC device" and "WebRTC browser". @@ -161,20 +162,23 @@ by the IPV6_PREFER_SRC_TMP preference flag specified in [RFC5014]. However, this rule is not completely obvious in the ICE scope. This is therefore clarified as follows: When a client gathers all IPv6 addresses on a host, and both temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in [RFC6724]. + If some of the temporary IPv6 addresses, but not all, are marked + deprecated, the client SHOULD discard the deprecated addresses. + 3.4. Middle box related functions The primary mechanism to deal with middle boxes is ICE, which is an appropriate way to deal with NAT boxes and firewalls that accept traffic from the inside, but only from the outside if it is in response to inside traffic (simple stateful firewalls). ICE [RFC5245] MUST be supported. The implementation MUST be a full ICE implementation, not ICE-Lite. A full ICE implementation allows interworking with both ICE and ICE-Lite implementations when they are @@ -365,21 +369,21 @@ data channels MUST use a single DSCP code point. The code point used SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the highest priority data channel carried. Note that this means that all data packets, no matter what their relative priority is, will be treated the same by the network. All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point. More advice on the use of DSCP code points with RTP is given in - [I-D.ietf-dart-dscp-rtp]. + [RFC7657]. There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points. Some of these schemes depend on classifying the traffic into flows based on 5-tuple (source address, source port, protocol, destination address, destination port) or 6-tuple (5-tuple + DSCP code point). Under differing conditions, it may therefore make sense for a sending application to choose any of the configurations: o Each media stream carried on its own 5-tuple @@ -439,166 +443,185 @@ contributions from Andrew Hutton also deserve special mention. 8. References 8.1. Normative References [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Loreto, S., and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf- - mmusic-sctp-sdp-12 (work in progress), January 2015. + mmusic-sctp-sdp-16 (work in progress), February 2016. [I-D.ietf-rtcweb-alpn] Thomson, M., "Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- - alpn-00 (work in progress), July 2014. + alpn-02 (work in progress), January 2016. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", - draft-ietf-rtcweb-rtp-usage-22 (work in progress), - February 2015. + draft-ietf-rtcweb-rtp-usage-26 (work in progress), March + 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- - ietf-rtcweb-security-07 (work in progress), July 2014. + ietf-rtcweb-security-08 (work in progress), February 2015. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- - rtcweb-security-arch-10 (work in progress), July 2014. + rtcweb-security-arch-11 (work in progress), March 2015. [I-D.ietf-tsvwg-rtcweb-qos] - Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. - Polk, "DSCP and other packet markings for RTCWeb QoS", - draft-ietf-tsvwg-rtcweb-qos-03 (work in progress), - November 2014. + Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP + and other packet markings for WebRTC QoS", draft-ietf- + tsvwg-rtcweb-qos-15 (work in progress), March 2016. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-09 (work in progress), January 2015. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, - "Stream Schedulers and a New Data Chunk for the Stream - Control Transmission Protocol", draft-ietf-tsvwg-sctp- - ndata-02 (work in progress), January 2015. + "Stream Schedulers and User Message Interleaving for the + Stream Control Transmission Protocol", draft-ietf-tsvwg- + sctp-ndata-05 (work in progress), March 2016. [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI + 10.17487/RFC0768, August 1980, + . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC - 793, September 1981. + 793, DOI 10.17487/RFC0793, September 1981, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ + RFC2119, March 1997, + . [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- - Oriented Transport", RFC 4571, July 2006. + Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July + 2006, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in - IPv6", RFC 4941, September 2007. + IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, + . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", RFC 5245, April - 2010. + Traversal for Offer/Answer Protocols", RFC 5245, DOI + 10.17487/RFC5245, April 2010, + . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, - October 2008. + DOI 10.17487/RFC5389, October 2008, + . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure - Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. + Real-time Transport Protocol (SRTP)", RFC 5764, DOI + 10.17487/RFC5764, May 2010, + . [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session - Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. + Traversal Utilities for NAT (STUN)", RFC 5766, DOI + 10.17487/RFC5766, April 2010, + . - [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays - around NAT (TURN) Extensions for TCP Allocations", RFC - 6062, November 2010. + [RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using + Relays around NAT (TURN) Extensions for TCP Allocations", + RFC 6062, DOI 10.17487/RFC6062, November 2010, + . - [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal + [RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC - 6156, April 2011. + 6156, DOI 10.17487/RFC6156, April 2011, + . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity - Establishment (ICE)", RFC 6544, March 2012. + Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, + March 2012, . - [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, + [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 - (IPv6)", RFC 6724, September 2012. + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC7639] Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP Header Field", RFC 7639, DOI 10.17487/RFC7639, August 2015, . 8.2. Informative References - [I-D.ietf-dart-dscp-rtp] - Black, D. and P. Jones, "Differentiated Services - (DiffServ) and Real-time Communication", draft-ietf-dart- - dscp-rtp-10 (work in progress), November 2014. - [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for - Browser-based Applications", draft-ietf-rtcweb-overview-13 - (work in progress), November 2014. + Browser-based Applications", draft-ietf-rtcweb-overview-15 + (work in progress), January 2016. [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. + Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/ + RFC3484, February 2003, + . [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 - Socket API for Source Address Selection", RFC 5014, - September 2007. + Socket API for Source Address Selection", RFC 5014, DOI + 10.17487/RFC5014, September 2007, + . [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address - Translators (NATs)", RFC 5128, March 2008. + Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March + 2008, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . + [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services + (Diffserv) and Real-Time Communication", RFC 7657, DOI + 10.17487/RFC7657, November 2015, + . + Appendix A. Change log This section should be removed before publication as an RFC. A.1. Changes from -00 to -01 o Clarified DSCP requirements, with reference to -qos- o Clarified "symmetric NAT" -> "NATs which perform endpoint- dependent mapping" @@ -723,16 +747,23 @@ (Bug #6) A.11. Changes from -10 to -11 o Added a definition of the term "flow" used in the prioritization chapter o Changed the names of the four priority levels to conform to other specs. +A.12. Changes from -11 to -12 + + o Added a SHOULD NOT about using deprecated temporary IPv6 + addresses. + + o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657 + Author's Address Harald Alvestrand Google Email: harald@alvestrand.no