Socketaddrv6 Is Not Roundtrip Serializable
Postedabout 2 months agoActiveabout 2 months ago
sunshowers.ioTechstory
calmmixed
Debate
60/100
Ipv6SerializationNetworking
Key topics
Ipv6
Serialization
Networking
The article discusses issues with round-trip serialization of SocketAddrV6, sparking a discussion on IPv6 complexities and potential improvements.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
6h
Peak period
4
6-9h
Avg / period
1.7
Comment distribution12 data points
Loading chart...
Based on 12 loaded comments
Key moments
- 01Story posted
Nov 4, 2025 at 12:43 PM EST
about 2 months ago
Step 01 - 02First comment
Nov 4, 2025 at 6:39 PM EST
6h after posting
Step 02 - 03Peak activity
4 comments in 6-9h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 6, 2025 at 11:53 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45813719Type: storyLast synced: 11/20/2025, 12:50:41 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
- parsing addresses is well defined (try parsing ::1%3)
- since 127.0.0.2 is on loopback, ::2 surely also would be
- interface number on Linux is unique
- unix domain socket names are zero-terminated (abstract are not)
- sin6_flowinfo matters (it doens;t unless you opt-in with setsockopt)
- sin6_scope_id matters (it doesn't unless on site-local range)
(I wonder if scope_id would work on ipv4-mapped-IPv6, but if I remember right I checked and it didn't)
- In ipv4, scope_id doesnt exist (true but it can be achieved by binding to interface)
and so on...
Years ago I tried to document all the quirks I knew about https://idea.popcount.org/2019-12-06-addressing/
WTF?..
(My Linux machine can, but I’ve no clue if I should trust that now.)
Since this is backward-compatible when QoS is not set, I'd just change Display to emit it. But I am guessing some people may complain, so special implementation for Debug would work too...
The socket API for IPv4 requires a strange ceremony of calling if_nametoindex to map an interface name to an index then setting IP_BOUND_IF in order to bind a socket to a particular network interface. (Sorry, this only works on BSD and Mac OS; Linux instead uses SO_BINDTODEVICE for whatever reason).
When you don't supply a network interface, the OS "helpfully" guesses an interface, and that interface is usually the wrong one for multicast and broadcast packets.
I made a PXE boot server in Rust recently, and I lost at least 30 minutes of my time figuring out why DHCP responses wouldn't be receieved by an EFI client. The problem was that 255.255.255.255:68 is inherently ambiguous when multiple network interfaces exist.
In the case of the IPv6 API, you have to specify the interface up front (e.g. ff05::1:3%en0) or else you won't even be able to send a packet. I used to find this design tedious, but I prefer writing scope IDs explicitly in an address rather than having libc (or my own code) iterate over a linked list provided by the kernel to get an integer then supply that integer to a setsockopt (and remember that Linux has a quirk here).
That reliance on layer 4 data means it is challenging to deploy a new transport protocol (such as SCTP) that even just crosses these networks; in fact, the trend these days for protocol design is to encrypt everything, even data that is not particularly sensitive (cf QUIC, on which HTTP/3 is based), in order to avoid such middleboxes growing dependent on data they should never have been able to read, and thus avoid the resultant fossilisation of the Internet protocols.
But this case of wireless networks shows there can be some justification to the routing part of the network treating different flows differently, if only on an opt-in basis, and IPv6 flowinfo is probably the best mechanism for such categorization/tagging where the sender does not request a particular level of services but does mark its data as being in a particular category, probably a dynamic one. Unfortunately, it is unlikely to be meaningfully used as long as IPv4 remains in wide use: until this changes, these networks will need a solution that works for IPv4 (which has ToS but no flowinfo, and too few ToS bits for it to be used for dynamic flow categorization, even after a redefinition -- fun fact: the IPv4 ToS field supplanted a previous definition for that field, then known as DiffServ), and the path of least resistance means they will just apply that solution for IPv6 as well.
2 more comments available on Hacker News