IPV6 and webRTC grumblings
If a device has a publicly routable IPv6 interface, safari won't offer that address for a peer to use in a WebRTC call. Unless one of 2 seemingly unrelated things are true
a) the page already has microphone permission or
b) the page specifies an IPv6 capable STUN server.
The whole point of IPv6 is that you don't need NAT to share scarce IPv4 addresses - and so STUN (which figures out what your public IP address is) would be irrelevant for IPv6
IPV6 and webRTC grumblings
This restriction is there because the surveillance based ad industry was using ip addresses as a way to fingerprint and track users. Apple takes the view that users need to have expressed some trust in a site before their public IPs are disclosed. The measure of trust they use is if the microphone (or camera) permission has been granted to a page.
This is a reasonable proxy indication for trust on video conference apps.
IPV6 and webRTC grumblings
Unfortunately I'm working on a streaming app which only receives live video from a camera, so asking for a mic permission would be weird.
This cropped up because the camera is 5g capable - and modern 5g networks can give devices routable IPv6 addresses - which should reduce connection times and latency - if I can use them.
The trick (kindly pointed out here https://github.com/w3c/webrtc-nv-use-cases/pull/14#issuecomment-1647968028 ) is to use a STUN server.
IPV6 and webRTC grumblings
The ironic downside of using a STUN server is that it adds a round trip time (or possibly 2 if DNS is needed) to the setup time and discloses your IP address to an additional server that didn't otherwise need to know it.
Sigh.
Now on to making my home network IPv6 friendly again - which I lost in the move from #openBSD to #freeBSD
</grump>
IPV6 and webRTC grumblings
@steely_glint
- "Set Phasers to Session Traversal Utilities for NAT, Scotty"!
- "But Cap'n, It's 2023, we're using IPv6"
BTW, when is your #STUN obtained address not your address? - When your upstream WISP is multi-homed and the route to the stun server is not the route to your rtp endpoint. So, run your own stun server beside your media server, also avoids your address revelation concern. Of course, 'should' not be an issue with IPv6, but....
IPV6 and webRTC grumblings
@keith In this case I have no media server - it's a P2P low latency stream (race car to pit crew). Also for older mobile nets I'll need an IPv4 TURN server too - which is much easier to buy from twilio - but they don't support V6 - sigh.
("You are in a twisty maze of passages all alike")
IPV6 routing grumblings
@steely_glint
I wonder how routable these IPv6 are or will be in reality. It should be ALL routable, in my experience it isn't. Most ISPs seem to have opted to not allow the customer to opt to do that. I have one domestic ADSL modem that seems to be doing some prefix delegation and then passes all incoming traffic. That works. But it's still a /64. Not that I fully understand where we are with all that, despite yes, having read up on it.
IPV6 routing grumblings
@keith Well I'm about to find out !
The IPv6 handed out by a stock BT VDSL router in UK routes just fine to the IPv6 handed to a DT 5g modem in Germany - nice low RTT too at 60ms.
I expect problems is when both ends are on the same provider's 5g network. We have found that having the peers on different networks helps.