WebRTC: Not Quite Magic • Hacker News Board

Re: WebRTC: Not Quite Magic

#51

Post by AshleysBrain » Mon, Mar 31, 2014, 2:28 PM UTC

yperr_string wrote: post #42

AshleysBrain wrote: post #31

Earlier quoted context omitted.

UDP hole punching does not work with all types of NAT, e.g. symmetric NAT where a user can appear from the outside to be coming from multiple different IP addresses. (This makes the STUN server useless for telling the other peer where to connect.) Symmetric NAT is common in corporate networks, which I suppose is not the first place you'd find gamers (or you could just run LAN games with co-workers). I guess WebRTC is…

"UDP hole punching does not work with all types of NAT..." I think what you mean to say is the STUN and TURN solutions do not work. What else have you tried? I personally do not use those solutions. The last resort is for a peer outside the problem NAT to forward traffic. This is not true peer-to-peer (IMO) but it does work. If what you suggest were true, that reliable peer-to-peer is "impossible" because of some typ…

Skype are a commercial company that has hundreds of millions of dollars in yearly revenue. Doubtless they have their own relay servers which they pay to run and connect everyone up. However it would be great if hackers and startups didn't have to deal with all of that.

Ideally it would not be necessary to try anything else and peers would just be able to directly connect. In practice TURN is a standardised way of doing relay, and what else are you going to do? Invent your own? How will you test it across the 1000s of different network configurations and know with any confidence that it actually works across the open Internet? Skype might have the resources to pull that off, but the next peer-to-peer startup might not.

Re: WebRTC: Not Quite Magic

#52

Post by AshleysBrain » Mon, Mar 31, 2014, 2:31 PM UTC

rlpb wrote: post #50

AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

> Once every device on the Internet is uniquely addressable again, we can do away with these NAT hacks and two endpoints should be able to reliably connect to each other again, no matter where they are. IMHO, this is a common misconception. IPv6 doesn't magically solve the problem. In an IPv6 world, we will all need stateful firewalls (imagine a typical human's home router). These will generally be configured to allo…

Aren't you talking more about firewalls than NAT? I don't see any problem with having uniquely addressed devices behind a single device implementing a firewall blocking incoming connections by default - that can still be done without modifying the addresses or ports (which NAT does). We could also do away with particularly nasty kinds like symmetric NAT which breaks STUN.

Re: WebRTC: Not Quite Magic

#53

Post by rlpb » Mon, Mar 31, 2014, 2:41 PM UTC

AshleysBrain wrote: post #52

rlpb wrote: post #50

Earlier quoted context omitted.

> Once every device on the Internet is uniquely addressable again, we can do away with these NAT hacks and two endpoints should be able to reliably connect to each other again, no matter where they are. IMHO, this is a common misconception. IPv6 doesn't magically solve the problem. In an IPv6 world, we will all need stateful firewalls (imagine a typical human's home router). These will generally be configured to allo…

Aren't you talking more about firewalls than NAT? I don't see any problem with having uniquely addressed devices behind a single device implementing a firewall blocking incoming connections by default - that can still be done without modifying the addresses or ports (which NAT does). We could also do away with particularly nasty kinds like symmetric NAT which breaks STUN.

> Aren't you talking more about firewalls than NAT?

Yes, I am, but this is exactly the distinction I'm saying is being conflated in discussions about the original problem. Problems are being attributed to NAT (and it is being assumed that IPv6 thus will solve it), when instead they should be attributed to the necessity of firewalls (and so IPv6 will not solve the underlying problem).

> I don't see any problem with having uniquely addressed devices behind a single device implementing a firewall blocking incoming connections by default

The problem is that peer-to-peer connections will fail by default, and we would like them to Just Work in cases when the user has initiated it and approves of it.

> We could also do away with particularly nasty kinds like symmetric NAT which breaks STUN.

Fair enough, but that will not make a peer-to-peer connection work when a firewall blocks the connection.

Re: WebRTC: Not Quite Magic

#54

Post by geocar » Mon, Mar 31, 2014, 9:45 PM UTC

comex wrote: post #26

geocar wrote: post #14

Earlier quoted context omitted.

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 gateway…

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.

Re: WebRTC: Not Quite Magic

#55

Post by geocar » Mon, Mar 31, 2014, 9:51 PM UTC

taf2 wrote: post #24

geocar wrote: post #19

Earlier quoted context omitted.

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…

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.

Re: WebRTC: Not Quite Magic

#56

Post by geocar » Mon, Mar 31, 2014, 9:55 PM UTC

AshleysBrain wrote: post #29

geocar wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: WebRTC: Not Quite Magic

#57

Post by jmspring » Tue, Apr 01, 2014, 4:20 AM UTC

ay wrote: post #48

jmspring wrote: post #47

Earlier quoted context omitted.

> When they do, most pain points caused by NATs will go away, and that's not webrtc specific. This is a naive statement since it assumes IPv6 support amongst the clients. At least here in the US, such support is fairly minuscule.

In the US, today, one in 15 clients accessing google.com / yahoo.com / facebook.com is doing it from an IPv6 address. And it's more than double compared to a year ago [1]. While indeed this still qualifies as "relatively small", I think it grew out of the "miniscule" :-) [1] http://6lab.cisco.com/stats/cible.php?country=US

I think mobile operators are going to drive the near term biggest uptick in ipv6 adoption.

My local ISP (small, independent) has no current IPV6 plans, which is actually a little bit annoying.

Re: WebRTC: Not Quite Magic

#58

Post by rictic » Sun, Apr 06, 2014, 3:18 PM UTC

pdkl95 wrote: post #27

rictic wrote: post #22

Earlier quoted context omitted.

I don't think that's so. A NAT also prevents random hosts from directly opening connections to the machines that it's obfuscating (module port forwarding), which serves a nice security purpose.

You're confusing NAT with the firewall. Without a firewall, a pure-NAT will often let you route to the internal network addresses from the outside. There isn't really much "obfuscation" of the LAN addresses either, as they are almost certainly a 1/256-guess away on the 192.168.1.x network. This confusion is very common, probably because it's incredibly rare to find NAT by itself. Every home router is basically guaran…

I suspect I am confused. If you're feeling generous (and notice this comment 6 days later, heh), would you mind correcting my mental model and slicing up the difference between NAT and firewall?

Suppose that there is one external ip, we'll say 1.1.1.1 which is NATting two internal ips, 10.0.0.1 and 10.0.0.2. When a packet comes in, say a TCP packet attempting to open a connection on port 80, what are the options that a non-firewalling NAT has to figure out which internal ip to route it to? Assume that both ips are running webservers.

I know of two answers to this question, one is port forwarding, where the NAT is explicitly configured to forward incoming port 80 traffic to one of the internal hosts (meaning that only one of them can listen for traffic on a given port). The other doesn't work for new incoming connections but just has the NAT watching for outgoing traffic and allowing incoming traffic to come back (using (foreign ip, receiving port, sending port) up to route packets to the internal IP that started that conversation). My understanding is that NAT traversal techniques typically try to first ask the NAT to forward a port for them (uPnP / NAT-PMP), and if that fails then they try to exploit the second method using ICE.

What am I missing?