Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Jaroslav Reznik]

As the Feature was renamed and the content of Feature has been extended
as requested by FESCo, re-announcing it to the community for re-review.

See https://fedorahosted.org/fesco/ticket/986

= Features/Fix Network Name Resolution =
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution

* Detailed description
Currently the getaddrinfo() function doesn't work as it was desinged. 
Many of its features are buggy and cannot be used without extensive
workarounds. Many software packages are using getaddrinfo() with such 
workarounds. Many can trigger its failures. And many packages that don't 
use getaddrinfo() will be ported in the near future.

- Rationale

 We are submitting this bug fixing effort as a Feature because:
 It is a high-impact change that will (positively) affect allmost all 
 networking software
 Developers will be able to use getaddrinfo() without ugly workarounds 
 for new code
 We are going to publish guidelines for proper getaddrinfo() usage
 Documentation for getaddrinfo() bugs will be availabe
 Possible workarounds will be offered for backward compatibility
 Comments and errata will be sent to standards organizations
 We want to recieve critical response during the whole process
 It will be part of the next networking testweek 

- Problem statement

 The behavior of getaddrinfo() is often nonstandard, undocumented, 
 surprising, or just plain wrong. We already indentified a number of 
 problems. The most prominent examples are here.

 getaddrinfo() may return duplicate or even wrong addresses from 
 /etc/hosts
 getaddrinfo() with NULL servname may return duplicate addresses
 getaddrinfo() with AI_PASSIVE may still return address list not 
 suitable for bind()
 getaddrinfo() with AI_ADDRCONFIG may fail to translate literal 
 addresses
 getaddrinfo() with AI_ADDRCONFIG may fail to resolve /etc/hosts 
 addresses
 getaddrinfo() with AI_ADDRCONFIG may send unwanted AAAA queries
 getaddrinfo() has a bad choice of default flags</code> 

 Whether or not the problematic actually occurs depends on /etc/hosts 
 configuration, /etc/resolv.conf configuration, getaddrinfo() input 
 parameters, runtime kernel network interface configuration, and more. 
 While testing the known bugs or reading the source code, more and more 
 bugs are discovered.

 Bug reports related to getaddrinfo() can be found upstream:

 http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo

-Affected software

 The above problems affect software that wants to use getaddrinfo() to:
 Get parameters for connect() or sendto() to start communicating
 Get parameters for bind() to listen on specific addresses
 Build IP address based accesslists
 Perform name resolution for other purposes 

Although it would be nice to also test and fix all software in Fedora using 
getaddrinfo(), that is not feasible. Therefore we are going to concentrate on 
checking and fixing the GNU C library, checking and fixing the most important 
toolkits dealing with networking, and documenting a set of guidelines for 
daemons and application software.

Fedora bugs related to dualstack networking including name resolution 
problems should be added to the following tracker bug:

http://bugzilla.redhat.com/show_bug.cgi?id=883152 

----- Original Message -----
> As decided by FESCo on 2012-12-05 meeting, all proposed Features are
> required
> to pass through the community review by announcing them on
> devel-announce list.
> FESCo votes on new features no sooner than a week from the
> announcement.
> 
> = Features/DualstackNetworking =
> https://fedoraproject.org/wiki/Features/DualstackNetworking
> 
> * Detailed description
> Fedora supports dualstack global networking. That means the computer
> with
> Fedora is connected to internet using both IPv4 and IPv6 protocols.
> But many
> important system services and applications either don't do IPv6, do
> it
> incorrectly, or don't cope with various network conditions.
> 
> Unfortunately, while trying to improve IPv6 support, some IPv4 use
> cases became
> broken as well. That's why the goal of this feature is not only to
> support IPv4,
> but to support all possible real-world cases.
> 
> Dualstack-ready software must cope with all possible scenarios
> including
> IPv4-only connectivity, IPv6-only connectivity and dual connectivity.
> The software must also cope with node-local (aka localhost)
> networking, which
> as been used by software for decades.
> 
> Though it would be nice to have all applications in Fedora fixed to
> work in
> any of the scenarios, it is not feasible to test that. Therefore this
> feature
> is about major software used in servers, desktops and laptops. The
> list of such
> applications will be completed over the time.
> 
> Bugs related to dualstack networking should be added to the following
> tracker
> bug:
> 
> http://bugzilla.redhat.com/show_bug.cgi?id=883152
> 
> Also see: https://bugzilla.redhat.com/show_bug.cgi?id=ipv6blocker