Considerations of IPv6-only Deployment in 5G Mobile Networks

Cellular broadband is one of the primary methods of accessing the Internet. To accommodate this surge in mobile connectivity, IPv6 support became a fundamental requirement. Accordingly, documented the support for IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) architectures. Since Release 99, 3GPP standards have mandated IPv6 support across all radio access and packet-based system variants, a mandate that extends through the 5G era and, absent exceptional circumstances, will apply to all subsequent generations. At the time of writing, IPv6 is widely deployed in mobile networks of operators worldwide, and from a traffic perspective, it has even become dominant in some network segments. However, IPv4-only applications still remain, and ensuring IPv4 service continuity is still required to preserve user experience. Despite this, many mobile operators have deployed IPv6-only networks, or are about to, in their operational environments. The transition to IPv6-only in 3GPP networks has been driven by several factors: the ongoing exhaustion of IPv4 address space, the increased operational complexity and cost of maintaining dual-stack networks, and the desire to simplify network architectures by removing IPv4 protocol stacks. However, this transition cannot be achieved in a single step. The objective of a gradual IPv6-only transition is to ensure the following: Legacy devices and applications that are IPv4-only will continue to operate seamlessly over the IPv6-only network through translation mechanisms such as 464XLAT, enabling uninterrupted access to IPv4-only services and the Internet. Dual-stack capable devices can transition to IPv6-only operation without user-perceptible impact. The IPv6-only network ensures that: Applications on the host function correctly via CLAT (client-side translator) or native IPv6 support; Network bearers and sessions are established as IPv6-only with appropriate translation at the network edge (e.g., PLAT/NAT64); and/or IPv4-only servers and endpoints remain reachable through stateless/stateful translation techniques (e.g., NAT64), thus preserving end-to-end service continuity. IPv6 connectivity should be prioritized as indicated by 3GPP signaling and/or IETF protocols. The IETF has specified a set of tools and mechanisms that can be utilized for transitioning to IPv6-only. Among the several IPv6 transition mechanisms developed to offer IPv4-as-a-Service (IPv4aaS) to ISPs with IPv6-only access and/or core networks (see ), 464XLAT is the most widely deployed solution in mobile networks, distinguishing itself as the predominant approach beyond dual-stack. This document therefore addresses 5G IPv6-only deployment, focusing on the practical deployment of 464XLAT on user plane in 5G networks. It discusses the major issues mobile operators may encounter and potential solutions to address them.

The following terms and abbreviations are used in this document: 464XLAT: IPv6-Only Transition Mechanism (IPv6-to-IPv4 and IPv4-IPv6-IPv4 Translation) 5GC: 5G Core 5GS: 5G System AMF: Access and Mobility Management Function APN: Access Point Name (used in 4G/EPS networks) CLAT: Customer-side translator (XLAT) that compiles with DHCPv6: Dynamic Host Configuration Protocol for IPv6 DN: Data Network DNS64: DNS extension that synthesizes AAAA records from A records DNN: Data Network Name EPS: Evolved Packet System (4G core network) FQDN: Fully Qualified Domain Name gNB: 5G base station (3GPP term) HPLMN: Home Public Land Mobile Network HR: Home-Routed (roaming mode) H-SMF: SMF in the Home PLMN H-UPF: UPF in the Home PLMN IMEI: International Mobile Equipment Identity LBO: Local Break Out NAS: Non-Access Stratum NAT64: Network Address and Protocol Translation 64 ng-eNB: evolved 4G base station (3GPP term) NG-RAN: Next Generation Radio Access Network PCF: Policy Control Function PCO: Protocol Configuration Options (3GPP) PDU: Protocol Data Unit PLAT: Provider-side translator (XLAT) that compiles with PLMN: Public Land Mobile Network RA: Router Advertisement (IPv6 Neighbor Discovery) RAN: Radio Access Network SBA: Service-Based Architecture SLAAC: Stateless Address Autoconfiguration SMF: Session Management Function UDM: Unified Data Management UE: User Equipment, e.g., mobile phone. UPF: User Plane Function VPLMN: Visited Public Land Mobile Network V-SMF: SMF in the Visited PLMN V-UPF: UPF in the Visited PLMN

