Bug 1254016

Lowering the severity to medium, as this bug does not fit the Urgent severity description.

You don't think it's urgent that any website with a non-working IPv6 end-point cannot be reached through squid?

A non-working IPv4 endpoint would likely become very obvious to a website owner pretty quickly and get fixed pretty quickly but a non-working IPv6 endpoint might not (get noticed or even fixed quickly) with the low-penetration of IPv6 thus far, in addition to the assumption by the website owner that any hosts failing to reach the IPv6 endpoint will fallback to IPv4.

This bug in squid leaves those websites unreachable to users with IPv6 with who knows what kind of repair time the website owner might have given the above assumptions.

And yes, it's not lost on me that ultimately this is the fault of the broken website but that doesn't change the fact that the fallback that any non-squid using host will enjoy will not be enjoyed by a squid-proxied user.

(In reply to Brian J. Murrell from comment #4)
> You don't think it's urgent that any website with a non-working IPv6
> end-point cannot be reached through squid?

I'm aware of the implications of this bug. I think the bug is important, but yes I don't think it is urgent.

Urgent stands for:
"catastrophic issues which severely impact the mission-critical operations of an organization. This may mean that the operational servers, development systems or customer applications are down or not functioning and no procedural workaround exists."

Also RHEL development works in a different way compared to Fedora. RHEL is aimed for stability and compatibility between releases. Therefore it is very unlikely we will update the package to the latest upstream version without thorough investigation of possible issues. However we may look at backporting the fix for the IPv4 fallback.

(In reply to Tomas Hozza from comment #5)
> 
> Urgent stands for:
> "catastrophic issues which severely impact the mission-critical operations
> of an organization. This may mean that the operational servers, development
> systems or customer applications are down or not functioning and no
> procedural workaround exists."

OK.

> Also RHEL development works in a different way compared to Fedora. RHEL is
> aimed for stability and compatibility between releases. Therefore it is very
> unlikely we will update the package to the latest upstream version without
> thorough investigation of possible issues. However we may look at
> backporting the fix for the IPv4 fallback.

Indeed.  I am aware of this.  I think this ticket was trying to cover both.  That a patch backport (which I will attach) is needed in the short term but that updating to the latest for the next point release would be desirable since there are lots of other fixes in there.

Created attachment 1064900 [details]
backported patch

Any activity/progress on this issue?

The bug is currently proposed for the next RHEL-7 minor update. However I can not make any promises that it will be included.

errata-xmlrpc 2016-06-14 08:04:34 EDT
Status: MODIFIED → ON_QA

How long does it stay ON_QA before we see it in the regular repo?

(In reply to Brian J. Murrell from comment #14)
> errata-xmlrpc 2016-06-14 08:04:34 EDT
> Status: MODIFIED → ON_QA
> 
> How long does it stay ON_QA before we see it in the regular repo?

Hello.

If the package passes testing, it should be available via regular means once RHEL-7.3 is GA. Unfortunately I can not provide you any exact date when this will be. Thank you for understanding.

Ahhh.  I didn't realise this was being held until RHEL-7.3 was GA.

Thanks for the update!

Hi Brian,

I have been trying to reproduce the original bug by following the steps you
mention in the description in order to verify the fix. I had little success so
far. Would you mind giving a more specific example how to reproduce it?

What I tried:
1) 3 machines, named 'client', 'proxy' and 'backend'; originally, all three had
   both IPv4 and IPv6 working
3) On 'backend', I disabled IPv6 as follows:

   # sysctl -w net.ipv6.conf.all.disable_ipv6=1
   # sysctl -w net.ipv6.conf.default.disable_ipv6=1

4) On 'proxy', I installed squid-3.3.8-26.el7 and started it with default
   configuration
5) On 'backend', I installed httpd-2.4.6-45.el7 and started it with default
   configuration
6) From 'client', I issued the following request:

   # curl -x proxy:3128 http://backend/testfile

The connection hanged for 1 minute (default value of connect_timeout) but
eventually, the requested file was correctly downloaded over IPv4.

Hi Martin,

Your test looks valid to me and seems to indicate that the problem is fixed.

I, unfortunately don't have any example sites where I know ipv6 is broken, but ipv4 is working where I can test.  I also don't have the fixed RPM to test with.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2600.html

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days