On Mon, 30 Jul 2007, Kurt Roeckx wrote:
On Mon, Jul 30, 2007 at 07:52:47PM +0200, Tomas Pospisek wrote:Hallo Release Team, I've read in the release goals:RELEASE GOALS ============= * full IPv6 support Advocate: Martin Zobel-Helasand wrote to Martin Zobel-Helas who redirected me here. My experience with IPv6 in Debian is foremost that it's a pita. Debian enables IPv6 by default. * AAAA before A DNS lookup[...]* Software that binds to the first socket found[...] Both of those problems seem to be problems in specific pieces of software. I suggest you file bugs against those packages and tag them with the ipv6 tag.* The cost of disabling IPv6I don't think that should be needed, and the software behaving wrong should get fixed instead.So before pushing IPv6 even further into Debian I ask you to consider whether the foundation that is laid today is sane enough or whether it should be improved with priority.I think the point of adding better ipv6 support is actually fixing those pieces of software that don't behave properly, in either an ipv4-only or ipv6-only world. They should be written that they should work with any protocol.
I was trying to say that I had been bitten by the "libc's name resolver does by default an AAAA name lookup before it does an A lookup" before and am asking whether that's still a problem as [1] suggest that it was for Ubuntu at least until Dec 06 and whether someone can confirm it. As told I can not reproduce it on my systems any more since I removed ipv6 as soon as it started causing me trouble and as such cannot file a bug report against libc.
Regarding dccproc you might[2] be right, however my suggestion for consideration is not whether or not to enhance applications to be able to deal with the new ipv6 support in libc and the kernel, but whether it's worth breaking those apps by default.
You can not build systems that can deal with all and any unforseen fundamental chang in their environments.
And arguably ipv6 is such a change (since it breaks applications). So arguing that applications don't "behave properly" or "behave wrong" is IMHO not correct. They break with ipv6 but not without. ipv6 is a new fundamental property of the system to deal with that came after the apps.
One could also ask the question the other way around: how come ipv6 is allowed to break apps and network configurations?
Or one could ask why does Debian break perfectly well running systems by enabling a new feature?
You're right that it'd be good if the apps would get improved so that they gracefully deal with ipv6 too.
But the question for me is: how high is the price? Does it mean that the part of the users that plug in the Debian install CD and happen to sit behind a ISP's DNS server that doesn't care about ipv6 will have multi-second lookup delays? Does it mean that one has to tweak every second daemon?
IPv6 is set as a release goal.Is having Debian CDs work out of the box for the average user plugging into an everyday ISP also a release goal?
Is not having to tweak every second daemon to somehow work with ipv6 [2] also a release goal? (Note that since most admins don't have a use for ipv6 they'll rather switch off ipv6 which as I said is not easy either.)
All I want to emphasize is: release team and ipv6 supporters be careful what you're pushing for. Please keep your goals in perspective.
Please don't judge this memorandum based on the fact that the problem in my specific case might sit in front of the keyboard, and instead please take into account that a default instalation should *just* run in the most common cases without the need to tweak - that is without the need to switch off something as "exotic" as IPv6.I've never actually had a problem on ipv4-only hosts. It would be nice if you could describe your problems in more detail.
The (concrete!) problems are described in the references I sent: [0] https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828 [1] http://lists.debian.org/debian-devel/2000/12/msg01922.html [2] http://www.google.com/search?q=dccproc+socket(UDP)%3A+Address+family+not+supported+by+protocol Also have a look at: http://bugs.debian.org/343140 And if you do also at RFC3484 wrt #343140. *t -- -------------------------------------------------------- Tomas Pospisek http://sourcepole.com - Linux & Open Source Solutions --------------------------------------------------------