[squid-users] Re: prefer ipv4 addresses

On Sat, 2009-10-31 at 12:00 +1300, Amos Jeffries wrote:
>
> An option to simply turn IPv6 off is not possible at run time. A rebuild
> of Squid is needed to fully disable IPv6.

:-( But I don't even really want to disable IPv6. My clients use IPv6
to access squid.

> As long as there is no global IPv6 address assigned to the machine Squid
> should be failing over to IPv4-only requests without a problem.

But there is a global IPv6 address assigned. It's in this space that
all of the machines on the network communicate.

> If you
> can identify a problem then please point it out so we can work through
> fixing it before 3.1 goes into wide scale production.

Well the problem is that I (usually) have both IPv4 and IPv6 Internet
connections so accessing the IPv6 Web is usually no issue. However at
the moment my v6 connection is down so all access has to be via IPv4.
Squid does not know this of course and when it gets an AAAA record for
www.example.com, it tries to go there, times out and displays an error
(i.e. web site not responding or some such). Even having it fall back
to an available A record would be preferable.

I did read something about the ability to try alternate addresses if a
connection fails. Indeed, the "connect_timeout" advertises itself as
the amount of time before this happens. But I don't seem to be getting
any alternate (i.e. a v4 address when a v6 address fails) connection
attempts happening. Is a simple failure to reach a remote not cause to
try an alternate address for a given website?

Would this all work better if I removed some v6 default route info so
that ICMP no-route messages were being generated?

> You might also want to retain the service by setting up your own tunnel.

I don't have that facility at hand. In fact my not-currently-working
connectivity is a 6to4 tunnel, just not working at the moment.

> Squid only needs a client readable tunnel. 6to4 or miredo end-point on
> the box for example provide enough access for Squid to relay IPv6 web
> access.

With any hope, this outage isn't going to last long enough to warrant
making other arrangements.

b.