defaulting to net.ipv6.bindv6only=1 for squeeze

[Marco d'Itri]

I am proposing to set net.ipv6.bindv6only=1 by default for new
installations, to simplify configuration and administration of systems
using IPv6 and to make the system behaviour match the one of all other
operating systems, which default to this or just do not provide a
choice.

When net.ipv6.bindv6only is set to 0, an application binding an
AF_INET6 listening socket to "any" will receive on the same socket IPv4
connections as well, with the endpoint addresses converted in the form
::ffff:1.2.3.4[1].

When net.ipv6.bindv6only is set to 1, an application binding an
AF_INET6 listening socket to "any" will only receive IPv6 connection and
will need to create an AF_INET listening socket to receive IPv4
connections.

Applications can change the behaviour for their sockets using setsockopt
and the IPV6_V6ONLY option[2], and many already do this to prevent the
need of adjusting their configuration depending on how the system is
configured.

More information is also available in[3].

While net.ipv6.bindv6only=0 is useful for daemons which are not designed
to listen on multiple sockets, it is annoying because it requires
dealing with IPv4-mapped addresses in logs and configuration files
unless the program takes care to convert them to IPv4 addresses.

I propose that netbase will create on new installations a file in
/etc/sysctl.d/ containing net.ipv6.bindv6only=1.



[1] http://en.wikipedia.org/wiki/IPv6#IPv4_mapped_addresses

[2] http://tools.ietf.org/html/rfc3493#section-5.3

[3] http://books.google.com/books?id=UuIqKlWVaKcC&lpg=PA118&ots=2XZWUqI0au&pg=PA118#v=onepage

--
ciao,
Marco

[Guus Sliepen]

On Sat, Oct 24, 2009 at 08:24:31PM +0200, Marco d'Itri wrote:

> I am proposing to set net.ipv6.bindv6only=1 by default for new
> installations, to simplify configuration and administration of systems
> using IPv6 and to make the system behaviour match the one of all other
> operating systems, which default to this or just do not provide a
> choice.
[...]
> While net.ipv6.bindv6only=0 is useful for daemons which are not designed
> to listen on multiple sockets, it is annoying because it requires
> dealing with IPv4-mapped addresses in logs and configuration files
> unless the program takes care to convert them to IPv4 addresses.

And bindv6only=0 is also not RFC compliant. However, a *lot* of applications
that use listening sockets will not work correctly anymore when you change the
default. So it probably is better to make it a release goal that applications
should work with bindv6only=1, and only if enough of them are fixed to change
the default.

--
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus@...>

[Marco d'Itri]

On Oct 24, Guus Sliepen <guus@...> wrote:

> And bindv6only=0 is also not RFC compliant. However, a *lot* of applications
> that use listening sockets will not work correctly anymore when you change the
> default. So it probably is better to make it a release goal that applications
Can you make a list? I do not think there is a significant number, I
only know about vmware.

--
ciao,
Marco

[Guus Sliepen]

On Sat, Oct 24, 2009 at 10:00:07PM +0200, Marco d'Itri wrote:

> > And bindv6only=0 is also not RFC compliant. However, a *lot* of applications
> > that use listening sockets will not work correctly anymore when you change the
> > default. So it probably is better to make it a release goal that applications
> Can you make a list? I do not think there is a significant number, I
> only know about vmware.

Well, last time I tried bindv6only=1 on a server running many listening daemons.
Over half of them stopped working properly (not listening on IPv4 anymore for
example). I'll try this again when I can and present a list, but I cannot cover
every program Debian.

--
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus@...>

[Russ Allbery-2]

md@... (Marco d'Itri) writes:

> Applications can change the behaviour for their sockets using setsockopt
> and the IPV6_V6ONLY option[2], and many already do this to prevent the
> need of adjusting their configuration depending on how the system is
> configured.

This is really the right solution.  We did this a while back for INN and
it's cleared up a bunch of complexity and weirdness.  It would be nice if
we could just get all the applications patched, although I suppose that's
unrealistic.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marco d'Itri]

On Oct 25, Russ Allbery <rra@...> wrote:

> This is really the right solution.  We did this a while back for INN and
> it's cleared up a bunch of complexity and weirdness.  It would be nice if
> we could just get all the applications patched, although I suppose that's
> unrealistic.
This is why I would be satisfied with only having to patch the ones
which do not work with net.ipv6.bindv6only=1.

I welcome more opinions about this issue.

--
ciao,
Marco

[Jarek Kamiński-2]

On Sat, Oct 24, 2009 at 10:00:01PM +0200, Marco d'Itri wrote:
>> And bindv6only=0 is also not RFC compliant. However, a *lot* of applications
>> that use listening sockets will not work correctly anymore when you change the
>> default. So it probably is better to make it a release goal that applications

> Can you make a list? I do not think there is a significant number, I
> only know about vmware.

I run this configuration on most of my systems and don't have many
problems. There was some problem with apache, but it's now fixed. Also
java is broken and my bug report got ignored by sun, but it should be
easy patchable (preloading socket() and calling setsockopt(IPV6_V6ONLY)
works for me).

There were also some problems with dovecot listening on either 0.0.0.0,
or [::], but I don't remember details nor know they current state.
I don't remember any problems with vmware, but I don't use it now. Maybe
I was connecting to it only with IPv6.

I'm not sure if I wasn't forced to modify default configuration for
some daemons.

Jarek.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marco d'Itri]

On Oct 25, Jarek Kami?ski <jarek@...> wrote:

> I run this configuration on most of my systems and don't have many
> problems. There was some problem with apache, but it's now fixed. Also
> java is broken and my bug report got ignored by sun, but it should be
> easy patchable (preloading socket() and calling setsockopt(IPV6_V6ONLY)
> works for me).
http://www.linux.it/~md/software/v6only.tgz
(Also a good teaching example about hijacking system calls!)

And now that Java has been freed I suppose that this bug can be fixed
for good... Can't it?

> There were also some problems with dovecot listening on either 0.0.0.0,
> or [::], but I don't remember details nor know they current state.
Fixed long ago.

> I don't remember any problems with vmware, but I don't use it now. Maybe
> I was connecting to it only with IPv6.
I was referring to vmware server, BTW.

--
ciao,
Marco

[Guus Sliepen]

On Sat, Oct 24, 2009 at 10:05:51PM +0200, Guus Sliepen wrote:

> > Can you make a list? I do not think there is a significant number, I
> > only know about vmware.
>
> Well, last time I tried bindv6only=1 on a server running many listening daemons.
> Over half of them stopped working properly (not listening on IPv4 anymore for
> example). I'll try this again when I can and present a list, but I cannot cover
> every program Debian.

polipo and ircd-hybrid are the only ones that are problematic for me. I guess
things have improved. Well, except for those daemons that are not listening on
IPv6 at all of course...

--
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus@...>

[Marco d'Itri]

On Oct 28, Guus Sliepen <guus@...> wrote:

> polipo and ircd-hybrid are the only ones that are problematic for me. I guess
> things have improved. Well, except for those daemons that are not listening on
> IPv6 at all of course...
ircds need custom configuration anyway, so this does not look like a
problem.
I expect that most applications correctly deal with bindv6only=1, since
they need to to work on the *BSD.
Indeed this would also help integration with the kfreebsd ports.

So, is there anybody really opposed to going forward with this?
Please remember that there will be pervasive IPv6 deployments by the end
of the lifetime of squeeze, so we should get it right.

--
ciao,
Marco

[Marco d'Itri]

On Oct 24, Marco d'Itri <md@...> wrote:

> I am proposing to set net.ipv6.bindv6only=1 by default for new
> installations
Done, let's see what breaks. :-)

--
ciao,
Marco

[Marcus Better]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco d'Itri wrote:
> On Oct 24, Marco d'Itri <md@...> wrote:
>> I am proposing to set net.ipv6.bindv6only=1 by default for new
>> installations
> Done, let's see what breaks. :-)

All of Java, it seems [1]. I'm very surprised this breakage was known in
advance [2] but no bugs were filed (TTBOMK) before making this change.

Hoping it can be fixed quickly.

Cheers,

Marcus

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056
[2] http://lists.debian.org/debian-devel/2009/10/msg00573.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksfkwsACgkQXjXn6TzcAQnXCgCgv9Xfp/lolYlCiHtdKPAd5EbQ
RVcAoMc3QmI/7BckQzkWjn3UbLn2lAAG
=J5Kj
-----END PGP SIGNATURE-----



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Roman Mamedov]

> Done, let's see what breaks. :-)

vnc4server: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560137

Marco, by making this change I assume you offer your personal help in dealing
with its consequences? Please feel free to submit a fix to #560137, thanks in
advance.

--
With respect,
Roman

[Marco d'Itri]

On Dec 10, Roman Mamedov <roman@...> wrote:

> Marco, by making this change I assume you offer your personal help in dealing
> with its consequences? Please feel free to submit a fix to #560137, thanks in
> advance.
I provided the usual workaround, but the "correct" solution would be to
open two sockets.

BTW, the maintainers of the affected packages should remember that they
need to be fixed anyway to correctly work on the kfreebsd ports.

--
ciao,
Marco

[Wouter Verhelst]

On Sat, Oct 24, 2009 at 08:24:31PM +0200, Marco d'Itri wrote:
> I am proposing to set net.ipv6.bindv6only=1 by default for new
> installations, to simplify configuration and administration of systems
> using IPv6 and to make the system behaviour match the one of all other
> operating systems, which default to this or just do not provide a
> choice.

I'm a bit late to the party, but...

Can you explain (or give pointers to an explanation) what the
argumentation here is? How does not adhering to relevant standards
simplify configuration?

I'm sure I'm missing something here, just dunno what.

TIA,

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marco d'Itri]

On Dec 10, Wouter Verhelst <wouter@...> wrote:

> Can you explain (or give pointers to an explanation) what the
> argumentation here is? How does not adhering to relevant standards
> simplify configuration?
There is no relevant standard that says what the default of IPV6_V6ONLY
should be. Currently what happens is that every OS except Linux and OS X
default to 1.
An important point is that the kfreebsd ports only support a default of
1, so these buggy programs need to be fixed anyway to work correctly on
them.

Among the benefits of using different sockets for IPv4 and IPv6 there is
the ability of running two different daemons for v4 and v6 on the same
port and simpler code, removing the need for making IPv6-mapped IPv4
addresses behave like real IPv4 addresses in logs, configuration files
and so on.

I have no objections to reverting this change in time for the release if
there are too many programs to be fixed, but so far I believe that the
results are very encouraging.

--
ciao,
Marco

[Eduard Bloch]

#include <hallo.h>
* Marco d'Itri [Fri, Dec 11 2009, 12:23:36AM]:

> On Dec 10, Wouter Verhelst <wouter@...> wrote:
>
> > Can you explain (or give pointers to an explanation) what the
> > argumentation here is? How does not adhering to relevant standards
> > simplify configuration?
> There is no relevant standard that says what the default of IPV6_V6ONLY
> should be. Currently what happens is that every OS except Linux and OS X
> default to 1.
> An important point is that the kfreebsd ports only support a default of
> 1, so these buggy programs need to be fixed anyway to work correctly on
> them.

From my POV as programmer it's a good change. The old behaviour (i.e.
silent creation of v4 mapped sockets) maybe made the porting (to
Linux/OS-X) of very simple network daemons easier but when you tried to
make the local address binding more flexible then things became PITA.

I.e. if you use getaddrinfo output then you need to sort out v6 sockets
out and connect on them, but then you cannot be sure about whether v4
mapping is active. You can test it by trial-and-error (binding on v4
versions and checking the results) but then you cannot be sure that they
are bound to you now (at least not without using ugly tricks).

> I have no objections to reverting this change in time for the release if
> there are too many programs to be fixed, but so far I believe that the
> results are very encouraging.

Maybe because most programmes already got burned by the problems
described above and don't rely on transparent v4 mapping anymore (IIRC I
had to fix some code last year when getaddrinfo output changed the
sort order, some assumptions in the code didn't work).

Regards,
Eduard.

--
<natoka> Alfie: ;) naja, wir sind nicht in Redm**** wo man den teppich
        hochhebt und den besen auspackt und alles drunterkehrt.
<natoka> Alfie: und das was sich dann nicht mehr unterm teppich ausgeht als
        produkt deklariert und verkauft ;)

[Russ Allbery-2]

Eduard Bloch <edi@...> writes:
> #include <hallo.h>
> * Marco d'Itri [Fri, Dec 11 2009, 12:23:36AM]:

>> There is no relevant standard that says what the default of IPV6_V6ONLY
>> should be. Currently what happens is that every OS except Linux and OS
>> X default to 1.  An important point is that the kfreebsd ports only
>> support a default of 1, so these buggy programs need to be fixed anyway
>> to work correctly on them.

> From my POV as programmer it's a good change. The old behaviour (i.e.
> silent creation of v4 mapped sockets) maybe made the porting (to
> Linux/OS-X) of very simple network daemons easier but when you tried to
> make the local address binding more flexible then things became PITA.

Agreed.

> I.e. if you use getaddrinfo output then you need to sort out v6 sockets
> out and connect on them, but then you cannot be sure about whether v4
> mapping is active. You can test it by trial-and-error (binding on v4
> versions and checking the results) but then you cannot be sure that they
> are bound to you now (at least not without using ugly tricks).

Yes, exactly.  You end up having to add a bunch of code to special-case
IPv4-mapped addresses in annoying ways, and that code isn't always tested
because other OSes don't do this dual-binding.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jarek Kamiński-2]

Na grupie linux.debian.devel napisałe(a)ś:
> Marco d'Itri wrote:
>> On Oct 24, Marco d'Itri <md@...> wrote:
>>> I am proposing to set net.ipv6.bindv6only=1 by default for new
>>> installations
>> Done, let's see what breaks. :-)
>
> All of Java, it seems [1]. I'm very surprised this breakage was known in
> advance [2] but no bugs were filed (TTBOMK) before making this change.

I have reported it upstream long before java was packaged in Debian
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342561) and then
saw no point in re-reporting it in Debian.

Jarek.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...