Fact-checked by Grok 2 weeks ago

NAT traversal

NAT traversal encompasses a range of techniques designed to enable direct communication between endpoints separated by one or more Network Address Translators (NATs), which allow multiple devices on a private network to share a single public IP address by modifying the source IP address and port in outgoing packets.^[1] This translation process creates discontinuities in addressing that prevent unsolicited inbound connections from reaching devices behind the NAT, posing significant challenges for peer-to-peer applications requiring end-to-end connectivity.^[1] The primary goal of NAT traversal is to discover the public IP address and port mappings allocated by the NAT, maintain these mappings through periodic keep-alives, and establish bidirectional communication paths without relying solely on manual configuration or symmetric routing assumptions.^[2] Key methods include Session Traversal Utilities for NAT (STUN), which allows clients to query a server to learn their reflexive transport address and keep NAT bindings open via binding requests.^[1] For scenarios where STUN fails, such as with symmetric NATs, Traversal Using Relays around NAT (TURN) provides a relay server to forward traffic between endpoints, ensuring connectivity at the cost of added latency and bandwidth.^[3] Interactive Connectivity Establishment (ICE) combines STUN and TURN by gathering candidate addresses, performing connectivity checks, and selecting the optimal path, offering robust traversal for UDP-based sessions.^[4] These techniques are widely applied in real-time communication protocols, including Session Initiation Protocol (SIP) for voice over IP (VoIP), Real-time Transport Protocol (RTP) for media streaming,^[5] and WebRTC for browser-based video conferencing and peer-to-peer data exchange.^[4] Additional approaches, such as UDP encapsulation for IPsec VPNs^[6] and latching mechanisms in hosted NAT traversal,^[7] address specific contexts like secure tunneling and media relaying in real-time applications. Challenges persist, including security vulnerabilities like address spoofing, varying NAT behaviors across implementations, and the overhead of relay-based solutions, driving ongoing standardization efforts.^[2]

Fundamentals of NAT

Network Address Translation Basics

Network Address Translation (NAT) is a technique that maps IP addresses from one address realm to another, enabling multiple devices on a private network to share a single public IPv4 address by modifying the source IP address and port in outbound packets.^[8] This process, often referred to as Network Address Port Translation (NAPT) when ports are involved, allows internal hosts using private IP addresses (as defined in RFC 1918) to communicate with external networks without requiring unique public IPs for each device. By conserving the limited IPv4 address space, NAT has become ubiquitous in routers and gateways. The development of NAT emerged in the early 1990s amid growing concerns over IPv4 address exhaustion, as the rapid expansion of the internet threatened to deplete the approximately 4.3 billion available addresses.^[9] Initially proposed as a temporary measure in RFC 1631 (1994), NAT addressed this crisis by allowing stub networks to reuse private address blocks internally while presenting a single public address externally, thereby extending the usability of IPv4 without immediate migration to IPv6.^[9] This approach gained widespread adoption following the formalization of NAT terminology and operations in subsequent RFCs, significantly delaying global address depletion.^[8] In operation, NAT primarily handles outbound traffic by replacing the private source IP address and port with a public IP and an available port, storing the mapping in a dynamic table to ensure inbound responses can be routed back correctly. For inbound traffic, the NAT device consults this table to reverse the translation, directing packets to the appropriate internal host based on the destination port and IP. Port Address Translation (PAT), a common variant of NAPT, multiplexes multiple private connections over the same public IP by assigning unique external ports, supporting thousands of simultaneous sessions on a single address.^[8] NAT behaviors vary in mapping and filtering: cone NATs maintain endpoint-independent or address-dependent port assignments, allowing consistent external mappings for outbound flows, whereas symmetric NATs use address- and port-dependent mappings, changing the external port for each new destination to enhance security but increasing complexity for return traffic.^[10] A practical example is a home router, where NAT enables multiple devices—like laptops, smartphones, and smart TVs—connected via a local area network (using private IPs such as 192.168.1.x) to share one public IP provided by the internet service provider.^[8] When a device initiates an outbound connection, the router translates its private IP and source port to the public IP and a unique port (e.g., from 192.168.1.10:12345 to 203.0.113.1:54321), records the mapping, and reverses it for incoming responses, allowing seamless internet access without address conflicts. This setup, however, primarily facilitates outbound-initiated communications and can pose barriers to unsolicited inbound connections in peer-to-peer applications.^[8]

Types of NAT Devices

Network Address Translation (NAT) devices are classified based on their mapping and filtering behaviors, which determine how they translate internal IP addresses and ports to external ones and how they handle incoming packets. These behaviors significantly influence the feasibility of NAT traversal techniques, as more restrictive types hinder direct peer-to-peer connectivity by limiting unsolicited incoming traffic.^[11] The primary classification framework, established in standards for UDP handling, distinguishes between endpoint-independent and endpoint-dependent rules for both mapping (outbound translations) and filtering (inbound permissions).^[11] Mapping behavior describes how a NAT assigns external IP addresses and ports to internal ones for outbound packets. In endpoint-independent mapping, all packets from the same internal IP address and port (denoted as X:x) are translated to the same external IP and port (X':x'), regardless of the destination external IP and port (Y:y); this allows reuse of the mapping for any outbound destination.^[11] Address-dependent mapping reuses the external mapping only for packets sent to the same external IP address, creating a new mapping for different destinations.^[11] Address and port-dependent mapping, the most restrictive, generates a unique external mapping for each distinct destination IP and port pair.^[11] Filtering behavior governs whether incoming packets from an external source (Z:z) are allowed to reach the internal host. Endpoint-independent filtering permits any incoming packet destined for the internal address and port (X:x), irrespective of the source, once an outbound mapping exists.^[11] Address-dependent filtering allows packets only from external IP addresses (Y) to which the internal host has previously sent packets.^[11] Address and port-dependent filtering is stricter, requiring prior outbound packets to the exact source IP and port (Y:y).^[11] These rules combine to form distinct NAT types, with implications for traversability: looser behaviors (e.g., endpoint-independent) enable easier hole punching, while dependent rules often require additional protocols or relays.^[11] Full cone NAT combines endpoint-independent mapping and endpoint-independent filtering. Any external host can send packets to the internal host via the mapped external port after the internal host initiates any outbound communication, making it the least restrictive and most traversable type.^[11]^[12] Restricted cone NAT uses endpoint-independent mapping but address-dependent filtering, allowing incoming packets only from external IP addresses previously contacted by the internal host.^[11]^[12] Port-restricted cone NAT employs endpoint-independent mapping with address and port-dependent filtering, further limiting incoming traffic to specific ports on previously contacted external IPs.^[11]^[12] Symmetric NAT, the most restrictive, typically features address and port-dependent mapping paired with address and port-dependent filtering. It creates a unique external mapping for each outbound destination IP and port pair, and incoming packets are allowed only from that exact pair.^[11]^[12] This behavior severely impacts traversability, as the external port changes per destination, breaking simple port forwarding schemes where a fixed external port is assigned for inbound traffic to reach an internal service.^[11] For instance, if an internal application attempts to receive connections on a forwarded port, symmetric NAT's dynamic mappings prevent consistent external access from unintended sources.^[11]

