This is entirely legitimate. IPv6 is actively confusing in what "enabling" means - is there a firewall, and under what conditions are ports opened? Is there mandatory use of privacy addresses from clients, and is there any protection from clients who generate SLAAC addresses from their MAC address? Is there a NAT? (NAT66 is a thing, but very few people implement it.) The mental model of IPv4 NAT is much more straightforward and I would strongly recommend that home users prefer that.

I'm not sure what routers you've used or seen but every home router I've touched in the last 5 to 10 years has had the option to enable IPv6 in its settings.

Also, IPv6 has a unique address that everybody can reach but most if not all routers have an IPv6 firewall that gives at least if not more security than NAT provides.

> IPv6 firewall that gives at least if not more security than NAT provides

That's just not true. NAT and firewall both achieve what little security they provide through simple blocking of packets based on state information. Firewalls generally provide more robust state information, but NAT is what lets you redirect sockets. They work together.

Except NAT gives no security, because NAT doesn't block packets.

If a packet comes in that doesn't match any NAT state, then the packet isn't dropped on the floor -- it's processed as normal like any other packet would be, and in the absence of a firewall (which is logically separate, even if often implemented in the same software stack) it'll be routed to whatever the destination in the packet header is.

"If a packet comes in that doesn't match any NAT state, then the packet isn't dropped on the floor"

Yes it is, it's the same scenario as if there was no route to the destination just at a higher abstraction layer. Think about it this way: a packet just hit the NAT IP from the internet, the packet has hit it's destination. There was no NAT table match for the packet so it was not rewritten. Where would the packet be forwarded to if not the bit bucket?

It's not the same scenario at all. If there's no route to the destination then the packet will necessarily be dropped, but with no matching NAT state table entry for a packet all that happens is that the dst header field is left alone.

There will still be an IP in the dst header field! The router will still deliver the packet to that IP, subject to all the usual constraints (e.g. it needs a valid route etc). NAT won't stop that; only a firewall will.

The destination IP will be for the router itself, so the router can either re-deliver the packet to itself or drop it.

I don't see how NAT isn't an effective inbound firewall by itself in the normal case where it's in front of local non-internet-routable IP addresses.

It won't necessarily be for the router. The packet could be addressed to one of the machines on your LAN, in which case nothing NAT does will stop the router from happily forwarding it right through.

NAT does nothing to stop a router from forwarding any given packet -- and that's something that's still true regardless of what IP range you're using on the LAN side.

And in practice what that means is that the router's own IP is the destination and the packet ends up at a closed port.

Unless of course you're talking about using NAT outside the context of the RFC1918/internet boundary, in which case you're absolutely right, but that wasn't what was being discussed.

Isn't it? I thought we were talking about NAT, not about RFC1918.

Even NAT in combination with RFC1918 doesn't give you security. The use of RFC1918 would certainly limit the set of people that could connect to your LAN machines, but it would be hard to call the result secure since anybody sharing your upstream L2 network, plus your ISP and anyone who can trick, force or coerce them into cooperating could still access your network.

And what does NAT add to the situation? Certainly not any security, since any connections that were possible before you added the NAT will still be possible afterwards too. In fact a lot more connections will become possible, so it seems like it reduces the security rather than improves it.

> call the result secure since anybody sharing your upstream L2 network, plus your ISP and anyone who can trick, force or coerce them into cooperating could still access your network

Ok, so the L2 thing isn't unheard of, but otherwise these are relatively unrealistic scenarios to be concerned about, don't you think?

I guess, but the fact remains that using RFC1918 is still both more effort and less secure than just using a firewall is, and that NAT doesn't help the situation.

Do you really want the security of your network to rely on your ISP always doing the right thing for you?

Terminology shifted, when NAT is talked about it is generally considered to be MASQ NAT to RFC1918 ranges

Even then, that would still only put you into the situation in the second paragraph of my previous post. You would still need a firewall, and if you have a firewall then shifting to RFC1918, adding MASQ NAT or even doing both won't help, because inbound connections are already blocked.

Windows uses ipv6 temporary addresses by default. NAT isnt security, and lot of implementations are faulty, so dont depend on it for security.

NAT absolutely is security. It prevents naming a resource that an attacker shouldn't have access to, which is the fundamental principle behind many successful security schemes: capability models, containers / virtualization, MMUs, etc.

Sure, there are implementation flaws (as there have been in other such schemes), and sure, just clicking a NAT button and walking away doesn't get you security any more than just clicking a capability or virtualize or MMU button gets you security. But it's a powerful and solid building block, and the Internet is a better and safer place because of widespread use of NAT.

It doesn't actually do that though. If you give a machine an IP of X, and then you turn on NAT on the upstream router so that its outbound connections appear to come from Y instead, the machine is still called X.

NAT won't prevent someone from sending a packet to X, and it won't cause the router to somehow drop the packet when it sees it either. That stuff is handled by firewalls, not by NAT.

On Linux at least, NAT isn't handled by routing, it's handled by a separate layer (the firewall layer, in fact). I think that's the obvious way of implementing NAT: you're not routing at all. On the public side you're not accepting any packets not addressed to you. On the private side you're converting all packets, so you're not doing normal packet forwarding.

