Hi everyone, Over the last two/three days, I have been noticing having connection issues with the swisscom.ch website via IPv6, which is my default as I use a 6RD connection from my router, connected to the internet via a Swisscom VDSL2 line. This is independent of the device and OS, since I am experiencing the issue on macOS, Windows, iOS and iPadOS. My macOS laptop with Safari shows this error when trying to connect: [upl-image-preview liId="39689i389FE826042AEBBF" alt="image.png" uuid="52138548-5fa1-433f-98c6-f68bd9446580"] If I switch off wifi on my iPad, and pass via the 4G network, the page opens fine, as the 4G connection is only IPv4 as confirmed by the excellent test website: [https://ipv6-test.com/](https://ipv6-test.com/) On the other hand, this website [https://community.swisscom.ch/](https://community.swisscom.ch/) is not affected by the issue, and I can access it regularly over IPv6. Am I the only one experiencing these connection issues with the swisscom.ch website? Many thanks, Luca

Hello @"lucaberta"#110906, Effectively the ipv6 webserver swisscom.ch (2a02:a90:c400:4001::2) isn't reachable. @"x"#103702could you report this issue?

Hello @"Biorn1950"#571597 @"lucaberta"#110906 Thank you for your contributions. I forwarded your reporting to our specialists. Let's wait for their answer. Have a nice day

I have reported and resolved this already. See [here](https://community.swisscom.ch/t5/Internet-Allgemein/IPv6-6rd-MTU/td-p/641943). Solution is to reduce your MTU from 1480 to 1472. And yes, there is no technical reason and the issue is caused by Swisscom creating a blackholing by blocking the ICMP response packets from the hosts which would notify your host to reduce the MTU. Basically Swisscom services are unavailable on any IPv6 enabled internet connection with an MTU larger than 1472.

@"SkyBeam"#1560 I just tried with mtu 1472 and the server still not answer.

> * * * > > @"Biorn1950"#571597 wrote: > > I just tried with mtu 1472 and the server still not answer. > > * * * Are you using any additional encapsulation? You might try even lower values then. However for me it works fine using MTU of 1472 on 6rd tunnel to 6rd.swisscom.com. Also make sure the MTU of 1472 is announced properly on your LAN devices (router advertisements). I am operating radvd on my LAN and use "AdvLinkMTU 1472" property.

@"x"#1560thanks for your answer. Just to be sure, at this moment you have an answer if you: ping6 swisscom.ch? Could you try it please and confirm me which ip is reached.

> * * * > > @"Biorn1950"#571597 wrote: > > @"x"#1560thanks for your answer. > > Just to be sure, at this moment you have an answer if you: ping6 swisscom.ch? > > Could you try it please and confirm me which ip is reached. > > * * * No. Absolutely not of course. This is part of the problem. Swisscom seems to filter all (yes all, not just echo-request/reply) ICMP traffic on swisscom.ch. So you will never get an ICMP echo reply. Even worse you will also not get ICMP error messages from the host's you want to reach. And exactly this is the problem: * You are sending a package with a size larger than 1472 to the swisscom.ch host * The host receives the package (or a router in between) but it cannot forward it due to an internal link having a maximum MTU of 1472 (6rd tunneling + PPPoE encapsulation). The router/host will reply with ICMP "Fragementation Needed" reply (Type 3, Code 4). * Unfortunately the reply is also dropped on it's way back to you. * Your client will wait forefer or any response. It will neither get any TCP answer nor any ICMP fragmentation needed message. So you're lost and the connection just times out. The solution is to assure that your client will never even try to send a packet larger than 1472 bytes to the swisscom.ch host (TCP packets on Port 443) so it's not getting dropped. Of course this is completely against any standard and a misconfiguration on the network but there are companies which still believe ICMP can be simply blocked and there is no real value of those information. Some of them only know ICMP type "echo request/reply" and think that's not needed. But specifically with IPv6 it's important also to forward ICMP traffic. So I am afraid that actually nobody using any provider which provides native or large-mtu IPv6 access will be able to reach any swisscom.ch services (with some exceptions like this community pages which seems to be on a host which can transport larger IPv6 packets (working with 1480 bytes MTU at least). But the majority of swisscom.ch services including MyCloud and the customer center simply will not work. The only workaround known to me is to announce a maxium MTU ofr 1472 bytes or smaller to your clients - at least for the path towards Swisscom services. Perhaps they will fix it once in a while, but I wouldn't hold my breath as I am facing this issue since years.

@"x"#1560it's most clear now, that why I can't get any answer with an mtu set to 1472 or below. Thanks for your explanations, I was disturbed by the fact I could reach and diagnose while ping6 mtu size for community.swisscon.ch and not for the main domain. Perfect, thanks again.

Thanks @"SkyBeam"#1560 for shedding a little light on this issue. It looks like changing the MTU down to 1472 did not change things for me. I also tried 1460 in case of additional padding from other (which ones?) tunnels, but no luck, still. Also, I am using a Zyxel router and I don't believe I can change radvd's configuration to advertise a smaller MTU to the clients on the LAN, I am afraid. The question now is, why would Swisscom block important ICMPv6 frames altogether, when it's best practice to allow them? There is an RFC which gives best practices on the topic: [https://tools.ietf.org/html/rfc4890](https://tools.ietf.org/html/rfc4890) On the other hand, most ICMPv6 error messages traveling end-to-end or any-to-end are essential to the establishment and maintenance of communications. These messages must be passed through firewalls and might also be sent to and from firewalls to assist with establishment and maintenance of communications. For example, the Packet Too Big error message is needed to determine the MTU along a path both when a communication session is established initially and later if the path is rerouted during the session. I wonder if all these issues I am seeing would simply be solved by implementing the correct best practices at Swisscom, rather than zapping all the ICMPv6 frames altogether... Any further comment is much appreciated. Ciao, Luca

> * * * > > @"lucaberta"#110906 wrote: > > I wonder if all these issues I am seeing would simply be solved by implementing the correct best practices at Swisscom, rather than zapping all the ICMPv6 frames altogether... > > * * * Sure it would be resolved. As written some host/router in between the client and the server will actually respond with an ICMP package indicating that it cannot forward the request due to its size. But as this response is dropped your client is waiting forever, not knowing the request has actually been silently dropped. Actually it should be enough to lower the MTU of your 6rd tunnel on your gateway to 1472. Assuming your gateway does not suffer from the same issues (you don't silently drop ICMP to your clients) then your gateway should actually tell your client to send smaller packages if it cannot forward them on the MTU-1472 6rd tunnel. So for your local network it would be sufficient. However it's perhaps a bit less efficient if your RA messages advertise 1480 on your LAN and your clients will detect on each TCP connection establishment that the actual MTU for global-unique IPs are limited to 1472 so the request needs to be split and re-sent. You can actually check the MTU on your client. On Linux just use 'ip a' command. On Windows open a command prompt and use the 'netsh interface ipv6 show subinterface' command to see the MTU advertised on your local link. Likely this one is 1480 but if your gateway needs to forward it on a link with MTU 1472 it will tell your client to send smaller packets (via ICMP). Since you don't block this (hopefully) it will work. Not sure however if your settings on the gateway are properly done. I am using a Linux router with 6rd tunnel. I had to modify the init script to allow me to set a custom MTU (ip lin kset mtu 1472 ). I guess your Zyxel perhaps allows to set a manual MTU on the 6rd tunnel. But you need to make sure it is in effect for the 6rd tunnel and not for any other interface. I am still very convinced that this is exactly your problem but I can't test your setup as I am not using any closed/embedded devices. In regards to why Swisscom is blocking ICMP all over... I don't know. I guess some "smart" security guy was living in the age where "ping of death" was a real thing and thought "why do we actually need ICMP? We just open TCP port 443, that's enought as the service just listen on this port". Well security engineers are usually not network engineers and I am sure there are many wrongly configured gateways, routers and hosts out there.

⁉️ Issues with IPv6 access to swisscom.ch website

SkyBeam

@lucaberta wrote:

Good news! I have just tried again by setting the MTU back to the default of 1500, and this time things seem to be working fine!

@SkyBeam can you confirm on your side?

No. Unfortunately a link MTU and local MTU/MSS of 1480 does NOT work for me on swisscom.ch web-pages. Still timing out (not getting any response at all).

But I do not have any issues with sbb.ch or train-schedule lookups.

I did actually have problems in the past with SBB park & rail app (prail.sbb.ch) but the problem there was different: The app seems to use SSL CONNECT method on port 2345 and 10433 which was disallowed in my proxy config (SSL_ports). So I needed to allow it.

lucaberta

@SkyBeam wrote:
No. Unfortunately a link MTU and local MTU/MSS of 1480 does NOT work for me on swisscom.ch web-pages. Still timing out (not getting any response at all).

bizarre. Now it also has stopped working for me. Go figure.

Looks like we're still stuck with the issue. Time to put my machine's MTU back at 1472.

I wonder why it was working before...

netztier

> that no packet larger than 1480 will pass and they will set the MSS to 1480.

I beg to disagree here, and I'm willing to revive this old thread for that. It might be nitpicking, but the above statement is just plain incorrect.

MSS is always lower than the MTU.

TCP MSS is 40 bytes lower than MTU for IPv4 (20bytes IPv4, 20bytes TCP)

TCP MSS is 60 bytes lower than MTU for IPv6 (40bytes IPv6, 20bytes TCP), or even more when option headers are present.

Assuming 1500byes of IPv4 MTU on the WAN, any 6RD tunnel can only offer 1480bytes of IPv6-MTU (20 bytes being consumed for the outer IPv4 header), and the "useable" TCP MSS is cut down to 1420 bytes when running over 6RD.

And as we learned in this thread, swisscom's 6RD BRs even assume 1472bytes of IPv6 MTU to support PPPoE clients that have an MTU of 1492 on their WAN (cutting down TCP MSS to 1412)

This again higlights that MTU problems are unidirectional by nature, and analysis must be done for both directions - this is also nicely shown by the experts who have contributed to this thread.

However, before using the big hammer and reducing the MTU on your LAN, there's always TCP MSS clamping to look at.

Routers/Firewalls can manipulate TCP MSS headers as they are flowing through, and while sometimes it gets considered a kludge by purists, I find MSS clamping to be a blessing in everyday networking life.

Back in the day, it actually took an Cisco IOS upgrade to support "ipv6 tcp adjust-mss" alongside the classic "ip tcp adjust-mss..." we had come to like when running IPSec and GRE tunnels. I had been running my 6RD deployment at home with "ipv6 tcp adjust-mss 1400" ever since.

> Most safe would be to advertise an MTU of 576 on your LAN. So no device would use any larger package (MSS)

> than this. 576 Bytes is the minimum MTU for IP links. However this is also causing efficiency issues and a high

> overhead. So it's not recommended.

Again: If IP MTU were 576bytes, TCP MSS would be no more than 536.

Even worse: IPv6 mandates a minum MTU of 1280bytes. A LAN or network segment with an IP MTU of 576 would simply be incompatible with IPv6.

Cheers

Marc

Zutheimmib80

I looked at my HE tunnel settings and the maximum MTU that can be set for the tunnel is 1480. This is the default value and the one my tunnel is using.

netztier

In a situation with an IPv6-in-IPv4 tunnel, an "inner" MTU (in extenso: for IPv6 packets, before being encapsulated in IPv4 packets) of 1480 is quite plausible, assuming the outer MTU (for IPv4 packets) is the common 1500.
The IPv4 header which is prepended to each IPv6 packet is 20 bytes in size.

In the case of such an IPv6-in-IPv4 tunnel, when TCP is using IPv6, it should not generate payloads ("segment size") of more than 1440 bytes per packet (1480 bytes of IPv6 MTU minus 40bytes of IPv6 header).

Also, in the SYN or SYN-ACK packet of every TCP-over-IPv6 connection, the TCP options field for MSS ("maximum segment size") should be set to 1440 bytes. Remote TCP peers will then know that when sending/responding to this system, they should keep payload size per packet at 1440 bytes or less.

millernet

The issue persists up until today and wasn't resolved by Swisscom at all. I'm by no means a network expert, so let me first explain my setup:

I'm using a Netgate 6100 pfSense appliance connected to a Sunrise Connect Box 3 in bridge mode.
Sunrise doesn't offer IPv6 or Dual Stack if you rely on a public IPv4 without any kind of CGNAT. Even as a business customer, there's no chance of getting a DS with native IPv6 on DOCSIS 3.1, you still need to downgrade to DOCSIS 3.0 to get native IPv6.
To use (or rather "experiment" with) IPv6 I'm using a Hurricane Electric GIF-Tunnel (https://tunnelbroker.net) which is implemented like described in https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunnel-broker.html

Everything works fine and the usual suspects like google.com, youtube.com, netflix.com etc. work in IPv6 only mode flawlessly. Only www.swisscom.com doesn't load at all. To fix these issues, you need to lower the MTU to 1478 Byte:

Even then, you need to activate IPv4, otherwise not all elements are loaded:

of course ICMP echo request / reply doesn't work at all, which seems to be the culprit for this behaviour:

To sum it up:

IPv6 only is still not very usable. Many websites like blick.ch, brack.ch, nzz.ch or even digitec.ch still just support IPv4 only.
The implementation of IPv6 for www.swisscom.ch is somehow wrong and not up to the same standards big players like Google and Microsoft are using. It's shame full for a state owned multi-billion-dollar company.

Maybe I'm wrong and something is missconfigured. Please let me know. I'm still very new to IPv6 😁

millernet

I just discovered that you could increase the MTU up to 1480 Byte and the www.swisscom.ch still loads fine. 20 Byte is the IPv4 header and 1500 Byte the total MTU to the Modem / Connect Box 3. So, 1500 Byte - 20 Byte = 1480 Byte which is the total MTU through the GIF tunnel. I think I'm on to something. 😎 (#Sherlock)

The issues lie in the way IPv6 manages fragmentation, which is nicely described in the following presentation: https://www.potaroo.net/presentations/2021-09-14-v6frag.pdf

Only the IPv6 source node is allowed to fragment packets and not all routers in between, like IPv4 allows fragmentation.

netztier

@millernet wrote:

I think I'm on to something. 😎 (#Sherlock)

You'll be on to something once you start looking at...

the TCP MSS header fields of your TCP connections during TCP handshake. Chances are that one of the routers along the path or Tunnel did some manipulation there (a.k.a. TCP MSS clamping). The value is probably quite a bit lower that actual or configured MTU.

MSS clamping is a dirty, but beneficial trick to make the TCP speakers at either end to believe that the remote can only accept a lower number of bytes per TCP segment, so'll the IP packets they generate will always be small enough for the given network path (lower-MTU tunnel included).

the size of the total incoming packets (IPv4/6 header and TCP header included)
the size of the pure TCP payload in the incoming packets (with all headers stripped away)

Wireshark might help to get some insights, here.

millernet

netztier Thank you very much for your input. I did some captures with Wireshark, but I can't interpret those data well enough, because I'm far from a TCP expert. What I know is, that everything works fine, when I set the MTU of my ethernet interface to 1480. As soon as it's changed back to 1500, www.swisscom.ch doesn't work but all other IPv6 sites I testet do. The only solution to overcome these issues is configuring each ethernet interface with MTU 1480, which is a pain in the but.

Here with MTU 1500: The webserver2a02:a90:c400:4001::2 seems to send an RST flag, which seems to indicate that the packets sent don't comply with something the server expects.

Here with MTU 1480:

millernet

Case solved. MSS clamping was the right keyword for the solution:

You not only need to specify the MTU 1480 for the IPv6 GIF interface but also the MSS of 1480 in pfSense. The MSS is 1420 (1480 - 60 Byte), but you need to enter 1480 as described bellow. So now pfSense seems to "clamp" itself. Now everything is working fine.

Basically, MSS clamping is needed, as soon as you are below the standard MTU of 1500, because path MTU discovery doesn't always work, due to blocked ICMP traffic. MSS clamping is still a hack and shouldn't be required, because it violates fundamental principles. But as soon as there's tunneling involved and you are below the standard 1500 Bytes, you need to use it, if you like it or not, especially on IPv6 without fragmentation in between the source and destination node. The whole issue is nicely explained in https://blog.ipspace.net/2013/01/tcp-mss-clamping-what-is-it-and-why-do.html and https://blog.ipspace.net/2013/01/mtu-issues-and-tcp-mss-clamping-in.html

Why the limited MTU of 1480 or even 1280, which is the required IPv6 minimum and configured as standard in pfSense if you leave the field empty, doesn't trigger MTU clamping, is still an open topic. To make MSS clamping work, you need put in a number into the MSS field on the interface as well.

millernet

The whole issue's root cause is the complete blockage of ICMPv6 on [www.swisscom.ch,](http://www.swisscom.ch,) which breaks Path MTU Discovery completely. This is far from the recommendations made by RFC 4890. I recommend according to 4.3.1 of RFC 4890 the following inbound rule on your firewall:

Allow - WAN Inbound

Source: any

Destination: any

ICMPv6: echo request, echo reply, destination unreachable, packet too big, time exceeded, parameter problem

On pfSense this rule looks like this:

You might consider rate limiting of ICMPv6 requests.

r00t

Hi @millernet

I guess its just another episode of shouldiblockicmp.com 😉

Perhaps @LeylaG could forward this thread to the according team again, as maybe their opinion on the topic has changed in the last three years? 😉

Best

r00t

« Page précédente