draft-ietf-rtcweb-ip-handling-06.txt		draft-ietf-rtcweb-ip-handling-07.txt
	Network Working Group J. Uberti		Network Working Group J. Uberti
	Internet-Draft Google		Internet-Draft Google
	Intended status: Standards Track G. Shieh		Intended status: Standards Track G. Shieh
	Expires: September 2, 2018 Facebook		Expires: October 20, 2018 Facebook
	March 1, 2018		April 18, 2018
	WebRTC IP Address Handling Requirements		WebRTC IP Address Handling Requirements
	draft-ietf-rtcweb-ip-handling-06		draft-ietf-rtcweb-ip-handling-07
	Abstract		Abstract
	This document provides information and requirements for how IP		This document provides information and requirements for how IP
	addresses should be handled by WebRTC implementations.		addresses should be handled by WebRTC implementations.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 2, 2018.		This Internet-Draft will expire on October 20, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4		5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4		5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4
	5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5		5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5
	6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 6		6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 6
	6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 6		6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 6
	6.2. Determining Host Candidates . . . . . . . . . . . . . . . 6		6.2. Determining Host Candidates . . . . . . . . . . . . . . . 6
	7. Application Guidance . . . . . . . . . . . . . . . . . . . . 7		7. Application Guidance . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 8		11.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	One of WebRTC's key features is its support of peer-to-peer		One of WebRTC's key features is its support of peer-to-peer
	connections. However, when establishing such a connection, which		connections. However, when establishing such a connection, which
	involves connection attempts from various IP addresses, WebRTC may		involves connection attempts from various IP addresses, WebRTC may
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	of UDP will be disabled, and TCP will be used to send and		of UDP will be disabled, and TCP will be used to send and
	receive media through the proxy. Use of TCP will result in		receive media through the proxy. Use of TCP will result in
	reduced media quality, in addition to any performance		reduced media quality, in addition to any performance
	considerations associated with sending all WebRTC media		considerations associated with sending all WebRTC media
	through the proxy server.		through the proxy server.
	Mode 1 MUST only be used when user consent has been provided. The		Mode 1 MUST only be used when user consent has been provided. The
	details of this consent are left to the implementation; one potential		details of this consent are left to the implementation; one potential
	mechanism is to tie this consent to getUserMedia consent.		mechanism is to tie this consent to getUserMedia consent.
			Alternatively, implementations can provide a specific mechanism to
			obtain user consent.
	In cases where user consent has not been obtained, Mode 2 SHOULD be		In cases where user consent has not been obtained, Mode 2 SHOULD be
	used.		used.
	These defaults provide a reasonable tradeoff that permits trusted		These defaults provide a reasonable tradeoff that permits trusted
	WebRTC applications to achieve optimal network performance, but gives		WebRTC applications to achieve optimal network performance, but gives
	applications without consent (e.g., 1-way streaming or data channel		applications without consent (e.g., 1-way streaming or data channel
	applications) only the minimum information needed to achieve direct		applications) only the minimum information needed to achieve direct
	connections, as defined in Mode 2. However, implementations MAY		connections, as defined in Mode 2. However, implementations MAY
	choose stricter modes if desired, e.g., if a user indicates they want		choose stricter modes if desired, e.g., if a user indicates they want
	all WebRTC traffic to follow the default route.		all WebRTC traffic to follow the default route.
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 31 ¶
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089,		[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089,
	DOI 10.17487/RFC8089, February 2017,		DOI 10.17487/RFC8089, February 2017,
	<https://www.rfc-editor.org/info/rfc8089>.		<https://www.rfc-editor.org/info/rfc8089>.
	Appendix A. Change log		Appendix A. Change log
			Changes in draft -07:
			o Clarify consent guidance.
	Changes in draft -06:		Changes in draft -06:
	o Clarify recommendations.		o Clarify recommendations.
	o Split implementation guidance into two sections.		o Split implementation guidance into two sections.
	Changes in draft -05:		Changes in draft -05:
	o Separated framework definition from implementation techniques.		o Separated framework definition from implementation techniques.
End of changes. 6 change blocks.
	5 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/