Fedora IPv6 testing and improvements - request for ideas

[Pavel Simerda]

----- Original Message -----
> From: "Zdenek Kabelac" <zkabelac at redhat.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Wednesday, November 4, 2015 1:43:12 PM
> Subject: Re: Fedora IPv6 testing and improvements - request for ideas
> 
> Dne 4.11.2015 v 13:24 Petr Spacek napsal(a):
> > On 3.11.2015 18:50, Moez Roy wrote:
> >> Hi Pavel Simerda,
> >>
> >> The IPv6 updates are breaking stuff (and probably increasing the
> >> attack surface):
> >>
> >> Bug 1231946 - unbound-anchor ignores net.ipv6.conf.all.disable_ipv6=1
> >> in /etc/sysctl.conf
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1231946
> >>
> >> Bug 1251762 - dnssec-triggerd ignores net.ipv6.conf.all.disable_ipv6=1
> >> in /etc/sysctl.conf
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1251762
> >>
> >> (maybe other software like avahi also don't remember right now)
> >>
> >> You can reproduce this by putting "ipv6.disable=1" in the kernel command
> >> line.
> >>
> >> Doing 'setsebool -P domain_kernel_load_modules 1' would reduce the
> >> security provided by SELinux so it is not an option.
> >>
> >> Would appreciate fixes please. Thanks.
> >
> > "ipv6.disable=1" or blacklisting ipv6 modules is going against contemporary
> > ways how network APIs. Many contemporary software projects are
> > using IPv6-enabled network calls by default because both IPv6 and IPv4
> > share the same name space on the machine so you only need to listen on a
> > IPv6 port to accept both IPv4 and IPv6.
> >
> > Apparently this is not Fedora-specific in any way because ArchLinux says
> > the same:
> > https://wiki.archlinux.org/index.php/IPv6#Disable_IPv6
> >
> > "net.ipv6.conf.all.disable_ipv6=1" is good enough and should not have
> > negative
> > side-effects of "ipv6.disable=1".
> >
> > Having said that, I'm proposing to close all issues caused by
> > "ipv6.disable=1"
> > as WONTFIX.
> 
> Hi
> 
> I strongly object against this idea.
> 
> System needs to work in  IPv4 environment  and with kernel without IPv6
> enabled.
> 
> There is number of reasons for keeping this possibility enabled - e.g.
> I want to use  older kernel for regression testing, I want to have disabled
> IPv6 stack for security reasons and lots of other...

I'm not taking any side in this discussion and will mostly attempt to reflect
actual usage, i.e. most installations dual-stack, some installations with
IPv6 disabled, no installations with IPv4 disabled (due to kernel inability
to disable IPv4).

> So please do not replace coder's inability

The project is about IPv6 and dual-stack testing and improvements. Insulting
authors who didn't make their software work with ipv6.disabled=1 isn't helpful.

> to write correct code to handle dual socket interface

In some cases software authors do not expect a situation when
`socket(family=AF_INET6)` fails but `socket(family=AF_INET)`
succeeds. It is indeed a very special situation that such a
basic thing in the system fails.

And that is indeed a very special situation. On most installation
the `socket()` calls with correct arguments will never fail. And
the IPv4 variant won't fail in any case which creates an undue
assymetry.

> with disabling usage of while Fedora on kernel with
> IPv6 disabled.
> 
> I'm fine if the particular software package would be  IPv6 only - as long
> as there is no IPv4-only user who cares - it's correct way.

Whether a package is IPv6 only and whether a package works with
ipv6.disabled=1 are two distinct things that need to be tested
separately. On the other IPv6 only packages are a very rare
phenomenon.

> Just do NOT make such package a core system dependency - it has to remain
> optional.

I don't see any reason to make a distinction between a dual-stack package
with IPv4 and IPv6 functionality and two distinct packages, one IPv4 only,
the other IPv6 only in this respect. Either way you end up with features
required for both protocols.

Anyway, are there any specific packages that are mandatory in Fedora or
might become so? I'd like to avoid discussions about something purely
hypothetical.

Cheers,

Pavel