> disabling NAT results in "exposed" LAN devices

"In theory, theory and practice are the same. In practice, they are not."

NAT was used as a blocking method for all incoming connections for SOHO networks for decades.

> NAT was used as a blocking method for all incoming connections for SOHO networks for decades.

And so have stateful/SPI firewalls,[1] and with those you don't need the convoluted rigamarole of STUN/TURN/ICE infrastructure: a whole class of technology that had to be invented to deal with NAT.

Meanwhile, if you have globally addressable (but not necessarily globally reachable) IPv6 on your clients all of that goes away, and it's just PCP [2][3] that's needed to hole punch on your CPE. Much less convoluted.

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

[2] https://en.wikipedia.org/wiki/Port_Control_Protocol

[3] https://en.wikipedia.org/wiki/Hole_punching_(networking)

It cannot work reliably, that's why Hole Punching is a thing.

If you don’t punch there’s no hole.

> If you don’t punch there’s no hole.

Good luck gaming then, or using BitTorrent (and probably other services). All consumer CPEs support PCP/UPnP for 'dynamic punching'.

And if the app in question doesn't use PCP/UPnP, then you have to stand up an entire STUN/TURN/ICE infrastructure.

Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole.

Your TCP stack is unlikely to accidentally punch port 3398 when you’re browsing hn.

> Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole.

That is not what is meant by "hole punching":

> Networked devices with public or globally accessible IP addresses can create connections between one another easily. Clients with private addresses may also easily connect to public servers, as long as the client behind a router or firewall initiates the connection. However, hole punching (or some other form of NAT traversal) is required to establish a direct connection between two clients that both reside behind different firewalls or routers that use network address translation (NAT).

* https://en.wikipedia.org/wiki/Hole_punching_(networking)

* https://en.wikipedia.org/wiki/Port_Control_Protocol

* https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...

The nature of an EIM/EIF NAT is that the hole exists without punching, as soon as the device behind the NAT connects to anywhere public.

That action creates a public side mapping on the NAT, being Proto/IP/Port - Proto generally being TCP or UDP.

While that mapping exists, any packet within that protocol, from any source address or port in the whole IPv4 Internet can be directed at that mapping, and received by the client computer.

Generally TCP syn's will be dropped by the client (unless they explicitly opened a fixed mapping, and are hence running a TCP server), but any UDP packet for an open UDP mapping will be received.

AFAIK, the various gaming programs tend to run over UDP...

The punching per-se is to coordinate between two clients, each behind NATs, and/or each behind actual firewalls (as opposed to the NAT filtering function).

One does NOT play with https://en.wikipedia.org/wiki/Phencyclidine !1!!

It's enough to keep the Shodan skiddies at bay. I distinctly 'member the modem/ISDN era and trolls shooting off unpatched machines of other gamers. In ye olde days remote RCE exploits were a regular issue...

No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them.

If those applications want to be reached over the network, they can use Hole Punching to turn what would otherwise be an inbound connection into an outbound one. But that requires an effort on both ends of the conversation: if I want a remote client with IP 1.2.3.4 to connect to my server that's behind a NAT, then my server first needs to send a packet to 1.2.3.4. (That's the hole that's punched.) But that doesn't change anything about the reliability of the NAT's protection, because other clients on the internet still can't reach my server. If 1.2.3.4 is not malicious, then nothing bad can happen here. If 1.2.3.4 is malicious, then I was already in trouble when I punched the hole in the NAT, before an inbound connection from 1.2.3.4 even arrives - simply because I created an outgoing connection to 1.2.3.4, over which they could have sent me exploits anyway.

I know you know all of this, but I wanted to add some context to your misleading and pedantic comment for other readers of this thread.

Nope, the hole created in the NAT is generally endpoint independent. It does not matter what the target is, anyone can now send packets to that mapping.

