7 ms·

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 Intern

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 NAT, and either ignored peer-to-peer connections or went ahead and broke them anyway. This makes innovation with peer-to-peer tech more difficult and expensive, because now to get things working for everyone you need to configure additional relay servers and pay for the bandwidth of everyone who needs to use it. That could rule out some services being made free and could mean the extra cost being passed on to customers when it could have just run through their ISPs. I think the solution is IPv6. 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. Of course, that's assuming we don't get more short-sighted engineering that breaks things again...

alexfreska 13y ago
Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?
- AshleysBrain 13y ago
  NAT only exists to workaround IPv4 address exhaustion. I think it's more likely the 5% edge cases have firewalls that block anything that doesn't look like normal HTTP traffic.
  - rictic 13y ago
    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.
    - pdkl95 13y ago
      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 guaranteed to have a basic stateful firewall in addition to providing NAT.
      - rictic 13y ago
        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?
      - zanny 13y ago
        And every modern IP stack also provides a firewall, be it iptables or whatever the Windows Firewall is. I don't think the "NAT is necessary because putting our computers on the public internet is scary" is anything close to a reason to keep the hodge podge mess we have.
  - derefr 13y ago
    > NAT only exists to workaround IPv4 address exhaustion. Untrue; people were using NATs long before they were concerned with running out of IPv4 addresses. I think it was a bit of paranoia combined with lack of trust in firewalls: corporate sysadmins just didn't want their internal networks to have routable addresses. This seems to have been mostly calmed by the explosion of "cloud" IaaS offerings, which need publically-routable addresses to do much of anything.
geocar 13y ago
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).
- AshleysBrain 13y ago
  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.
  - geocar 13y ago
    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.
    - taf2 13y ago
      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...
      - geocar 13y ago
        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.
simon_vetter 13y ago
Work is in progress to make webrtc implementations work over ipv6 but it's not ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true) [1], and hopefully Firefox will follow suit. When they do, most pain points caused by NATs will go away, and that's not webrtc specific. While you'll always encounter some (intentionally?) broken network which only allows 80/tcp and 443/tcp from time to time, there's not much you can do about it, and webrtc can't do much about it. [1] http://code.google.com/p/webrtc/issues/detail?id=1406 http://code.google.com/p/webrtc/issues/detail?id=1406
- AshleysBrain 13y ago
  Thanks for the heads up, this does look like it will help a lot! (Assuming IPv6 reaches most people eventually)
- jmspring 13y ago
  > 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.
  - ay 13y ago
    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 http://6lab.cisco.com/stats/cible.php?country=US
    - jmspring 13y ago
      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.
yperr_string 13y ago
You make the problem sound like it's lack of IPv4 address space. That is true in some respects because the method of allocation of these addresses is not straightforward and has its own set of problems. But in actuality "the problem" the OP is encountering is that for the RTC developer/user, a publicly reachable IPv4 address block is too expensive. With a publicly reachable IP address (most ISP's will provide one, often for an additional fee), you can do peer-to-peer quite easily. UDP hole punching works fine, save for when both peers are behind the same NAT, in which case you need a peer outside the NAT to forward traffic. And it's easy to simulate a LAN over the internet using encapsulation. Gamers have been successfully hole punching for many years. I'd say up until recently, gamers have really been the only group that has demanded peer-to-peer connectivity and made it work. One wonders if every ISP customer were willing to pay the extra fees (if any) and requested a publicly reachable IP address, could the ISP's meet the demand?
- AshleysBrain 13y ago
  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 the first place you'd run in to networking problems with NAT outside of gaming, torrents and bitcoin - and is perhaps the first developer-accessible peer-to-peer tech which is obviously useful in the workplace.
  - yperr_string 13y ago
    "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 types of NAT, then how do you explain the success of Skype? If you give specifics about what exactly you were trying to do, and what exactly you did to try to accomplish this, maybe someone could offer suggestions. I already knew that STUN and TURN have problems. That's why I do not even bother with those "solutions".
rlpb 13y ago
> 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 allow all outgoing connections, and block all incoming connections - just like a NAT router effectively does today. Now, you have the same problem all over again. How does the firewall know what new inbound connections to accept, and which to reject? We're back into the realms of packet inspection ("ALG") or protocols to explain to the NAT router what is required, such as NAT-PMP, uPnP etc. Sure - each endpoint will have a unique address, and this is useful. But a direct peer-to-peer connection between these endpoints will be firewalled by default, except via the same (equally bad) solutions that currently solve the problem (badly) in a NAT world.
- AshleysBrain 13y ago
  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.
  - rlpb 13y ago
    > 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.

