IPv6-only connection, IPv4 service: let a SOCKS proxy bridge it

You do not need an address in the destination family to reach it, as long as something in the path is willing to relay. The application connects to the proxy, and the proxy opens a second connection to the destination. Those are two sockets with independent address families, and nothing in either protocol requires them to match. That is application-level relaying rather than a native IPv4 path, and the distinction decides what will and will not work. Confusing the two is how a laptop ends up described as having IPv4 connectivity when all it has is a proxy.

Two sockets, two address families

A SOCKS5 request names the destination in one of three forms: a literal v4 address, a literal v6 address, or a name for the proxy to resolve. The request describes where the proxy should connect, not what the client-to-proxy connection looks like.

Read those address types as three independent choices inside one message. A proxy reachable over IPv6 can open an IPv4 destination socket whenever it has working IPv4 egress and its policy permits the request. The SOCKS5 specification defines them without reference to the client's transport at all.

A controlled SSH example

Take an SSH host you are authorized to use that answers on IPv6 and can itself reach an HTTPS service existing only on v4. OpenSSH dynamic forwarding puts a local SOCKS listener on your machine while the login session runs over v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

The host and account above are examples, and the loopback bind keeps the listener on this computer. Do not replace it with a wildcard bind so an office can share an unauthenticated proxy. ExitOnForwardFailure=yes exists so a failed forward ends the session instead of leaving a silent command running in the background.

With the session running, the request looks like this:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

The loopback connection is not an IPv4 internet path. What leaves your machine is the login session over v6, and the far side is what opens the destination socket. The socks5h form also delegates name resolution to that side, which matters when the client has no IPv4 resolver path of its own.

What the destination actually sees

The destination sees the relay's egress address. No address belonging to your laptop appears there. A source allowlist on that service has to name the relay. Its logs will attribute the traffic to the relay as well. Write that into the change record before the audit, because an allowlist built around client addresses fails at the first request.

The relay is also the place where the two halves of the conversation are visible, which is a useful property during diagnosis and a liability if the relay is shared without policy.

This is not DNS64 or NAT64

DNS64 answers with synthesized records that stand in for v4 destinations, and NAT64 rewrites packets along a configured path. Neither describes what happens here, where one transport conversation ends and another begins and no synthesized address explains the result. A successful request therefore says nothing about which translation services your provider operates, and the proxy may run ordinary NAT on its own egress.

Either mechanism can exist in the same network, so describe the one you actually verified instead of the one that sounds closest.

Know the scope before you promise it

OpenSSH's dynamic forwarding carries TCP connections, not arbitrary IP traffic, so UDP, ICMP and any protocol that ignores the proxy need a different supported design. Preserve SSH host-key verification, the server's forwarding restrictions and HTTPS certificate validation, because the proxy is an additional trusted participant rather than a reason to weaken identity checks. If the goal is to carry a VPN's outer transport through the proxy, verify that both ends support that transport instead of assuming any SOCKS listener can relay it.

None of this makes the client dual-stack, and none of it needs to. It makes one application reach one service through one relay, which is a smaller claim and a far easier one to verify.