i.e. assume 192.168.0.1:4567 sends a packet to 12.13.14.15:25, creating a mapping, and keeping that mapping session active. Assume the public translation for that client is 5.6.7.8:7777

Now anyone, e.g. 23.24.25.26:7654 can send a packet to 5.6.7.8:7777 and it will be received by 192.168.0.1:4567.

That behaviour is what is relied upon in order to make the NAT hole punching work.

It is only 5-tuple stateful firewall punching (of ADPF NAT - which are uncommon) which require that the return packets come from a target punched first. Hence needing the coordinated punching from both sides to the public address:port mapping of the peer.

It depends on a NAT implication but usually both src port+ip and dst port+ip should match for a reply to be sent back to an internal IP.

Go and find the academic survey papers of NAT behaviours. They list what I stated, the common case is EIM+EIF.

However, continue with your belief...

> EIM+EIF

This is a new and unfamiliar term/acronym to me. It seems to be from RFC 7857, "Updates to Network Address Translation (NAT) Behavioral Requirements":

* https://datatracker.ietf.org/doc/html/rfc7857

People may be more familiar with the various "cone" NAT variation definitions:

* https://datatracker.ietf.org/doc/html/rfc3489#section-5

Despite working in the industry, I always found the "cone" terms for NAT confusing, and difficult to remember.

So once the BEHAVE terms came out, I adopted them, as they were (at least to me) more obvious. They're also more flexible in that they can describe real behaviours which can not be mapped to "cone" terms.

I know how NAT works under FreeBSD and it doesn’t ignore remote IP/port. Would be surprised if Linux differs in this regard and most home router are based on Linux. I know little about CGNAT but one shouldn’t trust ISP with protection from unwanted connection and there is almost always a home router with one more NAT even if ISP uses CGNAT.

> No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them.

It is the state tracking that does the protection, which you do not need NAT to do:

* https://en.wikipedia.org/wiki/Firewall_(computing)#Connectio...

* https://en.wikipedia.org/wiki/Stateful_firewall

And by getting rid of NAT, you also remove the need for the convoluted bullshit of STUN/TURN/ICE, and all you're left with is PCP:

* https://en.wikipedia.org/wiki/Port_Control_Protocol

* https://en.wikipedia.org/wiki/Hole_punching_(networking)

"Applications" including malicious javascript in your browser.

I hate to be that guy, but: there is no 'deny' action in NAT.

Resist the urge to be that guy. There actually is a deny: it’s what your NAT system does when an incoming packet doesn’t match a connection initiated by a device behind it.

Trying to be pedantic about this isn’t adding anything to the conversation – people have been trying to make this seem like a useful distinction for decades but it’s never worked because anyone who cares about security is focused on “can an attacker initiate a connection to my system?” rather than “did I lovingly handcraft the packet filtering rule which dropped their attempt?”

> There actually is a deny

If you don't have NAT:

- the packet with your IP in dst_ip would be thrown out

If you do have NAT:

- the packet with your IP in dst_ip would be thrown out

In both cases the decision to drop the packet were carried out by the firewall and not NAT.

So puh-lease, stop.

NAT essentially has a "default deny" rule.

Having a publicly routable address absolutely does “expose” your network, which at the very least has the potential to generate load on your firewall (your problem) that would otherwise be absorbed by the NAT device (your ISP’s problem). Assuming the firewall is configured correctly in the first place, which is by no means guaranteed in consumer/SOHO settings.

> Having a publicly routable address absolutely does “expose” your network, which at the very least has the potential to generate load on your firewall (your problem) that would otherwise be absorbed by the NAT device (your ISP’s problem).

How is one your problem and the other your ISP's?

In both cases the bits are coming down your connection and hitting the CPE. Whether the CPE does only SPI firewalling or SPIFW+NAT seems to be irrelevant to me, as the same thing happens: packet's header tuple is examined, a state table is looked at, and the packet is passed or dropped depending on the contents.

I’m talking about CGNAT, where the bits do not enter your premises.

