Not working/listening on IPv6

[DennisGlindhart]

Describe the bug
Connecting to the IPv6 address of the IP (both Pod, LoadBalancer etc.) doesn't work.
curl -v http://\[2001:db8::10::1\]:80

To Reproduce
Steps to reproduce the behavior:

1. Deploy nginx gateway fabric on IPv6-enabled (or IPv6-only cluster)
2. curl -v http://<IPv6Address>:80 to IP of the nginx pod, LB etc. (Or hostname/DNS-name

Expected behavior
Able to connect, like via IPv4

Your environment

• NGINX Gateway Fabric 1.2
• Kubernetes 1.29
• Nginx Gateway Fabric Pod exposed via LoadBalancer
• NGINX Configuration: kubectl -n nginx-gateway exec <gateway-pod> -c nginx -- nginx -T

Additional context
Expected fix:
All "listen <port>"-directives in internal/mode/static/nginx/config/servers_template.go should have a corresponding
listen [::]:<port>

[nginx-bot]

Hi @DennisGlindhart! Welcome to the project! 🎉

Thanks for opening this issue!
Be sure to check out our Contributing Guidelines and the Issue Lifecycle while you wait for someone on the team to take a look at this.

[github-actions]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[mpstefan]

Hey Dennis, sorry for the delay in response! We are aware that NGF does not support listening on IPv6 or sending to IPv6 addresses at this time, but we are planning on implementing it in 1.4.

I'll move this issue into the milestone so we can track that work here until the epic is more detailed.

[mpstefan]

As this is enhancement is now being tracked in #2086, closing this bug report.

[aviallon]

@mpstefan Even with #2086 it does not work properly, as the LoadBalancer only acquires an IPv4 address.
Manually creating a service that specifies PrefersDualStack and ipFamilies: [ IPv4, IPv6 ] works.

[sjberman]

@aviallon The work done for #2086 was to ensure that the nginx process itself can listen for ipv4 and ipv6, but didn't make any changes to the LB service in the installation manifests, since users can configure this LB Service however they need when installing (pre-2.0).

However, I am realizing now that with the new 2.0 release architecture, we need to expose a way for users to set these values on the LB Service, because the nginx LB Service is no longer installed via the manifests, but instead installed via the NGINX Gateway Fabric control plane.

[aviallon]

@sjberman Oh, so I wasn't being crazy after all. I couldn't comprehend what I did wrong.

[sjberman]

If you're using a pre-2.0 release, then your process is the expected way to configure the Service. However, I've opened an issue to fix this for post-2.0 so that the Service gets provisioned with the expected value (default dual).