defaulting to net.ipv6.bindv6only=1 for squeeze
Marco d'Itri
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
> 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 <gu...@debian.org>
Marco d'Itri
> 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
> > 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.
Russ Allbery
> 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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
> 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
>> 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.
Marco d'Itri
> 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
> > 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...
Marco d'Itri
> 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
Marcus Better
Hash: SHA1
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-----
Marco d'Itri
> 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
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
Wouter Verhelst
> 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
Marco d'Itri
> 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
* Marco d'Itri [Fri, Dec 11 2009, 12:23:36AM]:
> On Dec 10, Wouter Verhelst <wou...@debian.org> 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
> #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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jarek Kamiński
> Marco d'Itri wrote:
>> On Oct 24, Marco d'Itri <m...@Linux.IT> wrote:
>>> I am proposing to set net.ipv6.bindv6only=1 by default for new
>>> installations
>
> 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.
Kurt Roeckx
>
> 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.
Why don't you fix the applications not doing that? As I see
it this only has an effect on what I would call broken
applications. I see 2 possible things:
- The application is broken and doesn't try to open 2 sockets
at all. This means now you break their ipv4 support.
- The application already tries to open the 2 sockets, but
didn't call setsockopt() so the 2nd one just fails. Adding
the setsockopt() is a very simple change and doesn't break
anything and has the effect you want. This is a very
simple change to make.
It looks like the only application I'm running that isn't calling
the setsockopt is samba.
Kurt
Hendrik Sattler
> I propose that netbase will create on new installations a file in
> /etc/sysctl.d/ containing net.ipv6.bindv6only=1.
> [2] http://tools.ietf.org/html/rfc3493#section-5.3
1. It obviously doesn't do this only on new installation but also on upgrades.
2. You cite RFC3493 but your request (and action) obviously violates it:
"By default this option is turned off."
Hint: "off" means 0, not 1.
Why does Debian violate the RFC on purpose? Why does it break installed
systems?
I have failures now with a client that cannot connect() to the IPv4 address
but get an ENETUNREACH instead.
The application DOES set this socket option:
socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
bind(3, {sa_family=AF_INET6,....) = 0
listen(3, ....) = 0
Did you ever test that "setting this option back to 0 by a program before
bind() and listen()" actually works?
Reverting your change fixes this. I am using Debian testing up-to-date with
linux-2.6.32 (self-compiled).
HS
Marco d'Itri
> 1. It obviously doesn't do this only on new installation but also on upgrades.
This is correct.
> 2. You cite RFC3493 but your request (and action) obviously violates it:
RFC3493 is informational.
> Did you ever test that "setting this option back to 0 by a program before
> bind() and listen()" actually works?
Yes.
--
ciao,
Marco
Jarek Kamiński
>
> but get an ENETUNREACH instead.
> The application DOES set this socket option:
> socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
> setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
> bind(3, {sa_family=AF_INET6,....) = 0
> listen(3, ....) = 0
>
> Did you ever test that "setting this option back to 0 by a program before
> bind() and listen()" actually works?
Yes. Following code actually works (runs with bindv6only enabled,
listens on [::]:1234 and accepts connection made to localhost:1234):
#v+
#include <sys/socket.h>
#include <netinet/in.h>
int main ()
{
int no = 0;
int listenfd = socket (AF_INET6, SOCK_STREAM, IPPROTO_TCP);
int clientfd;
char buf[1024];
ssize_t rv;
struct sockaddr_in6 addr = { AF_INET6, htons(1234), 0, IN6ADDR_ANY_INIT };
setsockopt (listenfd, SOL_IPV6, IPV6_V6ONLY, &no, sizeof(no));
bind (listenfd, (void*)&addr, sizeof(addr));
listen (listenfd, 1);
clientfd = accept (listenfd, 0, 0);
while ((rv = read (clientfd, buf, sizeof(buf))) > 0)
write (1, buf, rv);
return 0;
}
#v-
> Reverting your change fixes this.
If something doesn't work with bindv6only enabled, it's broken.
Jarek.
Bjørn Mork
> Yes. Following code actually works (runs with bindv6only enabled,
> listens on [::]:1234 and accepts connection made to localhost:1234):
I'm sure it works. But I wanted to note that "localhost" is somewhat
ambigious. It may include ::1
ipv6-pppoe-1:~# grep localhost /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ipv6-pppoe-1:~# host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1
You'd better test 127.0.0.1:1234 explicitly if that's what you want.
Bjørn
Jarek Kamiński
>
>> Yes. Following code actually works (runs with bindv6only enabled,
>> listens on [::]:1234 and accepts connection made to localhost:1234):
> I'm sure it works. But I wanted to note that "localhost" is somewhat
> ambigious. It may include ::1
In my case it doesn't.
> You'd better test 127.0.0.1:1234 explicitly if that's what you want.
I've done the test correctly, connecting over IPv4 with 127.1.
Jarek.
Hendrik Sattler
> Na grupie linux.debian.devel napisałe(a)ś:
I do:
int v6only = 0;
int fd = socket(AF_INET6, SOCK_STREAM, 0);
setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (void*)&v6only, sizeof(v6only));
bind(fd, (struct sockaddr *) &my_sock, sizeof(struct sockaddr_in6));
listen(fd, 2);
...
And the client cannot connect! The value of IPPROTO_IPV6 and SOL_IPV6 are both 41, thus this cannot be the cause.
Maybe the difference is the "0" vs. "IPPROTO_TCP"? "0" is supposed to work, though.
Additionally: what happens when I want to open an ::FFFF:127.0.0.1 as an IPv6 socket?
But even when using IN6ADDR_ANY, the client cannot connect to 127.0.0.1.
Thanks
HS
Julien Cristau
> I do:
> int v6only = 0;
> int fd = socket(AF_INET6, SOCK_STREAM, 0);
> setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (void*)&v6only, sizeof(v6only));
> bind(fd, (struct sockaddr *) &my_sock, sizeof(struct sockaddr_in6));
> listen(fd, 2);
> ...
>
Not knowing what my_sock is, this isn't very helpful…
Cheers,
Julien
Hendrik Sattler
Nevermind, it's the client not calling the socket option.
I still don't agree...
Kurt Roeckx
>
> I have failures now with a client that cannot connect() to the IPv4 address
> but get an ENETUNREACH instead.
> The application DOES set this socket option:
> socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
> setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
> bind(3, {sa_family=AF_INET6,....) = 0
> listen(3, ....) = 0
Does that mean your application only works if the kernel supports
IPv6? In that case I think your application is broken.
Kurt
Hendrik Sattler
> On Wed, Dec 23, 2009 at 12:47:45PM +0100, Hendrik Sattler wrote:
> > I have failures now with a client that cannot connect() to the IPv4
> > address but get an ENETUNREACH instead.
> > The application DOES set this socket option:
> > socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
> > setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
> > bind(3, {sa_family=AF_INET6,....) = 0
> > listen(3, ....) = 0
>
> Does that mean your application only works if the kernel supports
> IPv6?
Why would you want to disable basic IPv6 support?
> In that case I think your application is broken.
No. Every software has requirements on the system. And this one requires basic
IPv6 support because it's programmed that way. I don't see any problem with
that. But you are free to have your own opinion.
HS
Philipp Kern
>> Does that mean your application only works if the kernel supports
>> IPv6?
> Why would you want to disable basic IPv6 support?
People opt to not have IPv6 support in the kernel because they don't need it,
they don't want accidentally get out through IPv6 just because someone
sent out router advertisements in untrusted nets, or because some routers
do not cope with AAAA questions and don't answer, causing timeouts.
There are always possibilities where people would want that (me not included),
or where people would need that.
>> In that case I think your application is broken.
> No. Every software has requirements on the system. And this one requires basic
> IPv6 support because it's programmed that way. I don't see any problem with
> that.
Sure. But there are recommended ways on how to program with sockets to
support both IPv4 and IPv6 and it looks that yours is not one of them.
Might be a sign of bad quality if it does not depend on the availability
of IPv6 itself.
> But you are free to have your own opinion.
How grateful. I'll take my share of that too.
Kind regards,
Philipp Kern
Bernhard R. Link
> > Does that mean your application only works if the kernel supports
> > IPv6?
>
> Why would you want to disable basic IPv6 support?
I routinely blacklist the ipv6 module. There are far too many
programs breaking or doing stuff I do not want if it is loaded.
Hochachtungsvoll,
Bernhard R. Link
Ben Hutchings
> * Hendrik Sattler <po...@hendrik-sattler.de> [091226 18:48]:
> > > Does that mean your application only works if the kernel supports
> > > IPv6?
> >
> > Why would you want to disable basic IPv6 support?
>
> I routinely blacklist the ipv6 module. There are far too many
> programs breaking or doing stuff I do not want if it is loaded.
I trust you have filed bugs on these applications?
Ben.
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
Bernhard R. Link
> > I routinely blacklist the ipv6 module. There are far too many
> > programs breaking or doing stuff I do not want if it is loaded.
>
> I trust you have filed bugs on these applications?
No, on most I have not. I don't believe anyone only having ipv6 right
now so if ipv4 is broken I assume people know this and simply fix my
machines. (It's the sad state of affairs that the situation is broken
in so many subtle ways that sometimes every single program can hardly
do something[1]).
Hochachtungsvoll,
Bernhard R. Link
[1] For example running sshd without -4 and without ipv6 blacklisted causes
(or caused[2]) sshd to listen on ipv6 resulting in
a) netstat garbling the addresses of connected endpoints
b) the interface having a link-local address (bug/feature in kernel?),
which then causes(or caused[2]) programs to do ipv6 dns lookups[3]
Now who is at fault and whom should I assign bugs to?
Myself for not giving sshd a -4 (I once tries to
give every program needing it to avoid ipv6 loaded those options, at
some point they were to many)? Those programs for causing ipv6 to load
when there is no interface for it yet? The kernel for assigning
link-local address when ipv6 is loaded? Libc for asking for ipv6
addresses even when AI_ADDRCONFIG is given on interfaces with a
link-local address? (Not to speak of the programs not using
AI_ADDRCONFIG)
[2] I don't have the time to recheck all the time if things now work
every few months.
[3] which not only pesters the root servers with questions for the
top-level domain "$(hostname -s)", but I do not even want to think
what it means security-wise that the recursing name server I use or
someone sitting in between can answer those requests.
Marco d'Itri
> > > I routinely blacklist the ipv6 module. There are far too many
> > > programs breaking or doing stuff I do not want if it is loaded.
I call bullshit on this.
> a) netstat garbling the addresses of connected endpoints
This is one of the reasons why bindv6only should be set.
> b) the interface having a link-local address (bug/feature in kernel?),
Feature.
> which then causes(or caused[2]) programs to do ipv6 dns lookups[3]
libc issue, solved long ago.
> [3] which not only pesters the root servers with questions for the
> top-level domain "$(hostname -s)", but I do not even want to think
Not really.
> what it means security-wise that the recursing name server I use or
> someone sitting in between can answer those requests.
Maybe you should, because no such thing exists.
--
ciao,
Marco
Bernhard R. Link
> On Dec 30, "Bernhard R. Link" <brl...@debian.org> wrote:
>
> > > > I routinely blacklist the ipv6 module. There are far too many
> > > > programs breaking or doing stuff I do not want if it is loaded.
> I call bullshit on this.
You can call bullshit whatever how often you want. That does not change
that many people have had those problems and thus have ipv6 backlisted
(or not even compiled in if they have their own kernels built) and
programs not working with that are broken.
> > a) netstat garbling the addresses of connected endpoints
> This is one of the reasons why bindv6only should be set.
I'm not arguing about bindv6only. I'm only arguing programs should work
without ipv6 loaded.
> > [3] which not only pesters the root servers with questions for the
> > top-level domain "$(hostname -s)",
> Not really.
Try to look at the outgoing dns queries. As I said I did not retest
everything all the time. At least with etch that was still very common.
And even with lenny there are still programs needlessly sending AAAA
queries. (Though the only one I can name is apt, which even does so
without ipv6 module loaded).
Bernhard R. Link
Marco d'Itri
> You can call bullshit whatever how often you want. That does not change
> that many people have had those problems and thus have ipv6 backlisted
> (or not even compiled in if they have their own kernels built) and
> programs not working with that are broken.
Many people are also stupid, so we have no reason to consider their
opinion interesting.
> > > a) netstat garbling the addresses of connected endpoints
> > This is one of the reasons why bindv6only should be set.
> I'm not arguing about bindv6only. I'm only arguing programs should work
> without ipv6 loaded.
And guess what? Using bindv6only=1 solves this.
> > > [3] which not only pesters the root servers with questions for the
> > > top-level domain "$(hostname -s)",
> > Not really.
> Try to look at the outgoing dns queries. As I said I did not retest
> everything all the time. At least with etch that was still very common.
With squeeze it is not.
--
ciao,
Marco
Brian May
> > > a) netstat garbling the addresses of connected endpoints
> > This is one of the reasons why bindv6only should be set.
>
> I'm not arguing about bindv6only. I'm only arguing programs should work
> without ipv6 loaded.
Somewhere I got lost in this discussion.
I thought the idea of setting bindv6only is that applications should be binding
both to IPv4 and IPv6 sockets. Not to IPv4 only, and not to IPv6 only.
In that case, how can correct programs be broken if IPv6 is not supported?
Surely it is just a matter of binding to IPv4 and ignoring the error that
occurs when trying to bind to the IPv6 socket (or vice versa if IPv6 is
supported but not IPv4)?
--
Brian May <b...@snoopy.debian.net>
Russ Allbery
> In that case, how can correct programs be broken if IPv6 is not
> supported? Surely it is just a matter of binding to IPv4 and ignoring
> the error that occurs when trying to bind to the IPv6 socket (or vice
> versa if IPv6 is supported but not IPv4)?
I don't believe that combination can break correct programs.
This part of the thread started with a specific client that was having
problems following this configuration change, which I think was traced to
a bug in the way that program handled network setup. The discussion of
blacklisting the ipv6 module was a side-part of that thread sparked by
comments about the other ways in which that program seemed to be buggy.
This whole digression is basically unrelated to the change mentioned in
the subject line.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Marco d'Itri
> Somewhere I got lost in this discussion.
You did not, he did.
> In that case, how can correct programs be broken if IPv6 is not supported?
> Surely it is just a matter of binding to IPv4 and ignoring the error that
> occurs when trying to bind to the IPv6 socket (or vice versa if IPv6 is
> supported but not IPv4)?
Yes.
--
ciao,
Marco