I don't know about your network, but for me that NAT device is sat on my network and so very much my problem :D

The NAT device itself also is a firewall and can enforce policies comparable to what NAT would do. I had the impression that this is the default behavior in 2024.

In my Fritz!Box, i have to configure IPv6 ports the same way i used to forward ports for IPv4.

Assuming CGNAT, sure, it is the ISPs problem. But that just underscores the utility of IPv6 where defective CGNAT results in a hair pulling experience for the customer. Things don't get forwarded, and there isn't a thing you can do about it except call the ISP (provided you were able to troubleshoot it to that point in the first place).

If NAT is done on the router, then it gets to make a decision on every packet regardless.

"NAT Device" = "Firewall" (in this context) = "What you'd normally have with a public address plus the translation part".

There tends to be conflation that somehow you need an additional device to filter you've not had in place before. In order to do NAT a device has to be at the edge of your network (your device or the ISPs) which tracks connection states to automatically translate outbound ones and allow the reverse mappings through while that is open. Getting rid of NAT simply means dropping the "translate" part from that device. The conntrack and allow outbound initiated connection part remains. Instead of port forwards for inbounds you just have inbound allows. There is no big swap of security roles between devices or special additional configuration needed, just the independent removal of the translation configuration from the device.

While technically true I think with Nat enabled it disables access from the Internet by default even if a firewall is misconfigured.

If your firewall is disabled, an incoming v4 packet on the WAN interface with destination IP = a NAT'ed LAN device's address like 192.168.1.2 could cross over to the LAN interface and reach said LAN device. It is the firewall's job to filter such bogons.

How would the package get routed my way unless the attacker hooked up right outside my network?

You've answered your own question.

Such a rare occurrence.

Nat alone doesn’t protect you from 100% of threats. Neither does a firewall btw.

But it does add an extra layer of safety.

In what realistic scenario would a regular individual need to worry about such a threat scenario?

Having implemented a commercial hole punching mechanism, and having tested it on home and commercial deployments (various UK and USA ISPs), I have to agree.

For most deployments (home and commercial) the NAT function (its session table) employs Endpoint Independent Mapping, and Endpoint Independent Filtering (see BEHAVE RFCs).

As such once something behind the NAT (say at IP:Port) has connected to an external node, any external node can connect back to that internal IP:Port location by targeting packets at the public IP':Port' mapping. This applies even if the node behind the NAT was not expecting, nor desiring it.

For home deployments, there is generally no additional firewall.

For commercial deployments, there is usually a firewall working in an Endpoint Dependent Filtering manner (usually full 5-tuple, Port and Address Dependent Filtering).

This additional firewall blocks off the unexpected connection allowed by the home scenario above, but still allows for hole punching if the behind NAT node(s) can coordinate punching via a third party to exchange their public mappings.

Notably in the home deployment case, if the attacker is working with known public ports and addresses (i.e. itself being none NATted), then it can easily bypass the filtering logic of the home NAT once it learns of the existence of the 5-tuple public flow from the home NAT.

But even if the attacker knows the 5-tuple (which is a big if), how would they send a package with the correct headers? Pretty much every ISP firewall will just drop your packages if you send them with a source IP that's not yours.

Note that if you can fake source IP addresses, then a proper firewall won't protect anymore either, because all rules of the form "allow inbound connections from 1.2.3.4 only" are now broken.

I am assuming attacks against a home/retail NAT box, where the full 5-tuple is not required, only the 3-tuple being translated to on the public side of that NAT box. That being the endpoint independent mapping.

All an attacker needs to do is send packets from any source address and port, but using the same protocol (TCP/UDP) targeting that public 3-tuple, and the NAT box will allow the packet in.

I was not suggesting that the attacker resort to spoofing its source address, but use its real one. The attacker itself could be a zombie controlled by the real CnC entity, so mitigating against detection.

