So I’m using IPv6 at home. Great. Unfortunately that makes this place kind of unavailable a lot of the time on platforms that prefer IPv6.
Right now, for example:
sh-3.2$ dig forum.mikrotik.com | grep IN
;forum.mikrotik.com. IN A
forum.mikrotik.com. 2184 IN A 159.148.147.201
sh-3.2$ dig AAAA forum.mikrotik.com | grep AAAA
; <<>> DiG 9.7.3 <<>> AAAA forum.mikrotik.com
;forum.mikrotik.com. IN AAAA
forum.mikrotik.com. 7028 IN AAAA 2a02:610:7501:1000::201
sh-3.2$ ping 159.148.147.201
PING 159.148.147.201 (159.148.147.201): 56 data bytes
64 bytes from 159.148.147.201: icmp_seq=0 ttl=54 time=465.923 ms
64 bytes from 159.148.147.201: icmp_seq=1 ttl=54 time=385.715 ms
64 bytes from 159.148.147.201: icmp_seq=2 ttl=54 time=613.587 ms
64 bytes from 159.148.147.201: icmp_seq=3 ttl=54 time=533.988 ms
^C
--- 159.148.147.201 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 385.715/499.803/613.587/84.082 ms
sh-3.2$ ping6 2a02:610:7501:1000::201
PING6(56=40+8+8 bytes) 2001:470:f037:1:69d5:4e7e:8b9f:95aa --> 2a02:610:7501:1000::201
^C
--- 2a02:610:7501:1000::201 ping6 statistics ---
11 packets transmitted, 0 packets received, 100.0% packet loss
sh-3.2$ ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2001:470:f037:1:69d5:4e7e:8b9f:95aa --> 2001:4860:4001:803::1011
16 bytes from 2001:4860:4001:803::1011, icmp_seq=0 hlim=56 time=100.495 ms
16 bytes from 2001:4860:4001:803::1011, icmp_seq=1 hlim=56 time=52.778 ms
16 bytes from 2001:4860:4001:803::1011, icmp_seq=2 hlim=56 time=28.520 ms
16 bytes from 2001:4860:4001:803::1011, icmp_seq=3 hlim=56 time=28.183 ms
16 bytes from 2001:4860:4001:803::1011, icmp_seq=4 hlim=56 time=29.068 ms
^C
--- ipv6.l.google.com ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 28.183/47.809/100.495/27.961 ms
sh-3.2$ telnet -6 2a02:610:7501:1000::201 80
Trying 2a02:610:7501:1000::201...
telnet: connect to address 2a02:610:7501:1000::201: Operation timed out
telnet: Unable to connect to remote host
sh-3.2$
IPv4 latency is atrocious, IPv6 is just unavailable. Some platforms don’t just ignore IPv6 when it’s unavailable, so this resource is seen as unavailable when only IPv4 is up.
what about a traceroute? i have seen that some IPv6 providers can’t reach us, some can. Can you try from a different IPv6 provider (I assume you use HE?)
I am using HE. I can’t try using another provider, I’m afraid.
Here the traceroute - you’re right, it does die within HE. Unfortunately for your North American audience that’s going to be most of the traffic. Most of us can’t get native IPv6 at home since US providers are way, way, way behind the curve on IPv6 while many of your users aren’t.
Any chance of getting your IPv6 uplink to talk to HE about what’s going on? The hop names indicate I’m making it to Germany, I guess?
sh-3.2$ traceroute6 forum.mikrotik.com
traceroute6 to forum.mikrotik.com (2a02:610:7501:1000::201) from 2001:470:f037:1:69d5:4e7e:8b9f:95aa, 64 hops max, 12 byte packets
1 2001:470:f037:1::1 3902.205 ms 1.085 ms 0.913 ms
2 [retracted].tunnel.tserv15.lax1.ipv6.he.net 21.600 ms 21.214 ms 19.362 ms
3 gige-g4-6.core1.lax1.he.net 18.681 ms 33.925 ms 23.623 ms
4 10gigabitethernet4-3.core1.nyc4.he.net 80.134 ms 80.096 ms 78.218 ms
5 10gigabitethernet3-3.core1.lon1.he.net 147.565 ms 154.337 ms 146.257 ms
6 10gigabitethernet4-2.core1.fra1.he.net 170.106 ms 158.448 ms 157.756 ms
7 * * *
8 * * *
9 * *^C
sh-3.2$
3 2001:5a0:2800::e (2001:5a0:2800::e) 77.652 ms 77.582 ms 77.526 ms
4 ffm-b10-link.telia.net (2001:2000:3080:30c::1) 79.093 ms 79.060 ms 77.255 ms
5 s-b3-v6.telia.net (2001:2000:3018:9::1) 100.877 ms 99.454 ms 106.812 ms
6 * * *
7 * * *
Did you try to contact your provider? It doesn’t work from Fremont but it works from Frankfurt (tool http://lg.he.net/):
core1.fmt1.he.net> traceroute ipv6 2a02:610:7501:1000::2
Tracing the route to IPv6 node 2a02:610:7501:1000::2 from 1 to 30 hops
1 9 ms 2 ms 33 ms 2001:470:0:2f::2
2 34 ms 46 ms 27 ms 2001:470:0:1b4::2
3 52 ms 51 ms 51 ms 2001:470:0:1af::1
4 71 ms 71 ms 71 ms 2001:470:0:1c6::1
5 149 ms 150 ms 149 ms 2001:470:0:128::2
6 168 ms 157 ms 149 ms 2001:470:0:1d2::2
7 * * * ?
8 * * * ?
9 * * * ?
10 * * * ?
IP: Errno(8) Trace Route Failed, no response from target node.
# Entry cached for another 30 seconds.
core1.phx1.he.net> traceroute ipv6 2a02:610:7501:1000::2
Invalid input -> numeric# Entry cached for another 59 seconds.
core1.fra1.he.net> traceroute ipv6 2a02:610:7501:1000::2
Tracing the route to IPv6 node 2a02:610:7501:1000::2 from 1 to 30 hops
1 35 ms 41 ms 40 ms 2001:7f8::a7e3:0:1
2 54 ms 49 ms 56 ms 2a02:610:ffff:1800::2
3 43 ms 49 ms 50 ms 2a02:610:ffff:1003::2
4 41 ms 50 ms 49 ms 2a02:610:7500::1
5 57 ms 50 ms 49 ms 2a02:610:7500:8::2
6 50 ms 49 ms 50 ms 2a02:610:7500:9::2
7 55 ms 52 ms 48 ms 2a02:610:7501:1000::1
8 52 ms 47 ms 46 ms 2a02:610:7501:1000::2# Entry cached for another 51 seconds.
I been unable to access www.mikrotik.com all day with my HE 6 to 4 tunnel enabled it does load eventually but it takes minutes.
sudo rltraceroute6 www.mikrotik.com
traceroute to www.mikrotik.com (2a02:610:7501:1000::2) from 2001:470:1f09:1aa8:225:22ff:fe7a:4ff1, port 33434, from port 58938, 30 hops max, 60 bytes packets
1 2001:470:1f09:1aa8::1 (2001:470:1f09:1aa8::1) 0.195 ms 0.096 ms 0.137 ms
2 2001:470:1f08:1aa8::1 (2001:470:1f08:1aa8::1) 15.855 ms 15.633 ms 15.261 ms
3 gige-g4-6.core1.lon1.he.net (2001:470:0:67::1) 15.804 ms 23.469 ms 14.352 ms
4 10gigabitethernet4-2.core1.fra1.he.net (2001:470:0:1d2::2) 33.700 ms 24.800 ms 18.058 ms
5 * * *
6 * * *
7 * * *
8 * * *
As soon as disable my 6 to 4 tunnel ipv4 works fine but i not got any issues with any other ipv6 sites.
No kidding. It’s extremely annoying. As a single user of an HE tunnel there isn’t much I can do, I’m not even giving anyone money. Chances would be much, much better if Mikrotik used their IPv6 uplinks to lean on whoever is broken on the chain - at least there’s money changing hands there somewhere, so there’s incentive.
Or maybe you could as you are the representative here for Mikrotik considering its MIkrotik that can’t be reached. I know I’d track down the problem if it were my customers not able to reach me.
quote: “From experience, lots of things can’t be reached with ipv6.”
Strangely in the 6+ years I’ve been using IPv6, I can’t recall having many issues with sites broadcasting AAAA DNS records. The only one that sticks in my mind is mikrotik.com.
Maybe its not so much as the internet as a whole but more localised that you base your experience.
I always presumed it was for testing in case end users were using broken browser implementations etc. By seperating into the 2 domain records it is easy to identify issues between ipv4 and ipv6 without losing traffic to the site. That said, www.google.com has AAAA records too that work fine but I’m sure you know this.
www.google.com > has AAAA records too that work fine but I’m sure you know this.
no, they don’t work fine, that’s why they have a separate domain. because there are too many problems with ipv6 still.
like I said, we will try to get our other ISP to give us IPv6, we will see if that makes a difference. The current ISP is unable to solve the HE problem.
I have native Level3 v6 and can’t get there. It’s probably something to do with peering agreements between providers. : )
Email NOC@HE.NET and ask them to look into it, give them the source IP and the destination IP. I’ve had many times where my v6 bgp prefix was still being announced to them but many of their routers lost it / or dampened it for a week at a time.
Hurricane Electric is still announcing the IPv6 prefix in question to my network. Various public looking glass sites show that Sprint and TATA (among others) can reach MikroTik’s network just fine. I just sent off an email to HE.NET asking for more information. If I hear back, I will post in this thread. As we peer with HE.NET at http://www.seattleix.net/ and they provide us IPv6 transit for this particular prefix, I hope they’ll respond in a timely fashion. I would at least like to know the AS number of the HE.NET peer that’s injecting the prefix onto their network.