RFC 6156: TURN Extension for IPv6

[adrianosela]

RFC 6156: TURN Extension for IPv6

Closes #212

This PR implements RFC 6156: Traversal Using Relays around NAT (TURN) Extension for IPv6 enabling UDP and TCP relay allocations on IPv6 addresses.

cc:// @stv0g, @Sean-Der

Testing:

• Added relevant unit tests
• Added client-server example:

✔ ~/go/src/github.com/adrianosela/turn [rfc6156-ipv6-allocs|⚑ 2]
19:21 $ go run examples/turn-server/ipv6/main.go -public-ip ::1 -users username=password
2026/01/11 19:21:34 TURN server listening on [::]:3478 with IPv6 support (RFC 6156)
2026/01/11 19:21:34 Public IPv6 address: ::1

19:21 $ go run examples/turn-client/ipv6/main.go -host ::1 -user username=password -ping
2026/01/11 19:21:58 relayed-address=[::1]:61557 (IPv6)
2026/01/11 19:21:58 mapped-address=[::1]:52873
2026/01/11 19:21:59 32 bytes from from [::1]:61557 time=1 ms
2026/01/11 19:22:00 32 bytes from from [::1]:61557 time=1 ms
2026/01/11 19:22:01 32 bytes from from [::1]:61557 time=1 ms
2026/01/11 19:22:02 32 bytes from from [::1]:61557 time=2 ms
2026/01/11 19:22:03 32 bytes from from [::1]:61557 time=1 ms

[codecov]

Codecov Report

❌ Patch coverage is 73.95833% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.38%. Comparing base (edb776d) to head (04a5cd5).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
internal/server/turn.go	53.84%	15 Missing and 3 partials ⚠️
client.go	85.29%	5 Missing ⚠️
internal/allocation/allocation_manager.go	83.33%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #528      +/-   ##
==========================================
+ Coverage   81.07%   81.38%   +0.30%     
==========================================
  Files          46       46              
  Lines        3022     3099      +77     
==========================================
+ Hits         2450     2522      +72     
- Misses        362      373      +11     
+ Partials      210      204       -6     

Flag	Coverage Δ
go	81.38% <73.95%> (+0.30%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Sean-Der]

Hot damn that's amazing!

Mind squashing into one commit and copying your GitHub message into the commit? Reviewing now.

[Sean-Der]

@adrianosela LGTM! This is really impressive stuff, I am so appreciate of you getting involved :)

[Sean-Der]

Approved, see if you can do the following (totally understand if it isn't possible)

• Can we choose the transport from looking at passed PacketConn?
• Fix up linters
• Fix up commit message
• Possible to raise the code coverage a bit more? Error handling in server/turn.go would be nice

[adrianosela]

@Sean-Der , all reasonable feedback. Will get to it over next few days/weeks.

[adrianosela]

@Sean-Der

• ✅ Linters
• ✅ Commit message
• ✅ Raise coverage

• Can we choose the transport from looking at passed PacketConn?

So, server side we have to rely on the REQUESTED-ADDRESS-FAMILY as per the RFC. But on the client side we can try to infer it from the packet conn, but we cannot get rid of the additional RequestedAddressFamily field because the address methods of net.PacketConn are not necessarily IPs.

They will be for most, so we can definitely try. I propose we:

1. Make RequestedAddressFamily optional (and we treat the zero value as not set)
2. If set, use it
3. If not set, try infer from config.Conn.LocalAddr()
4. Default to IPv4 if inference fails

I'll make that change and ask you for another review.

[adrianosela]

Okay, this is ready for another review. cc:// @JoTurk @Sean-Der

[JoTurk]

I don't see any issues :)