NAT46 support request about i2pd HOT 3 OPEN

We exclude it here
https://github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/util.cpp#L668
I think even we use it, we shouldn't publish such addresses

from i2pd.

Yes, you definitely want to block publishing 64:ff9b::/96 IPs in router info as they are routable only within ISP network with NAT64 functionality but these addresses are still legit to use within IPv6 NAT64 network and shouldn't be abandoned completely as this is proper way of handling IPv4 traffic in IPv6 only networks with NAT64 functionality.

What I'm proposing is to add i2pd functionality that generates such IPv6 addresses for IPv4 only peers when on IPv6 only network with NAT64 support (which may be hard to autodetect so manual setting in i2pd.conf is the easiest way, the user should know if it needs it nat46 = true).

The only thing i2pd code have to do is to generate this 'fake' IPv6 address for every "IPv4 only" peer (only when nat46 = true is set by user as most users don't need this!) and use it for making connections.

Generation in reality means just adding NAT64PREFIX to the IPv4 address of peer like 1.2.3.4 -> 64:ff9b::1.2.3.4 or even better with HEX representation of IPv4 -> 64:ff9b::102:304 and using this to make connection, this way IPv6 only host can connect to IPv4 only peer.

That's all the story. We are fooling i2pd that IPv4 only host do have IPv6 address so i2pd can use it to make connection. Such a 64:ff9b::/96 address should be treated as normal IPv6 by i2pd only it's publishing should be avoided. The other part of translating it back to IPv4 and create connection to this IPv4 is on the NAT64 gateway side but i2pd don't need to worry about at all as it transparent.

from i2pd.

Technically NAT64 could be (and once implemented preferably should default to) auto detecting. All it takes is a AAAA lookup for ipv4only.arpa. Being able to explicitly provide NAT64 settings could allow for traffic engineering but probably wouldn't be the common/expected case.

Also don't forget about the reverse NAT46 (technically also "just" NAT64, but different usage) which is often used within data centers to provide "IPv4aaS", I.E. to NAT IPv4 INBOUND traffic towards a specific IPv6 address (and sometimes with multiple layers of routing and maybe even WAN in between it and the server that binds it) often with a custom (sub-netted) prefix (I.E. it will be out of either a GUA or a ULA address depending on environment). For all i2pd cares about it would have to support multi homing on IPv6, as all IPv4 connections will appear as if they're from IPv6 endpoints on that "special address" (ok, technically it's just another normal IPv6 address to us, most of the lifting is in the translation happening elsewhere).
A good way to think off this is using source routing, one of the IPv6 addresses on the interface on the server will be source routed through the infrastructure towards a NAT64/NAT46 gateway that holds the associated public IPv4 and does the translation (most common is 1:1 or with specific ports, where the port is often also encoded within the IPv6 address).
(This is basically also similar to CGNATs with port-forwarding support [see e.g. RFC6888, RFC7599, and RFC7597], just without the 2nd layer of translation to keep the internal network IPv6-only)

DNS response for ipv4only.arpa

without NAT64

Server:         ::1
Address:        [::1]:53

Name:   ipv4only.arpa
Address: 192.0.0.171
Name:   ipv4only.arpa
Address: 192.0.0.170

with NAT64

Server:         ::1
Address:        [::1]:53

Name:   ipv4only.arpa
Address: 192.0.0.171
Name:   ipv4only.arpa
Address: 192.0.0.170

Name:   ipv4only.arpa
Address: 64:ff9b::c000:aa
Name:   ipv4only.arpa
Address: 64:ff9b::c000:ab

from i2pd.