Scalable Operation of Address Translators with Per-Interface Bindings
Extracted elements (15)
For deployments where exactly one user device connects per tunnel interface and all tunnels use the same IPv4 address, storing the user device address in addition to the interface identifier is redundant; omitting it can decrease mapping entry storage and improve NAT scalability.
In pure IPv6 internal networks using NAT64 (RFC 6146), per-interface mappings are generally unnecessary because the IPv6 address space is large enough to provide a sufficient number of distinct mappings without address reuse.
Networks serving more than 2^24 (16 million) users cannot assign unique private IPv4 addresses to each user because the largest reserved private block is 10/8. Per-interface bindings solve this by reusing the same private address space across point-to-point interfaces without consuming additional address space.
Tunneling-based approaches (e.g., DS-Lite) can achieve similar address-conservation benefits, but where point-to-point links already exist, adding another tunneling layer is unnecessary and harmful due to MTU effects. The per-interface approach requires no tunnel endpoint discovery, security mechanisms, or host changes.
When user devices connect via individual point-to-point links, the NAT can identify the correct mapping via the interface rather than a unique private IP address, making it possible to support any number of devices behind the NAT using very few IPv4 addresses.
Existing tunnels (e.g., in cellular network gateways already present for mobility management) are a common special case of point-to-point links; per-interface NAT is particularly attractive in such environments because no additional tunneling mechanisms, negotiation, or host changes are required.
The use of overlapping private address space across interfaces prevents devices behind the same NAT from using unique private addresses to communicate with each other; a NAT operation must occur between any two such devices for them to communicate.
A NAT MUST manage its mappings on a per-interface basis, associating each NAT session not only with the five tuples for the transport connection on both sides, but also with the internal interface on which the user device is connected to the NAT.
In dual-stack deployments, the use of per-interface NAT mappings is RECOMMENDED for the IPv4 side to aid NAT scalability while IPv6 handles direct end-to-end communication.
Per-interface binding mode is only suitable where user devices connect over point-to-point links. If supported, this mode SHOULD be configurable and SHOULD be disabled by default in general-purpose NAT devices.
A NAT session is defined as an association between a transport layer session as seen in the internal realm and a session as seen in the external realm, by virtue of NAT translation, providing translation glue between the two session representations.
Per-interface NAT mappings associate each session with the five-tuple (transport connection identifiers on both sides) plus the internal interface identifier, allowing the same private IPv4 address range to be reused across all internal interfaces.
The internal interface need not be physical; it may correspond to a tunnel, VLAN, or other identifiable communications channel, enabling applicability to PPP, PPPoE, ATM PVCs, and per-subscriber VLANs.
The per-interface binding method is not externally observable: a device outside the NAT cannot distinguish a regular NAT from the per-interface NAT described in this document, so no new attack surface is introduced by the binding technique itself.
The use of the same address space for different devices behind the NAT means devices cannot communicate directly with each other without traversing the NAT or a router, enforcing traffic mediation as a structural property of the deployment.