Challenges Posed by NAT

Obstacles to Peer-to-Peer Connectivity

Network Address Translation (NAT) fundamentally disrupts peer-to-peer (P2P) connectivity by rewriting source IP addresses and ports of outbound packets while typically discarding unsolicited inbound packets that do not match existing mappings. This behavior renders internal hosts unreachable from the public Internet unless they possess a dedicated public IP address, as NAT devices maintain state tables that only permit return traffic for previously initiated connections.^[13] Without such mappings, attempts to establish direct inbound connections fail, isolating devices behind NAT from acting as servers in P2P scenarios.^[14] This obstacle manifests in various P2P applications requiring symmetric communication. In peer-to-peer file sharing systems like BitTorrent, clients must accept incoming connections from other peers to seed or download files efficiently; however, NAT blocks these unsolicited inbound requests, forcing reliance on centralized trackers or relays that undermine the decentralized model.^[13] Similarly, Voice over IP (VoIP) calls between endpoints behind NAT suffer from one-way audio or connection failures, as media streams cannot traverse the NAT without prior outbound initiation from both sides.^[13] Online gaming, particularly multiplayer titles, faces latency and synchronization issues when players cannot directly connect for real-time interactions, often resulting in degraded performance or fallback to server-mediated play.^[13] These challenges are exacerbated in environments with different NAT types, such as cone versus symmetric, where mapping behaviors further restrict inbound traffic.^[13] Cascaded or double NAT configurations, common in enterprise networks or ISP-provided carrier-grade NAT (CGN) setups, compound these issues by introducing multiple layers of address translation. In such scenarios, the inner NAT (e.g., a home router) maps to a private address in the outer NAT's pool, leading to port conflicts and unpredictable mappings that prevent direct P2P routing between endpoints sharing the same ISP.^[15] For instance, BitTorrent seeding fails outright in double NAT environments without unique public ports, as the outer NAT cannot distinguish overlapping inner mappings.^[15] A majority of Internet users still rely on NAT for IPv4 connectivity as of 2025, with global IPv6 adoption at approximately 45%, amplifying these barriers across residential and mobile networks.^[16] The ongoing transition to IPv6 is expected to reduce NAT dependency over time.^[17] A concrete example illustrates the failure: Consider two home users, each behind a full cone NAT, attempting a direct P2P file transfer. The initiating user sends an outbound connection request, creating a mapping, but the recipient's NAT drops the inbound SYN packet as unsolicited, since no prior outbound traffic from the recipient exists to establish state. This results in a timeout and failed connection, despite both devices being on cone NATs that theoretically support inbound if mappings align—highlighting how the lack of public reachability thwarts symmetric P2P without additional coordination.^[13]

Impact on Transport Protocols

Network Address Translation (NAT) fundamentally alters packet headers by replacing private IP addresses and ports with public ones, which necessitates recalculation of transport-layer checksums in protocols like TCP and UDP to maintain data integrity. This modification occurs because the checksum fields in TCP and UDP headers include the IP source and destination addresses as part of the pseudo-header, and any change to these addresses invalidates the original checksum, requiring the NAT device to recompute and update it for outbound packets.^[18] For UDP, the stateless nature of the protocol exacerbates NAT challenges, as it lacks inherent connection tracking, leading to temporary and unreliable port mappings or "holes" that NAT devices create for outbound traffic. These mappings typically expire after a timeout period if no further packets arrive, making inbound connections unreliable without external assistance, such as application-layer gateways (ALGs) or helper protocols, particularly in peer-to-peer scenarios like online gaming or VoIP.^[18] TCP encounters more pronounced issues due to its stateful three-way handshake, where SYN packets initiated from behind a NAT cannot easily receive inbound SYN/ACK responses without pre-established mappings, often resulting in connection failures for incoming sessions. NAT devices must track TCP states to rewrite SYN/ACK and subsequent packets, but disruptions arise if the NAT alters ports unpredictably or if bundled sessions (e.g., control and data channels) are misinterpreted, breaking the handshake integrity.^[18] IPsec protocols face significant compatibility problems with NAT because authentication headers (AH) and encapsulating security payloads (ESP) embed IP addresses and ports that are integrity-protected, preventing straightforward translation without detection and adjustment mechanisms. Specifically, NAT modifications invalidate AH checksums that cover the entire IP packet, while ESP encryption can obscure inner TCP/UDP headers needed for checksum updates, necessitating NAT traversal extensions like UDP encapsulation to detect NAT presence via Internet Key Exchange (IKE) and adjust accordingly.^[19]^[18] At the application layer, protocols like SIP using SDP for VoIP are impacted as they embed IP addresses and ports for RTP media streams in signaling messages, requiring explicit port mappings to ensure media flows traverse NAT boundaries correctly. Without such mappings, RTP packets sourced from private addresses fail to reach external peers, as SDP bodies reflect internal network details rather than NAT-translated public endpoints.^[20]^[18]

Core NAT Traversal Techniques

UDP Hole Punching

