On 2014-07-16 15:40, Andre Keller wrote:
Hi,
we have a strange issue with a not that special setup.
we have customers that run basically an IPv6-only infrastructure with some ipv4 reverse proxies in front of the services that need to be publicly available. Some of these internal services can be accessed using a VPN. The VPN connection will provide a static IPv6 address for the client and a route to the ipv6 only servers will be pushed so traffic goes through the VPN.
Are they in effect on the client and does the application actually use them? Which OS is this on? Due to "Happy Eyeballs" you can have a lot of fun side-effects of IPv6 not being chosen for instance. (Split horizon, be that of IP or DNS tends to be a bad idea...)
In chrome the above does not work if the client has no global IPv6 access (i.e. an IPv6 default route).
That is more likely related to the OS in question.
It just does not resolve AAAA records as it seems, because access with literals (such as http://%5B2001:db8::1]) works.
Sounds like you are using Windows. There is a regedit option to solve that problem:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters
DWORD AddrConfigControl = 0
google for that and you'll find more details.
Though note that Chrome does some kind of probing to "determine that you have working IPv4 IPv6 connectivity" (read: google like it when you contact them once in a while so they can better "understand" where you are")
Does anybody know if there is a knob to alter this behavior? Other tested browsers are Firefox, Opera, Midori and Lynx which seem to work fine.
PS: sorry I could not come up with a better subject :-)
Depends on the platform. While browsers do their own thing, the OS typically has a lot to say in it.
Note that when you are on OSX there is a lot of nonsense happening regarding address selection/ordering based on historical stats on latency/throughput and that stuff cannot be turned off.
Greets, Jeroen