Skip to content

feat: IPv6 support for clients and hub (#46) - #159

Merged
jamofer merged 2 commits into
mainfrom
feat/46-ipv6-client-transports
Jul 22, 2026
Merged

feat: IPv6 support for clients and hub (#46)#159
jamofer merged 2 commits into
mainfrom
feat/46-ipv6-client-transports

Conversation

@jamofer

@jamofer jamofer commented Jul 22, 2026

Copy link
Copy Markdown
Collaborator

What

Clients resolve and connect over IPv4 and IPv6; the hub listens dual-stack.

Why

hints.ai_family was hardcoded AF_INET in all client transports, so an
AAAA-only FQDN never connected, and the hub only ever bound IPv4. Closes #46.

How

  • Client tcp/tls: AF_UNSPEC + iterate the resolved list until one connects.
  • Client QUIC: dual-stack AF_INET6 UDP socket (IPV6_V6ONLY=0, AI_V4MAPPED|AI_ALL), falling back to AF_INET on IPv6-disabled hosts — no fd/epoll churn.
  • Hub: shared listen_endpoint helper (dual-stack open + bind + v4-mapped origin un-map); quic/tls bind in6addr_any, plain tcp stays v4 loopback.
  • connect_url parses bracketed IPv6 literals ([::1]:7227) for connect and --listen.

Testing

  • make test green (402, +17 new: connect_url + listen_endpoint)
  • Manual: v4/v6 literals and DNS names (incl. AAAA-only ip6-localhost) connect over quic/tls; plain tcp correctly v4-loopback only.

Notes

Dual-stack chosen over recreating the QUIC socket per resolved family to avoid reworking the static epoll registration. DNS off the hot path is out of scope (deferrable follow-up).

@jamofer
jamofer merged commit 9e1642d into main Jul 22, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Connect by FQDN: IPv6 (AAAA) support and re-resolve on reconnect

1 participant