UDP hole punching is a technique for enabling direct peer-to-peer communication between two endpoints behind NAT devices by exploiting the temporary mappings created in NAT translation tables for outgoing UDP packets. The process relies on a third-party rendezvous server that facilitates the exchange of the public IP addresses and port numbers (endpoints) assigned by each peer's NAT. Once obtained, each peer simultaneously sends UDP packets to the other's public endpoint, creating "pinholes" or temporary bidirectional mappings in their respective NATs that allow subsequent direct UDP traffic to pass through without further relay.^[21] For the pinholes to remain open and permit incoming packets, the initial UDP packets from both peers must arrive in a near-simultaneous manner, ideally crossing paths en route; this timing exploits the NAT's stateful behavior, where an outbound packet prompts the NAT to permit responses from the target address within a short timeout period, typically seconds to minutes. This requirement stems from the NAT's endpoint-dependent filtering rules, particularly in restricted cone NATs, where mappings are preserved only for traffic directed to previously contacted destinations.^[21] The technique achieves high success rates with cone NAT variants, such as full cone and restricted cone types, where port mappings remain consistent regardless of the destination, enabling up to 82% connectivity in empirical tests across diverse NAT implementations. However, it performs poorly with symmetric NATs, which assign unique port mappings for each outbound destination and thus close previous pinholes, often failing or having low success rates without additional port prediction mechanisms.^[21]^[22] Early applications of UDP hole punching appeared in peer-to-peer online gaming and VoIP systems, where low-latency direct connections were essential for real-time interaction. Limitations include its restriction to UDP, which lacks built-in reliability or encryption, necessitating application-layer handling for those features, and the ephemeral nature of pinholes, requiring periodic keep-alive packets to maintain connectivity against NAT timeouts.^[21]

TCP Hole Punching

TCP hole punching adapts the hole punching concept to TCP's connection-oriented nature, enabling direct peer-to-peer connections between hosts behind NAT devices. The technique relies on a rendezvous server to exchange the public IP addresses and ports (endpoints) of the peers, obtained through existing outbound connections to the server. Once endpoints are shared, both peers simultaneously initiate TCP connection attempts to each other's public endpoints using the same local port, racing SYN packets across the NATs to establish bidirectional mappings. This creates temporary "holes" in the NATs, allowing the SYN packets to traverse and complete the three-way handshake without relay involvement for data transfer.^[21] A key challenge arises from TCP's three-way handshake, which demands precise timing to prevent NATs from resetting unsolicited SYN packets with RSTs, potentially derailing the connection. To mitigate this, peers employ retries and asynchronous SYN transmission, ensuring that the initial outbound SYN from each side opens a consistent port mapping before the inbound packet arrives. Variants address these issues: the simultaneous connect method, supported by POSIX sockets via options like SO_REUSEADDR and SO_REUSEPORT, allows both peers to bind multiple sockets to the same port and initiate connections concurrently, resolving the race through standard TCP semantics. Alternatively, server-reflected SYN-ACK involves one peer attempting a connection first, with the server relaying the SYN-ACK to trigger the second peer's response, though this adds slight latency.^[21] Success rates for TCP hole punching are lower than for UDP due to TCP's stateful connections and stricter NAT behaviors, succeeding in approximately 64% of tested NAT configurations, primarily full-cone and restricted-cone types that maintain consistent mappings. It fails against symmetric NATs, which assign unique ports per destination, and multi-level NATs lacking hairpin translation. Historically, TCP hole punching was employed in some older peer-to-peer applications during the 2000s to facilitate direct TCP streams for file sharing and other data-intensive exchanges, though UDP variants often proved more reliable for initial handshakes.^[21]^[23]

Key Protocols for NAT Traversal

STUN and TURN

STUN (Session Traversal Utilities for NAT), as defined in RFC 8489 published in 2018, is a lightweight client-server protocol designed to facilitate NAT traversal by enabling endpoints behind NATs to discover their public IP addresses and ports allocated by the NAT device.^[1] A client initiates the process by sending a Binding Request message to a STUN server, typically over UDP.^[1] The server responds with a Binding Response containing the XOR-MAPPED-ADDRESS attribute, which encodes the client's reflexive transport address (the public IP and port as observed externally) by XORing it with a 32-bit magic cookie value of 0x2112A442 to prevent misinterpretation by intermediaries.^[1] This reflexive address revelation allows clients to predict NAT behavior and coordinate with peers for direct connectivity, such as in UDP hole punching techniques.^[1] STUN messages follow a structured format consisting of a fixed 20-byte header—comprising the 16-bit message type (indicating the method like Binding and class such as request or response), 16-bit message length, 32-bit magic cookie, and 96-bit transaction ID for matching responses—followed by zero or more type-length-value (TLV) encoded attributes.^[1] To detect NAT mapping properties, such as full cone mappings where all requests from the same internal address/port map to the same external address/port regardless of destination, clients can send multiple Binding Requests and analyze the consistency of the mapped addresses in responses; variations in mapping (e.g., endpoint-independent vs. address-dependent) inform traversal strategies.^[1] STUN supports both short-term (shared secret) and long-term credential mechanisms for authentication, ensuring secure interactions while maintaining low overhead.^[1] TURN (Traversal Using Relays around NAT), outlined in RFC 8656 published in 2020, extends STUN to provide a relay mechanism for scenarios where direct peer-to-peer paths cannot be established, such as behind symmetric NATs that map ports differently for each destination.^[3] A TURN client sends an Allocate request to the server, specifying transport protocols like UDP, TCP, or TLS, and receives a response with the XOR-RELAYED-ADDRESS attribute assigning a unique relayed transport address on the server's public interface.^[3] This address acts as a proxy: the client sends data encapsulated in Send indications to the server, which forwards it to the peer's address, and vice versa for incoming data via Data indications.^[3] To control relaying and prevent unauthorized use, clients issue CreatePermission requests to authorize specific peer IP addresses (with a default 5-minute lifetime) or bind channels for efficient ongoing data relay.^[3] TURN messages reuse the STUN format with additional methods (e.g., Allocate, Refresh, CreatePermission) and attributes (e.g., XOR-PEER-ADDRESS for specifying destinations), while channel data uses a compact 4-byte header with a 16-bit channel number for low-latency relaying after setup.^[3] Allocations have a default lifetime of 600 seconds, renewable via Refresh requests, and support even port allocation for media streams.^[3] In deployment, both STUN and TURN servers commonly operate on UDP/TCP port 3478 for unencrypted traffic and port 5349 for TLS/DTLS-secured connections, with TURN invoked as a fallback for symmetric NAT cases where STUN alone fails.^[1]^[3] Empirically, STUN achieves successful NAT traversal in about 80% of typical scenarios, while incorporating TURN as a relay boosts overall connectivity to 95-100% at the expense of added latency from data rerouting.^[24]^[25]

