Considerations of IPv6-only Deployment in 5G Mobile Networks

3.1. Introduction to 3GPP 5GS

A simplified 5G System (5GS) architecture is illustrated in Figure 1. This architecture, defined by 3GPP starting from Release 15, represents a fundamental evolution from the earlier Evolved Packet System (EPS). Unlike the node-centric GPRS core, the 5G Core (5GC) adopts a service-based architecture (SBA), where network functions are modularized and interact via standardized service-based interfaces. The architecture encompasses both the 5G Radio Access Network (NG-RAN), which includes gNBs (5G base stations) and ng-eNBs (evolved 4G base stations), and the 5G Core network. Based on the reference point representation, the 5GC functionality is distributed across several key network functions most notably the AMF, the SMF, and the UPF.¶

                        +-------+         +------+
                        |  AMF  |---------| SMF  |
                    N1/ +----+--+         +------+
                     /       |N2               | N4
                    /        |                 |
            +------+      +------+    N3   +---+--+  N6  +------+
            |      |------| NG-  |---------|      |------|      |
            |  UE  |      | RAN  |         | UPF  |      |  DN  |
            +------+      +------+         +------+      +------+

          Figure 1: Overview of the 5G System (5GS) Logical Architecture

AMF (Access and Mobility Management Function): The AMF is the central control-plane node in the 5GC. It terminates the N1 and N2 interfaces and is responsible for registration, connection, and mobility management. It also provides authentication and authorization for UE access and routes session management messages between the UE and the SMF.¶

SMF (Session Management Function): The SMF is responsible for session management, including the establishment, modification, and release of PDU sessions. It selects and controls the UPF, allocating UE IP addresses and managing QoS policy and charging rules.¶

UPF (User Plane Function): The UPF is the anchor point for user-plane data handling. It performs packet routing and forwarding, QoS enforcement, and traffic accounting. It serves as the gateway to the external Data Network (DN) via the N6 interface. For an IPv6-only deployment, the UPF is the key node that interacts with the translation function (e.g., PLAT) to provide IPv4 connectivity services.¶

N1: The reference point between the UE and the AMF. It carries NAS (Non-Access Stratum) signaling for mobility and session management.¶

N2: The reference point between the NG-RAN and the AMF. It carries control-plane signaling for radio access and mobility management.¶

N3: The reference point between the NG-RAN and the UPF. It carries user-plane data between the radio access network and the core network.¶

N4: The reference point between the SMF and the UPF. It is used for the SMF to control the UPF, including the provisioning of packet detection, forwarding, and QoS rules.¶

N6: The reference point between the UPF and the external Data Network (DN). It is the interface for user data to and from the internet or other networks.¶

The 5G System introduces several concepts that are crucial for mobile operators. These concepts are particularly relevant when planning an IPv6-only deployment. The PDU Session is the fundamental connectivity service in 5G, equivalent to the PDN connection in 4G. During PDU session establishment, the UE can request a specific session type (IPv4, IPv6, IPv4v6, Ethernet, or Unstructured). For an IPv6-only deployment, the UE can request an IPv6-only PDU session, and the SMF allocates an IPv6 prefix (via SLAAC or DHCPv6) without assigning an IPv4 address. The DNN (Data Network Name) serves as an FQDN identifying a specific data network and resolves to a set of UPFs. The SMF uses the DNN to select the appropriate UPF and determine the PDU session type. An operator may define multiple DNNs, each providing connectivity to a different DN (e.g., "Internet", "IMS", "Enterprise").¶

3.2. Data Network Name

The Data Network Name (DNN) is a Fully Qualified Domain Name (FQDN) that identifies a specific data network to which a UE requests connectivity. It resolves to a set of gateways or UPFs (User Plane Functions) in a 5G operator's network. DNNs are expressed as FQDNs and leverage the DNS namespace for service discovery. In the context of IPv6-only deployment, the DNN plays a critical role: the SMF selects the appropriate UPF and determines the PDU session type (IPv4, IPv6, or IPv4v6) based on the requested DNN and the UE's capabilities.¶

3.3. PDU Session

