3 ms·
None of the solutions you suggest exist today, to my knowledge. Am I wrong? For example, a single IP address per application would be fine, but there is no pro
by rlpb 11y ago
None of the solutions you suggest exist today, to my knowledge. Am I wrong?
For example, a single IP address per application would be fine, but there is no protocol that allows me to allocate addresses per application on a central home router such that I can then identify them to permit them individually.
And applications punching holes via APIs does exist in uPnP and NAT-PMP, but isn't that the same thing as what you dismissed above as a hack?
- zeroxfe 11y agoYou are not wrong. There is no consistent way to do this today -- most of it is in debate, and there is no standard. The most reliable way is to rely on your system firewall to prompt you to open up a port when an application binds to it (which can be accomplished with the default firewall software on a modern system.) Again, this is technically possible with IPv4 too, it's just impractical due to address space limitations. > there is no protocol that allows me to allocate addresses per application on a central home router Correct. But the whole point it to take the router out of the loop for this, and only use it as a coarse firewall. With IPv6 very device gets a separate /64, so it can simply allocate from its own pool of 10^19 addresses. > And applications punching holes via APIs does exist in uPnP and NAT-PMP, but isn't that the same thing as what you dismissed above as a hack? Not the same. With IPv6, you do not need to coordinate across multiple NAT devices (or even worse if you're double/triple NATted as in some countries.) You're also not limited by the maximum NAT table sizes (again amplified in the double/triple NATted situations.) Since each system has 10^19 addresses (preallocated out of a global pool of 10^38 addresses), these can now be treated as system resources and managed intelligently by the kernel.
- rlpb 11y ago> The most reliable way is to rely on your system firewall to prompt you to open up a port when an application binds to it...But the whole point it to take the router out of the loop for this, and only use it as a coarse firewall. I don't trust, and doubt I'll ever trust, the firewall on my Smart TV, even if it had one. That's because I don't trust that it'll ever receive timely security updates. So I must use [the firewall on] a central router.
- solidangle 11y agoThen trust your router's firewall. And if you don't trust your router's firewall build your own router (or install OpenWRT on store-bought router).
- hueving 11y agoWhich puts us back at square one with upnp to open up holes on the router.
- lmm 11y ago> And applications punching holes via APIs does exist in uPnP and NAT-PMP, but isn't that the same thing as what you dismissed above as a hack? I think applications communicating with firewalling is not a hack, but applications communicating with routing is a hack. E.g. I have two friends who share a house (and therefore an internet connection) and I can play a game with one or other of them (via uPnP) but not both at the same time. With IPv6 + uPnP (assuming that's supported), they'd still have the same firewalling they have now, but I'd be able to play a game with both of them. No?
- rlpb 11y agoSorry, I've only just seen this. I agree with you on this point, yes. But I think you have a pretty rare and specific case. The more general cry of "IPv6 fixes NAT!" incorrectly expects much more than this, I think.