Summary

  • RFC 3493 allowed an AF_INET6 socket to communicate with IPv4 peers represented as IPv4-mapped IPv6 addresses. Its IPV6_V6ONLY option disabled that dual-family behavior, but the RFC specified the option as off by default.
  • A socket-family label and a successful wildcard bind therefore did not prove which peer family could reach the process or whether a separate IPv4 listener could own the same port. Option state, kernel semantics and bind results were separate evidence.

An operations sheet can list sockets by the constants used to create them. That makes AF_INET6 look like a boundary: this process is IPv6, that other process is IPv4. RFC 3493 preserved no such simple inference. Its basic sockets API was designed during the transition from IPv4-only applications to systems that could serve both families without making every application understand two entirely separate interfaces.

The compatibility device was the IPv4-mapped IPv6 address. An IPv4 address could appear inside the low 32 bits of a 128-bit structure under the fixed ::ffff: prefix. An application could connect through an AF_INET6 socket to an IPv4 node using that representation. On receipt, the kernel could hand an IPv4 peer back through sockaddr_in6. The application that cared could test the address with IN6_IS_ADDR_V4MAPPED().

That was a representation contract at the application/kernel seam. It did not say the remote host ran IPv6. It did not say the packet crossed an IPv6-only path. It did not say the service had applied the same policy to native and mapped peers. It only described how one API could carry more than one network family.

RFC 3493 made the listener boundary explicit with IPV6_V6ONLY. When enabled, the boolean option restricted an AF_INET6 socket to IPv6 communications. The RFC set it off by default. That historical default meant a wildcard IPv6 bind could be dual-family: the process could receive native IPv6 and IPv4 peers represented in mapped form.

The RFC's example exposes the operational consequence. Turning the option on could allow two versions of the same server to use the same port, one bound for IPv6 and one for IPv4. The option was therefore not cosmetic metadata. It helped determine which socket acquired the effective port namespace. A deployment could contain two correctly configured binaries and still fail its intended partition if the first listener's bind semantics occupied both families.

This is why process inventory is weaker than listener evidence. “An IPv6 daemon is running” does not establish that only IPv6 can enter. “An IPv4 daemon is configured” does not establish that it successfully bound. A successful bind() on one descriptor does not establish reachability from outside a firewall or namespace. An accepted connection does not establish authorization, and authorization does not establish delivered service.

The mapped form needs one more qualification. RFC 3493 says IPV6_V6ONLY does not affect IPv4-mapped addresses that enter as valid IPv6 traffic through SIIT. Later translation specifications distinguish algorithmic IPv4-embedded prefixes and packet translation from the local socket representation. Seeing a mapped-looking peer is therefore not enough to reconstruct the path. The receipt must record where mapping occurred and which kernel behavior admitted the packet.

The same discipline applies to name resolution. getaddrinfo() can return candidates selected by family and mapping flags. RFC 6724 later specifies default address selection, while RFC 8305 treats IPv6 and IPv4 candidates as paths to race rather than promises to trust. A returned address is a candidate. It is not proof that a listener owns the port, that the path works or that the application completed its transaction.

RFC 3493 itself is dated evidence. It is Informational, it obsoleted RFC 2553, and it identifies the Open Group/IEEE/ISO specification as the official sockets standard. Its statement that IPV6_V6ONLY defaults off records the API contract the authors published in 2003. It must not be projected onto every current kernel, language runtime, container network or managed platform without measurement.

The durable lesson is narrower and stronger. Address family, effective option value, wildcard scope, successful bind, accepted peer representation, authorization and service outcome form a ladder of receipts. If an audit skips a rung, the label “IPv6 listener” can conceal an IPv4 entrance—or conceal the fact that the intended IPv4 listener never owned the port at all.

Sources