Interactive Connectivity Establishment (ICE)

Interactive Connectivity Establishment (ICE) is a standardized framework designed to facilitate NAT traversal for UDP-based real-time communication by enabling peers to discover and select the optimal network path among multiple candidates. It orchestrates the use of STUN for address discovery and TURN for relaying when necessary, ensuring robust connectivity even across complex network topologies involving multiple NATs and firewalls. Defined in RFC 8445, published in July 2018, ICE obsoletes the previous specification (RFC 5245) and introduces enhancements such as improved support for DTLS-secured transports to align with modern security requirements in protocols like WebRTC.^[4] The ICE process unfolds in several key phases: candidate gathering, prioritization, connectivity testing, and pair nomination. During candidate gathering, each ICE agent—either the controlling or controlled agent—compiles a list of potential transport addresses (candidates) from its local environment and external servers. This includes querying network interfaces, STUN servers, and TURN relays to build a comprehensive set of options for establishing connectivity.^[4] ICE defines three primary candidate types to cover a range of network scenarios. Host candidates represent the agent's local IP addresses and ports directly from its network interfaces, offering the lowest latency but potentially limited by NAT restrictions. Server-reflexive (srflx) candidates are public addresses discovered through STUN server responses, revealing the NAT-mapped view of the agent's host address. Relayed candidates, obtained via TURN servers, provide a fallback address through which traffic can be proxied when direct paths fail, though at the cost of additional latency and bandwidth overhead.^[4] Once gathered, candidates are assigned priorities to guide the selection process toward efficient paths. The priority calculation favors host candidates (type preference 126), followed by peer-reflexive candidates (110), server-reflexive candidates (100), and relayed candidates (type preference 0), combined with local and component-specific preferences using the formula: priority = (2^{24}) × (type preference) + (2^{8}) × (local preference) + (256 - component ID). Peers exchange these prioritized candidates via SDP in an offer/answer sequence, allowing both sides to form candidate pairs for testing.^[4] Connectivity checks form the core of ICE's validation mechanism, where the controlling agent initiates STUN Binding requests over candidate pairs to verify reachability, starting with the highest-priority pairs and proceeding in a paced manner (minimum interval of 5 ms to avoid overwhelming NAT bindings). Successful responses confirm a valid pair, while failures trigger retries or progression to lower-priority options. To ensure ongoing permission for data exchange and prevent unauthorized traffic, ICE enforces consent freshness through periodic STUN Binding Indications, as specified in RFC 7675, which verifies the remote peer's continued consent at intervals typically around 5 seconds.^[4]^[26] Upon identifying valid pairs, the controlling agent nominates the optimal one—usually the highest-priority successful pair—by including the USE-CANDIDATE attribute in an updated SDP offer, prompting the controlled agent to activate that path for media transmission. Failure handling is systematic: unchecked pairs time out after regulated intervals (e.g., RTO starting at 500 ms), and if all pairs fail, the checklist state transitions to "Failed," potentially triggering ICE restart or fallback to relay-only modes. This nomination ensures the selected pair balances performance and reliability.^[4] In real-time applications like WebRTC, ICE's comprehensive approach markedly improves peer-to-peer connection establishment by systematically exploring direct paths before resorting to relays, with the 2018 specification enhancing compatibility for DTLS-based security.^[4]

Universal Plug and Play (UPnP)

Universal Plug and Play Internet Gateway Device (UPnP-IGD) is a standardized protocol developed in the early 2000s to enable automatic configuration of network address translation (NAT) and firewall devices, facilitating inbound connectivity for applications behind a NAT router. The initial IGD v1.0 specification was approved by the UPnP Forum on November 12, 2001, defining a device-centric architecture where local clients can discover and control the internet gateway device (IGD) to create port mappings. This approach contrasts with server-assisted methods by directly modifying the local NAT configuration, making it suitable for consumer routers in home networks. The UPnP-IGD process relies on a multi-step discovery and control mechanism. Clients first use the Simple Service Discovery Protocol (SSDP), operating over UDP multicast on port 1900, to locate the IGD on the local network through search messages or announcement responses. Upon discovery, the client fetches the device's XML description to identify service endpoints, then invokes actions on the WANIPConnection service using SOAP messages over HTTP. These actions, such as AddPortMapping, specify parameters like the external port, protocol (TCP or UDP), internal client IP and port, and lease duration to establish a port forward, allowing external traffic to reach the internal host. This enables applications to receive unsolicited inbound connections without manual router configuration.^[27] Security in UPnP-IGD is a significant concern, as the protocol includes no authentication or authorization, permitting any local network device—including compromised ones—to request port mappings and potentially expose internal services to the internet. This vulnerability has led to exploits like unauthorized port openings by malware, prompting many firewall and router vendors to disable UPnP by default. Compatibility is limited to full cone and restricted cone NAT types, where static port mappings reliably enable inbound access; symmetric NATs, which dynamically assign external ports based on destination, prevent consistent forwarding and render UPnP-IGD ineffective for such setups. Despite these issues, it remains widely used in gaming consoles, such as Xbox and PlayStation, to achieve open NAT for peer-to-peer multiplayer sessions.^[28] In 2010, the UPnP Forum released IGD v2.0 on September 2, introducing IPv6 support through the WANIPv6FirewallControl service for managing firewall pinholes in IPv6 environments, along with security enhancements via the Device Protection device control point (DCP). IGD v2.0 became mandatory for UPnP+ certification, with v1.0 deprecated in 2015. However, adoption of IGD v2.0 has been limited, largely due to persistent security risks in the broader UPnP ecosystem and incomplete implementation in consumer devices.^[29]

NAT Traversal in Specific Contexts

IPsec VPNs

