Hacker News Reader

> The majority of nodes on local networks only ever need to connect _out_ to the external network, they don't need incoming connections.

And that's how we can't transfer large files from one computer to another, and why audio and video calls over the internet are only done through well founded companies, so there's nearly no competition.

If I give you the IPv6 address to my desktop computer, you still can't transfer a large file to me or try to video call me.

The reason is I haven't configured my firewall to let any of those things through. IPv6 or IPv4 NAT is in the same boat.

I think the point is that NAT is not necessary in IPv6, whereas it is in IPv4 due to address shortage. You can still have a firewall without NAT, btw.

Yes. What I'm trying to say is that I think embracing NAT would have been a better choice than the IPv6 we ended up with.

You can still use NATs with ipv6, there's just not many reasons too, no?

Yeah that's like the worst of both worlds in a way.

Nobody has configured their firewalls, because those things don't exist. If they existed, your firewall would have come configured by default.

But if your computer had connectivity to the rest of the network, you could choose to disable protection on some port, and help bootstrap some software like those. Instead, with NAT, you can't.

You don't need a firewall; you just need not to be listening on a port. And if you want to receive a file on a port, you can … start listening on it.

I wish I could upvote this 1000 times. Most firewalls are just so much security theater cargo culting. NAT and universal firewalls have done immeasurable, and at this point practically irreversible, damage to network freedom and free software.

And exploits

A fully peer-to-peer network is how IPv4 worked before NAT became popular. NAT was hack to solve address shortage. I worked for a couple ISPs in the 90's and many corporate networks had fully routed addresses on their LAN. I even had this at home.

I didn't have fully routed addresses on my LAN in the late 90's, because I only had dial-up.

My point is that even if I could today, with either IPv4 or IPv6, I don't really _want_ that.

It would make my internal network dependent on the external network, and the benefits don't outweigh that major downside.

What is the downside? The external network only needs to know you're responsible by an IP range that your ISP gives you, you can still configure your network internally as you please.

The addresses depend on the external network. If my prefix changes with IPv6, suddenly nothing works on the internal network until all the nodes are reconfigured and the firewall rules rewritten. I know because it happens to me regularly.

With NAT the internal nodes can for the most part work like normal. They might experience a gap of a few seconds where communication with the external network (the Internet) is down, but apart from that nothing.

You might say just use ULA[1]! To which I will say what's the point of IPv6 then?

[1]: https://en.wikipedia.org/wiki/Unique_local_address

It's true that this is a problem for intermittently connected consumer networks and customers of flaky ISPs that change the prefix on you needlessly. Regulation for allocating PI space to flaky isp customers might help.

At one point I had an entire /24 routed over a 28.8K connection. I eventually upgraded to an ISDN line. Fun times.

It sounds like what you really want is a firewall, not NAT. Having a globally unique prefix (either IPv6 or v4) does not mean your network is completely accessible externally. There are no dependencies. It actually makes things simpler if you ever want to connect two internal networks.

Of course I want a firewall. We all do. That much was obvious even when I was on dial-up, installing Shorewall or whatever it was back in 2000.

My point is that if you have a firewall you're in the exact same position as if you have a firewall+NAT in that you need to be able to punch holes in it.

IPv6 on its own does nothing to help with this.

NAT make hoke punching more complicated (or depending on exact type of NAT impossible)

A fully peer-to-peer network is arguably how the IPv4 internet still works, as hosts behind NAT are not really part of it. But of course it hurts the network effect when fewer users are on the network proper.

NAT is terrible because it prevents us from doing lots of nice things.. Like evolving internet protocols!

> And for the majority of local networks there's a fundamental asymmetry between the local and external network. The majority of nodes on local networks only ever need to connect _out_ to the external network, they don't need incoming connections.

This is kind of like the railway administrators who say "there's no reason to have the train stop in TinyTown, there are no passengers waiting for it there".

If I could receive incoming connections, I could host my own Internet services (such as my own web site) AT HOME, and not be at the mercy of corporations to allow me to offer my information and/or services.

Now try hosting two different web services on two different hosts inside your NATted network on port 443, so you can use https:// without specifying a port.

Because that's the big advantage with IPv6 and users getting subnets instead of a single IP.

