From Fedora Project Wiki
Line 1: Line 1:
= Dualstack Networking =
= Fix Network Name Resolution =


== Summary ==
== Summary ==
Line 19: Line 19:


* Targeted release: [[Releases/19|Fedora 19]]
* Targeted release: [[Releases/19|Fedora 19]]
* Last updated: 2013-01-08
* Last updated: 2013-01-15
* Percentage of completion: 5%
* Percentage of completion: 10%


== Detailed description ==
== 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.  
Currently the <code>getaddrinfo()</code> 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 <code>getaddrinfo()</code> with such workarounds. Many can trigger its failures. And many packages that don't use <code>getaddrinfo()</code> will be ported in the near future.


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.
=== Rationale ===


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.
We are submitting this bug fixing effort as a Feature because:


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.
* It is a high-impact change that will (positively) affect allmost all networking software
* Developers will be able to use <code>getaddrinfo()</code> without ugly workarounds for new code
* We are going to publish guidelines for proper <code>getaddrinfo()</code> usage
* Documentation for <code>getaddrinfo()</code> bugs and possible workarounds will be available to help maintaining backward compatibility
* Comments and errata will be sent to standards organizations
* We want to recieve critical response during the whole process


Bugs related to dualstack networking should be added to the following tracker bug:
=== Problem statement ===
 
The behavior of <code>getaddrinfo()</code> is often nonstandard, undocumented, surprising, or just plain wrong. We already indentified a number of problems. The most prominent examples are here.
 
* <code>getaddrinfo()</code> may return duplicate or even wrong addresses from /etc/hosts
* <code>getaddrinfo()</code> with NULL servname may return duplicate addresses
* <code>getaddrinfo()</code> with AI_PASSIVE may still address list not suitable for <code>bind()</code>
* <code>getaddrinfo()</code> with AI_ADDRCONFIG may fail to translate literal addresses
* <code>getaddrinfo()</code> with AI_ADDRCONFIG may fail to resolve /etc/hosts addresses
* <code>getaddrinfo()</code> with AI_ADDRCONFIG may send unwanted AAAA queries
* <code>getaddrinfo()</code> has a bad choice of default flags</code>
 
Whether or not the problematic actually occurs depends on <code>/etc/hosts</code> configuration, <code>/etc/resolv.conf</code> configuration, <code>getaddrinfo()</code> 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 <code>getaddrinfo()</code> can be found upstream:
 
http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo
 
=== Affected software ===
 
The above problems affect software that wants to use <code>getaddrinfo()<code> to:
 
* Get parameters for <code>connect()</code> or <code>sendto()</code> to start communicating
* Get parameters for <code>bind()</code> 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 <code>getaddrinfo()</code>, 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
http://bugzilla.redhat.com/show_bug.cgi?id=883152
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=ipv6blocker


== Benefit to Fedora ==
== Benefit to Fedora ==

Revision as of 11:01, 15 January 2013

Fix Network Name Resolution

Summary

IPv4 and IPv6 host/service name resolution doesn't work very well in Fedora. The getaddrinfo() function in glibc returns wrong results in many cases. This feature aims to fix a bunch of name resolution bugs in glibc that prevent applications from fully using name resolution functions without doing a bunch of workaround.

Owner

Current status

  • Targeted release: Fedora 19
  • Last updated: 2013-01-15
  • Percentage of completion: 10%

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 and possible workarounds will be available to help maintaining backward compatibility
  • Comments and errata will be sent to standards organizations
  • We want to recieve critical response during the whole process

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 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

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

Benefit to Fedora

One of Fedora's goals is to be a modern linux distribution that will work in modern environments. For this to be achieved, proper IPv4-only support and proper dualstack support is a MUST. IPv6-only use cases are rare but may become more common at any time. It's better to be prepared for those, too.

Scope

Application software used on day-to-day basis should be correctly handling IPv4-only, IPv6-only and dualstack use cases.

Libraries:

  • glibc: name resolution must work properly
  • glib: provides networking API for applications

System services:

  • knfsd

Applications:

Note: Network configuration tools are out of scope of this feature. Network testing tools were moved to a separate feature page. See Networking#Fedora_feature_pages for other network-related features.

How to test

This is the most difficult part. We are going to combine the following approaches to testing:

  • Everyday use of Fedora in various network environments
  • Testing the tracked bug reports
  • Specific tests, e.g. for getaddrinfo() and glib API

User experience

Users currently experience networking problems in various environments even during the most basic use of their system because of principal problems in the distribution. These problems would go away.

Dependencies

Not known.

Contingency plan

This feature is about fixing all important parts of the distribution. We do not expect the required changes to negatively affect the rest of the packages. But if any problems occur, we are ready to help fixing them before the respective version is released. As a last resort, any problematic change can be reverted.

Documentation

Release notes

Dualstack networking is fully supported and glibc and other packages will be tested for not including fundamental design flaws and important bugs regarding IPv4 and IPv6 support.

Comments and discussions

See Talk:Features/DualstackNetworking