NAT46 support request

[bjtftw]

How about adding support for NAT46 IP conversion directly to i2pd?

Right now I have moved to another ISP (LTE) which operates IPv6 single-stack network with 464xlat mechanism for IPv4 traffic, the problem is my Android 5.x phone (which acts as a WIFI AP for my entire home network) do support 464xlat and works great but have some issue with it and after 6 hours of working perfect this mechanism (probably clatd Android process) completely hangs (stops responding to any network requests), so I loss any IPv4 connectivity still having IPv4 addresses assigned to all the interfaces on my LAN machines and this means that this fault isn't easily visible to all the programs because they still try to use IPv4 connectivity as there are IPv4 addresses and default IPv4 route on the system and simply waits for connection timeout as they don't have any info that IPv4 connectivity is simply lost and shouldn't be used anymore.

This is why I have disabled IPv4 on my LAN machines completely and am using IPv6 only + DNS64 and it works great except for software like i2pd which doesn't use hostnames but uses direct IPs calls to make connections and in this case having NAT46 translation mechanism built into i2pd would help to get connectivity to IPv4 hosts by converting their IPv4 addresses to the form of NAT46PREFIX::IPv:4HEX internally.

As NAT46 is stateless it doesn't require too much code to be written it's just a conversion from IPv4 to NAT46 IPv6.

It would make sense to add additional config options to i2pd.conf like:
nat46 = 1
nat46prefix = 64:ff9b::/96
so it would be possible to enable or disable this functionality and probably it would make sense to have it disabled by default.

General logic would be simple, if nat46=1 then we simply ignore all the IPv4 related system settings and don't even try to use IPv4 stack at all (even if we have interfaces with IPv4 addresses on them and default IPv4 gateway in the system) but we convert any IPv4 address to the form NAT46PREFIX::IPv:4HEX and use that instead.

[orignal]

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

[bjtftw]

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.

[agowa]

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