4 ms·
You know what’s easier than all this happy crappy? Goddamn IPv6. How many engineer-hours have been spent trying to work around NAT and IPv4 which could have bee
by IgorPartola 2y ago
You know what’s easier than all this happy crappy? Goddamn IPv6. How many engineer-hours have been spent trying to work around NAT and IPv4 which could have been spent implementing IPv6? Every browser tab could have its own publicly routable address if we wanted to. And the more work arounds we create the less pressure there is to get over the hump and treat IPv4 as the weird legacy protocol instead of treating IPv6 as the weird new protocol.
I guess engineer activism is all there is really left to do. Enable dual stack, write your code to be IPv6-first (it can automatically do IPv4 connectivity if enabled so really you only need to support one stack and the OS will translate for you; this doesn’t mean you can avoid having IPv4 addresses if you want to have your service IPv4 accessible, just that your code can pretend like every address is an IPv6 address). Test your code without IPv4 connectivity. If you reference localhost, don’t use 127.0.0.1 preferring localhost instead. Don’t be the reason the next engineer has to say “well this codebase isn’t IPv6 compliant so we can’t enable it”.
- dboreham 2y agoIt would still block inbound connections.
- IgorPartola 2y agoYour firewall doesn’t currently block WebRTC does it? It is perfectly able to be bypassed.
- EGreg 2y agoGet around hole punching NATs with this one weird trick “they” they don’t want you to know about?
- IgorPartola 2y agoNAT should have never been a thing. That should have been the moment of “oh yeah we need a different IP protocol.”
- kelnos 2y agoMy network's firewall doesn't let random incoming IPv6 connections come in, and I wouldn't change that even if I didn't need NAT for IPv4. Is there a safe protocol to allow applications inside a network to automatically ask edge firewalls for temporary port forwards (or port unblockings, which would be all that would be needed with routable IPv6)? I still can't see how that could be made safe, though: how would the firewall know that the request was coming from a user on the network, and not malware (or a user being duped by malware)?
- LegionMammal978 2y agoAs I understand it, that is basically the purpose of UPnP IGD [0], as well as the newer PCP [1]. But hardly anyone implements these protocols due to the usual concerns around incoming connections. [0] https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc... [1] https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol
- IgorPartola 2y agoRealistically STUN and TURN are still just ways to get around your firewall rules, are they not? Your firewall is already being bypassed. IPv6 wouldn’t change that fact. Instead we could implement a better version of UPnP or just open a set of ports specifically used for P2P connections and allow the browsers to open those ports when they expect an incoming connection. Firewalls serve a purpose but make no mistake they don’t prevent you from bypassing them. Clearly P2P connections are still made all the time. Your specific question of “how do I know it’s not malware?” doesn’t make much sense. First most default firewalls allow outbound connections which is what malware would do. If you have malicious code running on your machine, the game is already lost. The job of the firewall is two-fold. First it protects against unwanted flood of traffic to devices whose local resources are too limited to do the filtering themselves. The second is to keep ports closed to hosts outside of your LAN that they shouldn’t have access to. Say you misconfigured your NAS network file system and allow connections from anywhere. Oops. Your firewall protects against that. But unless you effectively disconnect your laptop from the internet, the firewall won’t stop it from connecting to a remote host. At that point if you open a TCP port that is how you signal that you are requesting an incoming connection. Which is exactly what the current WebRTC system does except it also has to jump through a lot of hoops to establish the connection (steps that any malware would be able to take as well.)