----- Original Message -----
From: "Miloslav Trmač" <mitr(a)volny.cz>
On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik <jreznik(a)redhat.com>
wrote:
> = Features/DualstackNetworking =
>
https://fedoraproject.org/wiki/Features/DualstackNetworking
(Sending to the list instead of using the wiki talk page to hopefully
gather more information from networking experts. The recent-ish
bugzilla activity in this space does suggest that this is a good
topic to revisit in detail, thanks for taking the effort on.)
Thanks!
1. So what is the _precise_ scope of the ''proposed
feature''? For
example, does "glibc: name resolution must work properly" mean that
you have some specific proposals to change glibc?
Yes.
I identified a bunch of problems in glibc and commented on previously identified
problems:
http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo&li...
Now I'm writing and submitting patches. But it will take time.
(
https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG
suggests changing glibc as one of the options. Have you decided
which
option you propose? In general, glibc maintainers' signoff or at
least significant discussion would probably be required for any glibc
change of this kind. FWIW, historically it was recommended to have
AI_ADDRCONFIG enabled, see
http://www.akkadia.org/drepper/userapi-ipv6.html .)
It is now pretty clear that we need to do #3 and #4 (in this order) and then start
recommending AI_ADDRCONFIG for connect(), sendto() and other stuff again. But I found more
fundamental problems in getaddrinfo() while playing with the code and while reading
IPv6-related bug reports.
Ulrich's documentation is unfortunately not useful as it was written without practical
IPv6 skills and testing. I recommend to ignore it in favor of the resources on Fedora
Wiki.
2. We already have a guideline requiring IPv6
(
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=PackagingGuideline...
); to the extent that this feature would propose specific ways to use
the API, the packaging guideline should point to documentation that
describes the correct way.
Good point. Specific recommedations that are evolving will be part of this feature.
It would be great to get a wide review of the proposed approach
before any extensive effort to
modify many
packages starts.
Actually, it's easier than that.
Most important packages either use getaddrinfo() or are moving towards it. Many of them
(if not most) set AI_ADDRCONFIG. As we are now going to fix AI_ADDRCONFIG to make it
actually useful and not harmful, that would mean only packages that are buggy already
would need fixing.
Thank you for your feedback,
Pavel