Bug 883152 (dualstack)

Summary: IPv6 and dual-stack networking sanity tracker
Product: [Fedora] Fedora Reporter: Pavel Šimerda (pavlix) <psimerda>
Component: distributionAssignee: Pavel Šimerda (pavlix) <psimerda>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: codonell, dennis, djasa, hhorak, jakub, jsynacek, law, Michael, michele, mnewsome, nmavrogi, ohudlick, pfrankli, pwouters, thozza, tore, yersinia.spiros
Target Milestone: ---Keywords: Tracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 496300, 505105, 704219, 721350, 883155, 887577, 1091356, 1108335, 1130328, 1181625, 1220698, 1220700, 1220825, 1221496, 1228426, 1232743, 1238729, 1243441, 1269093, 1269914, 1275389, 1280318, 1336496, 195271, 617934, 641836, 830434, 1069809, 1090499, 1116474, 1154200, 1188891, 1220391, 1231946, 1238745, 1250082, 1250857, 1265628, 1274659    
Bug Blocks: 1220694    

Description Pavel Šimerda (pavlix) 2012-12-03 17:08:00 EST
I am starting this bug report to track dualstack networking problems, and especially getaddrinfo() usage in various packages. I'm also going to add several bug reports on getaddrinfo() itself that affect a lot of other packages.

I've started up a Fedora Wiki page to cover this topic:

https://fedoraproject.org/wiki/Networking/NameResolution
Comment 1 Pavel Šimerda (pavlix) 2012-12-11 08:06:26 EST
Fedora Feature (not submitted yet):

https://fedoraproject.org/wiki/Features/DualstackNetworking
Comment 2 Michael Heimann 2013-01-03 07:43:10 EST
ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.

How to create a bug for that and "attach" this tracker bug?
Comment 3 Jan Synacek 2013-01-07 05:19:13 EST
(In reply to comment #2)
> ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6.
> 
> How to create a bug for that and "attach" this tracker bug?

There is no need for a bug because it is not one. I would just delete the line that mentions ping from the feature page.
Comment 4 David Jaša 2013-01-07 08:32:53 EST
(In reply to comment #3)
> There is no need for a bug because it is not one. I would just delete the
> line that mentions ping from the feature page.

It is a bug but it was decided two years ago that it won't be fixed because upstream is non-responsive:
https://bugzilla.redhat.com/show_bug.cgi?id=617934#c2

Maybe it's time to revisit that decision but we certainly shouldn't flood this bug with specific package discussion any more.
Comment 5 Pavel Šimerda (pavlix) 2013-01-07 08:50:40 EST
> we certainly shouldn't flood this bug with specific package discussion any more.

Agreed.

Please continue to bug #617934.
Comment 6 Fedora Admin XMLRPC Client 2013-01-28 15:09:04 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Pavel Šimerda (pavlix) 2013-11-21 06:04:29 EST

For those interested about various problems with dualstack networking and libc name resolution, there's a new project that has been announced on the libc-alpha mailing list:

https://sourceware.org/ml/libc-alpha/2013-11/msg00219.html

Updated README and TODO files can be always found at:

https://sourceware.org/git/?p=netresolve.git;a=blob;f=README;hb=HEAD
https://sourceware.org/git/?p=netresolve.git;a=blob;f=TODO;hb=HEAD

The project aims to improve name resolution and dualstack via providing...

 * Testing tools for `getaddrinfo()` and similar
 * Alternative implementation of `getaddrinfo()`
 * Extended name resolution query API
 * Nonblocking API based on file descriptors
 * Socket API with happy eyeballs

It's in alpha stage but it can already serve as a source of inspiration as well as for initial testing.

https://sourceware.org/git/?p=netresolve.git;a=summary
Comment 8 Paul Wouters 2013-11-21 12:23:02 EST
Are you aware of http://www.vpnc.org/getdns-api/

It seems that is what the browser people are looking at for a new DNS API
Comment 9 Carlos O'Donell 2013-11-21 16:21:02 EST
(In reply to Paul Wouters from comment #8)
> Are you aware of http://www.vpnc.org/getdns-api/
> 
> It seems that is what the browser people are looking at for a new DNS API

I was not aware of this, but that looks like an interesting solution.

We should try to use that in testing for glibc.
Comment 10 Carlos O'Donell 2013-11-21 16:22:01 EST
(In reply to Carlos O'Donell from comment #9)
> (In reply to Paul Wouters from comment #8)
> > Are you aware of http://www.vpnc.org/getdns-api/
> > 
> > It seems that is what the browser people are looking at for a new DNS API
> 
> I was not aware of this, but that looks like an interesting solution.
> 
> We should try to use that in testing for glibc.

... that is whenever they get a real implementation and not just an API draft.
Comment 11 Pavel Šimerda (pavlix) 2013-11-21 17:48:26 EST
(In reply to Carlos O'Donell from comment #10)
> (In reply to Carlos O'Donell from comment #9)
> > (In reply to Paul Wouters from comment #8)
> > > Are you aware of http://www.vpnc.org/getdns-api/
> > > 
> > > It seems that is what the browser people are looking at for a new DNS API
> > 
> > I was not aware of this, but that looks like an interesting solution.

New for me as well, thanks! I'll certainly look at it an will implement it as one of the netresolve wrappers if it looks reasonable.

> > We should try to use that in testing for glibc.
> 
> ... that is whenever they get a real implementation and not just an API
> draft.

Actually we already have a real implementation with netresolve, we can just provide the API as one of the possibilities, as I'm already doing with traditional libc APIs and others.
Comment 12 Pavel Šimerda (pavlix) 2015-07-14 03:24:18 EDT
*** Bug 1220694 has been marked as a duplicate of this bug. ***
Comment 13 Nikos Mavrogiannopoulos 2015-10-23 06:03:29 EDT
This tracker bug has been combined with IPv6 sanity tracker. Thus this tracker will follow applications which are not IPv6-ready. The description of the IPv6 sanity tracker follows.

"There are applications which are not IPv6 ready or provide IPv6 functionality through an external tool. That is a relic of the past, we still drag.

IPv6 support should be transparent in programs, and programs should be modified to auto-detect IPv4 or IPv6 addresses and perform the expected actions."
Comment 14 Pavel Šimerda (pavlix) 2015-10-23 08:12:12 EDT
(In reply to Nikos Mavrogiannopoulos from comment #13)
> This tracker bug has been combined with IPv6 sanity tracker. Thus this
> tracker will follow applications which are not IPv6-ready. The description
> of the IPv6 sanity tracker follows.
> 
> "There are applications which are not IPv6 ready or provide IPv6
> functionality through an external tool. That is a relic of the past, we
> still drag.
> 
> IPv6 support should be transparent in programs, and programs should be
> modified to auto-detect IPv4 or IPv6 addresses and perform the expected
> actions."

Thanks!

And the original links also don't apply any more. Everyone please refer to the following link:

https://fedoraproject.org/wiki/QA/Networking