UDP/IPv6 Connectivity Issue: Server Replies Use Different Source Address Due to Privacy Extensions

[yandujun363]

Title: UDP/IPv6 Connectivity Issue: Server Replies Use Different Source Address Due to Privacy Extensions

Component: Core Networking / UDP Implementation

Issue Description:
When running a server application using Arc's networking layer in an IPv6 environment, clients can establish TCP connections but UDP communication fails. The root cause is inconsistent source addresses in UDP replies caused by IPv6 privacy extensions.

Problem Summary:

1. Server setup: Application binds to an IPv6 address (or all addresses ::)
2. Client connection: Client connects to server's permanent/public IPv6 address
3. UDP communication failure: Server's UDP replies are sent from a different IPv6 address (temporary privacy address)
4. Client rejection: Client doesn't recognize the reply address and rejects it with ICMPv6 Port Unreachable
5. Result: UDP-based features fail while TCP works normally

Technical Background:

• IPv6 Privacy Extensions: Modern OSes (Windows default, Linux common) generate temporary IPv6 addresses for outbound connections
• TCP vs UDP difference:
  • TCP: Connection-oriented, source/destination addresses fixed during handshake
  • UDP: Stateless, each packet's source address chosen by OS routing table
• Address Selection Policy: OS prefers temporary addresses for outbound traffic when privacy extensions are enabled

Evidence from Real Application:
In Mindustry, we observed:

• Client: 240e:452:ddc6:74f3:c4e1:13ff:feca:3b3c
• Server permanent address: 240e:355:7f0d:8a00:9a8f:e0ff:fe69:867d
• Server temporary address: 240e:355:7f0d:8a00:3c33:11b3:6a2d:711a

Packet flow:

1. Client → Server (permanent address): UDP request ✓
2. Server (temporary address) → Client: UDP reply ✗
3. Client → Server (temporary address): ICMPv6 Port Unreachable ✗

Impact Assessment:

1. Scope: Affects all Arc-based applications using UDP in IPv6 environments
2. Frequency: Will become more common as IPv6 adoption increases
3. Severity: Breaks core networking functionality
4. Workaround: Disabling IPv6 privacy extensions on server (not practical for users)

Root Cause Analysis:
The issue appears to be in how Arc's UDP socket implementation interacts with the OS's source address selection. When a server receives a UDP packet and replies, it should ensure the reply comes from the same address the client contacted, but current implementation allows the OS to choose a different source address.

Suggested Solutions (framework-level):

1. Address Binding: Ensure UDP sockets are bound to specific addresses rather than wildcards when practical
2. Socket Options: Use IPv6 socket options to control source address selection (e.g., prefer permanent addresses)
3. Connection State: Maintain address consistency between received packets and replies
4. Documentation: Document this behavior for developers deploying in IPv6 environments

Reproduction Steps:

1. Enable IPv6 with privacy extensions (default Windows setup)
2. Run any Arc-based server application with UDP networking
3. Connect from client using server's IPv6 address
4. Observe: TCP works, UDP fails
5. Verify with network capture: Source address mismatch in UDP packets

Testing Environment:

• OS: Windows 11 (privacy extensions enabled by default)
• Network: Native IPv6 connectivity
• Verification: Wireshark packet capture confirms address mismatch

Additional Notes:

• This is NOT a firewall issue (packets are visible in captures)
• This is NOT an application-specific issue (affects framework level)
• Disabling privacy extensions fixes the issue, confirming the diagnosis
• Original issues link:在 IPv6 网络环境下运行服务器时，客户端可以通过 TCP 连接到服务器（显示为可连接状态），但实际的 UDP 游戏数据传输失败，导致客户端无法正常加入游戏或游戏状态无法同步。

[Anuken]

If you'd like to fix this, feel free to submit a PR. I'm not interested in handling IPv6 support, and my ISP doesn't even support it.