Request to remove tunnel warnings

[elizandropacheco]

I verified that the validation to consider whether a connection is through a tunnel or not only considers whether the IPv4 provider is different from the IPv6 provider.

This is not correct.

In several locations around the world the allocation of IPv4 addresses for autonomous systems is no longer available, so we often find vendors using a vendor's IPv4 addresses and their own IPv6 addresses.

The simple fact that the suppliers are different should not alert as a tunneled connection.

The correct thing for such a function should be MTU validation, and even then it would be quite difficult to be precise.

But the way it is validated today generates information that can take away the credibility in troubleshooting using the tool.

I suggest changing to MTU validation or even removing this option, it will be beneficial.

[jfesler]

I disagree with you. This has worked rather well for quite a few people. It is fair to say I can't always detect a tunnel. But, when I do detect it, I've had little feedback telling me I was wrong. And when specific concerns are raised, I handle them. I've had this come up for a few providers.

Detecting tunnels by looking at MTU is .. at best, "difficult", and not easily accessible at the socket level; it would require sniffing the traffic and coordinating that process with the web server process. And, as observe, still difficult to be precise.

You're the first person in 10 years to suggest the feature be removed.

I am happy to mark specific BGP ASN numbers as "equivalent", which will make the message go away.

[elizandropacheco]

The service is widely used in Brazil and here it is normal for people to have more than 1 internet at home, especially in times of pandemic. But many times, only one delivers IPv6 to you.

So what is IPv6 comes out on one, what is IPv4 on the other, warn that the connection is being tunneled so it does not seem the most efficient way.

And new autonomous systems no longer receive ipv4 prefixes, only IPv6 ... so they end up using another ASN's IPv4.

Thus, whenever a user performs a test, the message gives the impression that there is something wrong, and as we know, this is not true.

I'm glad I was the first, maybe users didn't know exactly where to be able to communicate directly with the developers.

I am happy if you can at least change the message alerting that: If you use prefixes from different providers OR tunneling ...

Then it makes sense for the message to appear. Just being different ASNs I don't see the slightest sense, although that has been normal so far.

Just as a suggestion, I appreciate your attention.

[diegotiberio]

I am also experiencing the same problem, because my ipv4 addresses I receive from an operator and the ipv6 addresses are my prefixes linked to my ASN, because with the exhaustion of ipv4 we only receive ipv6. It would be interesting to change the message, as it presents a problem session.

[jamishenrique]

The cause raised by Elizandro is plausible! In scenarios such as Brazil, the current message and the way it is displayed can cause problems of interpretation, both for lay users who use the service and for people in the technical area of the ISP or other services that use this tool.

[moreiras]

Hi Jason. The situation has changed over the last 10 years. With the end of IPv4 in LACNIC region, we have a growing number of IPv6 only Autonomous Systems, and they surelly get their IPv4 for CGNAT elsewhere. In the other hand, traditional tunnels should not be so frequent anymore. I think that if you can't consider changing the method of verification, or if it is not viable, you could think of changing the message, and the warning status.

[jfesler]

As mentioned, I'm happy to add ASN pairs. At this point in time, I'm not willing to remove the feature for the whole world. It is frequently triggered - legitimately. And in many cases in ways people SHOULD know about it - ie, incomplete VPN solutions.

If you think all of Brazil should ignore this, that I can consider.

[jfesler]

Based on Antonio's comments, I'm removing the message in the LACNIC region specifically.

[elizandropacheco]

Yes, it is valid for us and we appreciate your attention. Thank you for your help.

[leleobhz]

Hello!

Create an exclusion zone for LACNIC does not exhaust the discussion about Tunnel validation. Same time I agree with @jfesler the creation of any method outside application layer is out of scope and possibilities, IPv6 is a completely independent L3 protocol, which can be implemented separately and does not require any IPv4 resource. That said, IPv6 analysis must not rely upon any IPv4 information.

IPv6 Tunnel, as @moreiras said, is not a hugely used approach anymore and most tunnel brokers - easily detectable - had shut down [1] and Microsoft disabled Teredo on Windows 10 [2].

I understand the concern about Tunnel usage on IPv6 but since most famous Worldwide tunnel providers are permanently disabled today (Maybe HE the unique exception?), I see the feature of Tunel Validation is just useless today.

[1] https://www.sixxs.net/news/2017/#sunsettingsixxs20170607-201703 [2] https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/directaccess-clients-teredo-tunneling-not-connect-after-upgrade

[jfesler]

• Sixxs was unfortunate, but not major. I did like their product. It was great when in a hotel since it worked with UDP.
• Hurricane, I still get a LOT of users visiting.
• VPN tunnels are also .. tunnels. And I see a LOT of cases where someone uses a VPN provider, but only for IPv4. People failing to VPN both protocols should see a warning.
• I've seen the ISPs outsourcing to another provider for quite some time - and those have had PMTUD issues. End users until visiting the site haven't known they were being handled by two different providers.

At this time, the code stays. I'll leave the issue open, in particular for input from other regions.

[leleobhz]

Hello!

• Sixxs was unfortunate, but not major. I did like their product. It was great when in a hotel since it worked with UDP.

Indeed - I was a power user of SixxS too.

• Hurricane, I still get a LOT of users visiting.

Agreed

• VPN tunnels are also .. tunnels. And I see a LOT of cases where someone uses a VPN provider, but only for IPv4. People failing to VPN both protocols should see a warning.

I see, but it's project main target? Afaik the main project target is detect the quality of IPv6 connectivity, not check if you access way is a VPN - specially if this VPN is a IPv4.

• I've seen the ISPs outsourcing to another provider for quite some time - and those have had PMTUD issues. End users until visiting the site haven't known they were being handled by two different providers.

I understand this issue and I agree with the warning - but this just reinforces the argument above - the best approach is just to inform ASN Information from both IPv4 and IPv6 and consider this a warning, not a failure. Maybe a text explaining all these conditions may be a better approach than - as example - try to do PMTUD on the backend or just don't make anything at all.

At this time, the code stays. I'll leave the issue open, in particular for input from other regions.

+1 :)

[jfesler]

I've gone ahead and removed most tunnel warnings (other than 6rd, teredo, and 6to4). The support issues caused on this have increased, much more so in China than LATAM even. Additionally, since engineering changes are primarily limited to my vacation time, I don't know when my next chance would be (other than next winter).