[JohnFen]

> Why is it so painful for you?

Mostly because of the number of machines that I have to fix up and the fact that updating each of them involves a fair bit of time. My estimation is I'm looking at at least a week's worth of work, during which my network isn't fully functioning.

It's also complicated by the number of devices I have that aren't possible to make work with IPv6 at all, which means I have to maintain some IPv4 segment and deal with making the two work together in a seamless way.

I'm also very concerned about security. I'm not confident that I know enough about how to secure an IPv6 network adequately, so I need to set aside a fair bit of time for study before I even start.

All in all, it's a large project with a lot of friction that wouldn't be as large if I didn't have to rethink everything.

[bauruine]

Going IPv6 only is a pain for sure but why not do dual stack and upgrade one by one and get comfortable with it first?

[JohnFen]

I could, sure, although if I'm going to do that, I may as well just put an IPv6 translation layer at my router level and keep everything internally at IPv4. Which I'm seriously considering doing as the path of least resistance, particularly since there are no special IPv6 features that I really want or need.

But the last time I mentioned half-measures here on HN, I got dumped on pretty harshly.

[bauruine]

I don't think that exists and I can't imagine how a IPv6 translation layer with internally IPv4 addresses should work. What exactly do you want to do?

[WorldMaker]

Some NAT46 (not to be confused with NAT64) tools and routers exist in the wild today. "Stateless" ones work by manually setting routes for chosen IPv4 addresses to IPv6 ones or treating all of IPv4 traffic as the "ultimate" semi-private IPv6 "subnet" and prepend a fixed IPv6 prefix to all IPv4 traffic (and you can do that with just about any IPv6 /64). Stateful ones act a lot like NAT44 routers and can also use "out-of-bound" protocols similar to NAT44's UPnP (but I think distinct from?) to setup routes on the fly from application requests.

Though they exist, my understanding is that the need and use cases for them is overall much weaker than NAT64 or NAT44.

[JohnFen]

If the internet destinations I want to reach have an IPv4 address, it's obviously very easy. It's just a kind of NAT. And everywhere I want to reach has IPv4 addresses and probably will for a long time.

If they're IPv6 and I really need to reach them anyway, then I could imagine writing a special NAT that keeps a database equating IPv4 addresses (that I make up) with real IPv6 addresses on the net and doing a NAT that way. That would be suboptimal because it would mean that I'd need to add a database entry in advance for each internet destination, of course. But it seems feasible. And I can think of a couple of ways to automate it.

But, honestly, I don't know. I'm just spitballing what the best way of handling all of this actually is. Every method I have heard or can think of has some serious downside, and I don't have sufficient expertise (and haven't spent the time) to do actual cost/benefit analyses of the various options yet.

This is all a huge time-consuming hassle, and is why I'm putting the whole thing off until I have no other option.