The Protocol Data Unit (PDU) session is the fundamental connectivity service in 5G, equivalent to the PDN connection in 4G. It establishes a logical connection between the UE and a Data Network (DN) identified by a DNN. Each PDU session can be of a specific type: IPv4, IPv6, IPv4v6, Ethernet, or Unstructured. For IPv6-only deployment, the UE can request an IPv6-only PDU session, and the SMF can allocate an IPv6 prefix (via SLAAC or DHCPv6) without assigning an IPv4 address. Multiple PDU sessions can be established simultaneously, potentially to different DNNs with different session types, enabling flexible service delivery.¶

3.4. IP Connectivity in 3GPP 5G

IP connectivity in 5G is provided over the user plane, which is carried over the N3/N6 interfaces between the Radio Access Network (RAN), UPF, and DN. The 5G system supports both IPv4 and IPv6 addressing. For IPv6, the UE can obtain IPv6 prefix(es) through IPv6 Stateless Address Autoconfiguration (SLAAC) or DHCPv6, as defined in [RFC4862] and [RFC8415]. The PDU session establishment procedure, as specified in [TS23502], allows the UE to indicate its requested PDU session type. If the UE only requests an IPv6 PDU session and the network supports it, the SMF allocates an IPv6 prefix and the UE is expected to operate without an IPv4 address. In the context of IPv6-only deployment, the key consideration is how the network handles IPv4 traffic by leveraging 464XLAT (CLAT/PLAT) mechanisms to ensure seamless access to IPv4-only services.¶

3.5. 5G Roaming

Roaming in 5G systems occurs when a User Equipment (UE) attaches to a Visited Public Land Mobile Network (VPLMN) that is not its Home PLMN (HPLMN). Similar to earlier generations (see [RFC6459]), 5G roaming can be categorized into two primary scenarios:¶

• International roaming: a UE enters a visited network operated by a different operator with a different PLMN code. The UE may attach to the VPLMN either automatically (based on operator-controlled PLMN selection policies) or manually (based on user selection).¶

• Intra-PLMN mobility: an operator may operate multiple PLMN codes. A UE may be configured with the codes identifying its HPLMN or Equivalent HPLMN (EHPLMN). Intra-PLMN mobility allows the UE to move across different areas within the HPLMN or EHPLMN. When the subscriber profile is not available in the visited area, the UDM (in 4G terminology, the HLR/HSS) in the home network provides the necessary subscription data to the visited network functions to complete registration.¶

The following subsections describe two primary roaming modes for PDU sessions in 5G: Home-Routed and Local Breakout.¶

        +----------------------------+            +-----------------------+
        |Visited Network (VPLMN)     |            |Home Network (HPLMN)   |
        |  +----+        +-------+   |   N32      |    +--------+         |
        |  | UE |=======>| (R)AN |   |(SEPP)      |    |  H-SMF |         |
        |  +----+        +---+---+   |============|--->|        |         |
        |                  |         |            |    +--------+         |
        |                  | N3      |            |         |             |
        |                  v         |            |    +----+----+        |
        |              +-------+     |            |    | H-UPF   |        |
        |              | V-UPF |     |            |    | (PDU    |        |
        |              +---+---+     |            |    | Anchor) |        |
        |                  |         |            |    +----+----+        |
        |                  | N9      |            |         |             |
        |                  +===============================>|             |
        |                            |            |         | N6          |
        |                            |            |         v             |
        |                            |            |    +--------+ Traffic |
        |                            |            |    |   DN   |=========>
        |                            |            |    +--------+         |
        +----------------------------+            +-----------------------+

          Figure 2: Home-Routed Roaming in 5G

        +-----------------------------+            +------------------------+
        |Visited Network (VPLMN)      |            |Home Network (HPLMN)    |
        |  +----+        +-------+    |   N32      |                        |
        |  | UE |=======>| (R)AN |    |(SEPP)      |    +--------+          |
        |  +----+        +---+---+    |============|--->|  UDM   |          |
        |                  |          |            |    +--------+          |
        |                  | N3       |            |                        |
        |                  v          |            |                        |
        |              +-------+      |            |                        |
        |              | V-UPF |      |            |                        |
        |              | (PDU  |      |            |                        |
        |              |Anchor)|      |            |                        |
        |              +---+---+      |            |                        |
        |                  |          |            |                        |
        |                  | N6       |            |                        |
        |                  v          |            |                        |
        |             +--------+ Traffic           |                        |
        |             |   DN   |==========>        |                        |
        |             +--------+      |            |                        |
        +-----------------------------+            +------------------------+

          Figure 3: Local Breakout Roaming in 5G

