There is no need to move your whole private network over to IPv6, although it might provide a good learning opportunity. You could start with enabling IPv6 for your nginx reverse proxy and make it listen on its IPv6 address. IPv6 has subnets too and firewalling is still possible, only NAT isn't needed anymore (which is good).

Edit: Reading your post again it sounds like you have mental model of either IPv4 or IPv6, when in practice it is often mixed. Each client can have an IPv4 and IPv6 address - even multiple ones! When you enable IPv6 on your router it gets a subnet from your provider and announces the prefix on your network. The clients then generate their public IPv6 address based on this announcement. Note: Even though they now have a public IPv6 address, the router's firewall should block incoming connections to it by default. That's the case for my router, but to be sure you should check it yourself for yours.

Yes it confuses me very much. If I were to get an ipv4 and and ipv6 to the internet but my internal network stays ipv4, then the ipv6 networking would never get used anyway and I might as well disable it, correct?

Now if I also let internal devices get both a v4 and a v6, they essentially all become directly exposed to the internet through v6 don’t they? That’s the part that really confuses me. And if they aren’t publicly accessible from the internet then I’m back to v4 NAT where I was all along which kinda makes v6 pointless doesn’t it?

> If I were to get an ipv4 and and ipv6 to the internet but my internal network stays ipv4, then the ipv6 networking would never get used anyway and I might as well disable it, correct?

If you enable IPv6 on your router it will likely advertise an IPv6 prefix on your internal network, which in turn will lead to your clients getting IPv6 addresses - unless you disable IPv6 on their interfaces. Clients will then make use of IPv6 to connect to any service that has an IPv6 address, as they prioritize IPv6 higher than IPv4.

> Now if I also let internal devices get both a v4 and a v6, they essentially all become directly exposed to the internet through v6 don’t they? That’s the part that really confuses me.

They won't become directly exposed - the router's firewall should block incoming IPv6 traffic by default. This is the case for my router and should also be the case for others. To be 100% sure you could do a quick check and try to ping your device from the internet using its IPv6 address. You will likely see a message saying: "Destination unreachable: Administratively prohibited" or get a timeout.

> And if they aren’t publicly accessible from the internet then I’m back to v4 NAT where I was all along which kinda makes v6 pointless doesn’t it?

You can open ports in the router's firewall for IPv6 addresses. However, the main advantage for you would be that your clients can access public IPv6 addresses - which they currently can't. This might not be a big deal yet, but as IPv6 slowly gains some traction it will be noticeable in the future. Some hosters already charge extra for IPv4 addresses.

>they essentially all become directly exposed to the internet through v6 don’t they?

Most consumer routers have a stateful firewall [0] for IPv6 that basically behaves like NAT. But it's less of a problem than on IPv4 anyway. It's possible to scan the whole IPv4 Internet in less than 5 minutes. [1] And this is done constantly by many people. The IPv6 address space is way to big to do this and you have to harvest addresses. [2] It's always a good idea to have a firewall but unlike IPv4 you don't get port and vulnerability scans seconds after you expose a host to the internet.

>which kinda makes v6 pointless doesn’t it?

IPv6 is mostly useful for ISPs. There are just not enough IPv4 addresses for everyone.

[0] https://en.wikipedia.org/wiki/Stateful_firewall [1] https://en.wikipedia.org/wiki/ZMap_(software) [2] https://isc.sans.edu/diary/Targeted+IPv6+Scans+Using+pool.nt...

>Even though they now have a public IPv6 address, the router's firewall should block incoming connections to it by default. That's the case for my router, but to be sure you should check it yourself for yours

This is why I won't enable IPv6 unless ISPs dramatically change how their hardware works. My ISP-issued modem+router doesn't even have a way to disable routing or automatic updates. I can test the firewall today, but what guarantee is there it'll just keep working?

The comment you're replying to is referring to Homeland. If all you have is an ISP-issued device, then you don't need to worry about it, just use the defaults.

Also, I doubt ISPs will ever change their home routers to default to IPv6 because of the complexity it'll add to customer support with no extra benefits.

Routers don't "default" to one protocol or the other. They do both v4 and v6, and end devices pick which to use for each connection.

It's not the router that decides which IP version to use but the operating system and AFAIK all default to IPv6 if they have an address. And yes many ISPs have activated IPv6 by default that's the reason we see 80% IPv6 usage here. It's not because 80% of the users have actively activated it. Most of them have no idea what an IP even is.

What is Homeland? I explicitly disable IPv6 because I don't trust the firewall, specially on an auto-updating device.

Is there a specific reason you trust your router for IPv4 but not for IPv6 traffic? IPv6 privacy extensions should be enabled by default on most devices. So even in the unlikely case of a device being exposed, someone has to know the temporary IPv6 address and then try to access it while it is still in use. This device would also have to run a vulnerable service on some port that the attacker has to know. All in all, I think that this is a pretty unlikely scenario.

"Most devices", "should be, "unlikely case", "pretty unlikely". That's my impression too, and none of those are good enough. I have many internet connected devices (appliances) and really don't want to worry about someone remotely accessing them. Behind the NAT it just isn't possible.

