TUN/TAP support

[Pantyhose-X]

Wintun
ligolo-ng
wireguard TUN
Universal TUN/TAP driver
tun2socks
tun2proxy
https://www.kernel.org/doc/html/v6.1/networking/tuntap.html
https://developer.android.com/develop/connectivity/vpn

[orignal]

I2P's address is 32 bytes, can't be used as ipv6

[Pantyhose-X]

I2P's address is 32 bytes, can't be used as ipv6

As I recall, i2p traffic can be routed through an IPv4 proxy.

Set both the HTTP and SSL Proxy to address 127.0.0.1 with port 4444 as shown in the following screenshot.
TUN/TAP address: 127.0.0.1 port 4444

Maybe i2p needs to develop its own network adapters.
win10 network adapters : Enter the I2P 32 bytes address

[agowa]

Technically we could do this even with the 32 bits of IPv4 + DNS. All we'd have to do is resolve the i2p name to some synthetic IPv4 and add the mapping to an internal state table for as long as the TTL we replied with to the original request. The way DNS and caching works will cause the client to re-request "an IP" for the name when needed. And the state table is almost certainly never going to exceed 2^32 simultaneous connections. at least if we keep the TTL low.

However using all 2^32 bits of IPv4 is obviously not a great idea, as we'd occupy the entire address space for our translation. This may work on IPv6-only environments as all 2^32 addresses are "free" there, but may make other applications think they've a native IPv4 connection and try to establish normal IPv4 connections through our translation layer.

Therefore I'd suggest to use a /64 or /56 IPv6-prefix for the translation. I'd suggest to either roll the dice for an entire /48 RFC 4193 "most likely unique" ULA (e.g. the just now freshly generated fdcf:634a:38ab::/48 one from https://www.unique-local-ipv6.com/) or to go "the proper route" by requesting a special-purpose IPv6 allocation within the official registry https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml)

Additionally if we don't use the entire address space, but just a prefix within it we can also rely on routing. E.g. we could advertise a route for that prefix towards a centralized server and transparently proxy the requests. That server would serve authoritative DNS replies for .i2p (e.g. our connection cookie encoded into the IP value). That way all it would take is for either a stub resolver, dns relay, or a "real" dns resolver to forward us the .i2p TLD and honor our TTL value.

I think there is something like this for .onion and tor already out there somewhere.

Edit: It's not a separate project, but part of tor itself. This are the torrc settings for it:

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsSuffixes .onion,.exit
AutomapHostsOnResolve 1
TransPort 192.168.0.1:9040
DNSPort 192.168.0.1:5353