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?
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?
> 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.
> 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?
That would be ideal. But you could also have a GUI program that manages mapping tunnels to ports for apps that don't have built-in support.
> No, I mean "running an application or library that knows how to open a port/tunnel".
Ah that makes more sense. Yeah you're correct that is something that has to be added, but it's as easy as installing any other app, which is much easier than buying a new router, switching to an ISP that supports IPv6, etc.
> The point about DynDNS stands, but you still need some DNS even in the tunneling case
If the tunneling is offered by the same service that sells domains, this can be much more streamlined to the point where it's unnecessary for the user to understand DNS. That's what I'm working towards with TakingNames.io[0].
> Same as you'd solve it in the tunneling case, you'd use a service that can absorb the DDoS.
If you're routing through a 3rd-party anyway, why not tunnel and gain all the additional benefits?
> I think we've mixed up too many things in the discussion
I agree. I didn't want to leave any of your questions hanging, but if you want to continue the discussion feel free to drop anything you find uninteresting.
> 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)
This is not a bad point. I do wish DNS had a way to specify ports in records. However, this is essentially solved by SNI routing. It does have the limitation of forcing you to use TLS for everything, but I don't think that's too big of a problem for now.
To be clear, I wish we had IPv6/UPnP everywhere and things worked the way you're describing, but I don't see it happening for many years to come. I'm betting on tunneling for the next decade or so.
> That would be ideal. But you could also have a GUI program that manages mapping tunnels to ports for apps that don't have built-in support.
Right, this sounds basically like what the firewall does in the p2p case.
> which is much easier than buying a new router, switching to an ISP that supports IPv6, etc.
Yes, if you can't just open a port, a tunnel is easier, true.
> If you're routing through a 3rd-party anyway, why not tunnel and gain all the additional benefits?
Well, you wouldn't be routing through a third party. DDoSes are costly and you usually don't need to protect against them if you're a home user.
> I do wish DNS had a way to specify ports in records.
That's what SRV records are for, no?
> but I don't see it happening for many years to come
Hmm, I don't think we need it everywhere, just where people care to use it, but maybe. I'm not as pessimistic, as my home ISP gives me a (fairly static? I've never actually checked) IPv4 where I opened a bunch of ports, but it would certainly be better if each of my home devices could be addressable from the internet.
TakingNames is an interesting idea, though I'd have to think a bit more about it to tell if I'd find it useful :P The current method of just opening a port on my router has worked extremely well for me so far!
