On 1/01/2014 10:40 a.m., Craig R. Skinner wrote: > On 2013-12-31 Tue 23:07 PM |, Eliezer Croitoru wrote: >> Hey Craig, >> >> I want to verify the issue. >> Do these FreeBSD machines operate only on the ipv4 level? > > As I wrote Eliezer, I use OpenBSD which is dual stack. > > I included a link to a bug verified by the FreeBSD ports team. > >> >> The line you have mentioned: >> http://bazaar.launchpad.net/~squid/squid/3-trunk/view/head:/src/cf.data.pre#L847 >> Assumes that the machine is ipv6 enabled by default. > > It's very easy to test. No kernel or squid recompile needed. > > By setting the DNS resolver to use IPv4 only, squid can't start/parse Exactly. * How does Squid know that IP is an IPv6? * What about the HTTP request "GET http://[::1]/ HTTP/1.1" ? * What about the HTTP request "GET http://facebook.com/ HTTP/1.1" ? All of those are involving IPv6. The first of those requests requires the system resolver library to translate from string to numeric representation ... exactly the same way the config file is using. Your machine being set to IPv4-only is in the minority. We have to tune the default configuration for the majority case. > (i.e. it is a DNS resolution issue): > >>> >>> $ fgrep family /etc/resolv.conf >>> family inet4 >>> > > Re-enabling IPv6 DNS resolution lets squid run again: > >>> >>> $ fgrep family /etc/resolv.conf >>> #family inet4 >>> > > Maybe squid could first check at run time if IPv6 DNS resolution is > avaliable before requiring IPv6 default ACLs? > Possibly the resolv.conf configuration directive could be done earlier in the configuration sequence, the ACL made non-fatal when an invalid value is passed for interpretation as an IP address, and Squid updated to support that family directive from resolv.conf. Amos
