IPv6 in Redis Software: Configuration, Troubleshooting, and Best Practices

Redis Software supports full IPv6 internal cluster communication (cluster management traffic) for new clusters starting with Redis Software 7.4.2. Earlier versions support IPv6 for some external endpoints (for example, Envoy listeners for the UI and APIs), but this guide focuses on 7.4.2+, where IPv6 is fully supported across the Redis Enterprise ecosystem (including features such as Active-Active CRDBs).

IPv6 enables scalable, modern networking for self-managed and Kubernetes-based Redis Software clusters.
This guide explains how IPv6 works in Redis Software, how to enable and configure it, and how to troubleshoot common connectivity and compatibility issues. It also summarizes known limitations and operational best practices.

Key sections include Architecture and Traffic Overview, Enabling and Configuring IPv6, Step-by-Step Configuration Examples, Troubleshooting IPv6 Issues, and Best Practices for IPv6 Deployments.

Architecture and Traffic Overview

Redis Software distinguishes between internal and external IPv6 traffic:

• Internal traffic: Communication between cluster nodes for management, replication, and failover.

• External traffic: Client connections to databases and access to the Cluster Manager UI.

If a node has a single IP address, it serves both roles. On multi-IP systems, you can assign separate addresses for internal and external communication.

Enabling and Configuring IPv6

Prerequisites

• Redis Software 7.4.2 or later.

• All nodes must include IPv6 interfaces for full IPv6 clusters.

• IPv6 must be enabled at the operating system level.

• For Kubernetes, use a supported CNI plugin and Kubernetes version with IPv6 capability.

See official IPv6 configuration documentation for detailed platform requirements.

Cluster Creation (Self-Managed)

• IPv6 internal traffic is supported only for new clusters and cannot be enabled post-creation.

• To bootstrap a new IPv6 cluster, set use_internal_ipv6: true in the Bootstrap REST API request.

• Each node must include a ::1 localhost entry in /etc/hosts.

Example:

POST /v1/bootstrap/create_cluster { "action": "create_cluster", "cluster": { "name": "cluster.fqdn" }, "credentials": { "username": "admin", "password": "password" }, "node": { "identity": { "addr": "2001:DB8::/32", "external_addr": ["2001:0db8:85a3:0000:0000:8a2e:0370:7334"], "use_internal_ipv6": true } } } 

Note: In the example above, addr should be a valid unicast IPv6 address assigned to the node, not a CIDR range. For example, use a host address like 2001:db8::10 rather than a network prefix.

When you join additional nodes to an IPv6 cluster, do not set use_internal_ipv6 manually in the join request. Joining nodes automatically inherit the cluster’s internal IP family. Manually forcing a mismatched value can cause NodeBootstrapError (for example, joining a node without an IPv6 interface to a cluster where use_internal_ipv6 is true, or vice versa).

For reference, see the Cluster Bootstrap API.

Cluster Creation (Kubernetes/REC)

• Use the redisEnterpriseIPFamily field in the RedisEnterpriseCluster (REC) Custom Resource to select the IP family (IPv4 or IPv6) when the Kubernetes cluster has dual-stack networking enabled. Originally introduced in operator 7.2.4-12 for dual-stack environments, this field is now officially documented and supported in 7.4.2-12 and later. The CRD still describes this field as “reserved, future use — only for use if instructed by Redis,” but it is actively used in production when explicitly enabled by design.
  Refer to Kubernetes IPv6 release notes for compatibility details.

Adding Nodes and Managing External Addresses

• Assign one IPv6 address for internal communication and optional IPv4/IPv6 addresses for external access.

• Use Cluster Manager UI or REST API to join nodes with the correct address type.

• To modify external addresses, run:

  rladmin node <ID> external_addr add|set|remove <IPv6 address>
  See the rladmin cluster config reference.

DNS and Endpoints

• Ensure DNS records are configured correctly for your IP family:

  • For IPv4-only clusters, use A records.

  • For IPv6-only clusters, use AAAA records.

  • For dual-stack clusters, provide both A and AAAA records, and confirm clients resolve the expected family.

• For Kubernetes deployments, validate that Services and Ingress/Routes are IPv6-aware and that dual-stack DNS entries (A + AAAA) resolve correctly from both application pods and external clients.

Step-by-Step: Changing an Internal IP Address

You cannot switch an existing cluster from IPv4 to IPv6 (or vice versa). You can only change the address within the same protocol.

1. Demote the node: rladmin node <ID> enslave demote_node

2. Disable the supervisor service: systemctl disable rlec_supervisor

3. Change the IP address at the OS level and reboot the node.

4. Update the node address from another node: rladmin node <ID> addr set <new_IPv6_address>

5. Re-enable the supervisor: systemctl enable rlec_supervisor systemctl start rlec_supervisor

6. Confirm the node rejoins the cluster: rladmin status nodes

Troubleshooting IPv6 Issues

Known Limitations

• Internal IPv6 traffic: Supported only for new clusters (7.4.2+).

• No protocol conversion: Existing clusters cannot migrate between IPv4 and IPv6.

• No dual-stack internal cluster traffic: Internal node-to-node communication uses either IPv4 or IPv6, chosen at cluster creation. You cannot mix protocols for internal traffic or change the internal IP family later.

• All nodes must match: All nodes must use the same IP protocol family.

• Kubernetes restrictions: Some features (for example, SSO) may fail in IPv6-only or dual-stack configurations.

• AWS VPC DNS: AWS VPC DNS does not query IPv6 name servers; use public resolvers (e.g., 8.8.8.8) if required.

• Private preview builds: Earlier IPv6 preview clusters lacked support for Active-Active CRDBs and modules. Only use GA versions 7.4.2 or newer.

Best Practices

• Decide IPv6 usage before cluster creation; protocol cannot be changed later.

• Verify OS and network IPv6 support on all nodes and Kubernetes infrastructure.

• Use proper DNS setup with AAAA records for both internal and external endpoints.

• Monitor release notes for ongoing IPv6 enhancements and fixes.

• Validate with IPv6 test plans in staging or CI/CD pipelines before production rollout.