Introduction As enterprises and government organisations accelerate their transition to IPv6, platform compatibility becomes a critical requirement for mission-critical analytics systems. While IPv6 adoption is progressing rapidly, particularly in the Public Sector and other heavily regulated industries, many data platforms  including Cloudera on-premises deployments, still primarily operate on IPv4 networks. Cloudera is progressing towards full IPv6 and dual-stack support. However, current on-premises deployments are IPv4-based, and native IPv6 client access is not yet supported in production. To address immediate customer demand, especially from customers operating in IPv6-only or IPv6-preferred networks, we validated a practical interim solution; routing IPv6 client traffic through an F5 BIG-IP Virtual Edition (VE) and forwarding it to an IPv4-only Cloudera on-premises deployment running on AWS. This blog summarizes the architecture, validation outcomes, and real-world applicability of this approach, along with references to the detailed technical setup document  used in this field validation. The Challenge: IPv6 Clients vs. IPv4-Only Data Platforms Many regulated and government environments are mandated to support IPv6-only or IPv6-preferred client networks, along with centralized ingress through enterprise-grade load balancers and strict security controls. At the same time, most enterprise data platforms including current Cloudera on-premises releases expect IPv4 connectivity for: Cloudera Manager Knox Gateway Hue Cloudera Data Warehouse, Cloudera Data Engineering, Cloudera AI and other service endpoints As a result, IPv6 clients cannot directly access IPv4-only service endpoints. Bridging this gap without redesigning the entire platform network stack was the primary objective of this field validation. Solution Overview: IPv6 to IPv4 Bridging via F5 BIG-IP VE The F5 BIG-IP Virtual Edition serves as an ingress layer to enable seamless access for IPv6 clients, performing the following key functions: Listening for IPv6 traffic on the client-facing side. Forwarding traffic towards Cloudera services using IPv4. Handling TLS termination and re-encryption. Providing optional functionality for URL rewriting and traffic steering via iRules. High-Level Architecture Key components: F5 BIG-IP VE deployed in an IPv6-enabled VPC Cloudera on premises environment running in an IPv4 VPC VPC peering between F5 VPC (IPv6) and Cloudera VPC (IPv4) Route tables configured to allow bidirectional traffic flow Virtual Servers on F5 listening on IPv6 and forwarding to IPv4 pool members iRules to handle application-specific routing and URL normalisation (where required) From the client perspective, all Cloudera services are accessed using IPv6 DNS names, while internally the traffic is translated and routed to IPv4 endpoints. Scope of this field validation This field validation focused on validating both connectivity and functional correctness across key Cloudera services. Connectivity Validation IPv6 client access to F5 virtual servers Successful forwarding to IPv4-only Cloudera service endpoints TLS handshake and certificate validation through F5 End-to-end application access via browser and API calls Application-Level Validation The following services were accessed successfully through the IPv6 path: Cloudera Manager UI, Knox Gateway, Hue UI, ECS Console, Data Services UIs (Cloudera Data Warehouse, Cloudera Data Engineering, Cloudera AI) This confirmed that: No application-level dependency required native IPv6 on the Cloudera side The F5 layer could transparently bridge the protocol difference without impacting user experience End-to-End Functional Validation Using Project Axon Using an End-to-End use-case, the deployment was validated across the full analytics lifecycle, covering secure ingestion, distributed processing, SQL analytics, and visualization on Cloudera on premises environment running on AWS. Specifically, the Bank Branch Performance Analytics use case from Project Axon was executed to validate real-world behaviour across services: Data Ingestion: Apache NiFi ingested data from a dummy Python-based generator across multiple datasets and persisted it into HDFS/Ozone, validating secure and stable ingestion. Data Processing & Engineering: Virtual Clusters were provisioned using Cloudera Data Engineering. Authentication was configured using keytabs, and Spark jobs were executed for data transformation and summarization, with Airflow pipelines orchestrating the workflows. Analytics & SQL: As part of this field validation, Hive and Impala Virtual Warehouses were enabled using Cloudera Data Warehouse, with interactive queries executed via Hue on data ingested by NiFi and processed by Cloudera Data Engineering Spark jobs. End-to-End Outcome: Analytics results were visualized using Cloudera Data Visualization by creating dashboards such as best-performing branches, revenue contribution per branch, and call center records analysis, confirming correct data flow across all layers. Why F5 BIG-IP Is Well-Suited for This Use Case F5 BIG-IP is commonly deployed in enterprise and regulated environments such as Public Sector and Finance, and provides several advantages for this scenario: Dual-Stack Traffic Handling Supports IPv6 listeners with IPv4 backend pools Acts as a protocol and address family bridge Enterprise Security Controls Centralized TLS termination Integration with enterprise PKI Advanced traffic inspection and policy enforcement Flexible Traffic Steering with iRules Some Cloudera services require: URL path normalization Host header rewrites Service-specific routing logic iRules provide fine-grained control to handle such cases without modifying the application. Operational Considerations While this approach is effective, there are important operational aspects to consider: DNS Strategy Two supported options were validated: Enterprise DNS (Recommended for Production) Create DNS records pointing to F5 external IPv6 and IPv4 interfaces Use service-specific ports and paths for access Local Hosts File (POC / Testing Only) Map DNS names to F5 IPv6 and IPv4 addresses locally Useful for quick validation without DNS changes Routing and VPC Design VPC peering must support cross-VPC IPv6 to IPv4 routing Route tables must be explicitly updated on both sides Security groups and NACLs must allow required service ports Certificate Management Certificates must be trusted by clients when terminated at F5 Backend re-encryption requires trusted certificates on Cloudera endpoints When Should This Architecture Be Used? This solution is best suited for: Public Sector and other heavily regulated customers with IPv6 mandates Enterprises migrating towards IPv6 but running legacy IPv4 platforms Scenarios where platform upgrades cannot be blocked by networking constraints It is intended as a transitional architecture until native dual-stack support is available across the Cloudera platform. Once full IPv6 support becomes available, organizations can simplify the architecture by allowing direct IPv6 connectivity to service endpoints. Key Outcomes and Learnings This field validation demonstrated that: IPv6 client access to Cloudera is feasible today without modifying the platform F5 BIG-IP can reliably bridge IPv6 to IPv4 for complex enterprise data services All major Cloudera UIs and APIs function normally through the translated path Enterprise security and compliance requirements can be preserved Most importantly, it provides customers with a practical deployment option that aligns with networking mandates while maintaining platform stability. Conclusion As IPv6 adoption accelerates, especially in government and regulated sectors, data platforms must adapt to new network realities. While native IPv6 enablement in complex distributed platforms requires significant engineering effort, customers still need workable solutions today. This field validation demonstrates a proven, production-aligned approach to enable IPv6 client connectivity to Cloudera on-premises deployments using F5 BIG-IP as a protocol bridge. It allows enterprises to move forward with IPv6 adoption without delaying analytics modernization initiatives. With engineering work underway towards full dual-stack support, this architecture serves as a reliable interim strategy ensuring business continuity, regulatory compliance, and operational stability during the transition period. ... View more