NAT Traversal for IPsec VPNs, commonly known as NAT-T, enables IPsec communications to function across Network Address Translation (NAT) devices by encapsulating IPsec Encapsulating Security Payload (ESP) packets within UDP datagrams on port 4500. Defined in RFC 3948, this mechanism addresses the incompatibility between IPsec protocols and NAT modifications to IP headers and ports, which would otherwise cause authentication or integrity failures.^[30] The negotiation process for NAT-T occurs during the Internet Key Exchange (IKE) phase, where peers agree to use UDP encapsulation if NAT presence is detected.^[6] Detection of NAT devices relies on NAT Discovery (NAT-D) payloads exchanged during IKE, which include hashed values of the peers' original IP addresses and ports to identify any translations.^[6] If discrepancies are found between sent and received hashes, NAT-T is activated; otherwise, standard IPsec protocols proceed. To maintain the NAT mapping and prevent timeouts, periodic NAT-T keepalives—empty UDP packets—are sent, often integrated with Dead Peer Detection (DPD) mechanisms from RFC 3706 to monitor peer liveness without additional overhead. This detection is performed in IKE main mode (third and fourth messages) or aggressive mode (second and third messages).^[6] While NAT-T primarily supports ESP encapsulation, challenges arise with Authentication Header (AH) due to its reliance on unmodified IP headers for integrity protection, making AH incompatible with NAT modifications even after UDP wrapping.^[30] Symmetric NATs, which assign unique external mappings for each destination, can further complicate traversal by restricting inbound connections, though UDP encapsulation mitigates this for ESP in most cases by allowing port address translation.^[30] The added UDP header introduces an overhead of 8 bytes per packet, minimally impacting performance but essential for the majority of IPsec VPN deployments where at least one peer is behind NAT.^[31] NAT-T is widely implemented in modern IPsec VPN clients and gateways, including open-source solutions like strongSwan and commercial platforms from Cisco and Juniper.^[32] Microsoft enabled NAT-T support in Windows XP Service Pack 2 in 2004, though it is now considered legacy in favor of newer operating systems with built-in compatibility.^[33]

Voice over IP and Real-Time Communication

Voice over IP (VoIP) systems face significant NAT traversal challenges due to the separation of signaling and media paths. The Session Initiation Protocol (SIP) handles call setup and signaling, typically over fixed ports like 5060, while the Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) manage dynamic media streams for audio and video, requiring unpredictable port mappings that NAT devices often fail to maintain without additional mechanisms. ^[5] This discrepancy leads to one-way audio or call failures when endpoints are behind NAT, as inbound media packets cannot reach the private addresses without explicit hole punching or relay support. ^[34] To mitigate these issues, techniques like RTP keepalives send periodic empty packets to preserve NAT bindings for RTCP, ensuring bidirectional media flow. WebRTC, introduced by Google in 2011, addresses these challenges in browser-based peer-to-peer (P2P) applications for real-time audio and video communication by integrating Interactive Connectivity Establishment (ICE), STUN, and TURN protocols natively. ^[35] ICE orchestrates connectivity checks to discover viable paths, using STUN for public address reflection and TURN for relaying traffic when direct P2P fails, while Session Description Protocol (SDP) offers exchange ICE candidates—potential IP:port pairs—during the offer/answer negotiation to establish the optimal media path. ^[36] This framework enables seamless VoIP and video calls without plugins, supporting dynamic RTP/RTCP port usage across NAT types in web environments. ^[37] Recent studies on WebRTC over 5G networks highlight low-latency gains, with millimeter-wave (mmWave) deployments achieving up to 80% better round-trip time (RTT) for video compared to sub-6 GHz bands, enhancing real-time collaboration quality. ^[38] However, carrier-grade NAT (CGNAT) in mobile operators introduces hurdles, as GTP tunneling and shared address pools complicate ICE candidate gathering and increase reliance on TURN relays for traversal. ^[38] For instance, applications like Zoom and Microsoft Teams utilize TURN relays for calls behind strict NATs to ensure reliable connectivity. The WebRTC specification mandates ICE implementation for all peer connections to handle NAT traversal robustly. ^[36] Post-2020 enhancements, including standardized simulcast support, allow senders to transmit multiple video quality layers simultaneously, improving adaptability to network variations during traversal without renegotiation. ^[39]

Advanced and Hosted Solutions

Carrier-Grade NAT Traversal

Carrier-Grade NAT (CGNAT), also known as large-scale NAT (LSN), is a form of network address translation deployed by Internet Service Providers (ISPs) at the provider edge, enabling thousands of subscribers to share a limited pool of public IPv4 addresses.^[40] This approach addresses IPv4 address exhaustion by translating private IP addresses from customer equipment to shared public ones, typically supporting ratios of hundreds or even thousands of subscribers per public address.^[41] Unlike traditional end-user NAT, CGNAT operates in the ISP's core network without subscriber access to configuration, ensuring scalability for high-volume traffic while enforcing per-subscriber port quotas to maintain fairness and prevent resource exhaustion.^[40] Key techniques in CGNAT include port block allocation paired with deterministic NAT, as outlined in RFC 7422 (2015).^[42] Port block allocation assigns contiguous ranges of external ports (e.g., 512 ports per subscriber) from a shared public IP pool, allowing efficient multiplexing of connections.^[40] Deterministic NAT enhances this by providing endpoint-independent mapping, where the external IP and port range for a given internal IP are computed algorithmically using a reversible function, independent of the destination.^[42] This mapping ensures that the same internal host always translates to the same external address and port block, facilitating reverse lookups without per-connection logs and reducing storage needs—for instance, eliminating logs for up to 4,032 static port assignments per subscriber.^[42] CGNAT deployments present significant challenges for NAT traversal due to the absence of user control over mappings, as subscribers cannot directly configure ports or access the device.^[40] This requires protocol-level solutions like the Port Control Protocol (PCP), specified in RFC 6887, to enable hosts to request and manage explicit inbound and outbound port mappings.^[43] PCP operates over UDP and allows clients to suggest external ports and lifetimes, though the CGNAT server may override these based on availability, policies, or quotas; for example, the MAP opcode creates dynamic translations, while the PEER opcode handles peer-specific mappings to support applications needing direct connectivity.^[43] Without such mechanisms, applications relying on inbound connections, such as servers or hole-punching protocols, often fail, as implicit mappings are unpredictable in shared environments.^[43] A prominent example of CGNAT application is in 5G core networks, where it conserves IPv4 addresses by aggregating translations at the packet data network gateway (PGW) or user plane function (UPF) for mobile subscribers during the IPv4-to-IPv6 transition.^[44] This setup supports massive device connectivity in scenarios like IoT or high-density urban deployments, sharing public IPv4 pools across thousands of users while prioritizing IPv6 for new allocations.^[44] CGNAT complicates peer-to-peer (P2P) communications by adding a second NAT layer (often NAT444), which disrupts direct endpoint reachability and port predictability essential for protocols like STUN or hole punching.^[15] Applications such as VoIP calls or file sharing may require intermediaries or fail entirely if both peers share the same public IP, increasing latency and dependency on relays.^[15] The IETF recommends accelerating IPv6 migration to eliminate CGNAT reliance, restoring native end-to-end connectivity and avoiding these traversal issues in future networks.^[15]

