Change:
Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}
Yeah, I think we should do the latter. That's what 6762 does.

Discussion:
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 <del> dynamically generated Multicast DNS RFC6762 names. </del> <ins> dynamically generated Multicast DNS (mDNS) RFC6762 names. </ins> 1.

not be supported. This document proposes an overall solution to this problem by <del> registering ephemeral Multicast DNS 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. </del> <ins> 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.

Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". <del> Register the candidate's mDNS hostname using Multicast DNS. </del> <ins> Register the candidate's mDNS hostname as defined in RFC6762. </ins> If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed.

not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. <del> Otherwise, use 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

latency is close to zero, the probability is high that the two peers are running on the same device. <del> To avoid this issue, browsers SHOULD NOT register Multicast DNS names for WebRTC applications running in a third-party browser execution </del> <ins> To avoid this issue, browsers SHOULD NOT register mDNS names for WebRTC applications running in a third-party browser execution </ins> context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. 4. <del> The proposal relies on identifying and resolving any Multicast DNS based ICE candidates as part of adding/processing a remote candidate. ICESDP section 4.1 could be updated to explicitly allow Multicast DNS names in the connection-address field. </del> <ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. </ins> <del> The proposal relies on adding the ability to register Multicast DNS names at ICE gathering time.  This could be described in ICESDP and/ or WebRTCSpec. </del> <ins> The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. </ins> The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the <del> default mode could be defined as mode 3 with Multicast DNS based ICE </del> <ins> default mode could be defined as mode 3 with mDNS-based ICE </ins> candidates.