The host side of V6 can be noticeably slower as well. Mostly due to lack of use. Here's one example: I recently fixed a performance bug in our (FreeBSD based

The host side of V6 can be noticeably slower as well. Mostly due to lack of use. Here's one example: I recently fixed a performance bug in our (FreeBSD based) TCP stack where having just 10% of connections be V6 on a busy CDN server would result in performance issues due to massive lock contention on network related hashtables. The issue was that when an ICMP (like must fragment, for path mtu discovery) was received targeted at a connection, the V4 code would look up the appropriate connection (with a read lock), and do the work for that connection. However, the V6 code would take a write lock on the global hash table (shared with v4) and iterate over the entire table while holding the write lock. So the entire system would come to a screeching halt, with readers spinning on that write lock while V6 bumbled along. This is something most people would not notice, but on a busy CDN server with ~100K connections serving 80-90Gb/s, it was pretty deadly. The cause of this bug was primarily because people have been optimizing the V4 code for years, but the V6 code "scary", unused, and often forgotten about. So people mostly forget about it when making optimizations. Looking at some data from last night, one of the biggest sources of lock contention on one of these 100G boxes is still in the v6 code, even at a site that's serving only 15% of traffic as V6. Sigh.