Finding the 3-tuple is the challenge, but not too great a one. One would start by seeing what info could be leaked from the public sites such NATed clients are connecting to.

IP packets originating from or addressed to a private IP address cannot be routed through the public Internet.

You can't send a packet addressed to i.e. 192.168.1.2 oder the Internet, sure. But that wasn't what we were talking about either. You can connect to the device that's behind a nat and has that ip address. I've linked to one of the best known strategies for that, hole punching.

Feel free to read that to broaden your horizon

Look what Arnavion wrote in this thread previously:

> If your firewall is disabled, an incoming v4 packet on the WAN interface with destination IP = a NAT'ed LAN device's address like 192.168.1.2 ....

But no package would ever make it back as none would be sent to the gateway and even then the gateway would send it to the local network.

Just checked my Steamdeck and from the kde desktop settings ipv6 was entirely disabled. I just re-enabled ipv6 to let it auto configure an address and got ipv6 connectivity.

NAT didn't make remote attacks harder, the default inbound deny rule did. NAT is not the firewall itself, it's just one of the things the firewall can do. Telephone companies are also ISPs, and they are and continue to be quite inept when it comes to securing their own networks, so NAT without a default inbound deny rule is not secure.

This matters in a very meaningful way. Have you seen how many enterprising but clueless consumers click random buttons until whatever they are trying to do works? They often don't know or care about other ramifications until it's too late.

What benefits has ipv6 beside that ipv4 addresses for public servers are in short supply?

If you live in a country rich enough that every ISP customer gets a dedicated IPv4 address you won't see many of the downsides of deploying IPv4 these days. If you don't, you'll get tired of Cloudflare's "checking if your connection is secure" becomes pretty tiring pretty quickly. Even in rich countries, CG-NAT is starting to get used more and more as prices for IP ranges go up. CGNAT also affects people trying to do something silly like "open a port" for a Minecraft server or a VPN back home, which is impossible without a public address.

Outside of CGNAT, just about any protocol works better without standard IPv4 NAT. Xbox and PlayStation have invented their own terminology (what the fuck is a "type 2 NAT" anyway) and have written custom code to work around the different ways in which NAT fucks up your connection. Linux and BSD based routers will do deep packet inspection to figure out if you're trying to do FTP or SIP or H363 and rewrite traffic on the fly while opening holes in the firewall just so you can use basic internet functionality. This has also led to an attack dubbed "NAT slipstreaming" where generations of routers will allow Javascript running in your browser to open any port on your device to the outside, or even any port on any device in your network, despite what your router's firewall may say.

For larger networks (with more than ±250 devices), you get a working connection without having to figure out what a DHCP pool is.

And lastly, while this will probably differ by ISP, my experience is that IPv6 has significantly less latency than IPv4, on the order of 4ms versus 20ms.

In Germany, the TV-cable based ISP all have started deploying CGNAT.

If you live in a densely populated area with many Vodafone customers, their CGNAT gateways tend to be overloaded, so in peak hours you sometimes experience packet loss.

Of course Vodafone won't admit that it's a structural problem instead of isolated cases.

At one point, I was forced to use a shitty DSL provider, "e-on highspeed" (formerly "Innogy") because they had exclusive rights to the VDSL DSLAM in my area. For a while, they didn't even offer IPv6 alongside the CGNAT v4. And when they did, it broke randomly (remote gateway dead).

By the way, does anybody have a clue on how to get SLAAC addresses into local DNS? I can't create static records because my current ISP keeps changing my assigned prefix. I'm still on v4 for my local fileservers and stuff like that because of this problem.

The easiest way is to use a ULA on the LAN side instead of the ISP-assigned prefix, and set up NAT66 at the router to convert delegated prefix <-> ULA. It sucks having to use NAT with IPv6, but at least it'll be stateless NAT. Then when your delegated prefix changes you will only need to update the NAT rule, meanwhile everything within your LAN that was using ULA-prefixed addresses to talk to each other will continue working.

