prefer ipv4 addresses

[Brian J. Murrell]

I have a Squid 3.1 server here in my IPv6 enabled network.
Unfortunately my IPv6 ISP has gone down but I still have IPv4 Internet
connectivity.

Is there any way I can disable Squid from wanting to connect to IPv6
websites, while still allowing IPv6 requests from clients?

Thanx!

b.

[Amos Jeffries-2]

Brian J. Murrell wrote:

> I have a Squid 3.1 server here in my IPv6 enabled network.
> Unfortunately my IPv6 ISP has gone down but I still have IPv4 Internet
> connectivity.
>
> Is there any way I can disable Squid from wanting to connect to IPv6
> websites, while still allowing IPv6 requests from clients?
>
> Thanx!
>
> b.
>

An option to simply turn IPv6 off is not possible at run time. A rebuild
of Squid is needed to fully disable IPv6.

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. 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.

You might also want to retain the service by setting up your own tunnel.
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.

Amos
--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.14

[Brian J. Murrell]

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.

[Amos Jeffries-2]

Brian J. Murrell wrote:
> 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.

Sorry, I read the Q wrong :(

>
>> 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.

Aye, this is what is supposed to be happening. There are a few others
reporting the same issue. I'm unable to replicate it here so far, so I'm
not sure what is breaking it.

ICMPv6 PMTU and DLD discovery should be rejecting the IPv6 connect and
causing immediate failover to IPv4.

Can you check that the MTU setting of your 6to4 interface restricts it
to under 1420 (around 1400 should do)?  if its over 1420 you will
encounter problems with some IPV4 networks doing packet fragmentation on
the wrapper packets.

>
> 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?

Perhapse. Probably just the interface down would be enough.

>
>> 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.

Ouch. Getting that going again ASAP has to be a priority. Do you know why?

>
>> 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.
>

Amos
--
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.14

[Henrik Nordstrom-5]

fre 2009-10-30 klockan 22:40 -0400 skrev Brian J. Murrell:
> 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.

A temporary workaround if the automatic failover doesn't work is to run
two squids, one ipv6+4, and one ipv4-only. Configure the ipv4-only Squid
as a parent to the other. This gives you a clean ipv6->ipv4 HTTP
gateway.

Regards
Henrik

[Brian J. Murrell]

On Sun, 2009-11-01 at 21:52 +0100, Henrik Nordstrom wrote:
>
> A temporary workaround if the automatic failover doesn't work

I was able to get the failover to work by installing an ip6tables rule
on the squid box:

Chain OUTPUT (policy ACCEPT 29M packets, 24G bytes)
 pkts bytes target     prot opt in     out     source               destination        
  101  8080 REJECT     all      *      *       ::/0                !2001:xxxx:xxxx::/64 OWNER UID match 13 reject-with icmp6-no-route

which basically just says that all packets leaving the squid server,
sent from a process with a uid of 13 (my squid user) and not going to
the local network get and ICMP no-route error, which makes squid do the
failover.

Excepting the local network is important so that responses to client
requests don't get met with the ICMP fate too.

> is to run
> two squids, one ipv6+4, and one ipv4-only. Configure the ipv4-only Squid
> as a parent to the other. This gives you a clean ipv6->ipv4 HTTP
> gateway.

Thanx for the suggestion.

b.