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 accordingly. 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 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),and may get additional IPv6 prefixes via DHCPv6, as defined in [RFC4862] and [RFC9915]. 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-based User Isolation

In 5G networks, the Data Network Name (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 fundamental concept can be leveraged not only for testing but also as a production-grade mechanism to separate IPv6-only users from legacy dual-stack users within the same operator network.¶

The DNN provides operators with a flexible tool to control the IP configuration and services offered to different groups of UEs. By provisioning multiple DNNs with distinct characteristics, an operator can achieve fine-grained isolation:¶

During PDU session establishment, the SMF selects the appropriate PDU session type and UPF based on the requested DNN, subscription data retrieved from the UDM, and local operator policies. For IPv6-only DNNs, the SMF instructs the UPF to allocate only an IPv6 prefix without assigning any IPv4 address and provides DNS64 server addresses. For dual-stack DNNs, standard DNS resolvers are used.¶

In a phased deployment, the operator creates a dedicated IPv6-only DNN for the pilot group. Initially, only a small set of test subscribers are provisioned with this DNN. As confidence grows, the operator gradually moves more subscribers to this DNN by updating their subscription profiles. Legacy DNNs are retained for backward compatibility. This approach provides clean separation between user groups, preventing unnecessary load on NAT64 gateways, while also enabling isolated testing of IPv6-only services without impacting production traffic.¶

5.4. IMEI Configuration at Network Side

One solution is to enhance the core network's capability to configure IP addresses and DNS server addresses based on IMEI number ranges. The IMEI (International Mobile Equipment Identity) is a unique sequence of 14 to 15 digits assigned to each mobile phone. It serves as a device identification number, enabling service providers to recognize the phone within the network. The primary purpose of the IMEI is to uniquely identify each device, allowing the network to determine whether the UE supports CLAT functionality. By configuring a whitelist of IMEIs that support CLAT functionality in the network, the network can assign an IPv6-only environment to UEs listed in the whitelist.¶

This approach can be implemented in 5G networks by leveraging the subscription data in the UDM, which can include IMEI-based policy rules. When a UE initiates registration, the AMF obtains the IMEI and provides it to the SMF during PDU session establishment. The SMF can query the UDM to check if the IMEI is in the CLAT-capable whitelist, and if so, allocate an IPv6-only PDU session (with appropriate DNS64 configuration) for that UE. This method provides device-specific targeting without requiring per-user subscription changes, and once the whitelist is configured, the network can automatically provision IPv6-only sessions for qualifying devices.¶

However, the IMEI-based approach has notable limitations:¶

• IMEI spoofing risks: IMEI numbers can be spoofed or modified on some devices, potentially undermining the reliability of the mechanism.¶
• Whitelist maintenance overhead: Keeping the IMEI whitelist up to date as new devices enter the market and existing devices receive software updates that add or remove CLAT support requires ongoing operational effort.¶
• Lack of dynamic capability discovery: The approach relies on a static database rather than real-time capability negotiation, which may not reflect the actual CLAT status of the device at the time of connection.¶

7.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.¶

7.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.¶

7.3. DNS64 RA Deployment Contexts

In environments where operators are migrating towards IPv6-only access networks while still supporting a large base of dual-stack subscribers, IPv6-only hosts require DNS64 to reach IPv4-only content, whereas dual-stack hosts should continue using standard resolvers to avoid unnecessary load on NAT64 gateways. When DNS server addresses are advertised via RDNSS (RFC 8106), all hosts receive the same set of resolvers, making it impossible for IPv6-only hosts to distinguish which resolvers are DNS64-capable, and causing dual-stack hosts to inadvertently send queries to DNS64 servers, thereby increasing the volume of traffic that must be translated by the NAT64 device. For phased rollouts where operators wish to gradually direct a percentage of IPv6-only subscribers to DNS64 resolvers, using RDNSS alone requires complex per-user provisioning or network-wide changes that affect all subscribers simultaneously.¶

7.4. 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 synthesized IPv6 address. 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 NAT64 prefix discovery mechanisms defined in [RFC7050] and [RFC8880], 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.¶