How though? The header format for the 32-bit IPs only has space for 32 bit IPs, so when the 32-bit host wants to connect to a particular 64-bit IP, where would it put that IP? And how would it know how to do it, since it doesn't understand what 64-bit IPs are in the first place?

I get how having a single entry point for external traffic to the internal network is helpful, but not having NAT doesn't suddenly add extra entry points to the network; you still have the exact same network layout with the same router chokepoint that you do with NAT, you just don't have NAT, so I don't see how NAT is helpful here.

If anything it's the opposite, because many people are mistaken about how NAT works in ways that compromise security. You don't have to look further than the comments on this article to find people who think that NAT will stop an inbound connection, and if you think NAT does that then you're liable to configure your network insecurely without realizing.

Hm, I suppose with dual-stack the 32-bit IPs continue to stay behind NAT until they don't need to reach other 32-bit IPs any more, rather than immediately dropping them after they get the upgraded stack. Okay, fair enough.

Perhaps you could explain how your "obvious workaround" works then? Because "32-bit IPs stay behind NAT" doesn't let those 32-bit IPs reach your 64-bit IPs, so I don't see how it works around the problem of 32-bit IPs not being able to send packets to 64-bit IPs.

That's basically dual stack, which is the approach v6 is already taking. One obvious limitation with it is that these hosts won't be able to reach the new addresses.

Maybe don't call the people behind v6 shitty engineers with arrogant asses when your own suggestion is the same thing they did.

Who are these "purists" you keep going on about?

Anyway... you can give the printer a ULA address and use that to print with. Pair that with advertising a GUA prefix on the network and you don't need any NAT at all. There's no need to give ULAs to the other machines on the network, because they can connect using their GUAs as a source address.

192.168.68.61 is routable though. If I try to ping it, my computer sends the ping packet to my router, which forwards it to its default route, which shows that it's routable.

How did you get that IP? Because I don't think that's the IP of your router, which I think is at 2405:9800:b520:900c:6620:e1ff:fe25:e7b. It does seem to be blocking connections (or at least pings), but that'll be your firewall doing the blocking, not NAT.

That's not what NAT means. NAT means that outbound connections from your network have their source addresses rewritten to appear to come from your router. What you're describing here is just normal routing.

That's not how routes work. Routes exist regardless of where a connection was established from. An unsolicited connection from outside your network can be routed onto your network; again, that's just normal routing. It's common for such connections to be blocked by a firewall, but NAT won't block them, because that's not a thing NAT does.

Sure they do: they have the addresses they use to make connections out to the Internet. Computers upstream of your router can use those addresses to make an inbound connection too, so long as they can get an IP packet with those IPs in the destination field to your router.

Yes you can, that's trivial to do.

It doesn't make any sense to say that internal IPs are designed to be unroutable; in fact the opposite is the case. The Internet wouldn't work if the IP ranges that people used on their networks were unroutable, because the Internet is designed around routing.

No, not necessarily. A connection might come in with the IP of a machine on the LAN (or indeed with any IP at all). NAT won't stop that from happening, and neither will it cause the router to somehow forget how to route packets. If you do get a connection like that, and you don't have a firewall to block it, it's not going to get dropped.

They're not bandaids, they're the backwards compatibility that you're talking about. How were you expecting it to work?

You don't need to use NAT to avoid changing the IP of your printer, so that doesn't make any sense.

NAT doesn't actually prevent that. NAT just rewrites the addresses on your outbound connections, it doesn't affect your routes at all.

I figure that if grandma has enough experience with iptables to get NAT working, she can get a firewall working. Home routers do generally have firewalls by default, especially when it's already required in v4 anyway if you want to make sure nobody can connect into your network.

Saying "assume the extra octets are zeros" is a sign that you aren't familiar with the problem domain and haven't thought your suggestion through at all. Doing that isn't useful.

Routers can already tell if someone is using v6 or v4, by looking at the version header (or the L2 next-protocol header), and existing v4 stuff already continues to work.

Between dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6 and probably other methods that I'm forgetting right now, it's really hard to argue there was "little" effort made towards backwards compatibility. You've got a choice of pretty much every method of backwards compatibility that can work with v4, so it looks more like a lot of effort has been put into it.

The main transition plan is to go via dual stack, which isn't "completely fucked" but rather works fine and is probably the simplest and most compatible approach.

1. I don't think it's a pricing decision, more of a business continuity issue. If they can't move their customers away from v4 then AWS will hit a limit on its growth, because there aren't infinite v4 addresses around for AWS to use. They can't keep buying them on the open market because the price will just spiral up and up until AWS starts to cost them money rather than earn money. They'd eventually have to turn away clients, which isn't a good place to be in.

2. DNS. You shouldn't be remembering IPs in the first place.

3. They changed barely anything. If you know how v4 works then you already know 80-90% of how v6 works. They also made it pretty much as backwards compatible as it's possible to be with v4; there's so many backwards compatibility methods available that you could make a reasonable argument that there's too many of them, even.