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

From: Ca By <[email-masked]>
Date: Wed, 29 Mar 2017 13:22:59 -0700

Just a comment following up on Jordi's Mic comment

Jordi said there was an issue with HE hiding IPv6 issues.

David's response was something along the lines of "deploy ipv6-only".  I
did not really understand this.

When folks deploy ipv6-only, they find they are all alone with a broken
ipv6 scenarios that work on all their competitors IPv4-only networks and HE
dual-stack networks.

Also, friendly reminder that Dan Wing catalogs a subset of the websites
that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/

And, my customers still complain about www.fra.dot.gov ... this works for
everyone but me... because of HE...and I am already on IPv6-only ... and
nobody will fix it.  This issues has been known by the USG DOT for over 3
months, noted to NANOG, nobody cares to fix it.

So, perhaps there is room in the I-D for including NAT64 synthesized
address candidate set.  Meaning the HE algo on an IPv6-only host would
include the set of available native IPv6 answers as well as a 500ms timer
for attempting an A query with using whatever mechanism is available to the
host for relaying IPv4 packets across an IPv6 only network (RFC6877, Bump
in API, ...)

Without this, IPv6-only networks are at a painful disadvantage since IPv6
must be perfect while every other scenario has HE to mask brokenness.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 29 Mar 2017 15:46:34 -0500

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 :-(

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Ca By <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 29 de marzo de 2017, 15:22
Para: IPv6 Ops WG <[email-masked]>
Asunto: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01

    David's response was something along the lines of "deploy ipv6-only".  I did not really understand this.
    
    When folks deploy ipv6-only, they find they are all alone with a broken ipv6 scenarios that work on all their competitors IPv4-only networks and HE dual-stack networks.
    
    Also, friendly reminder that Dan Wing catalogs a subset of the websites that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/
    
    And, my customers still complain about www.fra.dot.gov <http://www.fra.dot.gov> ... this works for everyone but me... because of HE...and I am already on IPv6-only ... and nobody will fix it.  This issues has been known by the USG DOT for over 3 months, noted to NANOG, nobody cares to fix it.
    
    So, perhaps there is room in the I-D for including NAT64 synthesized address candidate set.  Meaning the HE algo on an IPv6-only host would include the set of available native IPv6 answers as well as a 500ms timer for attempting an A query with using whatever mechanism is available to the host for relaying IPv4 packets across an IPv6 only network (RFC6877, Bump in API, ...) 
    
    Without this, IPv6-only networks are at a painful disadvantage since IPv6 must be perfect while every other scenario has HE to mask brokenness. 

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Mar 2017 08:59:44 +0200 (CEST)

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

> 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: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Thu, 30 Mar 2017 11:29:17 +0200

>below MSS 1220, perhaps there is no reason to).

I was very surprised to hear it, but there are already middle boxes close to
the customer edge (or in the CPE) that do MSS clamping for IPv6.

It is hard to quantify, but in IPv4 lots of potential PMTU problems are masked
by MSS clamping. 

Given that on the whole we failed to have PMTU blackhole detection/avoidance
deployed at large on the server side, using MSS clamping will be the most
effective way to deal with this problem.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Mar 2017 12:14:58 +0200 (CEST)

On Thu, 30 Mar 2017, Philip Homburg wrote:

> It is hard to quantify, but in IPv4 lots of potential PMTU problems are 
> masked by MSS clamping.

Yes. I don't have data, but I have commonly talked to people in the 
business who are of the opinion that MSS clamping solves "all" problems.

When I point out that there are other protocols I typically get back that 
MSS clamping is good enough and solved all their customer complaints.

While I don't really like the approach, I think the pragmatic thing to do 
is to have the devices themselves have the ability to do PMTUD clamping if 
they have lots of problems that can be attributed to PMTUD, and then have 
this reported by means of diagnostics report to application/device vendor.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 30 Mar 2017 14:11:29 +0200

>MSS clamping is good enough and solved all their customer complaints.

It's sad how little some people know about internet protocols. 

>this reported by means of diagnostics report to application/device vendor.

The 'nice' thing about doing MSS clamping in a CPE is that the CPE knows 
what it is using to connect to the internet. 

A host would have to probe every time it connects to a network for local
PMTU limitations. I wonder what the operational impact would be if every
host would start sending maximum sized packets to some well known destination
right after connecting to the network.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Mar 2017 14:20:57 +0200 (CEST)

On Thu, 30 Mar 2017, Philip Homburg wrote:

> host would start sending maximum sized packets to some well known 
> destination right after connecting to the network.

Well, I advocate to send lower MTU than 1500 in RA if you know that the 
upstream has lower than 1500 MTU. Otherwise you get a lot of useless PMTUD 
traffic from clients. Doing bidirectional MSS clamping makes sense as 
well, and I think some residential routers do this already.

---

From: Ca By <[email-masked]>
Date: Thu, 30 Mar 2017 12:41:05 +0000

> well, and I think some residential routers do this already.

Many, if not most, mobile providers do mss clamping.