4.1. Non-roaming Scenarios

Based on the wireless 3GPP network architecture defined in [RFC6877], the architecture is depicted in Figure 4. In the non-roaming scenario, the UE connects to its Home PLMN (HPLMN) directly. The User Plane Function (UPF) serves as the PDU Session Anchor and handles the user plane path of the PDU session. The UPF acts as a gateway between 5G devices and external networks (like the Internet), including IPv6 prefix assignment function. In this case, the CLAT function is deployed on the UE, while the PLAT/stateful NAT64 function and DNS64 function are deployed on the network side.¶

In this architecture:¶

1. The UE establishes an IPv6-only PDU session.¶

2. The UPF allocates an IPv6 prefix to the UE.¶

3. The UE activates CLAT (Customer-side Translator) to provide IPv4 connectivity for legacy applications.¶

4. The UPF (or a separate PLAT element) provides NAT64 and DNS64 functions.¶

5. IPv4 traffic from the UE is translated by CLAT to IPv6 and sent to the PLAT/NAT64 for translation to IPv4 toward the DN.¶

            +-------+  +------------+      _________
            |UE     |  |5GC(HPLMN)  |     /         \
            |+----+ |  |  +-----+   |    /    DN     \
            ||CLAT| +--+--+UPF  +---+---+  (Internet)|
            |+----+ |  |  +-----+   |    \          /
            +-------+  +---/-----\--+     +--------+
                         /       \
                       +------+  +------+
                       |PLAT  |  |DNS64 |
                       +------+  +------+

          Figure 4: 5GS IPv6-only Architecture (Non-roaming)

4.2. Roaming Scenarios

For roaming scenarios, two modes are supported.¶

          +----------------------------+            +------------------------+
          |Visited Network (VPLMN)     |            |Home Network (HPLMN)    |
          | +------+       +-------+   |            |    +--------+          |
          | |  UE  |======>| (R)AN |   |            |    |  SMF   |          |
          | |(CLAT)|       +---+---+   |============|--->|        |          |
          | +------+         |         |            |    +--------+          |
          |                  | N3      |            |         |              |
          |                  v         |            |    +----+---+ +------+ |
          |              +-------+  N9 |            |    |  UPF   |-|DNS64 | |
          |              | V-UPF |-----+------------+----+ (PDU   | +------+ |
          |              +---+---+     |            |    | Anchor)| +------+ |
          |                            |            |    +----+---+-|PLAT  | |
          |                            |            |         | N6  +------+ |
          |                            |            |         v              |
          |                            |            |    +--------+          |
          |                            |            |    |   DN   |          |
          |                            |            |    +--------+          |
          +----------------------------+            +------------------------+

          Figure 5: 5GS IPv6-only Architecture (Home Routed Roaming)

            +----------------------------+
            |Visited Network (VPLMN)     |
            |  +------+      +-------+   |
            |  | UE   |=====>| (R)AN |   |
            |  |(CLAT)|      +---+---+   |
            |  +------+        |         |
            |                  | N3      |
            |     +------+     v         |
            |     |PLAT  |-+-------+     |
            |     +------+ | V-UPF |     |
            |     +------+ | (PDU  |     |
            |     |DNS64 |-|Anchor)|     |
            |     +------+ +---+---+     |
            |                  |         |
            |                  | N6      |
            |                  v         |
            |             +--------+     |
            |             |   DN   |     |
            |             +--------+     |
            +----------------------------+

          Figure 6: 5GS IPv6-only Architecture (Local Breakout Roaming)

4.3. Summary of Network Capabilities

