Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01

[Mikael Abrahamsson <[e-mail]>]

On Wed, 29 Mar 2017, JORDI PALET MARTINEZ wrote:

> May be this is related to the US ESTA payment page, as it is broken since several years ago (unless they sorted it out after I paid my renewal about 5 months ago), and nobody is paying attention or even responding to the emails to their contacts …
>
> HE doesn’t even solve their problem, as it is related to PMTUD broken, 
> so only if you know this and are an engineer know how to disable IPv6 to 
> be able to access the payment … Nice example from a government :-(

I agree with both Lorenzo and Jordi here, there are multiple problems that 
won't get fixed, having "hard" failures doesn't seem to help that much at 
this time, but with the PMTUD failure mode as well (which might not be 
discovered until TCP handshake is already done), what about adding 
additional methods to try?

"normal HE mode with IPv4/IPv6"
If these fails, let's say 500ms
"try NAT64 method" (what Lorenzo proposed)

if these succeed but I'm not getting any data (for instance my GET / seems 
to time out, no data for 5 seconds)

then I try again but with TCP MSS 1200 and PMTU 1280 (I purposely went 
below MSS 1220, perhaps there is no reason to).

In Linux one could do this with adding a host route to the specific 
destination with lower MTU and ADVMSS values (I have no idea what other 
operating systems have available). I know this requires a lot more logic 
and might be invasive all the way up to the application layer, but I think 
it's the only way to really work around the PMTUD problem. It would also 
be nice if there were some reporting mechanism (diagnostics reporting) so 
that the devices could make a list of services that it needed to fallback 
to this behaviour to, both for diagnostics reporting and potentially also 
for caching what method to try so that any subsequent attempts to the same 
DNS/IP address by default went to the MSS1200 method from the beginning?

We should probably also say that PLMTUD should be default-on (as far as I 
can tell it's supported for TCP in a lot of operating systems, but it's 
not default on?). This would also workaround the problem.

I know if we do the above there is much less reason for people to fix 
their PMTUD hindering problems... but isn't it still better to do it this 
way than to have user breakage, especially for users who are behind new 
technology and this breakage is hindering that new technology because ISPs 
are afraid to deploy it?

-- 
Mikael Abrahamsson    email: [e-mail]