IPv6 EUI-64/SLAC address not gathered by ICE/WebRTC
Reported by
bakfi...@gmail.com,
Sep 6 2017
|
|||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Steps to reproduce the problem:
1. configure IPv6 EUI-64 address
e.g
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f0:de:f1:27:78:a2 brd ff:ff:ff:ff:ff:ff
inet 193.225.55.71/25 brd 193.225.55.127 scope global dynamic eth0
valid_lft 17751sec preferred_lft 17751sec
inet6 2001:738:0:41e:f2de:f1ff:fe27:78a2/64 scope global noprefixroute dynamic
valid_lft 2591801sec preferred_lft 604601sec
inet6 fe80::f2de:f1ff:fe27:78a2/64 scope link
valid_lft forever preferred_lft forever
2. Gather candidates https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Time Component Type Foundation Protocol Address Port Priority
0.009 1 host 94129689 udp 193.225.55.71 46872 126 | 32542 | 255
0.010 2 host 94129689 udp 193.225.55.71 43920 126 | 32542 | 254
0.103 1 host 1260368617 tcp 193.225.55.71 9 90 | 32542 | 255
0.107 2 host 1260368617 tcp 193.225.55.71 9 90 | 32542 | 254
0.154
0.154 Done
3. Try the same with Mozilla/FF, there the IPv6 EUI-64 address gathered correctly.
What is the expected behavior?
Gather IPv6 EUI64 address.
What went wrong?
EUI-64 IPv6 address not gathered..
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 60.0.3112.113 Channel: stable
OS Version: Ubuntu/Xenial
Flash Version:
,
Sep 7 2017
,
Oct 12 2017
Ping for triaging.
,
Oct 12 2017
It looks like this is intentional: https://webrtc-codereview.appspot.com/48509004 And, although there isn't a bug linked, the comment indicates that this is done to prevent client fingerprinting. Given the guidelines in https://w3c.github.io/fingerprinting-guidance, this would be considered a pretty high-severity fingerprinting surface, and "unless a feature cannot reasonably be designed in any other way, increased passive fingerprintability should be avoided." So I'd say this is intended behavior. We could consider adding an option to override it in the WebRTC Network Limiter extension, but that extension is mainly used for the opposite use case (reducing the fingerprinting surface, not increasing it).
,
Oct 12 2017
Agree. See https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17#section-3.3 for rationale. |
|||
►
Sign in to add a comment |
|||
Comment 1 by jmukthavaram@chromium.org
, Sep 7 2017