Relay Servers and Media Relaying

Relay servers provide a fallback mechanism in NAT traversal when direct peer-to-peer connections fail, routing traffic through an intermediary to bypass restrictive network configurations. These architectures extend beyond basic TURN implementations by incorporating selective and hybrid models that optimize resource usage, particularly for real-time applications like video conferencing. Full relay servers forward all traffic between endpoints, ensuring connectivity but at the expense of efficiency, while selective relaying focuses on media streams to minimize overhead. Relay types vary based on the scope of traffic handled. Full relays, such as those defined in the TURN protocol, route all application data through the server, making them suitable for symmetric NATs or firewalls that block direct paths entirely. Selective relays, often used for media-only forwarding, transmit only audio and video streams while allowing control signaling to proceed directly where possible; this approach is common in multiparty scenarios to reduce server load. Multipath relays leverage multiple network paths simultaneously, aggregating bandwidth and providing redundancy by distributing traffic across relays, as outlined in application-level frameworks for enhanced reliability.^[45] Implementations of relay servers typically build on TURN for general-purpose relaying, where clients allocate relay addresses and permissions to forward packets. In WebRTC environments, media-specific relays like Selective Forwarding Units (SFUs) receive incoming streams from participants and forward them selectively to others without decoding, preserving endpoint encoding for lower CPU usage on the server. Multipoint Control Units (MCUs), another partial relaying option, mix media streams centrally but can integrate selective elements for hybrid models, enabling efficient traversal in group communications when direct paths fail. Relay usage impacts performance by introducing additional network hops, typically increasing latency by 50-200 milliseconds depending on server proximity and adding bandwidth overhead as traffic is duplicated through the relay. Cloud-based relays, such as those hosted on AWS or Google Cloud, follow pay-per-use cost models based on data volume and relay duration, often charging for inbound and outbound traffic to cover infrastructure expenses. For instance, Google provides public STUN servers and supports TURN deployment on its cloud platform for free or low-cost WebRTC traversal in development scenarios.^[46]^[25] In practice, relays are employed in 10-30% of WebRTC sessions where STUN-based hole punching fails, particularly in enterprise or mobile networks.^[47] Optimizations in the 2020s have integrated relays with 5G edge computing, deploying them closer to users via edge nodes to mitigate latency and support low-delay applications like augmented reality.^[47]^[48]

Standards and Future Directions

IETF RFCs and Specifications

The Internet Engineering Task Force (IETF) has developed numerous standards addressing Network Address Translation (NAT) and its traversal challenges, with over 50 RFCs referencing NAT in various contexts, reflecting its pervasive impact on network architectures.^[49] Foundational documents include RFC 2663, published in 1999, which provides terminology and considerations for IP Network Address Translators (NATs), defining key concepts such as address mapping and transparent routing for hosts in private networks.^[8] This was followed by RFC 3022 in 2001, which specifies Traditional NAT, encompassing both Basic NAT for one-to-one IP address mapping and Network Address Port Translation (NAPT) for many-to-one mappings using TCP/UDP ports, enabling connectivity from private realms to global IP networks. Traversal-specific standards emerged to mitigate NAT-induced connectivity issues. RFC 5128, from 2008, analyzes peer-to-peer communication across NATs, highlighting problems with protocols like STUN and enumerating traversal methods such as UDP hole punching and relay usage.^[13] RFC 5389, also 2008 and developed under the Middlebox Communication (MIDCOM) working group, defines Session Traversal Utilities for NAT (STUN), a client-server protocol that enables endpoints to discover their public IP addresses and ports, perform connectivity checks, and support keep-alives for NAT bindings.^[50] Later, RFC 6887 in 2013 introduced the Port Control Protocol (PCP), allowing hosts to explicitly manage NAT port mappings, request explicit port allocations, and map external ports for incoming traffic, superseding earlier protocols like NAT Port Mapping Protocol (NAT-PMP).^[43] For IPsec deployments, RFC 3947 (2005) outlines negotiation of NAT-Traversal (NAT-T) within the Internet Key Exchange (IKE), enabling detection of NAT devices between peers and fallback to UDP encapsulation on port 4500 to bypass NAT restrictions on IPsec protocols.^[6] Complementing this, RFC 3948 (2005) details UDP Encapsulation of IPsec ESP Packets, specifying how Encapsulating Security Payload (ESP) packets are wrapped in UDP for traversal through NATs without altering IPsec security. Key updates include RFC 8489 (2018), which obsoletes RFC 5389 by refining STUN with enhanced security features like mandatory message integrity, support for short-term credentials, and improved handling of IPv6 and TLS, while maintaining backward compatibility for NAT discovery and connectivity checks.^[1] Similarly, RFC 8656 (2019) updates Traversal Using Relays around NAT (TURN), defining a relay protocol that allocates relayed transport addresses for clients behind restrictive NATs or firewalls, with mechanisms for channel binding, permissions, and multiplexing to optimize media flows.^[3] As of the IETF datatracker, no major new RFCs focused on core NAT traversal mechanisms have been published since 2020, though ongoing work addresses niche applications.

Considerations for IPv6 and 5G Networks

