This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Happy Eyeballs bias
- Previous message (by thread): [ipv6-wg] Happy Eyeballs bias
- Next message (by thread): [ipv6-wg] Happy Eyeballs bias
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Philip Homburg
pch-ripeml at u-1.phicoh.com
Wed Oct 26 17:27:54 CEST 2016
In your letter dated Wed, 26 Oct 2016 17:04:18 +0200 (CEST) you wrote: >but >instead recommend the OS vendor to install some kind of heuristic to flag >for the user somehow that their IPv6 connectivity is degraded, and offer >to fault find it... or let's invent some kind of telemetry where these >kinds of breakages can be reported to the OS vendor so they can contact >the ISP and alert them to the breakage? I wonder, if a host has a global IPv6 address that is not derived from any kind of transition technology or tunnel, and setting up a TCP connection is either slow or fails, then what percentage is due to an issue close to the host and what percentage close to the target. I.e., if IPv6 is broken is there any reason to believe it is often enough due to ISP provided services that is would be worth reporting it in a roudabout way. >Also, we still have the problem with PMTU blackhole detection and >mitigation. Why isn't this turned on more? I really don't understand this. I guess 'everybody' doing major operating systems still lives in an IPv4-only world with MSS clamping.
- Previous message (by thread): [ipv6-wg] Happy Eyeballs bias
- Next message (by thread): [ipv6-wg] Happy Eyeballs bias
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]