draft-ietf-rtcweb-mdns-ice-candidates-03.txt   draft-ietf-rtcweb-mdns-ice-candidates-04.txt 
RTCWEB Y. Fablet RTCWEB Y. Fablet
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational J. de Borst Intended status: Informational J. de Borst
Expires: September 26, 2019 J. Uberti Expires: April 18, 2020 J. Uberti
Q. Wang Q. Wang
Google Google
March 25, 2019 October 16, 2019
Using Multicast DNS to protect privacy when exposing ICE candidates Using Multicast DNS to protect privacy when exposing ICE candidates
draft-ietf-rtcweb-mdns-ice-candidates-03 draft-ietf-rtcweb-mdns-ice-candidates-04
Abstract Abstract
WebRTC applications collect ICE candidates as part of the process of WebRTC applications collect ICE candidates as part of the process of
creating peer-to-peer connections. To maximize the probability of a creating peer-to-peer connections. To maximize the probability of a
direct peer-to-peer connection, client private IP addresses are direct peer-to-peer connection, client private IP addresses are
included in this candidate collection. However, disclosure of these included in this candidate collection. However, disclosure of these
addresses has privacy implications. This document describes a way to addresses has privacy implications. This document describes a way to
share local IP addresses with other clients while preserving client share local IP addresses with other clients while preserving client
privacy. This is achieved by concealing IP addresses with privacy. This is achieved by concealing IP addresses with
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 26, 2019. This Internet-Draft will expire on April 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3 3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3
3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Implementation Guidance . . . . . . . . . . . . . . . 4 3.1.2. Implementation Guidance . . . . . . . . . . . . . . . 5
3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 6 3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 6
3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Implementation Guidance . . . . . . . . . . . . . . . 6 3.2.2. Implementation Guidance . . . . . . . . . . . . . . . 7
3.3. Additional Privacy Considerations . . . . . . . . . . . . 6 3.3. Additional Privacy Considerations . . . . . . . . . . . . 7
3.3.1. Statistics . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Statistics . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Interactions With TURN Servers . . . . . . . . . . . 7 3.3.2. Interactions With TURN Servers . . . . . . . . . . . 7
3.3.3. Generated Name Reuse . . . . . . . . . . . . . . . . 8 3.3.3. Generated Name Reuse . . . . . . . . . . . . . . . . 8
3.3.4. Specific Browsing Contexts . . . . . . . . . . . . . 8 3.3.4. Specific Browsing Contexts . . . . . . . . . . . . . 8
3.3.5. Network Interface Enumeration . . . . . . . . . . . . 8 3.3.5. Network Interface Enumeration . . . . . . . . . . . . 8
3.3.6. Monitoring of Sessions . . . . . . . . . . . . . . . 8 3.3.6. Monitoring of Sessions . . . . . . . . . . . . . . . 9
4. Potential Limitations . . . . . . . . . . . . . . . . . . . . 9 4. Potential Limitations . . . . . . . . . . . . . . . . . . . . 9
4.1. Reduced Connectivity . . . . . . . . . . . . . . . . . . 9 4.1. Reduced Connectivity . . . . . . . . . . . . . . . . . . 9
4.2. Connection Setup Latency . . . . . . . . . . . . . . . . 9 4.2. Connection Setup Latency . . . . . . . . . . . . . . . . 10
4.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10 4.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 11
5.2. Peer-reflexive Candidate From Slow Signaling . . . . . . 11 5.2. Peer-reflexive Candidate From Slow Signaling . . . . . . 12
5.3. Peer-reflexive Candidate From Slow Resolution . . . . . . 11 5.3. Peer-reflexive Candidate From Slow Resolution . . . . . . 12
5.4. IPv4, IPv6, and STUN handling . . . . . . . . . . . . . . 12 5.4. IPv4, IPv6, and STUN handling . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 14 6.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 15
6.2. Malicious Responses to Deny Name Registration . . . . . . 15 6.2. Malicious Responses to Deny Name Registration . . . . . . 16
6.3. Unsolicited ICE Communications . . . . . . . . . . . . . 15 6.3. Unsolicited ICE Communications . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
As detailed in [IPHandling], exposing client private IP addresses by As detailed in [IPHandling], exposing client private IP addresses by
default to web applications maximizes the probability of successfully default to web applications maximizes the probability of successfully
creating direct peer-to-peer connections between clients, but creates creating direct peer-to-peer connections between clients, but creates
a significant surface for user fingerprinting. [IPHandling] a significant surface for user fingerprinting. [IPHandling]
recognizes this issue, but also admits that there is no current recognizes this issue, but also admits that there is no current
solution to this problem; implementations that choose to use Mode 3 solution to this problem; implementations that choose to use Mode 3
to address the privacy concerns often suffer from failing or to address the privacy concerns often suffer from failing or
skipping to change at page 4, line 16 skipping to change at page 4, line 16
For each host candidate gathered by an ICE agent as part of the For each host candidate gathered by an ICE agent as part of the
gathering process described in [RFC8445], Section 5.1.1, the gathering process described in [RFC8445], Section 5.1.1, the
candidate is handled as described below. candidate is handled as described below.
1. Check whether this IP address satisfies the ICE agent's policy 1. Check whether this IP address satisfies the ICE agent's policy
regarding whether an address is safe to expose. If so, expose regarding whether an address is safe to expose. If so, expose
the candidate and abort this process. the candidate and abort this process.
2. Check whether the ICE agent has previously generated, registered, 2. Check whether the ICE agent has previously generated, registered,
and stored an mDNS hostname for this IP address as per Steps 3, and stored an mDNS hostname for this IP address as per steps 3 to
4, and 6. If it has, skip ahead to Step 7. 5. If it has, skip ahead to step 6.
3. Generate a unique mDNS hostname. The unique name MUST consist of 3. Generate a unique mDNS hostname. The unique name MUST consist of
a version 4 UUID as defined in [RFC4122], followed by ".local". a version 4 UUID as defined in [RFC4122], followed by ".local".
4. Register the candidate's mDNS hostname as defined in [RFC6762]. 4. Register the candidate's mDNS hostname as defined in [RFC6762].
The ICE agent SHOULD send an mDNS announcement for the hostname,
but as the hostname is expected to be unique, the ICE agent
SHOULD skip probing of the hostname.
5. If registering of the mDNS hostname fails, abort these steps. 5. Store the mDNS hostname and its related IP address in the ICE
The candidate is not exposed.
6. Store the mDNS hostname and its related IP address in the ICE
agent for future reuse. agent for future reuse.
7. Replace the IP address of the ICE candidate with its mDNS 6. Replace the IP address of the ICE candidate with its mDNS
hostname and provide the candidate to the web application. hostname and provide the candidate to the web application.
ICE agents can implement this procedure in any way as long as it ICE agents can implement this procedure in any way as long as it
produces equivalent results. An implementation may for instance pre- produces equivalent results. An implementation may for instance pre-
register mDNS hostnames by executing steps 3 to 6 and prepopulate an register mDNS hostnames by executing steps 3 to 5 and prepopulate an
ICE agent accordingly. By doing so, only step 7 of the above ICE agent accordingly. By doing so, only step 6 of the above
procedure will be executed at the time of gathering candidates. procedure will be executed at the time of gathering candidates.
An implementation may also detect that mDNS is not supported by the In order to prevent web applications from using this mechanism to
available network interfaces. The ICE agent may skip steps 3 and 4 query for mDNS support in the local network, the ICE agent SHOULD
and directly decide to not expose the host candidate. still provide mDNS candidates in step 6 even if the local network
does not support mDNS or mDNS registration fails in step 4.
This procedure ensures that an mDNS name is used to replace only one This procedure ensures that an mDNS name is used to replace only one
IP address. Specifically, an ICE agent using an interface with both IP address. Specifically, an ICE agent using an interface with both
IPv4 and IPv6 addresses MUST expose a different mDNS name for each IPv4 and IPv6 addresses MUST expose a different mDNS name for each
address. address.
3.1.2. Implementation Guidance 3.1.2. Implementation Guidance
3.1.2.1. Determining Address Privacy and Server-Reflexive Candidates
3.1.2.1. Registration
Sending the mDNS announcement to the network can be delayed, for
instance due to rate limits. An ICE agent SHOULD provide the
candidate to the web application as soon as its mDNS name is
generated, regardless of whether the announcement has been sent on
the network.
3.1.2.2. Determining Address Privacy and Server-Reflexive Candidates
Naturally, an address that is already exposed to the Internet does Naturally, an address that is already exposed to the Internet does
not need to be protected by mDNS, as it can be trivially observed by not need to be protected by mDNS, as it can be trivially observed by
the web server or remote endpoint. However, determining this ahead the web server or remote endpoint. However, determining this ahead
of time is not straightforward; while the fact that an IPv4 address of time is not straightforward; while the fact that an IPv4 address
is private can sometimes be inferred by its value, e.g., whether it is private can sometimes be inferred by its value, e.g., whether it
is an [RFC1918] address, the reverse is not necessarily true. IPv6 is an [RFC1918] address, the reverse is not necessarily true. IPv6
addresses present their own complications, e.g., private IPv6 addresses present their own complications, e.g., private IPv6
addresses as a result of NAT64 [RFC6146]. addresses as a result of NAT64 [RFC6146].
skipping to change at page 5, line 29 skipping to change at page 5, line 40
both IPv4 and IPv6 local addresses, provided that the application has both IPv4 and IPv6 local addresses, provided that the application has
configured both IPv4 and IPv6 STUN servers. If the STUN response configured both IPv4 and IPv6 STUN servers. If the STUN response
returns the same value as the local IP address, this indicates the returns the same value as the local IP address, this indicates the
address is in fact public. address is in fact public.
Regardless of the result, a server-reflexive candidate will be Regardless of the result, a server-reflexive candidate will be
generated; the transport address of this candidate is an IP address generated; the transport address of this candidate is an IP address
and therefore distinct from the hostname transport address of the and therefore distinct from the hostname transport address of the
associated mDNS candidate, and as such MUST NOT be considered associated mDNS candidate, and as such MUST NOT be considered
redundant per the guidance in [RFC8445], Section 5.1.3. To avoid redundant per the guidance in [RFC8445], Section 5.1.3. To avoid
accidental IP address, this server-reflexive candidate MUST have its accidental IP address disclosure, this server-reflexive candidate
raddr field set to 0.0.0.0 and its rport field set to 0. MUST have its raddr field set to "0.0.0.0"/"::" and its rport field
set to "9", as discussed in [ICESDP], Section 9.1.
Once an address has been identified as public, the ICE agent MAY Once an address has been identified as public, the ICE agent MAY
cache this information and omit mDNS protection for that address in cache this information and omit mDNS protection for that address in
future ICE gathering phases. future ICE gathering phases.
3.1.2.2. Special Handling for IPv6 Addresses 3.1.2.3. Special Handling for IPv6 Addresses
As noted in [IPHandling], private IPv4 addresses are especially As noted in [IPHandling], private IPv4 addresses are especially
problematic because of their unbounded lifetime. However, the problematic because of their unbounded lifetime. However, the
[RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy [RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy
protections, namely a short lifetime and the lack of any stateful protections, namely a short lifetime and the lack of any stateful
information. Accordingly, implementations MAY choose to not conceal information. Accordingly, implementations MAY choose to not conceal
[RFC4941] addresses with mDNS names as a tradeoff for improved peer- [RFC4941] addresses with mDNS names as a tradeoff for improved peer-
to-peer connectivity. to-peer connectivity.
3.1.2.3. mDNS Candidate Encoding 3.1.2.4. mDNS Candidate Encoding
The mDNS name of an mDNS candidate MUST be used in the connection- The mDNS name of an mDNS candidate MUST be used in the connection-
address field of its candidate attribute. When an mDNS candidate is address field of its candidate attribute. However, when an mDNS
the default candidate, its mDNS name MUST be used in the connection- candidate would be the default candidate, typically because there are
address field of the SDP "c=" line. Since an mDNS candidate also no other candidates, its mDNS name MUST NOT be used in the
conceals its address family, the "c=" line SHOULD use "IP4" in the connection-address field of the SDP "c=" line, as experimental
address-type field. deployment has indicated that many remote endpoints will fail to
handle such a SDP. In this situation, the IP address values
"0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and
m= lines, similar to how the no-candidates case is handled in
[ICESDP], Section 4.3.1.
Any candidates exposed to the application via local descriptions MUST Any candidates exposed to the application via local descriptions MUST
be identical to those provided during candidate gathering (i.e., MUST be identical to those provided during candidate gathering (i.e., MUST
NOT contain private host IP addresses). NOT contain private host IP addresses).
3.2. ICE Candidate Processing 3.2. ICE Candidate Processing
This section outlines how received ICE candidates with mDNS names are This section outlines how received ICE candidates with mDNS names are
processed by ICE agents, and is relevant to all endpoints. processed by ICE agents, and is relevant to all endpoints.
3.2.1. Procedure 3.2.1. Procedure
For any remote ICE candidate received by the ICE agent, the following For any remote ICE candidate received by the ICE agent, the following
procedure is used: procedure is used:
1. If the connection-address field value of the ICE candidate does 1. If the connection-address field value of the ICE candidate does
not end with ".local" or if the value contains more than one ".", not end with ".local" or if the value contains more than one ".",
then process the candidate as defined in [RFC8445]. then process the candidate as defined in [RFC8445].
2. Otherwise, resolve the candidate using mDNS. 2. Otherwise, resolve the candidate using mDNS. The ICE agent
SHOULD set the unicast-response bit of the corresponding mDNS
query message; this minimizes multicast traffic, as the response
is probably only useful to the querying node.
3. If it resolves to an IP address, replace the mDNS hostname of the 3. If it resolves to an IP address, replace the mDNS hostname of the
ICE candidate with the resolved IP address and continue ICE candidate with the resolved IP address and continue
processing of the candidate as defined in [RFC8445]. processing of the candidate as defined in [RFC8445].
4. Otherwise, ignore the candidate. 4. Otherwise, ignore the candidate.
3.2.2. Implementation Guidance 3.2.2. Implementation Guidance
An ICE agent may use a hostname resolver that transparently supports An ICE agent may use a hostname resolver that transparently supports
skipping to change at page 9, line 29 skipping to change at page 9, line 45
First, some networks may entirely disable mDNS. Second, mDNS queries First, some networks may entirely disable mDNS. Second, mDNS queries
have limited scope. On large networks, this may mean that an mDNS have limited scope. On large networks, this may mean that an mDNS
name cannot be resolved if the remote endpoint is too many segments name cannot be resolved if the remote endpoint is too many segments
away. away.
When mDNS fails, ICE will attempt to fall back to either NAT hairpin, When mDNS fails, ICE will attempt to fall back to either NAT hairpin,
if supported, or TURN relay if not. This may result in reduced if supported, or TURN relay if not. This may result in reduced
connectivity, reduced throughput and increased latency, as well as connectivity, reduced throughput and increased latency, as well as
increased cost in case of TURN relay. increased cost in case of TURN relay.
During experimental testing of the mDNS technique across a set of
known mDNS-aware endpoints that had configured a STUN server but not
a TURN server, the observed impact to ICE connection rate was 2%
(relative) when mDNS was enabled on both sides, compared to when mDNS
was only enabled on one side. In this testing, the percentage of
connections that required STUN (i.e., went through a NAT) increased
from 94% to 97%, indicating that mDNS succeeded about half the time,
and fell back to NAT hairpin for the remainder. The most likely
explanation for the overall connection rate drop is that hairpinning
failed in some cases.
One potential mitigation, as discussed in Section 3.3, is to not One potential mitigation, as discussed in Section 3.3, is to not
conceal candidates created from [RFC4941] IPv6 addresses. This conceal candidates created from [RFC4941] IPv6 addresses. This
permits connectivity even in large internal networks or where mDNS is permits connectivity even in large internal networks or where mDNS is
disabled. disabled. Future versions of this document will include experimental
data regarding this option.
The exact impact of the mDNS technique is being researched
experimentally and will be provided before publication of this
document.
4.2. Connection Setup Latency 4.2. Connection Setup Latency
As noted in Section 3, ICE agents using the mDNS technique are As noted in Section 3, ICE agents using the mDNS technique are
responsible for registering and resolving mDNS names as part of the responsible for registering and resolving mDNS names as part of the
ICE process. These steps may delay establishment of a direct peer- ICE process. These steps may delay establishment of a direct peer-
to-peer connection, compared to when raw local IP addresses are used. to-peer connection, compared to when raw local IP addresses are used.
Given that these mDNS registrations and queries are typically Given that these mDNS registrations and queries are typically
occurring on a local network, any associated delays should be small. occurring on a local network, any associated delays should be small.
skipping to change at page 10, line 20 skipping to change at page 10, line 41
endpoint will still provide its local IP addresses, and accordingly a endpoint will still provide its local IP addresses, and accordingly a
direct connection can still be attempted, even though the legacy direct connection can still be attempted, even though the legacy
endpoint cannot resolve the mDNS names provided by the new endpoint. endpoint cannot resolve the mDNS names provided by the new endpoint.
In the event the legacy endpoint attempts to resolve mDNS names using In the event the legacy endpoint attempts to resolve mDNS names using
Unicast DNS, this may cause ICE to take somewhat longer to fully Unicast DNS, this may cause ICE to take somewhat longer to fully
complete, but should not have any effect on connectivity or complete, but should not have any effect on connectivity or
connection setup time. connection setup time.
However, some legacy endpoints are not fully spec-compliant and can However, some legacy endpoints are not fully spec-compliant and can
behave unpredictably in the presence of ICE candidates that contain a behave unpredictably in the presence of ICE candidates that contain a
hostname, potentially leading to ICE failure. Such endpoints have hostname, potentially leading to ICE failure. Some endpoints may
been identified during testing of this technique, but appear to be also fail to handle a connectivity check from an address that they
rare. have not received in signaling. During the aforementioned
experimental testing, the connection rate when interacting with
endpoints that provided raw IP addresses (and therefore should be
unaffected) decreased by 3% (relative), presumably for these reasons.
5. Examples 5. Examples
The examples below show how the mDNS technique is used during ICE The examples below show how the mDNS technique is used during ICE
processing. The first example shows a simple case, the next two processing. The first example shows a simple case, the next two
examples demonstrate how peer-reflexive candidates for local IP examples demonstrate how peer-reflexive candidates for local IP
addresses can be created due to timing differences, and the final addresses can be created due to timing differences, and the final
example shows a real-world case with IPv4, IPv6, and STUN. example shows a real-world case with IPv4, IPv6, and STUN.
5.1. Normal Handling 5.1. Normal Handling
skipping to change at page 17, line 14 skipping to change at page 17, line 45
8.2. Informative References 8.2. Informative References
[HTMLSpec] [HTMLSpec]
"HTML Living Standard", n.d., "HTML Living Standard", n.d.,
<https://html.spec.whatwg.org>. <https://html.spec.whatwg.org>.
[ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/
Answer procedures for Interactive Connectivity Answer procedures for Interactive Connectivity
Establishment (ICE)", April 2018, Establishment (ICE)", April 2018,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-
draft-ietf-mmusic-ice-sip-sdp>. sdp>.
[IPHandling] [IPHandling]
Shieh, G., "WebRTC IP Address Handling Requirements", Shieh, G., "WebRTC IP Address Handling Requirements",
April 2018, <https://tools.ietf.org/html/ April 2018, <https://tools.ietf.org/html/draft-ietf-
draft-ietf-rtcweb-ip-handling>. rtcweb-ip-handling>.
[Overview] [Overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", November 2017, Browser-based Applications", November 2017,
<https://tools.ietf.org/html/draft-ietf-rtcweb-overview>. <https://tools.ietf.org/html/draft-ietf-rtcweb-overview>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
 End of changes. 28 change blocks. 
53 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/