2 ms·

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 se

by 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.
- joveian 11y ago
  I just noticed your reply but thanks, I agree that source filtering at the OS level would accomplish the same thing, be more flexible, and be more consistent with existing practice. I think the main additional assumption I have to (part of) what you describe is that applications (on a general purpose system) cannot be trusted to behave reasonably on the network, however users need insecure local networking to work. The public/private disctinction would work the way I imagined it, but only because I was assuming a limited form of source address filtering: essentially one bit on every interface (including VPNs) for "is this local" (I also assume separate addresses per interface). The second address is so that so wildcard listening only listens on local addresses, and explicit public addresses need to be specified (or otherwise enabled) by the user before a server will listen on it. I didn't realize that just doing source address filtering as you suggest could accomplish the same thing with one address in a much simpler way.

by joveian 11y ago

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.

joveian 11y ago
I just noticed your reply but thanks, I agree that source filtering at the OS level would accomplish the same thing, be more flexible, and be more consistent with existing practice. I think the main additional assumption I have to (part of) what you describe is that applications (on a general purpose system) cannot be trusted to behave reasonably on the network, however users need insecure local networking to work. The public/private disctinction would work the way I imagined it, but only because I was assuming a limited form of source address filtering: essentially one bit on every interface (including VPNs) for "is this local" (I also assume separate addresses per interface). The second address is so that so wildcard listening only listens on local addresses, and explicit public addresses need to be specified (or otherwise enabled) by the user before a server will listen on it. I didn't realize that just doing source address filtering as you suggest could accomplish the same thing with one address in a much simpler way.