Original text:
(e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. <del> #2 is a less significant but valid concern.  While the RFC4941 IPv6 addresses recommended by I-D.ietf-rtcweb-transports are fairly benign due to their intentionally short lifetimes, IPv4 addresses present some challenges.  Although they typically contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits of entropy with an indefinite lifetime.  As such, they can be a fairly significant fingerprinting surface.  In addition, intranet web sites can be attacked more easily when their IPv4 address range is externally known. Private local IP addresses can also act as an identifier that allows web applications running in isolated browsing contexts (e.g., normal and private browsing) to learn that they are running on the same device.  This could allow the application sessions to be correlated, defeating some of the privacy protections provided by isolation.  It should be noted that local addresses are just one potential mechanism for this correlation and this is an area for further study. </del>  #3 is the least common concern, as proxy administrators can already control this behavior through organizational firewall policy, and

Reviewer comments:
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
When I say "local" here, I am referring to the fact that the IP address is local to the machine, rather than an address for a remote party. To avoid confusion, I probably could just omit the word altogether here. Regarding NATing, your observation is often correct, but NAT64 is becoming increasingly common. I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses.
The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address.

Revised text:
(e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN.  <ins> #2 is a less significant but nonetheless valid concern.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf-rtcweb- transports is fairly benign due to their intentionally short lifetimes, IPv4 addresses present some challenges.  Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits of entropy with an indefinite lifetime.  As such, they can be a fairly significant fingerprinting surface.  In addition, intranet web sites can be attacked more easily when their IPv4 address range is externally known. Private IP addresses can also act as an identifier that allows web applications running in isolated browsing contexts (e.g., normal and private browsing) to learn that they are running on the same device. This could allow the application sessions to be correlated, defeating some of the privacy protections provided by isolation.  It should be noted that private addresses are just one potential mechanism for this correlation and this is an area for further study. </ins> #3 is the least common concern, as proxy administrators can already control this behavior through organizational firewall policy, and