Your talk about ports highlights what I'm trying to get at: we already depend on layered address spaces.

Why not accept that and roll with it?

So you're saying if you're used to drive stick, you shouldn't think about buying an automatic at all?

[Edit] The problem with public addressed end nodes is the Operating Systems we use aren't secure. Linux and Windows are unfit for purpose in a world of persistent connectivity. Suitable alternatives do exist, but aren't well known.

Once I get Genode or GNU Hurd running, I'll gladly hook it straight to the the full IP4/IP6 public addressed internet. Until that day, nope.

You’re confusing a firewall and a NAT. Having a publicly routable IP address does not in any way imply allowing external connectivity to that address.

The firewall rule that allows packets from ESTABLISHED and RELATED connections back to a host behind a NAT is the exact same rule that allows packets to get through a default-drop firewall.

If your computer is secure, you don't need a firewall.

And if you don't think Linux and Windows are secure, then you do. Either way, you shouldn't be putting them behind NAT.

You should put them behind NAT if you want to connect your network to the internet but you don't have enough IP space to do it. It has nothing to do with how secure you think your OSs are.

You misunderstand the depths of my pessimism.

I don't believe any firewall out there is fit for purpose, because the OS on which it is based is likely to be insecure. On top of that OS would then be the firewall software itself.

I would truly love to be proved wrong, but mathematically proven systems are few and far between.

I had to downvote you for conflating NAT with security. IPv6 has the same capability, by the way, due to a reserved address space called link local (fe80).

NAT is just as horrible, and secure, as spanning tree.

> I had to downvote you for conflating NAT with security.

I specifically didn't.

I said that nobody sane connects to the internet without a firewall. That firewall will of course be default-drop because otherwise why bother.

With that firewall in place, nodes on the outside of the firewall cannot talk to nodes on the inside without some configuration. So the fact that the nodes share an address space is moot.

My point was that punching a hole in that firewall requires a similar effort or solution that adding a NAT rule does.

The difference is that you can give an IP to a device semi-permanently and you can route to it directly if needed. This allows you to configure a firewall in your device specifically, rather than having to orchestrate with the router. For instance, you can give your laptop an IP and your partner's laptop another IP and you can just route everything to those two specific devices, which you know is handled properly by two responsible people. I agree with the point that you probably want to be more restrictive in the router level when you connect your fridge, printer, etc.

Moreover, the router is a lot simpler as it doesn't need to keep track of connections, which works well with TCP, but not necessarily with UDP. So, you can actually use other protocols other than TCP easily too. The only downside of IPv6 is that it is not backwards compatible, but being able to identify devices uniquely has no down sides.

You don't just need configuration on the fw, you are also limited to having at most one service of each kind per NATted network, because you use up their default ports.

> you are also limited to having at most one service of each kind per NATted network

That's not entirely true. It's possible to assign source port/address combos that route to different hosts.

For example, I can say that:

* 1.1.1.1:80 routes to 192.168.1.2:80,

* 8.8.8.0/24:80 routes to 192.168.1.3:80, and

* everything else on port 80 routes to 192.168.1.4:8080

It's possible to get even more convoluted, though not recommended.

That's already quite convoluted, and it means that one remote address can only connect to one of the services at a time and you need to reconfigure your router to change which one. It also gives you no selectivity for remote networks that use NAT, so if 1.1.1.1 is actually an ISP using CGNAT for thousands of customers then they're all stuck with going to only one of your services.

(If I read your post as written, it also seems to say that the client needs to pick a custom source port and if they're using NAT then they also need to get that source port unaltered through all of their layers of NAT. And they'll be limited to one connection at a time, perhaps one connection for however many people are behind the same CGNAT, because only one connection can use a specific source port at a time.)

So yes, you can pile hacks on top of hacks on v4, but it's not similar effort to just permitting the connection in a firewall, and it has a bunch of extra limitations too.

Correction about link-local: v6 link-local doesn't really work for this - LL addresses are meant to be used for low level stuff like address autoconfiguration and neighbour discovery. They don't even work with the normal socket APIs without doing some extra gymnastics (specifying interface indices etc).

What does work though is ULA (Unique Local Addresses) - they're also designed to prevent conflicts when you eventually end up making a mashup of your and someone else's network who also wanted to use their own addresses.