Change:
Abstract <del> WebRTC applications rely on ICE candidates to enable peer-to-peer connections between clients in as many network configurations as possible.  To maximize the probability to create a direct peer-to- peer connection, client private IP addresses are often exposed without user consent.  This is currently used as a way to track users.  This document describes a way to share IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses using dynamically generated names resolvable through Multicast DNS RFC6763. </del> <ins> WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections.  To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection.  However, disclosure of these addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with dynamically generated Multicast DNS (mDNS) RFC6762 names. </ins> 1. <del> As detailed in IPHandling, exposing client private IP addresses allows maximizing the probability to successfully create a connection between two clients.  This information is also used by many web sites as a way to fingerprint and identify users without their consent. The first approach exposes client private IP addresses by default, as can be seen from websites such as IPLeak.  The second approach implemented in the WebKit engine enforces the following policy: By default, use mode 3 as defined in IPHandling: any host ICE candidate is filtered out. Use mode 2 as defined in IPHandling if there is an explicit user action to trust the web site: host ICE candidates are exposed to the web site based on the use of navigator.mediaDevices.getUserMedia, which typically prompts the user to grant or deny access to cameras/microphones. The second approach supports most common audio/video conference applications but leads to failing or suboptimal connections for applications relying solely on data channel.  This is particularly an issue on unmanaged networks, typically home or small offices where NAT loopback might not be supported. To overcome the shortcomings of the above two approaches, this document proposes to register dynamically generated names using Multicast DNS when gathering ICE candidates.  These dynamically generated names are used to replace private IP addresses in host ICE candidates.  Only clients that can resolve these dynamically generated names using Multicast DNS will get access to the actual client IP address. </del> <ins> As detailed in IPHandling, exposing client private IP addresses by default maximizes the probability of successfully creating direct peer-to-peer connection between two clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes this issue, but also admits that there is no current solution to this problem; implementations that choose to use Mode 3 to address the privacy concerns often suffer from failing or suboptimal connections in WebRTC applications.  This is particularly an issue on unmanaged networks, typically homes or small offices, where NAT loopback may not be supported. This document proposes an overall solution to this problem by registering ephemeral mDNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates.  WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </ins> 2. <del> The gathering of ICE candidates without user consent is a well-known fingerprinting technique to track users.  This is particularly a concern when users are connected through a NAT which is a usual configuration.  In such a case, knowing both the private IP address and the public IP address will usually identify uniquely the user device.  Additionally, Internet web sites can more easily attack intranet web sites when knowing the intranet IP address range. A successful WebRTC connection between two peers is also a potential thread to user privacy.  When a WebRTC connection latency is close to zero, the probability is high that the two peers are running on the same device.  Browsers often isolate contexts one from the other. Private browsing mode contexts usually do not share any information with regular browsing contexts.  The WebKit engine isolates third- party iframes in various ways (cookies, ITP) to prevent user tracking.  Enabling a web application to determine that two contexts run in the same device would defeat some of the protections provided by modern browsers. 3. </del> This section uses the concept of ICE agent as define in RFC8445.  In the remainder of the document, it is assumed that each browser execution context has its own ICE agent. <del> 3.1. For any host ICE candidate gathered by a browsing context as part of RFC8445 section 5.1.1, obfuscation of the candidate is done as follows: </del> <ins> 2.1. </ins> <del> Check whether the context ICE agent registered a name resolving to the ICE host candidate IP address. </del> <ins> For any host candidate gathered by an ICE agent as part of RFC8445 section 5.1.1, the candidate is processed as follows: </ins> <del> If the ICE agent registered the name, replace the IP address of the ICE host candidate with the name with ".local" appended to it. Expose the candidate and abort these steps. </del> <ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. </ins> <del> Generate a random unique name, typically a version 4 UUID as defined in RFC4122. </del> <ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". </ins> <del> Register the unique name using Multicast DNS. </del> <ins> Register the candidate's mDNS hostname as defined in RFC6762. </ins> <del> If registering of the unique name fails, abort these steps.  The </del> <ins> If registering of the mDNS hostname fails, abort these steps.  The </ins> candidate is not exposed. <del> Store the name and its related IP address in the ICE agent for future reuse. </del> <ins> Store the mDNS hostname and its related IP address in the ICE agent for future reuse. </ins> <del> Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. </del> <ins> Replace the IP address of the ICE host candidate with its mDNS hostname, and expose the candidate as usual. </ins> <del> 3.2. </del> <ins> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip steps 2 and 3 and directly decide to not expose the host candidate. This procedure ensures that a mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. 2.2. </ins> For any remote host ICE candidate received by the ICE agent, the following procedure is used: If the connection-address field value of the ICE candidate does <del> not finish by ".local", process the candidate as defined in RFC8445. </del> <ins> not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. </ins> <del> Otherwise, remove the ".local" suffix to the value and resolve it using Multicast DNS. </del> <ins> Otherwise, resolve the candidate using mDNS. </ins> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of

Discussion:
Attacks by message flooding and name registration blocking are detailed.
This PR is doing some renaming. Maybe it should be done in a separate commit PR. Also, the mention of a mdns name per browsing context might conflict with another PR.
LGTM with change to make limit browser-wide.
LGTM