Please replace mdns4_minimal and mdns4 by, respectively, mdns_minimal
and mdns by default in /etc/nsswitch.conf.

No, don't!

Lennart

Why is that ?

Mike

Try Google. Try reading docs. Try reading mailing list archives.

This has been discussed a million times already on various places.

Lennart

A million times ? Googling for mdns4_minimal mdns_minimal return only 3 pages
or results, which, by google standards, is pretty few. And the only reference
to mdns_minimal being a problem instead of mdns4_minimal is a bug report where
*YOU* were only ranting. And a bunch of the other results are... *this* bug.

So please support your point with better arguments.

Mike

I think the answer is in bug 388864, comment #20 (http://bugs.debian.org/388864#20):

People *do* complain when their apps become mysteriously slow at
connecting. Based on the deployed base of IPv6, I think the current
balance is that it is better to disable IPv6 lookups by default.

If this is a barrier to IPv6 adoption in itself, then perhaps
someone would be willing to start a strike force to get these
broken applications fixed. I expect one could find potential
troublemakers with some greps of the Debian archive (eg.
bad use of gethostbyname).
</tangent>

I think the answer is in bug 388864, comment #20 (http://bugs.debian.org/388864#20):

People *do* complain when their apps become mysteriously slow at
connecting. Based on the deployed base of IPv6, I think the current
balance is that it is better to disable IPv6 lookups by default.

If this is a barrier to IPv6 adoption in itself, then perhaps
someone would be willing to start a strike force to get these
broken applications fixed. I expect one could find potential
troublemakers with some greps of the Debian archive (eg.
bad use of gethostbyname).
</tangent>

Avahi default, at least in debian, is to register IPv6 addresses.

As for delays, they should be considered bugs as with the glibc.

Mike

It's a Debian default. Not an Avahi default.

And doing what Debian does with Avahi+IPv6 is a very bad idea, as I
have told Sjoerd before.

Also, I believe only the tiniest number of networks run exclusively
Debian Unstable these days. You might not believe this, but there is
this alternative operating system around, which is called "Windows",
and which enabled IPv6 at all only very recently, so this Bonjour
thing cannot do IPv6 either when it is running of those machines. And
let's not forget all those embedded devices like printers, cameras,
routers, which do bonjour -- but without ipv6.

But of course, my insight into all this fancy zeroconf stuff is rather
limited, ya know? You of course, know much more about it, I
figure. So, teach me.

It's not a limitation in GLIBC. It's the stupid applications.

Lennart

Hi,

all these rants about things not working perfectly with IPv6 were made
in 2008 when there were plenty of addresses and the only IPv6 people
were Internet enthusiasts.

IPv6 is now attacking mainstream usage and most current operating
systems are designed for IPv6 and IPv4 working in parallel.

Isn't it time to revisit old bugreports like this one and get Debian
IPv6 ready?

Pavel Šimerda

tags 466014 ipv6
thanks

Are there any issues left on this? I believe this is needed
for reaching full IPv6 release goal.

I have IPv6 in my network and want Avahi to use it either.

Hi,

Maybe it's time to reconsider this bug and switch to ipv6 ?

Thanks

Control: forwarded 466014 https://github.com/lathiat/nss-mdns/issues/62

Yes, this. When people install nss-mdns (perhaps because something
depends on it), and it makes seemingly unrelated software take an extra
5 seconds to connect, in my experience the usual reaction is to complain
about nss-mdns (or about Debian in general, if the user does not
successfully diagnose that the delay was caused by nss-mdns).

The goal of nss-mdns is to make it more likely that "the right thing"
happens without configuration. If we want that to be the case, then it
needs to be installed by default, but it is not useful to install it
by default if it breaks applications.

The reason to want IPv6 everywhere is that there are not enough
globally-routable IPv4 addresses for everyone. However, mDNS is a
link-local protocol: it doesn't need globally-routable IPv4 addresses,
only RFC1918 or RFC3927 locally-valid addresses, and there is no shortage
of those. So the situations in which it would be useful for nss-mdns to
look up both IPv4 and IPv6 by default are:

