4 ms·

> If, even with the hurdles of poor performing NATs, there is market pressure for P2P protocols, it's absurdly obvious the Internet must be symmetrical, not ser

by rlpb 11y ago

> If, even with the hurdles of poor performing NATs, there is market pressure for P2P protocols, it's absurdly obvious the Internet must be symmetrical, not server-client. I think there's a fallacy here. IPv6 does not solve this problem. Even if all devices were IPv6, typical homes will still have a router that blocks incoming connections by default, even if it is now a deliberate stateful firewalling decision rather than a consequence of NAT. Firewalling P2P traffic effectively remains just as hard with IPv6 as with NAT. The only way to fix this currently is to either stop using firewalls (very dangerous in this era of never-security-updated IoT devices) or to use IPv6 equivalents of the same solutions the IPv4 NAT world has developed (NAT-PMP, uPnP, etc). The latter case won't improve anything in P2P connectivity using IPv6 over anything we have already with IPv4 NAT.

zeroxfe 11y ago
This is not correct, there are many ways to do this without resorting to NAT hacks like uPnP. For example, ISPs hand out entire /64 per customer (at a minimum, almost all will give you larger subnets if you ask). This allows you to have a separate IP address per application, which can be allocated from an unfirewalled pool. There's also the fact that almost all major OSs now come with sane firewall defaults, also allowing applications to punch holes via APIs. (You could also have done this with IPv4 if it had a larger address space.) If you spend some time thinking about how to solve these problems with IPv6, you will find that there are lots of ways to do it that are simpler and far more secure.
- 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 ago
    You 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 ago
        Then 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 ago
