SixXS::Sunset 2017-06-06

[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[de] Shadow Hawkins on Monday, 13 January 2014 10:08:19
Hi there, I've got the problem that the AICCU tunnel seems to work great, I can ping6 all ipv6 hosts, Chromium works with ipv6 only hosts, netstat -nr shows me that routing seems to work fine.... But: Safari will not touch any ipv6 host and always tells me that the host could not be found. (Same for Firefox.) Now that is kind of annoying... Since the tunnel is set up correctly (works from the shell) I guess that somehow I'm missing an additional step. Since I however haven't found anything searching the web, I'm now asking for help here. :) Do you have any suggestion in which direction I have to search to debug this? Some info: ifconfig shows this (shortened)
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1280 inet6 fe80::226:b0ff:fedb:c91c%tun0 prefixlen 64 scopeid 0x8 inet6 2001:6f8:900:10db::2 --> 2001:6f8:900:10db::1 prefixlen 128 nd6 options=1<PERFORMNUD> open (pid 18719)
netstat -nr show s this (shortened)
Internet6: Destination Gateway Flags Netif Expire default 2001:6f8:900:10db::1 UGSc tun0 ::1 ::1 UHL lo0 2001:6f8:900:10db::1 2001:6f8:900:10db::2 UHLr tun0 2001:6f8:900:10db::2 link#8 UHL lo0
I have found this thread on apples support forum where someone seems to have the same symptoms: https://discussions.apple.com/message/23524843#23524843 But alas also no solution. :-(
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[ch] Jeroen Massar SixXS Staff on Monday, 13 January 2014 10:12:24
Sounds like a DNS-related issue to me. What DNS server are you using? It could be that Chromium uses an alternative if it detects mangling of responses (they do DNS tests). Can you try the ipv6check to see what the results there are?
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[de] Shadow Hawkins on Monday, 13 January 2014 10:26:08
Jeroen Massar wrote:
Sounds like a DNS-related issue to me.
That sounds true, I have checked for ipv6 addresses in the browser, and I am able to use Safari to connect to URLs like this: http://[2a00:1450:4001:c02::67]/ (ipv6.google.com).
What DNS server are you using? It could be that Chromium uses an alternative if it detects mangling of responses (they do DNS tests).
Well, since 'dig ipv6.google.com AAAA' works as expected and show that the local dns server (fritz box) is used for the query, I took that as a sign that dns queries work ok. :/ assumptions :/
Can you try the ipv6check to see what the results there are?
This is from Safari:
Prefers IPv4 or IPv6?: Request could not be made NXDOMAIN test (must fail): Failed as expected DNS-based IPv6 access: Request could not be made Fetch 50k IPv6: Request could not be made DNS-based SSL IPv6 access: Request could not be made IPv6-only DNS resolver: Request could not be made Naked IPv4: Got expected response (ipv4) in 342 ms DNS-based IPv4 access: Got expected response (ipv4) in 402 ms Naked IPv6: Got expected response (ipv6) in 405 ms IPv4-only DNS resolver: Got expected response (ipv4) in 419 ms Fetch 50k IPv4: Got expected response (ipv4) in 602 ms Prefers IPv4 or IPv6? (SSL): Got expected response (any) in 675 ms DNS-based SSL IPv4 access: Got expected response (ipv4) in 712 ms Your IPv4 address: 88.217.25.183 (IPv4) Your IPv6 address: 2001:6f8:900:10db::2, country: Germany, ISP: Easynet, AS4589, Prefix: 2001:6f8:900:10db::1 (SixXS Tunnel on PoP deham01)
This is from Chromium:
Prefers IPv4 or IPv6?: Request could not be made NXDOMAIN test (must fail): Failed as expected Prefers IPv4 or IPv6? (SSL): Got expected response (any) in 273 ms Naked IPv4: Got expected response (ipv4) in 289 ms Naked IPv6: Got expected response (ipv6) in 366 ms DNS-based IPv6 access: Got expected response (ipv6) in 495 ms IPv4-only DNS resolver: Got expected response (ipv4) in 538 ms DNS-based SSL IPv4 access: Got expected response (ipv4) in 555 ms IPv6-only DNS resolver: Got expected response (ipv6) in 599 ms DNS-based SSL IPv6 access: Got expected response (ipv6) in 622 ms Fetch 50k IPv6: Got expected response (ipv6) in 745 ms DNS-based IPv4 access: Got expected response (ipv4) in 2853 ms Fetch 50k IPv4: Got expected response (ipv4) in 3192 ms Your IPv4 address: 88.217.25.183 (IPv4) Your IPv6 address: 2001:6f8:900:10db::2, country: Germany, ISP: Easynet, AS4589, Prefix: 2001:6f8:900:10db::1 (SixXS Tunnel on PoP deham01)
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[ch] Jeroen Massar SixXS Staff on Monday, 13 January 2014 10:38:40
Do you have any kind of firewalling enabled (eg Little Snitch? which btw is very recommended on a Mac, you'll suddenly see how much network leakage is happening with everything calling home)
Well, since 'dig ipv6.google.com AAAA' works as expected and show that the local dns server (fritz box) is used for the query, I took that as a sign that dns queries work ok. :/ assumptions :/
Which kind of Fritz!Box is it? Most should be IPv6 ready, then again, if the ISP you are resolving against has broken DNS servers it won't help much. Being able to dig for an AAAA is a good sign though. DNS on Mac OSX is rather tricky, as they do latency tests and other things in the resolver that Chrome afaik seems to skip as they have their own resolver (see chrome://net-internals and then the DNS tab). Just in case, Safari works for me on OSX 10.9.1 with Safari 7.0.1 (9537.73.11). (The first "Prefers IPv4 or IPv6?: Request could not be made" is 'ok' btw, still need to resolve that problem, has to do with the Origin allowances and going from https to http, hence why that thing notes "BETA"; and definitely ignore the latencies, as the requests are all made at the same time the start time is noted wrongly and the times are thus for the full length of the request/response which is wrong)
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[de] Shadow Hawkins on Tuesday, 14 January 2014 09:25:32
Jeroen Massar wrote:
Do you have any kind of firewalling enabled (eg Little Snitch? which btw is very recommended on a Mac, you'll suddenly see how much network leakage is happening with everything calling home)
Yes, I'm using LittleSnitch - however disabling it doesn't make Safari work. :/ Checking settings for Safari and it's background process also doesn't bring up anything fishy.
Which kind of Fritz!Box is it? Most should be IPv6 ready, then again, if the ISP you are resolving against has broken DNS servers it won't help much. Being able to dig for an AAAA is a good sign though.
Well, not mine and since this is something that I need to work wherever I am, not something I can rely on. However, switching to googles dns server (8.8.8.8) doesn't bring any relief. :(
DNS on Mac OSX is rather tricky, as they do latency tests and other things in the resolver that Chrome afaik seems to skip as they have their own resolver (see chrome://net-internals and then the DNS tab).
Just in case, Safari works for me on OSX 10.9.1 with Safari 7.0.1 (9537.73.11).
When I'm at home and my fritz box is providing ipv6, Safari is also working perfectly fine - it's just when I'm using this aiccu tunnel that Safari doesn't want to play. So, I'm currently stuck with that Safari doesn't seem to want to make AAAA dns queries and thus thinks that it cannot reach IPV6 enabled hosts. Is there a way to invoke the dns logic that Safari uses directly from the shell to debug it? It almost seems like there is just a boolean wrong somewhere that prevents it from actually doing the ipv6 AAAA dns requests.
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[ch] Jeroen Massar SixXS Staff on Tuesday, 14 January 2014 10:34:15
it's just when I'm using this aiccu tunnel that Safari doesn't want to play.
I use that combination quite often when traveling/locations-without-native-ipv6, never had an issue with it.
Is there a way to invoke the dns logic that Safari uses directly from the shell to debug it?
The OSX resolver is horrible ever since Lion, this as there is logic that cannot be turned off or easily inspected. (I have a "AddressFamily inet6" in my .ssh/config because of this nonsense....) Apparently:
dns-sd -G v4v6 <host>
might give you the possibility to pre-fill the DNS cache, then try if Safari sees that host, thus that is something to try, and using:
dns-sd -q <host>
Beats me why this is apparently related to "DNS Service Discovery" btw.... Also, you can see "routing statistics" by running:
nettop -n -m route
That can show you if decisions are being made to even consider routing over IPv6...
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[de] Shadow Hawkins on Tuesday, 14 January 2014 16:16:55
Jeroen Massar wrote:
it's just when I'm using this aiccu tunnel that Safari doesn't want to play.
I use that combination quite often when traveling/locations-without-native-ipv6, never had an issue with it.
Well, I had this running about a year ago with 10.8, but I haven't yet seen this working with 10.9.1 that I'm now on.
The OSX resolver is horrible ever since Lion, this as there is logic that cannot be turned off or easily inspected. (I have a "AddressFamily inet6" in my .ssh/config because of this nonsense....)
:) I'm also appalled by the state of tooling, for example in the browser there is no way to see in the debugging tools whether content was loaded via IP4 or 6 and there is no way to restrict some hosts to be reachable via ipv6 only, etc...
Apparently:
dns-sd -G v4v6 <host>
might give you the possibility to pre-fill the DNS cache, then try if Safari sees that host, thus that is something to try, and using:
dns-sd -q <host>
Nope, doesn't work. :/
Also, you can see "routing statistics" by running:
nettop -n -m route
That can show you if decisions are being made to even consider routing over IPv6...
I'm not completely sure what I make from this, looking at this output:
bytes in default -> en1 -> 10.1.3.254 6754 KiB 10.1.127.249 10 KiB 17.72.148.53 532 B # Some ipv4 addresses removed 95.105.215.172 54 B 97.88.14.151 54 B 157.55.235.155 54 B 111.221.74.20 54 B 157.55.235.157 48 B 10.1.0/22 -> en1 560 B 10.1.3.254 -> 0:0:c:7:ac:0 0 B 10.1.3.255 0 B 10.1.3.41 -> lo0 71 KiB 127/8 -> lo0 -> 127.0.0.1 0 B 127.0.0.1 -> lo0 107 MiB 169.254/16 -> en1 0 B 169.254.255.255 0 B default -> tun0 -> 2001:6f8:900:10db::1 38 KiB 2001:4860:4860::8888 0 B 2a01:4f8:192:61cf::4 2230 B 2a00:1450:4001:807::1005 5844 B 2a00:1450:4001:c02::5b 7776 B 2a00:1450:4001:80f::1005 22 KiB 2a00:1450:4001:807::1009 0 B ::1 -> lo0 4258 KiB 2001:6f8:900:10db::1 -> tun0 19 KiB 2001:6f8:900:10db::2 -> lo0 0 B fe80::/64 -> lo0 -> fe80::1%lo0 0 B fe80::1%lo0 -> lo0 449 KiB fe80::/64 -> en0 0 B fe80::/64 -> en1 21 MiB fe80::143f:51:d0a8:c748%en1 -> f4:f1:5a:ec:96:2b 4401 KiB fe80::8e2d:aaff:fe3f:fb55%en1 -> 8c:2d:aa:3f:fb:55 383 KiB fe80::226:bbff:fe09:30a8%en1 -> lo0 94 KiB fe80::/64 -> tun0 -> fe80::226:b0ff:fedb:c91c%tun0 0 B fe80::226:b0ff:fedb:c91c%tun0 -> lo0 0 B ff01::/32 -> lo0 -> ::1 0 B ff01::/32 -> en0 0 B ff01::/32 -> en1 0 B ff01::/32 -> tun0 -> fe80::226:b0ff:fedb:c91c%tun0 0 B ff02::/32 -> lo0 -> ::1 0 B ff02::/32 -> en0 0 B ff02::/32 -> en1 0 B ff02::/32 -> tun0 -> fe80::226:b0ff:fedb:c91c%tun0 0 B
I would say that routing is considering ipv6 - which makes sense as it works great from Chromium and I can surf to urls like http://[ipv6:address] with Safari. Well.... I'm kinda out of Ideas how to tame this beast. I know it should work, but by all intents and purposes, the Mac DNS resolver seems to blatantly resist using ipv6. :-(
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[ch] Jeroen Massar SixXS Staff on Tuesday, 14 January 2014 16:59:45
:) I'm also appalled by the state of tooling, for example in the browser there is no way to see in the debugging tools whether content was loaded via IP4 or 6 and there is no way to restrict some hosts to be reachable via ipv6 only, etc...
Well, Chrome does this neither, they do not report the actual IP address they talked to; strange as that info should be available one would think.
I would say that routing is considering ipv6
It is not the routing, it the actual connections that where used. The fun part is that latency/throughput is considered too, and based on that, effectively random either IPv4 or IPv6 or even a certain IP is chosen for a destination based on recent performance, which makes debugging things on a Mac amazing.... and nope, there is no (known) toggle for disabling this magic or even a log of sorts.
Well.... I'm kinda out of Ideas how to tame this beast.
You don't have any strange programs running or plugins in Safari? One place you could ask is the Apple IPv6 lists: https://lists.apple.com/mailman/listinfo/ipv6-dev at least there are Apple folks there who might some other weird undocumented tricks and tips.
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[de] Shadow Hawkins on Wednesday, 15 January 2014 09:16:34
Jeroen Massar wrote:
:) I'm also appalled by the state of tooling, for example in the browser there is no way to see in the debugging tools whether content was loaded via IP4 or 6 and there is no way to restrict some hosts to be reachable via ipv6 only, etc...
Well, Chrome does this neither, they do not report the actual IP address they talked to; strange as that info should be available one would think.
Well, please support this meta bug so we get decent tooling at some point: https://bugs.webkit.org/show_bug.cgi?id=125152
It is not the routing, it the actual connections that where used. The fun part is that latency/throughput is considered too, and based on that, effectively random either IPv4 or IPv6 or even a certain IP is chosen for a destination based on recent performance, which makes debugging things on a Mac amazing.... and nope, there is no (known) toggle for disabling this magic or even a log of sorts.
:-( Logs that can at least be enabled do debug this are quite essential I'd say. I'll see if I can file a rdar:// for this.
Well.... I'm kinda out of Ideas how to tame this beast.
You don't have any strange programs running or plugins in Safari?
I do, lots of them. Sadly disabling all of them didn't get me any improvements. Also note that Firefox shows the same behavior, so I think it is something deeper down than Safari.
One place you could ask is the Apple IPv6 lists: https://lists.apple.com/mailman/listinfo/ipv6-dev at least there are Apple folks there who might some other weird undocumented tricks and tips.
Thats at least a good next step. Thanks!
[Mac/Mavericks] Safari cannot use AICCU Tunnel - but Chromium can
[de] Shadow Hawkins on Wednesday, 15 January 2014 10:35:57
PROGRESS! The hint with the apple ipv6-dev mailinglist got me this great tip: -- snip -- - How can I understand how the dns resolver is resolving ip addresses? scutil dns; look for flags : Request A records, Request AAAA records vs. just A records. The moment this changes is the moment you have an IPv6 address on an officially managed interface. So despite having a tun0 with an IPv6 address and an inet6 default route it will not do AAAA lookups. Workaround: set the IPv6 configuration to Manual and just put a 2001:db8::1 in the address field of your wifi or ethernet. -- snap -- In addition to the ipv6 address, I also had to add the prefix length of 64 to make it work, but now it does and I have ipv6 in Safari. Finally. Sadly this is not a permanent workaround since as soon as I hit a spot where I have native ipv6 (and I don't want to use the tunnel then) I have to remove this manual configuration. But at least it's a workaround. Some additional info I got from there:
> How can I see how and when the dns resolver did resolve specific addresses? Turn on mDNSResponder logging and debugging (see the signals in the man page) and then do a sudo tail -100f /var/log/system.log Funny thing you might see in certain cases if scutil doesnt report the AAAA look-up but you have put in hardcoded IPv6-only resolvers for a certain domain (see resolver(5) about /etc/resolver/<domain.name>) that Mail might log errors about No route to host despite route get -inet <IPv6-only DNS Sever IP> returns your tunnel default host. Totally confusing error message. The best way would to have a System Preferences addition to manage the sixes interface officially; that would be awesome.

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker