Dagger2

No, NAT only affects which IP your connections appear to be coming from. It doesn't change which IPs your devices actually have.

The person I replied to said that they only get a single v6 address. If that's true, it doesn't matter whether they have NAT or not; their network isn't going to have publicly-routable addresses either way.

If your network is air-gapped then no connections will be happening at all, in or out... and if you connect a router to both the Internet and to your network, and enable routing on it, then it's not air-gapped any more.

You should read my other comments on this post. I've attempted, multiple times (but apparently without much success) to make the point that NAT is not a security feature because it does not, without a firewall, protect against an attacker.

You don't need a qualifier like "on the WAN subnet". It just doesn't do anything to protect you from inbound connections at all.

That's the type of NAT I've been talking about the entire time. It doesn't do anything to inbound connections unless you explicitly tell it to.

Connections to the router's IP address go to the router, but you need to consider what happens to connections that go to IP addresses on the network behind the router too.

It's not, because in the real world NAT only affects your outbound connections. That means that turning it off only changes the behavior of outbound connections, not inbound ones.

Any inbound connection that would have worked before you turned it off will still work afterwards, and any that wouldn't have worked before will still not work afterwards.

No they didn't? v6 is compatible with v4 in tons of different ways, probably in almost every way that it's possible to be compatible with v4.

Admittedly, it's not compatible in the ways that _aren't_ possible. But it's highly unreasonable to blame that on the people who designed v6.

If you can be uniquely identified without NAT then you can be uniquely identified with it too, because IPs don't contain your identity. You get them from a combination of the network prefix and a random number generator.

There's generally no reason to be enabling NAT when you have enough address space to not need it. It can be a useful tool in your toolbox sometimes, but it's not something to be enabling by default.

That's not the case at all. You could disable their NAT and they wouldn't lose any protection whatsoever.

Yes, of course. If NAT denied connections in the way people think it does, then it wouldn't be necessary to separately configure the router to reject inbound connections. It's possible to have configurations that don't do that precisely because NAT doesn't do that itself.

But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.

The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.

So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.

(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)

It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.

NAT doesn't protect you from either of these.

> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.

As I keep trying to explain each time this comes up: no, it doesn't and it won't.

When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.

Of course, this just strengthens your point that NAT isn't security.

That's kind of my point though: it didn't need to be written to expect a v6 upgrade, because the socket API is family-agnostic.

20 years ago, getaddrinfo() was 7 years old. You should have been using it already by then.