> Behind the NAT it just isn't possible.

It could be with UPnP, which as a security conscious person you likely have disabled. Do you trust it staying disabled or none of your many devices trying to use it to poke holes in the NAT?

Even if you have to use your ISPs modem/router device, it might have a bridge mode where it just becomes a modem, enabling you to use your own router. It might be worth checking this option if you didn't already.

It is possible -- NAT won't protect you from inbound connections. Even using RFC1918 addresses on your LAN won't protect you from all inbound connections. You need a firewall for that.

If you don't trust the ISP device to firewall, then you can't trust it even for v4. You need to run your own router.

> I understand why v6 is necessary for the internet but I can’t reconcile it with my home network.

Your home network is part of the Internet, by definition. There is no difference between one part and another.

It’s useful for certain corporations to try to crush the end-to-end principle but there is no benefit in going along with their plans.

Here's the dumb naive question of the day:

Why didn't "ipv6" simply get implemented as:

"Well, our ipv4 addresses of 4x8bit, well, we'll just switch those to 4x64bit or whatever."

Then it becomes like a gradual y2k migration. Old servers could be addressed by the new ones, and if the old ones didn't want to address the new ones, well, that was their problem. You didn't need new infra, addresses, etc, you simply upgraded the software.

Or, using NAT, the 4x64s would provide some NAT port with an 4x8bit address to respond with. As the internet switched over to 4x64 in the DNS and freed up 4x8bit addresses, they could be dedicated to the translation.

I know the ship sailed long ago, but what am I missing here? Can this still be done with some "IPv8" movement where everyone gets fed up with IPv6 hassle, and also just wrap in ipv6 addresses somehow? Why didn't the original group simply expand the size of the numbers in the address quads?

Yeah the current holders of IPV4 ranges would have gotten large segments of address space, but if there are 4x64bit, that's still several universes of per-atom addressing.

As for India, it's unsurprising a nation with a billion people and on the outside looking in of ip address governance is more gung-ho about ipv6 adoption. Plus, India is probably mostly mobile phones in terms of computing, and ipv6 was the basis of mobile phone internet infrastructure from the ground up.

This is actually one of the most interesting parts of the Urbit project IMO -- their addressing scheme has 8, 16, 32, 64, 128 address support. The addresses are displayed in memorable terms that fit into an astromoical-styled system.

A /8, an example being "~rel" (one syllable names based out of a bank of 256 memorable 3-letter syllables)-- these are galaxies and are extremely rare (128 galaxies total). Then you have /16 stars which are like "~tabrel", combining two of these syllables -- their are 64,000 stars. And then finally, you have /32 planets like "~sampel-tabrel", which are 4b illion and enough to be valuable and stop spam, but are somewhat disposable kind of like a phone number.

Each one of those planets can spawn billions of /64 moons (sampel-tabrel^dambel-gabnel) which can be used for IoT or family members.This naming scheme draws a good delineation has both human understandable names and memorable addresses you can use for a lifetime -- as well as tremendous scalability to support routing between trillions of addresses.

https://urbit.org/blog/value-of-address-space-pt2

I had no idea about urbit. Thanks for sharing.

> Why didn't the original group simply expand the size of the numbers in the address quads?

Almost all fields in IP header have fixed size - so it doesn't really matter that you just change address size - it is already a new and incompatible protocol.

And adoption of IPv6 wasn’t so slow due to its design or any technical properties. Simply no one wanted to do additional work as long as supporting only IPv4 worked fine.

But IPV6 always had an "Internet2" vibe to it between dual stacks, different syntax/separator, hostility towards NAT firewalls. Like they wanted to be completely separate and force everyone to move to them. And this is back in the day when another stack meant another hunk of infrastructure, probably new switches, etc, not just a bunch of VMs allocated via API in IaaS.

As in they didn't even seem to consider that maybe you adapt the existing IPV4 code to some form that can handle both protocols. It seemed like they wanted to force total software rewrites and hardware purchases all over the stack.

I mean look, one if-then to identify the packet type is not that bad. Or simply have the ipv4 as the first part and the wrapped packet has another 128-256 addressing bytes.

No such thing as a "NAT firewall"... and v6 was designed this way because nothing else really works.

Almost all existing code that was written to handle v4 was written to handle addresses of exactly 32 bits, not addresses of arbitrary length. Longer addresses therefore required writing new code to handle them. v6 is close enough to v4 that you can write code that can handle both families, but neither the existing code or the new code was under the control of the people designing v6.

You use dual stack because it's maximally compatible with existing devices and code. There are plenty of ways to run single-stack v6 if you want to, but they all have some compatibility issue or another (and the compatibility issues stem from the way v4 was designed, not the way v6 was designed).

v6 addresses use : rather than . because they could otherwise be confused with DNS. For example, a string ending in ".be" could have been a v6 address or a subdomain of the .be ccTLD.

IP packets do start out with a version field, so your "one if-then to identify the packet type" requirement is exactly what v6 already does.

> Or simply have the ipv4 as the first part and the wrapped packet has another 128-256 addressing bytes.

You've invented 6to4. It already exists, but people seem to prefer native.