3 ms·

> Implementing UPnP and NAT punching is trivial It's possible if and only if you have control of the router. Good luck doing that when it's your ISP doing CGNA

by pdkl95 7y ago

> Implementing UPnP and NAT punching is trivial It's possible if and only if you have control of the router. Good luck doing that when it's your ISP doing CGNAT. This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT. This isn't a theoretical concern; there are already many places on the IPv4 network that cannot get any kind of port forwarding (including UPnP). Also, NAT hole punching is not[5] "trivial". It only seems trivial if you only consider the easiest case. It also requires a centralized server to initiate. edit: re: the supposed privacy benefits of NAT - even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to. You do not need NAT to have webservers see a single IP address from your LAN. > harder to fund 100% offtopic; I'm not talking about software funding. The point is that NAT has held back software development. There are entire categories of network software that haven't even been invented yet, because they require being able to receive calls (incoming TCP SYN packets). We don't know what is even possible, because true network software has receive4d very little development effort. > end-user hosted websites That is useful. I know several people that use local hosting for various useful activities. Bandwidth isn't that important if you're just sharing with friends. However, this is yet again an example of the client/server model. You seem to be proving my point that being stuck behind NAT can limit your thinking to the one model that works. For a simple example of non-client/server network software, how about chat software that makes direct connections without the need for a server? (discovery can still use a server; that doesn't mean the chat protocol itself has to be centralized). In ~1996 I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address. Just like we dial people on the telephone network by their telephone number. Yes, there are more convenient methods, most of which require trusting a centralized source. To even have a chance at developing something better, we need the ability to develop software freely at the network endpoints, which is incompatible with NAT. > DNS I didn't say anything about DNS. As I said above, you seem to be assuming a very limited range of network software. Of course DNS has serious problems; it's not the only way we can discover IP addresses. I want a future where we are free to invent these new methods, instead of a highly-centralized future where the surveillance capitalists have the power to decide which network connections you are allowed to make. [5] https://bford.info/pub/net/p2pnat/ https://bford.info/pub/net/p2pnat/

mindslight 7y ago
> There are entire categories of network software that haven't even been invented yet, because they require being able to receive calls (incoming TCP SYN packets) > I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address This is a cute demo but ultimately a red herring. I think the crux of our disagreement comes down to whether we see IP addresses as sufficient user-facing/user-identity addresses. I do not believe them to be so. By "DNS" above, I really meant DNS+IP - a namespace that assumes the ability to contact an authoritative server, talking directly to it to accomplish a task. As I said, there is no ability to retrieve the latest version of a given object from an untrusted peer - talking to the authoritative server is the only way to obtain updates! A real communication service needs things like presence information, roaming, multiple endpoints, asynchronous notifications, etc. Which in your example (phone number == IP address) ultimately requires having a bona fide server sitting there to answer for those requests. You called this "discovery", but it's much heavier than that. This is the technical burden that is straightforwardly solved by the software-as-surveillance companies - set up a well-known server, and simply pay a bunch of people to make sure it is always up. A thought experiment: Say I have a neighbor who is also DIY-technical. What can we actually gain by running a network link between us? I can give him an NFS export (or the like) to access my collection, but he's got to explicitly use of it (ie incorporate my hierarchy into his own mental hierarchy). For wider use with HTTP(s), the best I can do is give him transit to contact the server himself, but that is just becoming his ISP. However if we're on the same torrent, and the torrent client knows how to discover his client, we can both cooperate without explicit coordination. Because Bittorrent addresses chunks by the hash of their content, I can verify whatever I receive from him without needing to contact the original publisher! Contrast when an object identity relies on an IP or DNS name, the only way to verify it is to contact its server yourself. > even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to So, L4 address translation instead of L3... And I agree, to scrub fingerprints it makes sense to proxy at the highest protocol layer possible. So sure, maybe the future will be a nice flat v6 namespace for incoming connections, and a household HTML proxy to scrub access to legacy HTTP(s). Don't get me wrong - I'm certainly not arguing against adopting v6. I just don't think it is wise to wait for it to usher in the peer paradise that people were imagining 20 years ago. AJAX and surveillance as a service didn't get adopted simply due to a shortage of v4 addresses. > This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT At a basic level, I do agree this development path is worrying. But IMO the real way to push back against this is to create a demand for something else. Unless the net result looks immediately different to a significant number of end users, the demand isn't there. And right now, even in the US/EU there isn't a widely-compelling advantage to having a routable v4 address.

by pdkl95 7y ago

mindslight 7y ago

> There are entire categories of network software that haven't even been invented yet, because they require being able to receive calls (incoming TCP SYN packets) > I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address This is a cute demo but ultimately a red herring. I think the crux of our disagreement comes down to whether we see IP addresses as sufficient user-facing/user-identity addresses. I do not believe them to be so. By "DNS" above, I really meant DNS+IP - a namespace that assumes the ability to contact an authoritative server, talking directly to it to accomplish a task. As I said, there is no ability to retrieve the latest version of a given object from an untrusted peer - talking to the authoritative server is the only way to obtain updates! A real communication service needs things like presence information, roaming, multiple endpoints, asynchronous notifications, etc. Which in your example (phone number == IP address) ultimately requires having a bona fide server sitting there to answer for those requests. You called this "discovery", but it's much heavier than that. This is the technical burden that is straightforwardly solved by the software-as-surveillance companies - set up a well-known server, and simply pay a bunch of people to make sure it is always up. A thought experiment: Say I have a neighbor who is also DIY-technical. What can we actually gain by running a network link between us? I can give him an NFS export (or the like) to access my collection, but he's got to explicitly use of it (ie incorporate my hierarchy into his own mental hierarchy). For wider use with HTTP(s), the best I can do is give him transit to contact the server himself, but that is just becoming his ISP. However if we're on the same torrent, and the torrent client knows how to discover his client, we can both cooperate without explicit coordination. Because Bittorrent addresses chunks by the hash of their content, I can verify whatever I receive from him without needing to contact the original publisher! Contrast when an object identity relies on an IP or DNS name, the only way to verify it is to contact its server yourself. > even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to So, L4 address translation instead of L3... And I agree, to scrub fingerprints it makes sense to proxy at the highest protocol layer possible. So sure, maybe the future will be a nice flat v6 namespace for incoming connections, and a household HTML proxy to scrub access to legacy HTTP(s). Don't get me wrong - I'm certainly not arguing against adopting v6. I just don't think it is wise to wait for it to usher in the peer paradise that people were imagining 20 years ago. AJAX and surveillance as a service didn't get adopted simply due to a shortage of v4 addresses. > This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT At a basic level, I do agree this development path is worrying. But IMO the real way to push back against this is to create a demand for something else. Unless the net result looks immediately different to a significant number of end users, the demand isn't there. And right now, even in the US/EU there isn't a widely-compelling advantage to having a routable v4 address.