Hacker News Reader

Comment by geocar | Hacker News Reader

NAT has been around for twenty years now, so there's no excuse for having anything less than robust, any-direction-any-path in every new protocol. I'm honestly more than a bit disappointed that WebRTC has pushed this down into the application leaving every application to work it out for itself.

The smart thing to do would have been to make the signalling layer use IPv6 and insist on configured 6in4-configured gateways (or similar).

View on HN

Maybe NAT has been around a long time but there is still a lot of broken NAT, e.g. symmetric NAT on corporate networks (where one user might appear to come from two different IPs from the outside). This is not WebRTC's fault, it makes any peer-to-peer connections over the Internet hard, and given IPv6 adoption stands at around 3% right now insisting on IPv6 support would probably have been sufficient to prevent widespread adoption.

I'm not convinced.

WebRTC is supported by huge corporations with massive resources. If they had decided to use IPv6 instead of SDP for addressing, I can't imagine there would be any difficulty in user adoption, and they could only improve service adoption.

Don't most users of the internet not have IPv6 addresses. I know my FIOS and business Comcast lack IPv6 support... I can only imagine that means everyone in a very large radius around my hometown are in the same boat of zero IPv6... That said, I agree it would be nice if the browser vendors handled networks that block all traffic that is not over TCP port 80 and TCP port 443, but I'm certain that it's because WebRTC is non-trivial and we have it's usefulness goes beyond peer to peer...

WebRTC isn't just non-trivial: It's hard, and the hardest part is the fact that every service provider has to implement a complex network configuration that is difficult to test and exercise.

Even tunnelling IPv6 would be preferable, but my point was about making browser vendors do "the hard work" instead of making service providers.

SDP is a session description protocol, not an addressing protocol. WebRTC will be able to use IPv6 addressing in future, too, and supporting IPv4 where possible means it's practical to use now as well.

> SDP is a session description protocol, not an addressing protocol

SDP is most certainly an addressing protocol. It's a very complicated one that uses many binary tokens including IPv4 addresses (or IPv6 adddresses) and port numbers, cookies, and keys.

That some of the binary tokens used in the SDP addresses are discovered using ICE/STUN (sometimes) complicates service providers greatly.

TURN/ICE is supposed to work just fine on symmetric NATs. Chrome even supports single-socket TCP relays, which can't be broken easily by any sane firewall. I personally have a few boxes testing it with only TCP 80 port allowed and it still finds a way to connect. A few tricks on the TURN side have to be employed but it's pretty robust. Whatever issue the OP has to be a bug or configuration issue. There are known problems and I still see a lot of freezes, protocol or hardware compatibility issues, CPU overload and so on, but straight Chrome to Chrome connections seem robust.

Not all people have Chrome or latest version of Chrome and I think a fairly recent version is required to relay over TCP.

How is this supposed to work? Unless you want to route all non-native-IPv6 traffic (i.e. almost all traffic) through the gateway, which would defeat the goal of peer-to-peer, you need a way to do NAT traversal over UDP, and at that point assigning IPv6 addresses would be somewhat redundant.

Users can arrange NAT traversal or tunnelling as appropriate, and have a better success rate than services which have to anticipate all of the different NAT configurations (and test them), without pissing off users. It's clear that the browser can help a lot here.

WebRTC is deployed on somewhere around 40% of browsers and is potentially supported on some 80-90% of those browsers, and works on maybe half of the services. Your mileage may vary, but there's not going to be a Skype competitor built on WebRTC unless Google makes it and tunnels to Google's servers (which they do).

Requiring servers implement IPv6 correctly is a lot easier than making every server do the STUN/TURN/conntracking dance. It's probably easier than making one server work with WebRTC everywhere, since the only WebRTC app that seems to work for me is Google.

Reply on news.ycombinator.com