The adoption of IPv6 addresses the core limitations of IPv4 that necessitated widespread NAT deployment by providing an enormous pool of globally unique IP addresses—approximately 3.4 × 10^38—enabling direct end-to-end connectivity between devices without the need for address translation in most scenarios. This shift eliminates traditional NAT traversal requirements for peer-to-peer communications, as devices can be directly routable on the public internet. However, during the ongoing transition to IPv6, dual-stack configurations—where networks support both IPv4 and IPv6—necessitate hybrid traversal techniques to maintain compatibility, as detailed in RFC 4213, which outlines basic mechanisms for hosts and routers to operate in mixed environments.^[51] Despite these advantages, persistent challenges in IPv6 deployment sustain NAT usage in certain contexts. Transition mechanisms such as 6rd (IPv6 Rapid Deployment, RFC 5969) and DS-Lite (Dual-Stack Lite, RFC 7597) rely on encapsulation and tunneling over IPv4 infrastructures, effectively incorporating NAT-like functions at the provider edge to conserve scarce IPv4 addresses while bootstrapping IPv6. As of November 2025, global IPv6 adoption remains at approximately 45%, meaning a majority of networks still depend on IPv4 and associated NAT for connectivity, particularly in regions with slower rollout.^[52]^[16] In 5G networks, innovations like network slicing and multi-access edge computing (MEC) further evolve NAT traversal by enabling virtualized, isolated network segments and localized processing, which minimize latency and reduce dependence on centralized NAT gateways for real-time applications. A 2023 empirical study on carrier-grade NATs in 5G environments found Interactive Connectivity Establishment (ICE) to be highly effective, achieving direct peer-to-peer connectivity in 75% of tested mobile carrier networks (across four Dutch providers), though carrier-grade NAT continues to persist for IPv4 traffic due to incomplete IPv6 adoption. Looking ahead, protocols such as QUIC (defined in RFC 9000) integrate robust NAT traversal via connection identifiers, which allow seamless handling of IP address changes from NAT rebinding or mobility without session interruption.^[53]^[54] The reliance on NAT has notably delayed full IPv6 adoption by providing a workaround for IPv4 exhaustion, allowing networks to postpone comprehensive upgrades. In contrast, 5G standards from the 3GPP mandate native IPv6 support for core and user plane functions to leverage its scalability, while incorporating NAT64 for stateless translation to ensure compatibility with legacy IPv4-only services and devices.^[55]^[56]

References