When packets arrive on the public side, you have to translate addresses sent to the router to convert Y to X, so you might as well drop packets that aren't sent to a valid target. I'd expect you have to go out of your way to get NAT "wrong," possibly by trying to stuff the functionality on top of actual routing. Home routers generally don't need to do actual routing ever (and if they do, they're in a non-NAT mode) so it would be surprising for them to get this wrong.

It's handled by a separate layer, yes, but that doesn't mean that the routing layer magically disappears. It's still there, and in fact it's still required to forward every single packet that goes through the router. NAT is just simply an extra layer on top that sometimes changes the addresses in the src or dst fields of some packets.

Dropping packets not sent to a valid target is called firewalling. NAT doesn't decide what's valid and what isn't; all it does is detect packets which correlate to known connections and rewrite some of the headers on those packets.

Home routers, like all routers, do a lot of routing. They sit between two networks and they forward packets between them, which is pretty much the definition of a router. Having some header rewriting going on doesn't change that.

IPv6 allows for so many IP addresses that you could give yourself a new IP address every minute and never worry about running out.

You could, but does your device actually do so? Are you confident that 100% of the devices you own use privacy addresses and do not leak non-privacy addresses?

The nice thing about IPv4 NAT is that you plug a single gadget in to your ISP's connection (cable modem, ONT, whatever), you connect your devices to that gadget, and it works out of the box and has all the security properties you'd expect, even if you're a person who hasn't ever thought about security properties and doesn't know what IP is and is still running Windows XP because your word processor still works fine. It might be unclean, but the benefits of this model are immense.

> Are you confident that 100% of the devices you own use privacy addresses and do not leak non-privacy addresses?

I've heard stories, but I've never seen a modern operating system without privacy extensions in the wild. Maybe XP, but did XP have IPv6 enabled by default? As far as I know it didn't.

Most operating systems default to using Privacy Extensions which will cycle your address at frequent intervals, unless you specifically disable it.

One problem with IPv4 is that each interface can only have one IP. With IPv6 an interface can have many! For example both a private and a public IP address!

?? multiple IPv4 addresses work fine... ip addr add 192.0.2.2 dev eth0

It's true that IPv6 requires IP stacks to support this, but nothing in IPv4 prevents IP stacks from supporting it.

Every time I see a conversation about IPv6, this argument comes up. Is "it's got a gorillion IP addresses" the only redeemable quality IPv6 has?

It's less a redeeming quality and more the entire reason why we bothered to switch to a new system. So yes, that is the point.

I don't think its helpful to discredit all the other technical advantages of v6. Address assignment and configuration is significantly better under SLAAC than DHCP, multicasting actually makes sense, and routing logic and packet format are simplified.

If you were to try implementing a router for ipv4 and v6 the v6 one would be dramatically simplier with a lot fewer convoluted edge cases.

I actually specifically do regard (most of) v6's additional features as a bug; I think most of them could and therefore should have been implemented as separate protocols (consider ipsec, which actually did get pulled out and back ported to 4). I think the protocol we ended up with suffers from horrible second system effect and its scope creep it's part of the reason why it's taken decades to get mass adoption.

Then, given that CG-NAT solutions have proven to work well and they don't bother most end users, it's no wonder the transition to IPv6 has stopped.

For ISPs (and mobile carriers) that are actively involved in their infrastructure, CG-NAT is more expensive to run than native ipv6 (aquiring IPv4 public addresses; tracking connection states; if all customers are on private IPv4, maintaining multiple distinct private networks with the same address space is a hassle too), so those ISPs are pushing to make services available over IPv6 (I've heard from T-Mobile USA and Jio India), but that doesn't mean they won't also run CG-NAT for customers on older devices and for services that aren't IPv6 -- it just reduces the deployment. For smaller ISPs, or where everything is contracted out, the cost savings aren't as apparent.

> it's no wonder the transition to IPv6 has stopped

Where are you getting that from? Looking at public IPv6 statistics from big companies shows that it's going up. Google's shows a 4.5% increase in IPv6 of total traffic during the past year[0]. Facebook's shows a 6% increase and at 55% for the US [1]. Meanwhile Mexico went from 5% IPv6 to 25% this year [2].

[0]: https://www.google.com/intl/en/ipv6/statistics.html [1]: https://www.facebook.com/ipv6/?tab=ipv6 [2]: https://www.vyncke.org/ipv6status/project.php?metric=p&timef...

These statistics are meaningless propaganda. What you should be interested in is the velocity of IPv6 adoption growth among ISPs and countries where adoption stopped all together, to know what to expect from actual adoption in coming years. (it's basically a failure btw)

> What you should be interested in is the velocity of IPv6 adoption growth among ISPs and countries where adoption stopped all together, to know what to expect from actual adoption in coming years. (it's basically a failure btw)

I don't understand. Are you telling me to look at how IPv6 adoption is among countries, where IPv6 usage growth has stopped? Are there any such countries? Furthermore, I'm not sure what you mean by "actual adoption". Every statistic I look at, as referenced in my previous comment, I see IPv6 usage continuing to grow. And you're calling that "propaganda"?