Summary

  • RFC 3338 placed a translator between socket APIs and a host's dual IPv4/IPv6 stacks. For an AAAA-only peer, it could synthesize an A answer from a local IPv4 pool and map that value to the real IPv6 address without translating IP headers.
  • The returned IPv4 value was scoped translator state. Pool exhaustion, eviction, API-semantic gaps and a mismatch between host AAAA support and a particular server port could break the illusion. Mapping generation, translated call, transport and application outcome therefore needed separate receipts.

The resolver returned a shape the application understood

An IPv4-only program expected gethostbyname-style results and IPv4 socket structures. Rewriting its source might have been impossible because the source was unavailable. RFC 3338 proposed a temporary compatibility layer for a dual-stack host that already possessed native IPv6 networking but still had old applications.

The BIA name resolver intercepted the application's call and sought both A and AAAA records. If only AAAA existed, the address mapper selected a value from an internal IPv4 pool, stored the pair and constructed an A answer for the application. The program received the familiar four-byte shape and proceeded unchanged.

When the program later passed that value to an IPv4 socket call, the function mapper intercepted the call, looked up the IPv6 address and invoked the corresponding IPv6 API. The packets traveled through the native IPv6 stack. Unlike Bump-in-the-Stack, BIA did not need to rewrite IPv4 and IPv6 headers in the network layer.

The apparent address named table state, not a remote interface

Ordinary network addresses invite a durable interpretation: this value identifies an interface or endpoint in the network. BIA's synthetic value meant something narrower. Within a particular translator table, at a particular generation, it referred to one IPv6 address.

RFC 3338 suggested unassigned values such as 0.0.0.1 through 0.0.0.255 for the internal pool. Those values were not meant to escape the host. Their uniqueness mattered only inside the translator's scope. A per-node table, per-user table and per-process table could assign different meanings to the same bits.

Logging only the synthetic value would therefore be ambiguous. A useful record needs the table scope, entry generation, creation trigger, IPv6 referent, DNS answer set and process identity. The address was closer to a file descriptor than a globally meaningful destination.

Reuse could turn yesterday's handle into today's other peer

The pool was finite. If many IPv4 applications contacted many IPv6 hosts, addresses could run out. The RFC discussed freeing the oldest mapping and reusing its IPv4 value. That restored capacity but changed the handle's referent.

Any stale copy retained by an application, cache, log or delayed callback could now appear valid while resolving through the translator to another IPv6 host. The risk did not require duplicate global routing; it came from lifetime disagreement inside one machine.

Safe evidence must record allocation, last use, eviction, reuse and generation. A lookup result should be joined to the generation active when the socket call occurred. The same four bytes before and after reuse are not the same operational identity.

API translation did not make two APIs semantically identical

The function mapper translated corresponding IPv4 and IPv6 socket functions, but RFC 3338 warned that the APIs were not fully compatible. IPv6 introduced features without IPv4 equivalents. Raw sockets, ancillary data, ICMP values and addresses embedded in application protocols created OS-dependent work.

A successful function substitution proves that a call was issued, not that every option, error or side effect retained its meaning. The application might depend on an address family, structure size, wildcard rule or returned error that the translator could not reproduce exactly.

The receipt chain therefore keeps original API name and arguments, translated API name and arguments, option conversion, operating-system implementation, returned status and application interpretation. “No header translation” simplified one layer; it did not erase semantic translation.

A host AAAA record did not prove the chosen service spoke IPv6

A dual-stack server machine might publish AAAA because some services supported IPv6 while the application on one port remained IPv4-only. An IPv4 client using BIA could choose the AAAA path, reach the host and still fail at the service boundary.

RFC 3338 considered trying every returned address. For TCP, BIA might observe a failed connect and iterate. For UDP, the translator could not reliably know which address worked because success might not produce an immediate, observable response. The application might have to perform the iteration itself.

This distinction survives every transition technology. DNS proves that a name has records. Network reachability proves that packets can reach an address. A listening service proves something about a port. Application success proves the requested operation. None can replace the next.

The compatibility layer could become a reason not to port

The RFC drew a strong product boundary. BIA was Experimental, useful for early adopters with an IPv6 stack and legacy applications whose source was unavailable. It was not recommended for mainstream production. If source existed, developers should port the application rather than use BIA, and the mechanism should not become an excuse to postpone that work.

That warning recognized the institutional risk of compatibility layers. A bridge that solves today's gap can accumulate mappings, exception rules and operational dependencies until removing it becomes harder than the original port.

The short-term owner benefits from continued application use, while future operators inherit hidden resolver behavior and stateful address meanings. Sunset criteria belong in the deployment receipt: which applications qualify, who owns porting, which calls remain unsupported and what observation proves the bridge can be removed.

Later connection racing answered a related problem differently

RFC 2767's BIS inserted translation lower in the stack and relied on SIIT from RFC 2765; RFC 3338 explicitly moved the adaptation to the API boundary. RFC 2893 supplied the contemporary dual-stack transition setting. RFC 3493 later documented basic IPv6 socket extensions, and RFC 4038 surveyed application transition choices.

RFC 6555 and its RFC 8305 update later specified Happy Eyeballs approaches that race or sequence connection attempts across address families. They address delay and fallback without turning a synthetic IPv4 value into a private alias for an IPv6 peer. Reading those later algorithms into BIA would erase an important historical difference.

RFC 4291 defines IPv6 addressing, but it does not make BIA's synthetic IPv4 pool globally meaningful. None of these standards demonstrates that a vendor or operator deployed RFC 3338.

Every compatibility handle needs a generation number

BIA's elegant move was to preserve the application's interface while changing the implementation below it. The cost was hidden state. What looked like an address became a reference into a mutable local table, and what looked like an ordinary socket call became an intercepted translation.

The durable operational lesson is to record both the representation and the authority that interprets it. A synthetic A response should carry a mapping receipt. A translated call should carry its original and resulting semantics. A connection should carry the actual IPv6 destination and service outcome.

Without those receipts, investigators see an IPv4-shaped number and assign it global meaning it never had. RFC 3338 was a transition mechanism, but also a lesson in handles: the bits are not the identity; the live mapping is.

Sources