[squid-users] no fallback to ipv4 if ipv6 remote address is non-functional

[Brian J. Murrell]

On Mon, 2015-06-15 at 06:47 +1200, Amos Jeffries wrote:
> 
> 1)
> I have confirmed my suspicion that your IPv6 routing is a bit broken.

I'm not sure I agree with you entirely on that (more below)...

> The IPv6 address is in a private IP range fc00::/7.

Oh damn.  It's a ULA address.  I did not even recognize that.  The IPv6
addressing space is still foreign enough to me that I don't immediately
recognize what bits of the space certain addresses are in, unlike my
instant recognition of IPv4 private IP space.

> Which is the IPv6
> equivalent of RFC1918 10.0.0.0/8 or 182.168.0.0/16.

s/182/192/, but yes, indeed.  I see that now.

> When your Squid
> contacts it nothing at all happens within 10 seconds.

Unsurprisingly, of course.

> What should be happening is that when Squid tries to contact a network
> range which is not your own LAN fd31:aeb1:48df::/48 sub-net.

It should forward it to the Squid machine's default router.

> The routing
> system in your Squid machine responds with a "network unavailable"
> within nanoseconds.

I disagree.  While I will agree that it is good network management
practice to not allow RFC-1918 and IPv6's corresponding ULA addresses to
leak outside of your network, AFAIK, it's not a requirement.  RFC 4193
4.3 makes it a recommendation ("should") rather than a requirement
("MUST").

This is really no different than RFC-1918 addresses, which were not
always designated for their current practice and only since that
designation are also only recommended against blocking at the site
router.

> This signal which is not appearing is what Squid
> depends on to to do the failover.

(As you point out below, so I think we are in agreement) I would think
that a simple timeout to connect should be just as sufficient, just like
any other piece of software, such as telnet for example.  I would think
no software should really rely on the behaviors of (only) recommended
practices.

> Do you have an entry in the routing table for fc00::/7 or /8 ?

No.

> 2)
> Squid should still be attemoting the IPv4 address though.

Agreed.

> I also see you have Squid-3.4.3. Can you try an upgrade to 3.5.5 ?

OK.  Built and installed.

Still doesn't seem to be working.

> If the problem persists after that upgrade. Please redo with 26,5 in the
> debug list.

Sent to your e-mail.

> Also, check your proxy connect_timeout is shorter than forward_timeout.

#Default:
# forward_timeout 4 minutes

So seems it is.

> The connect timout affects these individual connections, forward_timeout
> needs to allow mulitiple (25?) of them for failover to have a chance in
> lost packet situations like this.

Interestingly enough, my override of the default of connect_timeout to
10 seconds actually makes it as close to 25 times less than
forward_timeout as I could reasonably get.  :-)

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150615/62a30f29/attachment.sig>