When dealing with 5G IPv6-only deployment, mobile operators should understand several key concepts that distinguish 5G from 4G. This section provides a brief overview of these concepts and their implications for IPv6-only operation. Understanding these concepts is essential for operators planning to deploy IPv6-only in 5G networks, as they directly impact UE behavior, session establishment, and the coexistence of IPv4 and IPv6 services.

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 (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").

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.

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.

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 and . The PDU session establishment procedure, as specified in , 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.

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 ), 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.

In the Home-Routed (HR) mode, the UE's PDU session is anchored in the home network. The SMF (Session Management Function) in the HPLMN (H-SMF) is responsible for managing the PDU session, while an SMF in the VPLMN (V-SMF) acts as an intermediary. All user-plane traffic belonging to the PDU session is routed back to the home network via the N9 interface between the V-UPF (User Plane Function) and the H-UPF. The H-SMF allocates IP addresses (or IPv6 prefixes) from the home network's address pool, and the H-PCF (Policy Control Function) enforces home network policies.

| (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 ]]>

In the Local Breakout (LBO) mode, the PDU session is anchored in the visited network. The SMF, UPF, and PCF are all located in the VPLMN. IP addresses (or IPv6 prefixes) are allocated by the visited network, and user-plane traffic is offloaded locally at a UPF close to the UE's point of attachment, without traversing the home network.

| (R)AN | |(SEPP) | +--------+ | | +----+ +---+---+ |============|--->| UDM | | | | | | +--------+ | | | N3 | | | | v | | | | +-------+ | | | | | V-UPF | | | | | | (PDU | | | | | |Anchor)| | | | | +---+---+ | | | | | | | | | | N6 | | | | v | | | | +--------+ Traffic | | | | DN |==========> | | | +--------+ | | | +-----------------------------+ +------------------------+ Figure 3: Local Breakout Roaming in 5G ]]> Unlike the Home-Routed mode, the LBO mode provides a more optimized forwarding path with lower latency, as traffic does not need to traverse the inter-PLMN connection back to the home network. This mode is particularly suitable for low-latency services, edge computing applications, and scenarios where local data network access is preferred. Emergency PDU sessions are never established in Home-Routed mode; they are always handled via LBO.

Roaming introduces additional complexity for IPv6-only deployment. In the Home-Routed mode, the home network's NAT64/DNS64 functions can serve the UE regardless of the visited network's IPv6 support, but this may introduce additional latency. In the Local Breakout mode, IPv6-only service continuity depends on the visited network's ability to provide NAT64 and DNS64 functions, which requires coordination between operators and may not be available in all roaming partners. Operators must consider these trade-offs when defining their roaming strategy for IPv6-only subscribers.

This section describes the architecture for deploying 464XLAT-based IPv6-only technology on user plane in 3GPP 5G systems. The 5G System (5GS) defines four types of PDU session: IPv4, IPv6, Ethernet, and Unstructured. For IPv6-only deployment, the PDU session is established as IPv6 type, and the UE is allocated an IPv6 prefix without an IPv4 address. Applications that support native IPv6 can communicate directly over the IPv6 PDU session without translation. For legacy IPv4-only applications, the 464XLAT mechanism provides transparent IPv4 connectivity.

Based on the wireless 3GPP network architecture defined in , 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: The UE establishes an IPv6-only PDU session. The UPF allocates an IPv6 prefix to the UE. The UE activates CLAT (Customer-side Translator) to provide IPv4 connectivity for legacy applications. The UPF (or a separate PLAT element) provides NAT64 and DNS64 functions. IPv4 traffic from the UE is translated by CLAT to IPv6 and sent to the PLAT/NAT64 for translation to IPv4 toward the DN.

For roaming scenarios, two modes are supported.

In the Home Routed mode, the PDU session is anchored in the HPLMN. The UE gets IPv6 prefixes from the home network, and all user-plane traffic is routed back to the home network via the N9 interface between the V-UPF and H-UPF.

