I'm slightly confused.  If you don't tell xinetd that the daemon is 
ipv6-capable, it doesn't listen for ipv6 connections, but if you do, it does?  
That sounds like it's working correctly to me.  The bug would be in 
the /etc/xinetd.d/* files that don't enable ipv6 for ipv6-capable servers. 

They don't have to specify that they're IPv4-capable. Why should they have to
specify that they're IPv6-capable?

In most cases, they're actually capable of neither -- they're only capable of
stdin and stdout. That's why they use xinetd.

xinetd should assume IPv6 capability by default, and perhaps there should be a
flag to tell it _not_ to listen on IPv6 for a given service.

David, please attach your git conf file.

David, also do you realize you have a fc4 bug on a fc6 blocker? You are testing
on fc6 right?

service git
{
        disable = no
        socket_type     = stream
        wait            = no
        user            = nobody
        server          = /usr/bin/git-daemon
        server_args     = --base-path=/home/git --user-path=public_git
--export-all --syslog --inetd
        log_on_failure  += USERID
}


Yes, I've only reproduced this on FC4. Are you suggesting that it's already been
fixed in rawhide?

OK, I think I have some of the issues sorted out. The ipv6 flag is to select
either IPv4 or IPv6 addresses when more than one is returned by a dns lookup.
You should not be using this for this particular problem.

The issue appears to be no bind statement. If you had a "bind = ::" in the
default section, all would be well. I traced through the code and see that what
is happening is that it is using INADDR_ANY. I think you are wanting
IN6ADDR_ANY_INIT.

I looked at Richard Steven's documentation for getaddrinfo and think there is a
chance that I might be able to determine if IPv6 is available that way. I need
to review the portability code to ensure it always returns INADDR_ANY and what
glibc returns when IPv6 is not available.

So, I think this is your real issue, not that Xinetd is not IPv6 capable. Its
the bind address should be IN6ADDR_ANY_INIT in some cases.

And no, I don't think rawhide has this fixed. Its just odd that a FC4 bug is
blocking FC6.

I think the portable thing to do is listen on ::, then listen on INADDR_ANY
_too_. But accept a failure to listen on INADDR_ANY, because on _some_ systems
the IPv6 socket will also accept IPv4 connections and will prevent you from
listing on the IPv4 socket. I'm sure Uli's documentation will make this clear.

And yes, the issue has always been described as "xinetd doesn't listen on IPv6
by default", not "xinetd lacks IPv6 support". 

Simply adding "bind ::" to the defaults section in /etc/xinetd.conf as-shipped
doesn't seem to be enough to fix this, that breaks configurations with IPv6
forcibly disabled (via modprobe.conf). 

David, the design of xinetd is 1 socket per service. I do not see this changing
anytime soon. I can make it prefer IN6ADDR_ANY_INIT over INADDR_ANY when that is
available, but I cannot make it do both in 1 service config at the moment. So, I
need to make sure I understand your request. Do you want:

1) Prefer IN6ADDR_ANY_INIT over INADDR_ANY when available   - or -

2) Multiple addresses per service config

Choosing _one_ of :: or INADDR_ANY is fine for Linux, since listening on :: will
(normally) accept IPv4 connections. 

It's only if you want code to be portable to BSDs that you need to listen on
both, iirc.

(contining from comment #10...)

See the IPV6_V6ONLY sockopt -- we default it to off, some BSDs default it to on
(and just turning it off might suffice there). I _think_ that OpenBSD refused to
implement it on 'security' grounds, so you still actually have to listen to both
:: and 0.0.0.0 there if you want to accept both IPv6 and Legacy IP connections.

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Still not working in rawhide. I installed rsync and it's listening on IPv4 only.

I wasn't even able to add the 'IPv6' flag in the default section of
/etc/xinetd.conf:

Apr 16 06:37:04  bombadil xinetd[9666]: attribute: flags should not be in
default section [file=/etc/xinetd.conf] [line=35]

Any progress on getting this fixed? do we need to manually add 'flags=IPv6' to
every file we put in /etc/xinetd.d through the whole distribution, to work
around this bug?

I have checked it into CVS (devel) and built it. It will not be included in FC7
though (it's too late and this is not blocking bug). It should appear in rawhide
when FC7 gets released.

You can access the built RPMs in Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=6707

This should probably also get pushed as an update after F7 goes out.  

I'm going to drop it from the blocker list and move to F7Update

xinetd-2.3.14-12.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.