When IPv6-only nodes begin to appear in the network, AF_INET6 applications on these nodes might need to communicate with AF_INET applications. For a multihomed dual-mode IP host, it is a likely that the host has both IPv4 and IPv6 interfaces over which requests for host-resident applications are received or sent. IPv4-only (AF_INET sockets) applications are not generally able to communicate with IPv6 partners, which means that only the IPv4 partners in the IPv4 network can communicate with those applications; an IPv6 partner cannot.

As soon as IPv6-only hosts are being deployed in a network, applications on those IPv6-only nodes cannot communicate with the IPv4-only applications on the dual-mode hosts, unless one of multiple migration technologies are implemented either on intermediate nodes in the network or directly on the dual-mode hosts.

Numerous RFCs describe solutions in this area. One solution is a SOCKS64 implementation that works as a Sockets Secure (SOCKS) server that relays communication between IPv4 and IPv6 flows. SOCKS is a well-known technology, and the issues around it are familiar. Servers do not require any changes, but client applications (or the stack on which the client applications reside) need to be socks-enabled to be able to reach out through a SOCKS64 server to an IPv4-only partner.

Other solutions are based on a combination of network address translation, IP-level protocol translation, and DNS-flow catcher/interpreter. These solutions all have problems with application-level IP address awareness and end-to-end security.