For my own homelab, I give all my machines and VMs static IPs instead of using SLAAC, which also makes it straightforward to register them in DNS, and memorize them in the worst case.

> The easiest way is to use a ULA on the LAN side instead of the ISP-assigned prefix, and set up NAT66 at the router to convert delegated prefix <-> ULA.

You don't need to not use your ISP-assigned globally-routable prefixes. You can use both a ULA and a globally-routable prefix. In my years of experience with fully-functional IPv6 service, I've never noticed an address selection problem... machines always use the globally-routable address as the source for off-LAN communications and (because it's what's in my local DNS) the ULA address for on-LAN communications.

The single pitfall I've seen is if your ISP ever "shuts down" [0] that globally-routable prefix, and your border router isn't configured to reject traffic from fc00::/7 going out through the WAN interface, your border router will happily pass traffic out the WAN interface from your not-globally-routable ULA range.

> For my own homelab, I give all my machines and VMs static IPs instead of using SLAAC, which also makes it straightforward to register them in DNS...

I just configure my machines to use either MAC-based or DUID-based SLAAC address generation, rather than that stupid "privacy addressing" stuff.

[0] By this I mean by stopping advertising it, refusing to renew a DHCPv6-PD lease, or similar.

> does anybody have a clue on how to get SLAAC addresses into local DNS

I use an ULA for that (a private /48 that's not routable through the internet). I have a random server in my network (doesn't need to be a router) advertise it through radvd (though some routers also offer that ability). I then put the static address (not the random IPv6 privacy address) in local DNS. If you don't pick any "easy" ULAs, you can have multiple devices announce multiple ULAs on the same network and everything will keep working just fine (unlike multiple DHCP servers).