* when the local machine is IPv6-only (no IPv4 addresses at all, not
  even link-local addresses in 169.254.x.x); or
* when the machine we are looking up is IPv6-only (again, no IPv4 addresses
  at all)

In both of these situations, using mdns_minimal instead of mdns4_minimal
would turn unsuccessful name resolution into successful name resolution.

We have to trade these off against the situation in which it's harmful
for nss-mdns to look up both IPv4 and IPv6 by default:

* the machine we are looking up is IPv4-only (no IPv6 addresses), or it
  only advertises its .local name as IPv4; and
* a program (inadvisably) uses getaddrinfo() with ai_family=AF_INET6,
  and if that fails, it tries getaddrinfo() with ai_family=AF_INET;
  or it does the equivalents with the obsolete gethostbyname2[_r]()

In that situation, we don't want to incur a 5 second delay while the
first getaddrinfo() call asks the network "does anyone know an IPv6
address for printer.local?" and waits for replies.

Now, it might be possible to modify the code of the mdns module to
avoid this delay while still providing IPv6 support (perhaps replying
with IPv6 addresses for AF_UNSPEC queries, but declining AF_INET6
queries). However, that is not as simple as replacing mdns4_minimal
with mdns_minimal, and should be done upstream, if at all.

    smcv

Both Avahi and glibc are problematic regarding dual-stack networking. I
created a test suite project for application behavior that can be used
to catch application problems but I also tested glibc thoroughly and and
there are problems from the resolver implementation through the limited
internal nsswitch API to the standard getaddrinfo API which is
considered limited and unreliable by many and avoided using more custom
(and also buggy) implementations.

It looks easy but in practice it proves by no means trivial to have a
proper IPv4/IPv6 client behavior implemented. I have done many
experiments with that and the situation in open source (or any other)
software including the core components is not satisfactory at all.

https://github.com/crossdistro/netresolve
https://github.com/crossdistro/network-testing

There is, in my opinion, no good excuse not to support IPv6 properly in
open source software nowadays.

You may want to use link-local networking even for machines that have
global IPv6 or IPv6. The switch to global IPv6 and the behavior of
avahi/nss-mdns is IMO questionable.

Plus the current usage of IPv4 link-local are just useless because they
are only used as a fallback to DHCP and only by some implementations and
deployments.

I can possibly help with automated tests and with development.

You actually never want to incur a 5 second delay. I understand it is
much better than the former 60 seconds or 15 seconds for many protocols
but I'm convinced that the way to go is to always connect in ~100 ms if
there is either IPv4 or IPv6 available to connect (i.e. do not enforce
protocol precedence when one of the protocol is slower than that) and in
rare cases where sequential connect is acceptable 1 second should be
good enough.

I would be honored if you contacted me directly and we could chat a
little bit rather than have an online e-mail discussion.

Cheers,

Pavel

If you have a plan for improving the situation, please open bugs or
feature requests on the relevant upstream projects (glibc, Avahi and/or
nss-mdns).

Distro maintainers' priority is to avoid introducing regressions for
existing software. I don't intend to make downstream changes in nss-mdns
that cause it to regress for existing software, even if that existing
software is not implemented in the ideal way.

Of course, but nss-mdns does not control application behaviour. If an
existing application correctly asks for AF_UNSPEC, great; but if it
wrongly resolves one protocol and then the other, nss-mdns is not in a
position to fix that.

Sorry, I do not have enough time available for nss-mdns maintenance to
spend it on private real-time conversations.

    smcv

I do not have any motivation to start bug reports or feature request
with abandonware (Avahi and mdns). Also don't you think I have started
enough bug reports with glibc that never get processed simply because
noone is willing to actively work on the resolver code not to say review
proposals that go deep into the API details?

Did I not prove enough knowledge of the topic to avoid template advice?
A short answer that you aren't interested would save us another message
exchange.
I don't think we want to get into that sort of discussion as part of a
bug report.
That is exactly why I focused on application behavior first and library
behavior only as a second step.

Good to know. Let me know at any time if the situation changes or if
there's someone interested. But for now I suppose this discussion is
over. Nice to meet you!

Cheers,

Pavel