4 ms·

You really think it would still work today though? I want to believe you.

hackmiester 5y ago
This is how IPv6 works today.
stavros 5y ago
Yeah, why not? As long as you use a firewall that blocks all incoming ports by default and only opens the ones you want, it would be fine.
- anderspitman 5y ago
  A p2p internet with no open ports is pretty pointless. And the average p2p application user isn't likely to understand the ramifications of opening ports, even if good tools are provided to do so (which I'm skeptical). So I don't really see how this improves much on the CGNAT world we're headed into. I think tunneling is a safer and easier approach for most people. They never have to expose their IP or ports, and the application on the private end of the tunnel can run in a sandbox to protect the rest of the user's stuff.
  - stavros 5y ago
    How will the application in the tunnel open a port? And why would the p2p application not sandbox? Seems like a double standard.
    - anderspitman 5y ago
      With tunneling you never open incoming ports. Everything gets tunneled through an outgoing connection from the client to the tunnel server. Maybe we're talking about different things? Oh p2p apps can and definitely should be sandboxing. That's not a unique feature of tunneling. The exposed IP and trickiness of educating users on opening ports are much bigger issues. That said, if you're willing to accept the risk of exposing your IP, all we really need is wider UPnP support. But just like IPv6 it's been around forever but hasn't taken off. It's really a chicken-egg problem. We're not going to get IPv6, UPnP, fast upload internet speeds, simple sandboxing on all major OSes, etc, until we can prove that people want p2p apps and there's money to be made by supporting them. But p2p apps are difficult to build without those things, unless you use tunneling... Note that you can get maybe 90% of the way there by using NAT traversal[0]. But you still need relays (tunneling) for the last 10%. Given the other benefits, I think going straight to tunneling makes sense. [0]: https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/
      - stavros 5y ago
        Yeah I'm a bit confused as to what you mean by tunneling. If you mean something like CloudFlare tunnels or ssh -R, how is that different from having the application open a firewall port automatically?
        anderspitman 5y ago
        Many reasons here are a few, some of which I mentioned at least once above: * Cloudflare can handle a DDoS. Your home router can't. * The application can't automatically open a port without something like UPnP, which isn't widely deployed enough to rely on. * Your IP stays private. * You don't need to use things like DynDNS to keep your DNS records in sync with the IP your ISP gives you.
        stavros 5y ago
        Right, but this amounts to "the downside of your approach is that none of this is built-in, whereas with my approach also none of this is built-in".
        anderspitman 5y ago
        I'm confused. I think we really must have different mental models of this conversation. What do you mean by "built-in" exactly? You mean adopted standards that are widely deployed? Assuming that, with tunneling it doesn't matter if it's built-in, because you're side-stepping the devices between you and the public internet. Any device that can open a TCP connection to a remote IP address can create a tunnel, and then it's only constrained by the limitations of the tunnel provider, not by the home router, the ISP, or any software therein. Maybe this would be more productive and I can learn something if we reduce the scope. How would you solve the DDoS problem in a network full of true p2p IPv6 devices?
        stavros 5y ago
        > I think we really must have different mental models of this conversation. It sounds like it, from what I understand, you're saying that each application would connect to a service like CloudFlare to open a tunnel to itself, right? > What do you mean by "built-in" exactly? You mean adopted standards that are widely deployed? No, I mean "running an application or library that knows how to open a port/tunnel". Remember that in the p2p case each computer has an externally accessible IP address, so all ports are just blocked by the firewall and the user can open them (or the application can request to have them open). > Any device that can open a TCP connection to a remote IP address can create a tunnel, and then it's only constrained by the limitations of the tunnel provider, not by the home router, the ISP, or any software therein. That's true, but in the p2p case, all ports are already open. You're using a firewall to block them, for security. If you want to allow programs to become connectable, you wouldn't block their ports. If you didn't, you would block them even in the tunneling case. The point about DynDNS stands, but you still need some DNS even in the tunneling case (unless you assume that the tunnel endpoint has a static IP but your IP is dynamic, which there's no reason to assume, as it might well be the other way around). > How would you solve the DDoS problem in a network full of true p2p IPv6 devices? Same as you'd solve it in the tunneling case, you'd use a service that can absorb the DDoS. There's nothing that makes a tunnel inherently DDoS-resistant, it's just that one of the providers you can use for tunneling (CloudFlare) can provide you with anti-DDoS services. I think we've mixed up too many things in the discussion. The main benefit I see in p2p vs tunneling is that tunneling hides your IP, but p2p lets you choose the port numbers (you can't choose whatever port you want for your tunnel, because all users have to share an IP). All the other features seem equal to me in both cases.

This is how IPv6 works today.

Yeah, why not? As long as you use a firewall that blocks all incoming ports by default and only opens the ones you want, it would be fine.

anderspitman 5y ago
A p2p internet with no open ports is pretty pointless. And the average p2p application user isn't likely to understand the ramifications of opening ports, even if good tools are provided to do so (which I'm skeptical). So I don't really see how this improves much on the CGNAT world we're headed into. I think tunneling is a safer and easier approach for most people. They never have to expose their IP or ports, and the application on the private end of the tunnel can run in a sandbox to protect the rest of the user's stuff.
- stavros 5y ago
  How will the application in the tunnel open a port? And why would the p2p application not sandbox? Seems like a double standard.
  - anderspitman 5y ago
    With tunneling you never open incoming ports. Everything gets tunneled through an outgoing connection from the client to the tunnel server. Maybe we're talking about different things? Oh p2p apps can and definitely should be sandboxing. That's not a unique feature of tunneling. The exposed IP and trickiness of educating users on opening ports are much bigger issues. That said, if you're willing to accept the risk of exposing your IP, all we really need is wider UPnP support. But just like IPv6 it's been around forever but hasn't taken off. It's really a chicken-egg problem. We're not going to get IPv6, UPnP, fast upload internet speeds, simple sandboxing on all major OSes, etc, until we can prove that people want p2p apps and there's money to be made by supporting them. But p2p apps are difficult to build without those things, unless you use tunneling... Note that you can get maybe 90% of the way there by using NAT traversal[0]. But you still need relays (tunneling) for the last 10%. Given the other benefits, I think going straight to tunneling makes sense. [0]: https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/
    - stavros 5y ago
      Yeah I'm a bit confused as to what you mean by tunneling. If you mean something like CloudFlare tunnels or ssh -R, how is that different from having the application open a firewall port automatically?
      - anderspitman 5y ago
        Many reasons here are a few, some of which I mentioned at least once above: * Cloudflare can handle a DDoS. Your home router can't. * The application can't automatically open a port without something like UPnP, which isn't widely deployed enough to rely on. * Your IP stays private. * You don't need to use things like DynDNS to keep your DNS records in sync with the IP your ISP gives you.
        stavros 5y ago
        Right, but this amounts to "the downside of your approach is that none of this is built-in, whereas with my approach also none of this is built-in".
        anderspitman 5y ago
        I'm confused. I think we really must have different mental models of this conversation. What do you mean by "built-in" exactly? You mean adopted standards that are widely deployed? Assuming that, with tunneling it doesn't matter if it's built-in, because you're side-stepping the devices between you and the public internet. Any device that can open a TCP connection to a remote IP address can create a tunnel, and then it's only constrained by the limitations of the tunnel provider, not by the home router, the ISP, or any software therein. Maybe this would be more productive and I can learn something if we reduce the scope. How would you solve the DDoS problem in a network full of true p2p IPv6 devices?
        stavros 5y ago
        > I think we really must have different mental models of this conversation. It sounds like it, from what I understand, you're saying that each application would connect to a service like CloudFlare to open a tunnel to itself, right? > What do you mean by "built-in" exactly? You mean adopted standards that are widely deployed? No, I mean "running an application or library that knows how to open a port/tunnel". Remember that in the p2p case each computer has an externally accessible IP address, so all ports are just blocked by the firewall and the user can open them (or the application can request to have them open). > Any device that can open a TCP connection to a remote IP address can create a tunnel, and then it's only constrained by the limitations of the tunnel provider, not by the home router, the ISP, or any software therein. That's true, but in the p2p case, all ports are already open. You're using a firewall to block them, for security. If you want to allow programs to become connectable, you wouldn't block their ports. If you didn't, you would block them even in the tunneling case. The point about DynDNS stands, but you still need some DNS even in the tunneling case (unless you assume that the tunnel endpoint has a static IP but your IP is dynamic, which there's no reason to assume, as it might well be the other way around). > How would you solve the DDoS problem in a network full of true p2p IPv6 devices? Same as you'd solve it in the tunneling case, you'd use a service that can absorb the DDoS. There's nothing that makes a tunnel inherently DDoS-resistant, it's just that one of the providers you can use for tunneling (CloudFlare) can provide you with anti-DDoS services. I think we've mixed up too many things in the discussion. The main benefit I see in p2p vs tunneling is that tunneling hides your IP, but p2p lets you choose the port numbers (you can't choose whatever port you want for your tunnel, because all users have to share an IP). All the other features seem equal to me in both cases.