| (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) ]]> In this mode: The UE is allocated IPv6 prefixes from the HPLMN. NAT64 and DNS64 are deployed in the home network. The UE activates CLAT locally.

In the Local Breakout (LBO) mode, the PDU session is anchored in the VPLMN. IPv6 prefixes are allocated by the visited network, and user-plane traffic is offloaded locally. In this mode: IPv6 prefixes are allocated by the VPLMN. NAT64 and DNS64 are deployed in the visited network. The UE activates CLAT locally.

| (R)AN | | | |(CLAT)| +---+---+ | | +------+ | | | | N3 | | +------+ v | | |PLAT |-+-------+ | | +------+ | V-UPF | | | +------+ | (PDU | | | |DNS64 |-|Anchor)| | | +------+ +---+---+ | | | | | | N6 | | v | | +--------+ | | | DN | | | +--------+ | +----------------------------+ Figure 6: 5GS IPv6-only Architecture (Local Breakout Roaming) ]]>

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

The basic goal of the deployment solution is to enable IPv6-only capable UEs to access the IPv6-only environment. To achieve this, the following aspects should be carefully considered: DNS64 Server Address: IPv6-only users must be provided with DNS64 server addresses to enable IPv4 name resolution. CLAT Support: The User Equipment (UE) must support the CLAT (Customer-side Translator) functionality to ensure compatibility with IPv4 applications. PLAT/NAT64 Placement: The Provider-side Translator (PLAT) with NAT64 capability can be deployed either within the UPF or as a standalone network element. Roaming Support: For roaming scenarios, the roaming agreement between operators must specify whether NAT64/DNS64 is provided by the HPLMN (Home Routed) or VPLMN (Local Breakout). However, beyond the above technical considerations, there remain several practical challenges. For instance, not all UEs on the market currently support CLAT, and achieving full device compatibility overnight is unrealistic. Additionally, even within a single operator's network, ensuring consistent PLAT deployment across all geographic regions and network segments poses significant operational hurdles. These challenges suggest that a purely architectural approach is insufficient. To address these real-world issues, the deployment strategy generally falls into two main categories: solutions based on 3GPP PCO (Protocol Configuration Options) signaling and those relying on IETF protocols.

The PCO information element is defined in 3GPP TS 24.008 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: the requested PDU session type (IPv4, IPv6, or IPv4v6), IPv6 DNS server address request, and 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.

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: 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. Operational transparency: RAs are observable using standard network diagnostic tools such as tcpdump and Wireshark, facilitating troubleshooting and performance monitoring. 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.

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.

Beyond the technical and architectural challenges discussed in the previous sections, IPv6-only deployment presents significant operational, performance, and service-layer hurdles that operators must address.

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.

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.

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 ), 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.

Operators must consider the operational security implications of IPv6-only deployment. Traditional security monitoring and incident response tools that rely on IPv4 address information may not function correctly in an IPv6-only environment. In addition, the following security aspects require careful attention: CLAT/PLAT DoS risks: The CLAT and PLAT functions may become targets of DoS attacks. Operators should ensure that these functions are deployed with adequate capacity and redundancy, and are monitored for anomalous traffic patterns. NAT64 state table exhaustion: The stateful NAT64 function has a limited session table. An attacker could attempt to exhaust this table by generating a large number of short-lived sessions. Operators should implement appropriate rate-limiting and session timeout policies to mitigate this risk. DNS64 hijacking risks: DNS64 servers are critical for service continuity in IPv6-only networks. Operators should ensure that DNS64 servers are protected against spoofing and cache poisoning attacks, as described in and , and that DNS64 responses are properly validated. IPv6 extension header attacks: IPv6 extension headers can be used to carry malicious payloads. Operators should ensure that their security devices and firewalls are capable of inspecting and filtering IPv6 extension headers, and that they are configured with appropriate policies to mitigate related threats.

This document has no IANA actions.

The comments and suggestions of the following are gratefully acknowledged: Lorenzo Colitti, Jordi Palet.