In World of Warcraft there is an option to use IPv6 when available, under "System" and "Advanced"
Sadly this is still not ticked by default. I really think it should be now.
Unfortunately I found it was not working. SYNs going out and no reply. This adds some delay to connecting as it tries IPv6 first. A trace shows that we are getting in to Telia, who prove Blizzard with their connectivity.
So, it looks like some sort of firewalling issue to me - otherwise you'd expect ICMPv6 errors for network or host, or a RST for the connection. Indeed, if there was some sort of error response, as their should be, the client could immediately fall back to IPv4 with no delay.
What is worse is there seems to be no way to get this sorted. I did, of course, raise a ticket. In fact I raised two - one for the impossibility of logging in at all when busy (just hangs) and one for the lack of IPv6. They promptly assumed the two were related, which they were not, and I spent an hour or so talking to a GM on the subject.
He was, to my surprise, quite knowledgable. Unfortunately both tickets are sort of going nowhere. The load issue may be a bug as well, as I worked out that I can work around by logging in to a character that is not parked in a garrison, and then logging out and logging in as the one I want. We discussed the way garrison instances work. I see why they can't do the garrison on the client - as apparently you can visit a friends garrison. That is something I did not know :-)
However, the IPv6 issue he basically can't help with, and has no way to escalate to someone that can.
I have offered to help in any way I can, checking route announcements are right, tracing from various places, etc. I am sure if their IPv4 connectivity was broken in this way then they would fix it damn quick, so why not treat the current version of IP in the same way?
So, Blizzard:
- Please fix the broken IPv6 - ask me if you want any info, ticket EU47550106
- Fix your firewall so that if IPv6 is not working the correct ICMPv6 responses are sent
- Please change the client to default to IPv6 enabled
Similar results:
ReplyDeleteroot@nagios:/home/fbulk# tcptraceroute6 2a04:e800::100:f6ce:46ff:fe89:e5f4 3724
traceroute to 2a04:e800::100:f6ce:46ff:fe89:e5f4 (2a04:e800:0:100:f6ce:46ff:fe89:e5f4) from 2607:fe28:0:1000::5, port 3724, from port 35987, 30 hops max, 60 bytes packets
1 router-core.mtcnet.net (2607:fe28:0:1000::1) 0.276 ms 0.219 ms 0.205 ms
2 sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197) 0.201 ms 0.131 ms 0.130 ms
3 v6-premier.sxcy-mlx.fbnt.netins.net (2001:5f8:7f0a:2::1) 1.629 ms 1.573 ms 1.583 ms
4 v6-ins-db4-te-0-6-0-4-219.desm.netins.net (2001:5f8:1:1::1) 8.377 ms 8.003 ms 7.815 ms
5 2001:550:2:24::9:1 (2001:550:2:24::9:1) 7.959 ms 7.907 ms 7.905 ms
6 2001:550:0:1000::9a36:2eed (2001:550:0:1000::9a36:2eed) 15.156 ms 15.399 ms 15.207 ms
7 2001:550:0:1000::421c:44a (2001:550:0:1000::421c:44a) 15.558 ms 15.502 ms 15.946 ms
8 2001:550:3::11a (2001:550:3::11a) 19.467 ms 19.441 ms 22.727 ms
9 * * *
10 * * *
11 * * *
12 adm-b5-v6.telia.net (2001:2000:3018:d::1) 118.025 ms 117.893 ms 117.871 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
root@nagios:/home/fbulk#
One of the problems here is there is a general perception that all ICMP is evil and must be firewalled into a blackhole. I can't generate outgoing pings from work for example, our company firewall just eats them. This isn't very sensible in IPv4 and makes even less sense in IPv6, but the "ping of death" vulnerability and DDOS attacks using ICMP have made it so.
ReplyDeleteHmm, I'm sure I had v6 enabled in the client and it seemed to be working fine last time I checked. I'll have to try it again sometime...
ReplyDelete