I get all of that... but it just sounds like you're arguing that either using RFC1918, or someone's inability to route to your router, is a firewall. Neither of these things are NAT! Nor will either of them protect you from all inbound connections, so neither of them count as firewalls either (although I'll grant that they limit the number of people that could make such a connection).

You can't trust an attacker to politely not send you packets that you think they can't send you. They can run `ip route add 10.5.5.5 dev vpn`/`via <next-hop>` just fine if they happen to be in the right place to do it, and your NAT won't help you.

The reason the packets are being dropped does matter. The issue at hand is all the people thinking that v6 is insecure because NAT is a security barrier; they're wrong, because it's not a security barrier, and if they continue to misattribute their security to it then they're going to keep reaching the wrong conclusions about v6.

> ignore (effectively: drop)

Well, no. They do ignore them, but that's not effectively a drop. It's an ignore. It just means that they don't edit the packet. Whether it gets dropped or not depends completely on the routing and firewalling parts of the router.

People do generally expect a NATing router to firewall inbound connections, but it's important to realize that you won't get that behavior from NAT. You must have a firewall, which is a separate thing.

I'd be tempted to shove that VPN into a network namespace together with jool, and NAT64 their 10.x subnets into, let's say, 2001:db8:a:b::/96, so that their 10.1.2.3 becomes 2001:db8:a:b::10.1.2.3. Then there's no overlap as viewed from outside the namespace.

And if you ever need to use another VPN that also clashes on 10.x, you can do the same thing but map that one into 2001:db8:a:c::/96. Then you've got 2001:db8:a:b::10.1.2.3 and 2001:db8:a:c::10.1.2.3, neither of which clash with either each other or your 10.1.2.3.

It would be easy to make such an extension, but you're going to hit the same problem v6 did: no v4 stacks use your extension.

How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4, so you can't avoid hitting all of the same limits v6 did when it tried to do the same thing. In the end you'll produce something that's exactly as hard to deploy as 6to4 is, but v6 already did 6to4 so you achieved nothing.

Make sure they actually have GUA addresses, not just link-locals.

If you're on a Linux machine, check `ip -c addr show` for an address that's "scope global" and doesn't start with "f". Those are the ones you need. If you have one of those, check `getent ahosts google.com` to see if v6 is being sorted before v4 in DNS lookups, and then `wget google.com` to see if wget prints any errors connecting to the v6 address.

If you have GUA addresses and nothing is outright broken, devices and software that support v6 will prefer it over v6.

I'd expect folks would see the behavior you're describing here as being part of security.

However, NAT in the real world doesn't work the way you're describing here. My position is based on how NAT actually behaves, not on incorrect descriptions of how it behaves.

Or perhaps you could explain how NAT stops inbound connectivity at the NAT edge? I've tested and it doesn't, so I don't think it's possible to explain how it does, but I'm open to being wrong on that if anybody could actually explain it in a way that doesn't contract actual observed behavior.

> How do you get to github?

  $ wget https://github.com/
  Resolving github.com (github.com)... 64:ff9b::8c52:7204, 140.82.114.4
  Connecting to github.com (github.com)|64:ff9b::8c52:7204|:443... connected.
  HTTP request sent, awaiting response... 200 OK

> How do you connect to news.ycombinator.com?

  $ wgetnull 'https://news.ycombinator.com/
  Resolving news.ycombinator.com (news.ycombinator.com)... 2606:7100:1:67::26, 209.216.230.207
  Connecting to news.ycombinator.com (news.ycombinator.com)|2606:7100:1:67::26|:443... connected.
  HTTP request sent, awaiting response... 200 OK

> Why is an IP address more valuable than an IPv6 address?

Because there's such an incredible amount of v6 addresses. You could pay a trillion dollars per second for a /64 and still only pay $1.70/year for each address.

> Why is IPv4 the incumbent 30 years after IPv6?

Because IPv4 was the only choice until IPv6, and replacing the Internet's L3 protocol is hard and takes a long time.

But we do want a v6-only future, right? We don't want to be running both protocols forever, which is what you'd be asking for.

They didn't screw up. They made it a breaking change to OSs because it had to be a breaking change to OSs. If anyone screwed up here, it was the people who made v4, not the ones that made v6.

For ping, I think it originally had different binaries because ICMPv4 and ICMPv6 are different protocols, but Linux has had a dual-stack `ping` binary for a very long time now. You can just use `ping` for either address family.

Google's stats are tracking the percentage of people that reach Google over IPv6. That means they've not just been given addresses, but they configured them and are actively using them. How can that possibly not count as "adoption"?

No, that would be forwards compatibility. v4 doesn't have forwards compatibility with any address protocol that uses addresses bigger than 32 bits, and it never will regardless of how that protocol is designed because the flaw is in v4's design.

There is no possible way to design an address protocol with bigger addresses than v4 that a) makes v4 forward compatible with it, and b) can actually work. Feel free to suggest one.

> .0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits

That prefix is ::ffff:0:0/96. 127.0.0.1 is ::ffff:127.0.0.1 (::ffff:7f00:1). 30 years and you still haven't realized v6 has this?

You don't need NPTv6 to use ULA. Just use both ULA and the dynamic prefix from your ISP. The latter is handled automatically by DHCPv6-PD, and if you're only using it for outbound connections then it changing isn't going to break anything.

I'd say this is actually elegant, compared to NPTv6 which is a kludge and will break things (and isn't well-supported anyway).

They pretty much did. "Just add N bits to v4" is far more work than you're thinking it is, and most of what v6 does is a direct consequence of taking v4 and adding more bits to it.

The amount of work doesn't depend on the number of bits either, so adding fewer bits is a false economy. Deploying a new version of IP is so hard that you only want to be doing it once, not once every time you need an extra few bits.

Dual stack is a natural part of migrating between two protocols, because it's the most compatible way of handling both of them. You don't need to use dual stack to use both v4 and v6, but you'll probably choose to the instant you hit even the most minor incompatibility.

Your L6 code should work perfectly fine if you wrote it properly in the first place. If you pass "localhost" to getaddrinfo() with flags=AI_PASSIVE, it returns a list of socket addresses to listen on, and all you need to do is pass those to socket(). You don't need to look inside the sockaddrs and they might as well be opaque data to you, so it doesn't matter what L3 protocol they represent.

I suspect you forgot to implement a workaround for servers with broken pMTUd. The quickest test for that is probably to run `ip link set mtu 1280 dev eth0` on a client machine and see if it helps.

You'll encounter the same problem on v4, where it's just as difficult to fix as it is on v6. Why single out the latter?

An ASN with a /32 allocation (the smallest for ISPs) is four billion /64s. It takes dozens of yottabytes of traffic to exhaustively scan one single /64. The entire v4 space takes 0.00000001 yottabytes, or about 110 GB/port in more understandable units.

There's a ton of things you can do to cut down on the scan space for v6, but it's still far huger than v4 can be.

No, the side effect of NAT is that outbound connections made from your network look like they come from the router's WAN IP. It doesn't filter incoming traffic.

If it did then you might have a point, but since it doesn't it's very different from a firewall that's configured to do that.