alexfreska 13y ago

Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?

AshleysBrain 13y ago
NAT only exists to workaround IPv4 address exhaustion. I think it's more likely the 5% edge cases have firewalls that block anything that doesn't look like normal HTTP traffic.
- rictic 13y ago
  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.
  - pdkl95 13y ago
    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 guaranteed to have a basic stateful firewall in addition to providing NAT.
    - rictic 13y ago
      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?
    - zanny 13y ago
      And every modern IP stack also provides a firewall, be it iptables or whatever the Windows Firewall is. I don't think the "NAT is necessary because putting our computers on the public internet is scary" is anything close to a reason to keep the hodge podge mess we have.
- derefr 13y ago
  > NAT only exists to workaround IPv4 address exhaustion. Untrue; people were using NATs long before they were concerned with running out of IPv4 addresses. I think it was a bit of paranoia combined with lack of trust in firewalls: corporate sysadmins just didn't want their internal networks to have routable addresses. This seems to have been mostly calmed by the explosion of "cloud" IaaS offerings, which need publically-routable addresses to do much of anything.

geocar 13y ago

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).

AshleysBrain 13y ago
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.
- geocar 13y ago
  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.
  - taf2 13y ago
    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...
    - geocar 13y ago
      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.

simon_vetter 13y ago

Work is in progress to make webrtc implementations work over ipv6 but it's not ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true) [1], and hopefully Firefox will follow suit. When they do, most pain points caused by NATs will go away, and that's not webrtc specific. While you'll always encounter some (intentionally?) broken network which only allows 80/tcp and 443/tcp from time to time, there's not much you can do about it, and webrtc can't do much about it. [1] http://code.google.com/p/webrtc/issues/detail?id=1406 http://code.google.com/p/webrtc/issues/detail?id=1406

AshleysBrain 13y ago
Thanks for the heads up, this does look like it will help a lot! (Assuming IPv6 reaches most people eventually)
jmspring 13y ago
> 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.
- ay 13y ago
  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 http://6lab.cisco.com/stats/cible.php?country=US
  - jmspring 13y ago
    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.

yperr_string 13y ago

You make the problem sound like it's lack of IPv4 address space. That is true in some respects because the method of allocation of these addresses is not straightforward and has its own set of problems. But in actuality "the problem" the OP is encountering is that for the RTC developer/user, a publicly reachable IPv4 address block is too expensive. With a publicly reachable IP address (most ISP's will provide one, often for an additional fee), you can do peer-to-peer quite easily. UDP hole punching works fine, save for when both peers are behind the same NAT, in which case you need a peer outside the NAT to forward traffic. And it's easy to simulate a LAN over the internet using encapsulation. Gamers have been successfully hole punching for many years. I'd say up until recently, gamers have really been the only group that has demanded peer-to-peer connectivity and made it work. One wonders if every ISP customer were willing to pay the extra fees (if any) and requested a publicly reachable IP address, could the ISP's meet the demand?

AshleysBrain 13y ago
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 the first place you'd run in to networking problems with NAT outside of gaming, torrents and bitcoin - and is perhaps the first developer-accessible peer-to-peer tech which is obviously useful in the workplace.
- yperr_string 13y ago
  "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 types of NAT, then how do you explain the success of Skype? If you give specifics about what exactly you were trying to do, and what exactly you did to try to accomplish this, maybe someone could offer suggestions. I already knew that STUN and TURN have problems. That's why I do not even bother with those "solutions".

rlpb 13y ago

> 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 allow all outgoing connections, and block all incoming connections - just like a NAT router effectively does today. Now, you have the same problem all over again. How does the firewall know what new inbound connections to accept, and which to reject? We're back into the realms of packet inspection ("ALG") or protocols to explain to the NAT router what is required, such as NAT-PMP, uPnP etc. Sure - each endpoint will have a unique address, and this is useful. But a direct peer-to-peer connection between these endpoints will be firewalled by default, except via the same (equally bad) solutions that currently solve the problem (badly) in a NAT world.

AshleysBrain 13y ago
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.
- rlpb 13y ago
  > 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.