The benefit of an extra ULA inside your network is that you don't need to set up NAT or NAT66. The downside is that your ULA services won't be reachable from the outside. I solved that with a Wireguard VPN, but you may need something more complicated. You could consider using something like HE.net's free IPv6 ranges to add an extra prefix into your network that's reachable even when your prefix changes, but that needs some automation (and you want to configure it in a way that devices won't try to route to the internet over that prefix, or streaming services will stop working and your network will probably slow down a bit).

I used https://it.jason.tools/ipv6-ula-generator to generate a random enough ULA, then put this into my /etc/radvd.conf:

    interface vmbr1
    {
            AdvSendAdvert on;
            AdvDefaultLifetime 0;
            MinRtrAdvInterval 3;
            MaxRtrAdvInterval 10;
            prefix fdae:5594:90d5::/64
            {
                    AdvOnLink on;
                    AdvAutonomous on;
                    AdvRouterAddr off;
            };
    
            RDNSS fdae:5594:90d5:0:215:5dff:fe01:d119 {
                    AdvRDNSSLifetime 3600;
            };
    };

Maybe some of those timeouts aren't correct, I don't know for sure, but this seems to work fine for me. The RDNSS entry is for automatically assigning a DNS server, that's optional as well of course.

Alternatively, using mDNS also works more often than you'd expect, either over IPv4 or IPv6. Try `yournashostname.local` and you may just find it works out of the box. If it doesn't, you can probably install avahi-daemon on there to make it work.

> By the way, does anybody have a clue on how to get SLAAC addresses into local DNS?

As others have mentioned, ULA is one option.

> I can't create static records because my current ISP keeps changing my assigned prefix. I'm still on v4 for my local fileservers and stuff like that because of this problem.

Perhaps worth looking at:

* "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events", https://datatracker.ietf.org/doc/html/rfc8978

* "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-...

> By the way, does anybody have a clue on how to get SLAAC addresses into local DNS?

The main difference between v4 and v6 (which reaaally trips v4 entrenched folks) what it's absolutely normal to have dozens of different addresses on the interface.

As other said, just pick your own ULA subnet and use addresses from it.

> And lastly, while this will probably differ by ISP, my experience is that IPv6 has significantly less latency than IPv4, on the order of 4ms versus 20ms.

I feel like <random big game> could have killed IPv4 ten years ago if they had just introduced this sort of latency difference.

> If you don't, you'll get tired of Cloudflare's "checking if your connection is secure" becomes pretty tiring pretty quickly.

Is this really related? I'm on IPv4 and get these "checking if your connection is secure" all the time as well. I think that this is unrelated to CG-NAT, because, after all, Cloudflare does mostly use the browser's properties to determine if a manual check should be done (click the button...).

> Cloudflare does mostly use the browser's properties to determine if a manual check should be done

Cloudflare uses the threat score of each IP address as a signal to determine whether additional checks are necessary. A shared IP address is more likely to be associated with "issues", such as a compromised IoT device being used for DDoS attacks, one of your neighbours spamming a forum, ...

How is it not a GDPR violation? Before I've even connected to the site I intended and had the opportunity to consent, an IP address that potentially uniquely identifies me (plus whatever else) is shared with a third-party data processor?

There is generally exceptions for anti-abuse/spam to some of the provisions of GDPR and the like.

That said, is there really any 3rd party here? You are connecting to cloudflare and they are the ones that have seen this IP before and judging its behavior.

It's a good point (made by sibling comment to yours too) but I do think it's a bit of a break-down in the intent of GDPR, or even 'not possible to satisfy requirement'?

Because from a user's perspective, my relationship is with news.ycombinator.com or whatever - I don't (have to) know or care if the site uses Cloudflare, that's some other company, maybe I haven't even heard of it or have any other relationship with it. But now it is a company that the one I knowingly have a relationship with is causing to be made aware of information which uniquely identifies me.

I didn't know there were anti-abuse/spam exceptions though, so I suppose that's it.

How would it work with IP/Internet at all? Doesn't matter if the site is hosted in Cloudflare, aws or random datacenter.

Really easy prefix delegations on consumer/small business links without configuration.

End-to-end connectivity, rather than having to think at all about what will one day be a "public server."

Avoiding of crummy CGNAT.

No more collisions between private addresses when a company is acquired or networks otherwise merge.

Avoiding most of the annoyances of DHCP.

There's more, but these are the ones that really resonate with me.

> What benefits has ipv6 beside that ipv4 addresses for public servers are in short supply?

What more benefits do you need?

It's a major issue for many folks, especially if you (a) didn't manage to get in early on the IPv4 land rush, or (b) aren't a mega-corp with money to buy a whole bunch of addresses:

> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.

> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.

* https://community.roku.com/t5/Features-settings-updates/It-s...

* https://news.ycombinator.com/item?id=35047624

Do you think we'd have as much mobile/smartphone connectivity without IPv6? T-Mobile US went to IPv6-only on handsets because of exhaustion, and they're only one carrier (in the US).

Cost. IPv4 is so expensive to support that one ISP out there is literally giving people Apple TVs with IPv6 support to replace IPv4-only Roku devices https://daringfireball.net/linked/2023/03/06/roku-apple-tv

On Spectrum and AT&T in the U.S. I tend to see a little better latency, on average, on IPv6 (2-4ms). Not sure the exact reason

Little for a typical web client, but p2p connection setup in theory should get better in a world with less NATs.

No need to pay Big Tech to do anything like videochat.

I wonder if we could have just done something simple like add a block to ipv4? Like 255.255.255.255.255

No, too much software and hardware relies on fitting the IP address into 32 bits. That means the only way to increase the number of addresses is in a way a clean break, so we might as well increase the number to a ludicrous size, far beyond what we can imagine practically exceeding, like IPv6's 128 bits.

IP packets are like a C struct that only have 4 bytes allocated per address. If you want to have more space, you need to change that struct, and that's what IPv6 does. Together with a new Ethertype so the different structs can be reliably differentiated.