@MSGID: 2:280/5555 6839d87c
@REPLY: 1:129/14.1 6839c04e
@TID: FMail-W32 2.3.0.1-B20240319
@RFC-X-No-Archive: Yes
@TZUTC: 0200
@CHRS: CP850 2
Hello Alex,

On Friday May 30 2025 10:25, you wrote to me:

 MV>> Then Comcast and/or their users are doing something wrong. Native
 MV>> IPv6 is definitely not slower than IPv4.

 AG> It`s definitely slower by design:

 AG> - Bigger headers (40 B vs. 20 B) add per-packet overhead.

 Hardly noticeable on modern hardware and well compensated by the
packages themselves that can be larger.

 AG> - Path MTU Discovery failures (blocked ICMPv6 "Too Big") lead to
 AG> drops/retries.

Blocking ICMPV6 is a configuration error, not a design flaw.

 AG>  - Transitional tunnels (e.g. 6in4, Teredo) introduce
 AG> extra hops and encapsulation cost.

 Agreed, but those tunnel mechanisms were only meant to facilitate
the transition. Should have been fased out long ago. And mostly are. I
enjoy native IPv6 from my ISP for about a decade now.

 AG> - Less hardware offload and OS-stack tuning for IPv6 vs. decades of
 AG> IPv4 optimizations.

 IPv6 has been in use for well over a decade now. It has gone
through the optimasation fase as well. Add to that the overhead in IPv4
like multiple levels of NAT and other tricks and work around to keep it
working despite the IPv4 exhaustion.

If IPv6 is noticeably slower than IPv4 someone is doing something wrong.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
 * Origin: http://www.vlist.org (2:280/5555)
SEEN-BY: 50/109 203/0 280/464 5555 292/854 301/1
450/1024 452/166 463/68
SEEN-BY: 5000/111 5015/46 5020/545 715 830 846
1042 4441 12000 5023/24
SEEN-BY: 5030/49 1081 1474 5053/51 55 58 5060/900
5061/133 5068/45 5075/35
SEEN-BY: 5075/128 5083/1 444
@PATH: 280/5555 5020/1042 4441