[zamadatix]

The nice thing about NAT64 is you only NAT when you're talking to a v4 only client, otherwise you still have pure v6. This leaves no hacks to remove for a pure IPv6 experience it just means you can have single stacked IPv6 devices instead of needing to dual stack or wait for the entire rest of the world to also configure IPv6 too.

I.e. it allows you to push IPv4 to your internet edge only in a way that doesn't downgrade anything about actual IPv6 capable connections. For a single server that probably does seem pretty silly but once you have multiple it can make more sense.

[JohnFen]

When the day comes that I have to shift to IPv6, I think I still want to NAT, though. I could be (and probably am) misunderstanding things, but I don't see how I can eliminate my need for it.

What I want it for is so that I can have services exposed through my domain name, but operated on different internal servers.

[Dagger2]

What you're asking for here is port forwards/DNAT, i.e. applying NAT to redirect an inbound connection. When people say "NAT", they're usually talking about SNAT/MASQUERADE, i.e. NATing outbound connections.

If you want to NAT inbound connections, you can do it without NATing outbound connections. Essentially: you don't need to NAT, you just need to port forward.

Honestly, I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running -- it only takes scanning 65k ports on one IP to find them all, rather than 65k ports on 2^64 IPs. That's the difference between megabytes and yottabytes of port scan traffic.

If you NATed outbound connections to also come from this IP then things get even worse because every outbound connection any of your machines make would immediately inform the server of the IP needed to make an inbound connection to you. That's a completely unnecessary security sacrifice.

But if you're gonna do it, you can do just that, without trying to run the network on some local IP range too.

[zamadatix]

It's not uncommon to load-balance or NAT over fe80:: link-local addresses for internal service delivery for your use case. Some services are nicer, allowing DNS SRV records or the like, but many require the middle-man.

Some ask "why bother with IPv6 if I'm still going to do that then?" and generally the two key advantages are the fe80:: address co-exists with the unique public address of each box so you don't need outbound masquerade NAT pools and the fe80:: address space is enormous+interface specific so you don't have to worry about unique internal space or conflicts with other networks. Or, if you have a static IPv6 assignment in a more "proper" hosted deployment instead of a dynamic home deployment, you can of course just do stateless NAT to the public addresses without worrying about IP scarcity.

[bauruine]

There are some services that have a different resource record in DNS like email (MX) or use SRV records like XMPP but else yes you are forced to either use a different hostname (like www. and ftp. and mail.) or do it port based with NAT like you used to.

[WorldMaker]

At that point you just use a much simpler reverse proxy, I think? NATs have to be stateful to operate, but in IPv6 you can do a lot with simpler stateless reverse proxies.

[zamadatix]

NATs in this inbound scenario are most often stateless 1:1 static mappings of the port.

[JohnFen]

For several services, you're probably right. But not all of them. I think.