Bug 883152 - (dualstack) IPv6 and dual-stack networking sanity tracker
IPv6 and dual-stack networking sanity tracker
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Pavel Šimerda (pavlix)
Fedora Extras Quality Assurance
: Tracking
: 1220694 (view as bug list)
Depends On: 496300 505105 704219 721350 883155 887577 1091356 1108335 1130328 1220698 1220700 1220825 1221496 1228426 1232743 1238729 1243441 1269093 1269914 1275389 1336496 IPv6Blocker 617934 ipv6 830434 1069809 1090499 1116474 1154200 1181625 1188891 1220391 1231946 1238745 1250082 1250857 1265628 1274659 1280318
Blocks: 1220694
  Show dependency treegraph
 
Reported: 2012-12-03 17:08 EST by Pavel Šimerda (pavlix)
Modified: 2016-07-26 03:21 EDT (History)
16 users (show)

See Also:
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:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.