On 1/12/2012 3:09 a.m., Arzhel Younsi wrote:
> Hey list!
>
> Last week we ran into what I believe is a ipv6 implementation bug. We
> used to have a default IPv6 route (sent by the router via RA) on our
> Squid hosts but only fe80 (linklocal) addresses. A normal behavior
> would have been to not try to reach any v6 services outside its scope
> (same vlan) but here, Squid was trying to reach the v6 of
> www.google.com for example.
Squid attempting to connect to the v6 site when v6 connectivity is
available is correct behviour. Even if the only connectivity is a
different subnet (link-local in this case). There very well may be a
relay on the default gateway to handle the traffic for public Internet.
In the event that there is no route available the default gateway is
expected to respond with an ICMPv6 message informing the Squid box the
connectivity is broken. This gets relayed to Squid and it tries the next
destination IP in its DNS results. All in the order of less than a
millisecond even on dial modem connections.
> We worked-around that by disabling v6 on the hosts and will bring a
> full v6 connectivity in the next few days. So I was wondering if this
> was known (expected?) and if not, where to file a bug.
>
> That's for a regular forward, non-transparent
> squid-3.1.10-9.el6_3.x86_64 on RHEL6.
There is a side effect of the way 3.1 and older series outgoing
connections were designed that it tries the v6 addresses too often and
every failure results ina DNS re-lookup. This design flaw was resolved
in 3.2 series.
Please ensure that ICMP for both v4 and v6 are enabled properly on your
network (ICMP is not optional).
Please try squid-3.2, the IPv6 implementation is more stable than in 3.1
when it comes to partial connectivity.
Amos
Received on Fri Nov 30 2012 - 22:15:57 MST
This archive was generated by hypermail 2.2.0 : Sat Dec 01 2012 - 12:00:32 MST