Redpanda can bind to both IPv4 and IPv6 addresses simultaneously, allowing clients to connect using either protocol.
Let’s see it in action. Imagine you have a Redpanda cluster running. You’ve configured it to listen on a specific IPv4 address, say 192.168.1.100, and now you want it to also accept connections on an IPv6 address, like 2001:db8::1.
Here’s how you’d typically configure this in redpanda.yaml:
# redpanda.yaml
listeners:
kafka:
- name: kafka-plaintext
port: 9092
address: 192.168.1.100
ssl_mode: none
- name: kafka-ipv6-plaintext
port: 9092
address: 2001:db8::1
ssl_mode: none
http:
- name: http-plaintext
port: 9644
address: 192.168.1.100
- name: http-ipv6-plaintext
port: 9644
address: 2001:db8::1
After restarting Redpanda with this configuration, you can verify that it’s listening on both protocols. On Linux, you’d use ss or netstat:
sudo ss -tulnp | grep 9092
# Expected output will show something like:
# tcp LISTEN 0 128 192.168.1.100:9092 0.0.0.0:* users:(("redpanda",pid=12345,fd=6))
# tcp LISTEN 0 128 [2001:db8::1]:9092 [::]:* users:(("redpanda",pid=12345,fd=7))
sudo ss -tulnp | grep 9644
# Expected output will show something like:
# tcp LISTEN 0 128 192.168.1.100:9644 0.0.0.0:* users:(("redpanda",pid=12345,fd=8))
# tcp LISTEN 0 128 [2001:db8::1]:9644 [::]:* users:(("redpanda",pid=12345,fd=9))
Notice how ss shows separate entries for the IPv4 and IPv6 addresses. The 0.0.0.0:* and [::]:* in the output are the wildcard addresses that the kernel uses to represent "all available interfaces" for IPv4 and IPv6 respectively. When Redpanda explicitly binds to 192.168.1.100 and 2001:db8::1, the kernel handles the routing for both.
This dual-stack capability is crucial for modern infrastructure where networks often consist of both IPv4 and IPv6 subnets. It allows for seamless connectivity and avoids the need for complex NAT gateways or dual-stack provisioning on client machines if they can already reach the Redpanda nodes via both protocols. Redpanda achieves this by leveraging the operating system’s dual-stack networking support. When you specify multiple address entries for a given port in the listeners configuration, Redpanda makes separate bind system calls for each address and port combination. The operating system’s network stack then manages the incoming connections, directing them to the correct Redpanda listener based on the client’s source IP address family.
The key insight here is that Redpanda doesn’t invent its own dual-stack mechanism; it relies on the OS. This means that if your OS isn’t configured for dual-stack operation on the network interfaces Redpanda is binding to, you’ll encounter issues. For example, if your eth0 interface only has an IPv4 address assigned, trying to bind Redpanda to an IPv6 address on eth0 might fail, or connections might not route correctly. Ensuring your network interfaces are properly configured with both IPv4 and IPv6 addresses is a prerequisite.
When configuring listeners in redpanda.yaml, you can define separate listener entries for each protocol and port combination. This allows you to have distinct configurations, such as different SSL settings or even different ports if needed, for IPv4 and IPv6 clients. For instance, you could have a plaintext Kafka listener on IPv4 and an SSL-enabled Kafka listener on IPv6, all on the same Redpanda node.
listeners:
kafka:
- name: kafka-ipv4-plaintext
port: 9092
address: 192.168.1.100
ssl_mode: none
- name: kafka-ipv6-ssl
port: 9092
address: 2001:db8::1
ssl_mode: require
certificate_chain: /etc/redpanda/certs/tls.crt
private_key: /etc/redpanda/certs/tls.key
The address field is where you specify the IP address. For IPv4, use the standard dotted-decimal notation. For IPv6, enclose the address in square brackets, like [2001:db8::1]. This syntax is important for distinguishing IPv6 addresses in configurations where they might otherwise be ambiguous.
A common pitfall is assuming that binding to 0.0.0.0 for IPv4 and :: for IPv6 automatically covers all dual-stack scenarios. While these are wildcard addresses that listen on all available interfaces for their respective families, explicitly binding to specific addresses like 192.168.1.100 and 2001:db8::1 gives you finer control and clarity, especially in environments with multiple network interfaces or complex routing. The explicit binding ensures Redpanda is actively listening on those exact IP endpoints.
The port can be the same for both IPv4 and IPv6 listeners. Redpanda’s internal multiplexing and the OS’s network stack handle directing traffic to the correct listener based on the source IP address family. This simplifies configuration as you don’t need to use different ports for IPv4 and IPv6 if your security policies allow.
The most surprising thing about Redpanda’s dual-stack support is that it doesn’t require any special flags or a separate "dual-stack mode" to be enabled. It’s a natural consequence of how you configure its network listeners and how the underlying operating system handles network sockets. As long as the OS allows it, Redpanda will bind to both.
When clients connect, they will resolve the hostname or IP address they are given. If a client has an IPv6 address and can reach the Redpanda node’s IPv6 address, it will attempt an IPv6 connection. Conversely, if it has an IPv4 address and can reach the IPv4 address, it will try IPv4. Redpanda’s dual-stack listeners are ready for either.
The next challenge you’ll likely face is managing DNS records to correctly point to both your IPv4 and IPv6 addresses for your Redpanda cluster.