Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
obsoletes
Extracted elements (27)
BIH supports only applications that use DNS for address resolution and do not embed IP address literals in application-protocol payloads, and that can perform NAT traversal. Applications embedding IP literals are outside the supported class.
RFC 1918 address space was chosen for synthetic IPv4 addresses because legacy applications generally understand it as private, ensuring NAT traversal techniques are initiated. 127/8 and 169.254/16 were rejected because applications may make special assumptions about those ranges. Addresses from 172.16/12 are preferred over 10/8 or 192.168/16 as less likely to conflict.
The socket API-layer implementation (Bump-in-the-API) is RECOMMENDED over the network-layer implementation (Bump-in-the-Stack) because it is name-resolution protocol agnostic, supports hosts-file, mDNS, NetBIOS, and avoids DNSSEC conflicts with synthetic A records. Network-layer translation can only intercept actual DNS queries.
This document obsoletes RFC 2767 (BIS) and RFC 3338 (BIA) and combines them into a single Standards Track document. Key improvements include use of RFC 1918 addresses instead of unassigned addresses (0.0.0.1-0.0.0.255), addition of PTR/reverse DNS support, DNSSEC considerations, and a recommendation to prefer the API-layer approach.
No Application-Level Gateway (ALG) functionality is specified in BIH; ALG design is discouraged for host-based translation and BIH is explicitly intended only for applications that do not include IP addresses in protocol payloads.
Protocol translation for IPv4 multicast is not supported by BIH. Multicast traffic cannot be translated between IPv4 and IPv6 in this mechanism.
Some IPv4 socket API functions are not fully compatible with IPv6 because IPv4 supports features absent in IPv6 (e.g., SO_BROADCAST). These API incompatibilities cannot be fully resolved by function mapping.
A BIH implementation MUST offer Endpoint-Independent Mapping following RFC 4787 guidelines. Address-Dependent Mapping MAY also be supported.
An ENR implementation SHOULD, by default, exclude certain real IPv4 and IPv6 addresses from A and AAAA records, including addresses that should not appear in DNS or on the wire per RFC 6147 Section 5.1.4 and RFC 5735. Additional addresses MAY be excluded by local policy.
BIH implementations MUST implement proper protection against DoS attacks on limited resources, including allocating a limited amount of memory for fragmented packet storage to prevent memory exhaustion.
BIH MUST NOT be deployed in combination with NAT64; use of BIH together with NAT64 is NOT RECOMMENDED per RFC 6180, which advises against double protocol translation.
BIH MUST NOT perform protocol translation from IPv4 to IPv6 for dual-stack destinations when the host has any IPv4 interfaces (native or tunneled) available. If an IPv4 interface becomes available during BIH operation, BIH MUST stop initiating new translation sessions.
BIH SHOULD select a source address from the recommended source address pool when a socket has not been explicitly bound to any IPv4 address. The binding of an explicitly bound socket MUST NOT be changed by BIH.
ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT (RFC 6145). In the network-layer alternative, the protocol translator MUST translate ICMPv6 to ICMPv4 and vice versa; in the socket API alternative, the socket API MUST handle these conversions.
If a DNS A record reply contains non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 addresses; synthesis only occurs when the A query returns no usable real IPv4 result.
The function mapper MUST NOT perform function mapping when the application is initiating communications to the address range used by local synthesis and the address mapping table does not have a matching entry.
The Protocol Translator MUST use SIIT (RFC 6145) for IPv4/IPv6 conversion. To avoid unnecessary fragmentation, the host's IPv4 module SHOULD be configured with an MTU equal to the IPv6-enabled link MTU minus 20 bytes.
When an application requests a reverse PTR lookup for a synthetic IPv4 address, the ENR MUST check the mapping table, and if a synthetic entry is found, MUST initiate a reverse lookup for the corresponding real IPv6 address. Requests for non-synthetic addresses MUST be passed on unmodified.
When BIH shuts down or address mapping table entries are cleared for any reason, DNS cache entries for synthetic IPv4 addresses MUST be flushed, including caches in both the network-layer ENR and the host's stub resolver.
When the function mapper detects IPv4 socket API function calls from IPv4 applications, it MUST intercept those calls and invoke the corresponding IPv6 socket API functions.
While running BIH with the network-layer ENR, the host's main resolver SHOULD NOT perform validation of A records, because synthetic A records created by the ENR would fail DNSSEC validation.
BIH consists of three core components: an Extension Name Resolver (ENR), an Address Mapper, and either a Function Mapper (socket API layer) or a Protocol Translator (network layer). These cooperate to synthesize IPv4 addresses from AAAA records and translate communications between IPv4-only applications and IPv6-only peers.
Synthetic IPv4 addresses are drawn exclusively from RFC 1918 private address space. Recommended primary destination addresses are 10.170.160.0/20, secondary destination 172.21.80.0/20, primary source 172.21.112.0/20, and secondary source 10.170.224.0/20.
The Address Mapper maintains an IPv4 address pool drawn from RFC 1918 private addresses and a table of (synthetic IPv4 address, real IPv6 address) pairs. New mappings are registered when the ENR resolves only IPv6 addresses, when all real IPv4 addresses are excluded, or when the function mapper receives an IPv6 packet with no existing mapping entry.
Any protocol that protects IP header information is incompatible with BIH. End-to-end IPsec verification fails when AH is used (both transport and tunnel mode) and when ESP is used in transport mode. UDP encapsulation per RFC 3948 can restore end-to-end IPsec protection.
BIH modifies DNS answers (synthesizing A records), which directly conflicts with DNSSEC, which is designed to detect such modifications and treat them as bogus. DNSSEC validation of synthetic A records will fail by design.
BIH's synthetic IPv4 address pool is a DoS attack surface: an attacker can exhaust the pool by triggering DNS queries that cause ENR to synthesize A records. Implementations MUST protect against this and against memory exhaustion from fragment storage attacks.