[1]
RFC 8489: Session Traversal Utilities for NAT (STUN)
Summary of each segment:
[2]
RFC 7604 - Comparison of Different NAT Traversal Techniques for ...
This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows ...
[3]
RFC 8445 - Interactive Connectivity Establishment (ICE)
This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity ...
[4]
RFC 6314 - NAT Traversal Practices for Client-Server SIP
This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows.
[5]
RFC 3947 - Negotiation of NAT-Traversal in the IKE - IETF Datatracker
This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP ...
[6]
RFC 2663 - IP Network Address Translator (NAT) Terminology and ...
Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts.
[7]
RFC 1631: The IP Network Address Translator (NAT)
The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local ...
[8]
RFC 4787 - Network Address Translation (NAT) Behavioral ...
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP.
[9]
RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
### Summary of NAT Classification from RFC 4787
[10]
RFC 3489: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
Summary of each segment:
[11]
RFC 5128: State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
### Summary of Obstacles NAT Poses to Peer-to-Peer Connectivity (RFC 5128)
[12]
RFC 3235: Network Address Translator (NAT)-Friendly Application Design Guidelines
### Summary of NAT Impacts on Peer-to-Peer Applications (RFC 3235)
[13]
RFC 7021 - Assessing the Impact of Carrier-Grade NAT on Network ...
This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications.Missing: obstacles | Show results with:obstacles
[14]
RFC 3027 - Protocol Complications with the IP Network Address ...
The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known ...
[15]
RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements
### Summary of Incompatibilities Between NAT and IPsec (RFC 3715)
[16]
RFC 7362: Latching: Hosted NAT Traversal (HNT) for Media in Real ...
Background The general problems with NAT traversal for protocols such as SIP are: 1. The addresses and port numbers encoded in SDP bodies (or their ...Missing: challenges | Show results with:challenges
[17]
[PDF] Peer-to-Peer Communication Across Network Address Translators
This paper documents and analyzes one of the simplest but most ro- bust and practical NAT traversal techniques, commonly known as “hole punching.” Hole punching ...Missing: seminal | Show results with:seminal
[18]
[PDF] UDP NAT and Firewall Puncturing in the Wild.
Our results show that UDP hole punching is an effective method to increase the connectability of peers on the Internet: approximately 64% of all peers are ...
[19]
RFC 5128: State of Peer-to-Peer (P2P) Communication across ...
4. Recent Work on NAT Traversal [P2P-NAT] has a detailed discussion on the UDP and TCP hole punching techniques for NAT traversal. [P2P-NAT] also lists ...Missing: seminal papers
[20]
RFC 8656: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
Summary of each segment:
[21]
How to setup your own STUN/TURN server for NAT traversal
Jul 5, 2016 · Success rate is about 80%, but in case of failure of connectivity with STUN it's necessary to have a TURN server as fallback or it will be not ...
[22]
What is a TURN server? (Traversal Using Relays around NAT)
Jun 7, 2025 · TURN vs STUN at a Glance ; Success rate, fails 20-25% of the time. ICE first tries STUN and then as a fallback uses TURN, Always works ...
[23]
RFC 7675 - Session Traversal Utilities for NAT (STUN) Usage for ...
RFC 7675 STUN Usage for Consent Freshness October 2015 response messages that verifies the remote peer's ongoing consent to receive traffic. This consent ...
[24]
[PDF] WANIPConnection:2 Service –Standardized DCP (SDCP)
Sep 10, 2010 · The NAT Traversal or port mapping functionality allows creation of mappings for both TCP and UDP protocols between an external IGD port (called ...
[25]
What Is UPnP and Why Is It a Security Risk? - SecurityScorecard
May 14, 2025 · Recommendations include: Disable UPnP on all routers, gateways, and firewalls. Block inbound and outbound SSDP traffic at the network edge.
[26]
Internet Gateway Device (IGD) V 2.0
The IGD V2.0 is required for UPnP+ certification, provides security enhancements, IPv6 support, and has standardized device and service descriptions.
[27]
RFC 3948 - UDP Encapsulation of IPsec ESP Packets
This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing ...
[28]
How NAT-T Affects MTU - Cisco Learning Network
Feb 16, 2020 · The overhead for NAT-T compared to the same IPSEC encapsulation without NAT-T is (as far as i know) only the 8 byte for the UDP header.MTU in GRE Tunnels - Cisco Learning NetworkTCP, IP MTU, MSS, UDP, GRE fragmentation problemMore results from learningnetwork.cisco.com
[29]
NAT Traversal - strongSwan Documentation
The solution proposed by RFC 3948 is to encapsulate ESP packets in UDP datagrams which then allows to apply Port Address Translation.Missing: details | Show results with:details
[30]
Configure L2TP/IPsec server behind NAT-T device - Microsoft Learn
Jan 15, 2025 · If you must put a server behind a NAT device, and then use an IPsec NAT-T environment, you can enable communication by changing a registry value.
[31]
[PDF] SIP, NAT, and Firewalls - Columbia CS
Each layer uses a pair of RTP and RTCP ports and this example gives a total of four ports. For this. Page 31. Page 31 of 69 scheme to work these ports must be ...
[32]
What is WebRTC (Peer-to-Peer Technology) | PubNub
Mar 6, 2024 · WebRTC, first released by Google in 2011, quickly gained support from major companies like Apple, Microsoft, Mozilla, and Opera. Its ...
[33]
Introduction to WebRTC protocols - Web APIs | MDN
Aug 19, 2025 · ICE uses STUN and/or TURN servers to accomplish this, as described below. STUN. Session Traversal Utilities for NAT (STUN) is a protocol to ...
[34]
[PDF] webrtc-for-the-curious.pdf
The SDP that the two WebRTC agents exchange contains details like: • The IPs ... addIceCandidate allows a WebRTC agent to add more remote ICE Candidates.
[35]
WebRTC over 5 G: A Study of Remote Collaboration QoS in Mobile ...
Oct 24, 2023 · This study aimed to evaluate the actual 5 G capability to achieve high quality of service (QoS) for remote collaboration.
[36]
The Big Churn - learning from real usage stats (Lasse Lumiaho and ...
Apr 8, 2016 · In the WebRTC services that we observe, the failure rate is on average 12%, i.e., 1 in 8 sessions are never set up. However, most failures (85%) ...Typical Webrtc Applications · Webrtc Usage In Numbers · Performance Metrics
[37]
https://webrtcforthecurious.com/docs/webrtc-for-the-curious.pdf
[38]
RFC 6888 - Common Requirements for Carrier-Grade NATs (CGNs)
This document describes behavior that is required of those multi- subscriber NATs for interoperability. It is not an IETF endorsement of CGNs or a real ...
[39]
RFC 7422 - Deterministic Address Mapping to Reduce Logging in ...
This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability ...
[40]
RFC 6887 - Port Control Protocol (PCP) - IETF Datatracker
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator ...Missing: traversal | Show results with:traversal
[41]
LTE / 5G Routers - Explaining Carrier Grade NAT
Dec 14, 2021 · Carrier-Grade NAT (CGNAT) is a network address translation technology used by Internet Service Providers (ISPs) to reduce the consumption of public IPv4 ...
[42]
RFC 8656 - Traversal Using Relays around NAT (TURN)
Feb 21, 2020 · This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to ...<|control11|><|separator|>
[43]
A general framework of multipath transport system based on ...
This paper presents a general framework of multipath transport system based on application-level relay (MPTS-AR), currently under the standardization within the ...<|separator|>
[44]
https://www.mavenir.com/wp-content/uploads/2023/09/Converged-Packet-Core_Solution-Brief.pdf
[45]
WebRTC TURN server: Everything you need to know - 100MS
Oct 17, 2022 · It is estimated that almost 20% of WebRTC call connections require a TURN server to connect, whatever may the architecture of the application be ...Missing: percentage | Show results with:percentage
[46]
Relay-empowered beyond 5G radio access networks with edge ...
This paper proposes the use of relays with edge computing capabilities. The approach's potential for B5G are identified, and a system model is defined.
[47]
The NAT RFCs came after the routing RFC and refer to NAT as a ...
The IETF collectively aren't big fans of NAT as a good solution but that hasn't stopped multiple standards track NAT RFCs per year. v6 only increased this ...
[48]
RFC 5389 - Session Traversal Utilities for NAT (STUN)
STUN is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal.<|control11|><|separator|>
[49]
Why is NAT not Needed in IPv6? - RapidSeedbox
Sep 23, 2025 · NAT is not needed in IPv6 addresses because IPv6 has a vast address space. This allows direct communication between devices, simplifying networks and improving ...
[50]
Transition Mechanisms — RIPE Network Coordination Centre
DS-lite enables an IPv6 device to connect to IPv4 devices and the IPv4 Internet. The main purpose of DS-lite is for the ISP to avoid deploying a public IPv4 ...
[51]
IPv6 Adoption - Google
IPv6 Adoption ... The graph shows the percentage of users that access Google over IPv6. Native: 44.51% 6to4/Teredo: 0.00% Total IPv6: 44.51% | Oct 27, 2025.
[52]
https://www.ripe.net/publications/ipv6-info-centre/deployment-planning/transition-mechanisms/
[53]
[PDF] Mass Adoption of NATs: Survey and experiments on carrier-grade ...
11 years after the launch of IPv6—,. Google statistics show 41.93% of their users having adopted. IPv6 [43] thus it is ...
[54]
How Does NAT Affect the Transition to IPv6 Addressing?
Mar 28, 2025 · NAT has played a crucial role in mitigating IPv4 address exhaustion and supporting Internet growth, it has also contributed to the delayed adoption of IPv6.
[55]
draft-ma-v6ops-5g-ipv6only-01 - Considerations of Gradual IPv6 ...
Aug 29, 2025 · This document describes the approach of gradually deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G networks.