The following table summarizes the 5GC network capabilities required for each scenario.¶

              +------------------+-----+-------------+---------------+
              |Scenario          |UE   |Home Network |Visited Network|
              +------------------+-----+-------------+---------------+
              |Non-roaming       |CLAT |NAT64,DNS64  |    N/A        |
              +------------------+-----+-------------+---------------+
              |Roaming with Local|CLAT |NAT64,DNS64  |NAT64,DNS64    |
              |Breakout          |     |             |               |
              +------------------+-----+-------------+---------------+
              |Roaming with Home |CLAT |NAT64,DNS64  |    N/A        |
              |Routed            |     |             |               |
              +------------------+-----+-------------+---------------+

              Table 1. Network Capabilities for IPv6-only 5G Scenarios

5.1. PCO-based Capability Negotiation for IPv6-only Deployment

The PCO information element is defined in 3GPP TS 24.008 [TS24008] and is used to carry configuration parameters related to IP protocols between the UE and the network during session establishment procedures. The PCO is structured as a container that can include multiple protocol configuration options, each identified by a protocol identifier.¶

In the context of 5G PDU session establishment, the PCO is carried in NAS messages such as PDU SESSION ESTABLISHMENT REQUEST and PDU SESSION ESTABLISHMENT ACCEPT. The PCO allows the UE to request specific IP configuration parameters (e.g., DNS server addresses) and to indicate its capabilities to the network.¶

Specifically, the UE includes the following information in the PCO field of the PDU Session Establishment Request message:¶

1. the requested PDU session type (IPv4, IPv6, or IPv4v6),¶

2. IPv6 DNS server address request, and¶

3. optionally, terminal capability indicators such as CLAT support and operating system version.¶

Upon receiving the request, the SMF (Session Management Function) parses the PCO, evaluates the UE's requested session type against the subscription data retrieved from the UDM and the operator's local policy (e.g., DNN-specific IPv6-only configuration), and determines the final PDU session type to be allocated. For an IPv6-only DNN configuration, the SMF instructs the UPF to allocate only an IPv6 prefix without assigning any IPv4 address and returns the corresponding PDU session establishment response to the UE. Upon receiving the IPv6-only PDU session, the UE automatically activates its local CLAT functionality to provide a virtual IPv4 interface for legacy applications, thereby ensuring seamless compatibility with IPv4-only services. This PCO-based negotiation mechanism enables operators to implement IPv6-only services on a per-DNN or per-subscriber basis with minimal impact on existing UE implementations.¶

Note that no standard defines the specific parameters or procedures for PCO-based IPv6-only capability negotiation. The approach described in this section is provided for informational purposes, giving operators a practical reference for implementing this mechanism in their networks.¶

5.2. RA-based Capability Negotiation for IPv6-only Deployment

The IPv6 Neighbor Discovery Router Advertisement (RA)-based mechanism provides a comprehensive set of configuration options for IPv6-only UEs in 5G networks. Unlike PCO-based signaling, which is confined to 3GPP access and requires encoding configuration parameters in NAS messages between the UE and the SMF, RA-based signaling operates at the network layer and is access-agnostic. This enables a unified configuration framework across cellular, Wi-Fi, fixed, and satellite networks, and more importantly, decouples the IP-layer configuration from the 3GPP core network control plane.¶

In the context of 5G network deployment, these RA options are delivered to the UE via the user plane after PDU session establishment. Specifically, the network infrastructure including the UPF and gNBs is configured to periodically send Router Advertisements on the link to which the UE is attached. These RAs can carry the PREF64 option, which advertises the NAT64 prefix(es) deployed in the network, and the DNS RA Option, which provides DNS64 server addresses. Upon receiving these RAs, the UE can discover the necessary translation parameters without relying on 3GPP-specific signaling.¶

Compared to the PCO-based approach, the RA-based mechanism offers several distinct advantages for large-scale IPv6-only deployment:¶

1. Dynamic configuration updates: when the network introduces a new NAT64 prefix or changes DNS64 server addresses, the updated information is propagated via periodic RAs, allowing UEs to adapt without session re-establishment or PDU session modification.¶