zAy0LfpBZLC8mAC 11y ago
> Firewalling P2P traffic effectively remains just as hard with IPv6 as with NAT. Nope, it's much easier because the addresses are easy to predict. When both parties are behind NAT, neither side knows which address and port they will appear to be coming from to the other side, while without NAT, both parties know exactly what address the other side will see (it's the one the local socket is bound to ...), that makes it relatively easy to establish a connection through a stateful firewall with a simultaneous connect if both sides can somehow tell each other where their respective sockets are. It's outright trivial with UDP, not quite that easy with TCP: Assume both sides are behind a stateful firewall, both sides simply send a packet from their socket to the respective remote address/port, which will cause each local firewall to establish a connection tracking entry that will allow packets in the respective opposite direction to pass through. There is a race condition that might cause one of the packets to be rejected by the remote firewall (if it arrives before the locally originated packet passed through the firewall), but that doesn't matter: Afterwards, both firewalls have an entry for the connection, and all subsequent packets will pass through just fine. This is impossible with NAT because you cannot know the remote address that the NAT will assign for the connection, so you cannot send a packet to establish the entry in your firewall, and you cannot learn the address because you would need to receive the packet to see the address on it, which you can't as long as the firewall doesn't know about it. Also, a protocol for opening ports on the stateful firewall would be much simpler without NAT, as the firewall doesn't need to allocate ports or handle conflicts between multiple clients wishing to be forwarded the same port: The address/port allocation authority is with the client, the client('s kernel/network stack) can simply allocate ports on its assigned addresses and then only needs to tell the firewall that connections to a specific address plus port should be allowed in. This also means that, for example, the firewall forgetting those open ports doesn't cause much trouble: The clients simply can tell it again whith ports to open, and they will be reachable again, at the same address, no need to tell peers a new address because a uPnP gateway forgot which ports it had allocated to which client. And maybe most importantly: P2P traffic between devices on the same LAN becomes much, much simpler. Currently, if you have two participants of some P2P system in one LAN segment, where both establish an open port on the NAT gateway via uPnP, when one wants to connect to the other, there are roughly three possible scenarios: It can try to connect to the public address/port as established by uPnP, just like any remote client would. If you are unlucky, the NAT gateway only does DNAT, in which case the connection won't work because any responses will come from the local address of the peer instead of from the public address of the NAT gateway, so won't be recognized as belonging to the connection. If you are lucky, the NAT gateway does hairpin NAT, in which case the connection works, but all traffic has to go through the NAT gateway in order to rewrite addresses, instead of directly from one machine to the other at the ethernet level, which usually will be much slower than a direct transfer (even more so when there might be multiple people doing the same thing on the same LAN, where the switch might well be able to forward multiple gigabit flows at once, but your DSL NAT gateway most likely will not, not even if they are both in the same case). Or, if you want to avoid both of that, you'd have to somehow detect that you are in the same LAN and then figure out what the address of the peer on the LAN is in order to connect to that address instead (and note that you can't use the local addresses to decide that, even if you know them, as you might well have addresses in the same private address range, but still be connected to completely different LANs). Without NAT? You simply connect to whatever address the peer announces. If you are on the same LAN, your machine's routing table will automatically route the packets to your local LAN, directly to the other machine, at full LAN speed. If not, they will be forwarded to your local gateway, through the internet, through the remote stateful firewall, and to the remote peer. No difference at all, apart from the speed, possibly, it just works.
joveian 11y ago
I agree with you and wish there was a public address/private address pair system, so that connections origionate from the private address (which has NAT-like semantics) while servers intending to be public listen on the public address. Local systems could still connect to the private address, so server applications could still listen there by default but would not listen on the public address unless explicitly configured to do so. Not having this local/wide address distinction makes it more likely that firewalls will simply block all traffic until, as you say, similar systems to those used with NAT are implemented. Another way to fix this problem is a personal VPN that only establishes outgoing connections automatically by default but can proxy incoming connections when explicitly requested. This is the same type of thing as used with NAT, except without the expectation that your ISP is the one providing it. Considering how obnoxious ISPs are these days in terms of filtering and such, this would be a major improvement. Since I am currently doing this (minus the proxying so far which I haven't needed but could easily add) for $15/year with a IPv4 address and virtual host that is way overprovisioned for what it needs, it seems likely that this could be done on a large scale for IPv6 at a quite low cost.
- zAy0LfpBZLC8mAC 11y ago
  > Not having this local/wide address distinction makes it more likely that firewalls will simply block all traffic until, as you say, similar systems to those used with NAT are implemented. Yes, and that would be the sensible thing to do. This "public/private" distinction doesn't even work: What if you have two LANs that aren't bridged? Possibly because they are connected through a VPN? Or maybe one Ethernet and one WiFi? Can you communicate between them? Or only on "public addresses"? What if the VPN is between two companies, say, who don't trust each other? And why would you make it depend on the "address type" anyhow, why not just have the application drop connections that come from outside the LAN? Blocking all inbound connections by default is no real problem as long as you have a protocol for telling the firewall which addresses/ports to open to the public - the problem with the "port forwarding" that you need with NAT is that ports collide and that you create asymmetric address translations or bottlenecks and all that crap, a simple protocol that tells the firewall to open a specific port or address would be trivial to implement and to use. Also, IPv6 has link-local addresses, which are essentially "private addresses for a LAN", so you can actually set up services that are reachable only on a given LAN (and nowhere else) - but that really only makes sense for local LAN management (neighbour discovery and such), not for application protocols, those really should just be reachable from everywhere, as far as the local API is concerned, and access control should then happen based on source addresses, possibly implemented as a stateful packetfilter at the network boundary, as you otherwise severely limit which network architectures can be used.
X-Istence 11y ago
There's an upside to this, yes ingress will still be blocked by default (good!) but with uPnP or something along those lines, we now open a single port and it's a 1:1 connection. No longer are we limited to having one device in the household holding that forwarded port and all traffic hitting the external IP going to a single internal machine. This would allow two users to have the same port opened. This makes it easier to communicate with others on the internet.

by rlpb 11y ago

zeroxfe 11y ago

This is not correct, there are many ways to do this without resorting to NAT hacks like uPnP. For example, ISPs hand out entire /64 per customer (at a minimum, almost all will give you larger subnets if you ask). This allows you to have a separate IP address per application, which can be allocated from an unfirewalled pool. There's also the fact that almost all major OSs now come with sane firewall defaults, also allowing applications to punch holes via APIs. (You could also have done this with IPv4 if it had a larger address space.) If you spend some time thinking about how to solve these problems with IPv6, you will find that there are lots of ways to do it that are simpler and far more secure.

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 ago
  You 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 ago
      Then 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 ago

zAy0LfpBZLC8mAC 11y ago

> Firewalling P2P traffic effectively remains just as hard with IPv6 as with NAT. Nope, it's much easier because the addresses are easy to predict. When both parties are behind NAT, neither side knows which address and port they will appear to be coming from to the other side, while without NAT, both parties know exactly what address the other side will see (it's the one the local socket is bound to ...), that makes it relatively easy to establish a connection through a stateful firewall with a simultaneous connect if both sides can somehow tell each other where their respective sockets are. It's outright trivial with UDP, not quite that easy with TCP: Assume both sides are behind a stateful firewall, both sides simply send a packet from their socket to the respective remote address/port, which will cause each local firewall to establish a connection tracking entry that will allow packets in the respective opposite direction to pass through. There is a race condition that might cause one of the packets to be rejected by the remote firewall (if it arrives before the locally originated packet passed through the firewall), but that doesn't matter: Afterwards, both firewalls have an entry for the connection, and all subsequent packets will pass through just fine. This is impossible with NAT because you cannot know the remote address that the NAT will assign for the connection, so you cannot send a packet to establish the entry in your firewall, and you cannot learn the address because you would need to receive the packet to see the address on it, which you can't as long as the firewall doesn't know about it. Also, a protocol for opening ports on the stateful firewall would be much simpler without NAT, as the firewall doesn't need to allocate ports or handle conflicts between multiple clients wishing to be forwarded the same port: The address/port allocation authority is with the client, the client('s kernel/network stack) can simply allocate ports on its assigned addresses and then only needs to tell the firewall that connections to a specific address plus port should be allowed in. This also means that, for example, the firewall forgetting those open ports doesn't cause much trouble: The clients simply can tell it again whith ports to open, and they will be reachable again, at the same address, no need to tell peers a new address because a uPnP gateway forgot which ports it had allocated to which client. And maybe most importantly: P2P traffic between devices on the same LAN becomes much, much simpler. Currently, if you have two participants of some P2P system in one LAN segment, where both establish an open port on the NAT gateway via uPnP, when one wants to connect to the other, there are roughly three possible scenarios: It can try to connect to the public address/port as established by uPnP, just like any remote client would. If you are unlucky, the NAT gateway only does DNAT, in which case the connection won't work because any responses will come from the local address of the peer instead of from the public address of the NAT gateway, so won't be recognized as belonging to the connection. If you are lucky, the NAT gateway does hairpin NAT, in which case the connection works, but all traffic has to go through the NAT gateway in order to rewrite addresses, instead of directly from one machine to the other at the ethernet level, which usually will be much slower than a direct transfer (even more so when there might be multiple people doing the same thing on the same LAN, where the switch might well be able to forward multiple gigabit flows at once, but your DSL NAT gateway most likely will not, not even if they are both in the same case). Or, if you want to avoid both of that, you'd have to somehow detect that you are in the same LAN and then figure out what the address of the peer on the LAN is in order to connect to that address instead (and note that you can't use the local addresses to decide that, even if you know them, as you might well have addresses in the same private address range, but still be connected to completely different LANs). Without NAT? You simply connect to whatever address the peer announces. If you are on the same LAN, your machine's routing table will automatically route the packets to your local LAN, directly to the other machine, at full LAN speed. If not, they will be forwarded to your local gateway, through the internet, through the remote stateful firewall, and to the remote peer. No difference at all, apart from the speed, possibly, it just works.

joveian 11y ago

I agree with you and wish there was a public address/private address pair system, so that connections origionate from the private address (which has NAT-like semantics) while servers intending to be public listen on the public address. Local systems could still connect to the private address, so server applications could still listen there by default but would not listen on the public address unless explicitly configured to do so. Not having this local/wide address distinction makes it more likely that firewalls will simply block all traffic until, as you say, similar systems to those used with NAT are implemented. Another way to fix this problem is a personal VPN that only establishes outgoing connections automatically by default but can proxy incoming connections when explicitly requested. This is the same type of thing as used with NAT, except without the expectation that your ISP is the one providing it. Considering how obnoxious ISPs are these days in terms of filtering and such, this would be a major improvement. Since I am currently doing this (minus the proxying so far which I haven't needed but could easily add) for $15/year with a IPv4 address and virtual host that is way overprovisioned for what it needs, it seems likely that this could be done on a large scale for IPv6 at a quite low cost.

zAy0LfpBZLC8mAC 11y ago
> Not having this local/wide address distinction makes it more likely that firewalls will simply block all traffic until, as you say, similar systems to those used with NAT are implemented. Yes, and that would be the sensible thing to do. This "public/private" distinction doesn't even work: What if you have two LANs that aren't bridged? Possibly because they are connected through a VPN? Or maybe one Ethernet and one WiFi? Can you communicate between them? Or only on "public addresses"? What if the VPN is between two companies, say, who don't trust each other? And why would you make it depend on the "address type" anyhow, why not just have the application drop connections that come from outside the LAN? Blocking all inbound connections by default is no real problem as long as you have a protocol for telling the firewall which addresses/ports to open to the public - the problem with the "port forwarding" that you need with NAT is that ports collide and that you create asymmetric address translations or bottlenecks and all that crap, a simple protocol that tells the firewall to open a specific port or address would be trivial to implement and to use. Also, IPv6 has link-local addresses, which are essentially "private addresses for a LAN", so you can actually set up services that are reachable only on a given LAN (and nowhere else) - but that really only makes sense for local LAN management (neighbour discovery and such), not for application protocols, those really should just be reachable from everywhere, as far as the local API is concerned, and access control should then happen based on source addresses, possibly implemented as a stateful packetfilter at the network boundary, as you otherwise severely limit which network architectures can be used.

X-Istence 11y ago

There's an upside to this, yes ingress will still be blocked by default (good!) but with uPnP or something along those lines, we now open a single port and it's a 1:1 connection. No longer are we limited to having one device in the household holding that forwarded port and all traffic hitting the external IP going to a single internal machine. This would allow two users to have the same port opened. This makes it easier to communicate with others on the internet.