I had a similar proposal a couple of years ago, which is almost the same as this one, with one notable difference.

Instead of communicating the IP through the proxy protocol, I had envisioned the IPv4 address could be encoded in the IPv6 source address form the proxy; you’d simply have to give the proxy a /96 for itself.

But before I was able to implement it, someone else already did it better than I ever could, although they used the PROXY protocol, like in this article; sniproxy by dlundquist does everything this article mentions, and I’ve been running it in front of multiple projects myself.

Although when I looked at the Github issues back then, it seemed that this project was a lot more popular for setting up Netflix proxies than it was for the purpose in this article.

Congrats on submitting the (by my count) 9th Lobsters article that mentions IPv6 in the title! A real tragedy that so few devs are interested in this stuff.

Wouldn’t SIIT serve this purpose better? My router doesn’t support SIIT so I may be misunderstanding it, but I believe your router would do the translation at Layer 3. Then you could do SNI or “Host” header routing like normal in some other proxy like nginx inside your IPv6-only network. The IPv4 source IP would be visible in logs and can be blocked with normal tools since it just appears as a padded IPv6 IP.

For the HardenedBSD build infrastructure, which I host out of my home behind a single IPv4 address and tunneled IPv6 (with HE’s TunnelBroker service), I use nginx as a web reverse proxy. Below is a sanitized version of the nginx configuration.

All hostname-related records in the hardenedbsd.lan domain have ONLY an IPv6 AAAA record. No A records exist for *.hardenedbsd.lan.

Here’s the nginx.conf file:

worker_processes  8;

events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    keepalive_timeout  65;

    upstream gitlab {
	    server gitlab.hardenedbsd.lan:443;
    }

    upstream hbsd-os-build-01 {
	    server hbsd-os-build-01.hardenedbsd.lan:443;
    }

    upstream hbsd-pkg-13-stable-01 {
	    server hbsd-pkg-13-stable-01.hardenedbsd.lan:443;
    }

    upstream hbsd-pkg-current-01 {
	    server hbsd-pkg-current.hardenedbsd.lan:443;
    }

    ssl_certificate [redacted];
    ssl_certificate_key [redacted];
	server_names_hash_bucket_size 128;

    server {
        listen       80;
	listen [::]:80;
        server_name 
		git.hardenedbsd.org
		dacxzjk3kq5mmepbdd3ai2ifynlzxsnpl2cnkfhridqfywihrfftapid.onion;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
			proxy_pass https://gitlab;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
        }
    }

	server {
		listen 80;
		listen [::]:80;
		server_name
			rsync.hardenedbsd.org
			installers.hardenedbsd.org
			qspcqclhifj3tcpojsbwoxgwanlo2wakti2ia4wozxjcldkxmw2yj3yd.onion;

		location / {
			proxy_pass https://hbsd-os-build-01;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
		}
	}

	server {
		listen 80;
		listen [::]:80;
		server_name
			x4tlazkltc5ttgk6friorlmlgqx4kopaqsom4hhw5blrmww7sszk2vad.onion;

		location / {
			proxy_pass https://hbsd-pkg-13-stable-01;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
		}
	}

	server {
		listen 80;
		listen [::]:80;
		server_name
			hbsd-pkg-current-01.hardenedbsd.org;

		location / {
			proxy_pass https://hbsd-pkg-current-01;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
		}
	}

	server {
		listen 443 ssl;
		listen [::]:443 ssl;
		server_name git.hardenedbsd.org;

		location / {
			proxy_pass https://gitlab;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
		}
		break;
	}

	server {
		listen 443 ssl;
		listen [::]:443 ssl;
		server_name rsync.hardenedbsd.org installers.hardenedbsd.org;

		location / {
			proxy_pass https://hbsd-os-build-01;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
		}
		break;
	}

	server {
		listen 443 ssl;
		listen [::]:443 ssl;
		server_name hbsd-pkg-13-stable-01.hardenedbsd.org;

		location / {
			proxy_pass https://hbsd-pkg-13-stable-01;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
		}
		break;
	}

	server {
		listen 443 ssl;
		listen [::]:443 ssl;
		server_name hbsd-pkg-current-01.hardenedbsd.org;

		location / {
			proxy_pass https://hbsd-pkg-current-01;
			proxy_set_header Host $http_host;
			proxy_set_header X-Forwarded-For $remote_addr;
			break;
		}
		break;
	}

}

As a bonus, here’s a snippet of the unbound config file for the HardenedBSD build infrastructure DNS server:

server:
	log-servfail: yes
	local-zone: "md.hardenedbsd.lan" static
	local-data: "hbsd-pkg-current-01.hardenedbsd.lan. IN AAAA 2001:470:e1e1:100::125"

I wonder, could you use something like Boundary or Teleport for SSH where TLS is built in? So you do v6 to the proxy and that does v4 to the target.