On 1/09/2013 11:16 a.m., Eliezer Croitoru wrote:
On 08/31/2013 06:47 AM, Amos Jeffries wrote:
On 31/08/2013 6:53 a.m., Michael Graham wrote:
On Wed, 2013-08-28 at 16:50 +1200, Amos Jeffries wrote:
What problem is it causing you exactly? Squid getting a SERVFAIL means
it goes on and uses the IPv4 addresses instead.
It takes around 2-4 seconds to time out which can make access to the
site very sluggish.
NP: It is worth noting that this SERVFAIL happens on *less* IPv6-enabled
sites overall than on IPv4-enabled ones. About 0.01% of IPv6 sites last
time it was measured by APNIC researchers, and things have been steadily
improving. Disabling access to IPv6 networks *entirely* for all your
customers is a bit of overkill for that type of error rate.
I know, I'm trying to keep it enabled but people are complaining about
access to this site and what else am I supposed to do?
There has been a proposal with patch submitted in the last few days that
can be used to avoid this problem on an dst-IP specific basis:
http://bugs.squid-cache.org/show_bug.cgi?id=3901
Amos
I wanted to ask something:
let say we have another general proxy situation not HTTP one.
if the client is trying to access a ipv4 intercepted address the general
and logical rule will be to contact the IPV4 address first right??
No. It is protocol dependent.
* FTP proxying for example has to proxy the IP:port-specific data
channels so while it can gateway things are not as easy.
* VoIP and other P2P have the opposite problem - with IPv6 it has no
need to perform lengthy rendevous processes to avoid NAT . So an
efficient implementations will prefer IPv6 over IPv4 to the point of
auto-enabling IPv6 in the client host system if it is not already
operational.
* HTTP was designed right from the core of the protocol to operate with
client-side and server-side connections being independent - they do not
even have to be using TCP/IP protocol.
and if the client tries to contact an IPV6 address the default will be
to contact the IPV6 service provider\server?
So can we set a basic rule of logic for squid intercepted connections to
try IPV4 first in a case of intercepted connection on a IPV4 address and
IPV6 on a IPV6 intercepted connection??
NP: these "rules" are true as of Squid-3.2. Older Squid versions had a
much more complicated behaviour involving repeated cycles of DNS lookups
(and rotating IPs) which nobody could really predict well when more than
just IPv4 was involved. In overview Squid should behave a lot more like
the browsers now (but not exactly like them).
It is the default that Squid prefers IPv6 over IPv4 for *all* traffic.
There are some exceptional conditions where this is not possible however:
* if the Host header validation fails - we are required to use the same
IP the client was (ORIGINAL_DST)
- the default for intercepted traffic is to try the client
ORIGINAL_DST first anyway and use the Squid preferences as backup
routes. This ensures some measure of true transparency for the client
and server about who they are connecting to.
* if IPv6 is not working on the destination host - we still try IPv6
first but failover to IPv4 as quickly as possible (and remember the
failure for futrue IPv4 preference).
* if IPv6 is disabled in the machine - we are required to use IPv4-only
(obviously).
* if explicit access controls are configured to deny access to the IPv6
destinations ("admin knows best - even if they are a complete and utter
idiot").
- the bug report and patch I reference above come under this clause.
Why we prefer IPv6?
The squid by-line is "Optimizing Web Delivery". IPv6 traffic is
faster for the majority of networks and that majority is both getting
faster and growing as more network admin become aware of and solve their
IPv6 problems.
I am unsure about the current situation So correct me if i'm wrong on
the current logic.
Thanks,
Eliezer