2. Operational transparency: RAs are observable using standard network diagnostic tools such as tcpdump and Wireshark, facilitating troubleshooting and performance monitoring.¶

3. Alignment with Local Breakout roaming: UEs can discover visited network translation services directly via RAs, reducing inter-operator signaling dependencies.¶

At the time of writing, the RA-based mechanism has not yet been deployed in mobile networks. Whether this approach should be adopted for large-scale IPv6-only deployment remains an open question and requires further discussion among operators, vendors, and standardization bodies. Key considerations include the trade-offs between architectural simplicity and operational readiness. The RA-based approach requires that 5G systems support the delivery of RAs over the user plane, and that UEs are capable of receiving and processing these RA options, which may not be universally available in current deployments.¶

5.3. DNN Isolation for Testing

In 5G networks, DNN serves as the primary identifier for a data network to which a PDU session is established, equivalent to the APN in 4G networks. This capability can be leveraged to create isolated testing environments for IPv6-only service validation without impacting production network traffic.¶

As operators progressively deploy IPv6-only services in 5G networks, comprehensive testing becomes essential to ensure that all network functions including IPv6 address allocation, DNS64 provisioning, NAT64 prefix discovery, and CLAT behavior operate correctly across diverse scenarios.¶

The DNN isolation mechanism operates by provisioning a dedicated DNN specifically for testing purposes. This test DNN is configured with the same IPv6-only service parameters as the production DNN but is isolated from production traffic at the network level through separate UPF selection, independent policy configuration, and traffic segregation. PDU sessions established using the test DNN are logically separated from those using the production DNN, enabling controlled observation of test results without cross-contamination. Operators should note that not all core network equipment vendors support this granularity of isolation; compatibility with the existing infrastructure should be verified before deployment.¶

6.1. Operational and Organizational Challenges

In large operator environments, mobile core teams, IP network teams, and device procurement teams often operate as separate organizations with distinct priorities and release cycles. Coordinating across these teams to deploy IPv6-only capabilities requires substantial effort and alignment. Additionally, operators must develop new operational procedures for monitoring, troubleshooting, and maintaining IPv6-only networks. Traditional diagnostic tools and practices that rely on IPv4 addressing may no longer be applicable, and network operations teams must be trained on IPv6-specific debugging techniques.¶

6.2. NAT64 Performance Degradation

NAT64 translation introduces performance implications compared to native IPv4 forwarding. The stateful translation between IPv6 and IPv4 requires additional header conversion, checksum recalculation, and session state management, which consumes memory and processing resources. Experimental studies have shown that while NAT64 can offer certain performance improvements in specific metrics, the overall processing overhead remains a concern for large-scale carrier deployments. The NAT64 gateway must be carefully dimensioned to handle peak traffic loads, and high-availability configurations are necessary to avoid single points of failure. Operators must therefore carefully evaluate NAT64 performance characteristics including throughput, latency, and session capacity and dimension the translation function appropriately to meet their service requirements.¶

6.3. Impact on IPv4-Address-Aware Services

Many existing 5G services including content filtering, parental controls, geo-fencing, application-aware traffic steering, and subscriber analytics have been designed with the assumption that the subscriber's IP address is an IPv4 address that can be directly examined and acted upon. In an IPv6-only environment with NAT64 translation, these services no longer see the subscriber's original IPv4 address; instead, they see the IPv6 address synthesized by the CLAT. For services that perform deep packet inspection, the IPv4 address is embedded within the lower 32 bits of the IPv6 address (as defined in [RFC6052]), but existing service logic typically expects to find the IPv4 address in the IPv4 header. These services therefore require modification to extract the embedded IPv4 address from the IPv6 source address field. For services that rely on the ipv4only.arpa discovery mechanism, this issue can be mitigated by using the PREF64 option, but existing service logic still requires adaptation. Operators must undertake a comprehensive audit of their value-added service portfolio to identify all services that depend on IPv4 address information and implement the necessary adaptations, which represents a significant operational effort spanning multiple service domains and may require coordination with third-party service providers.¶