From Fedora Project Wiki

No edit summary
Line 4: Line 4:
infrastructure.
infrastructure.


== Networking concepts and configuration ==
=== Networking concepts and configuration ===


* [[Networking/Ethernet|Ethernet]]
* [[Networking/Ethernet|Ethernet]]
Line 17: Line 17:
* [[Networking/Dependencies|Network connectivity dependencies]]
* [[Networking/Dependencies|Network connectivity dependencies]]


== Most prominent projects involved in linux networking ==
=== Most prominent projects involved in linux networking ===


* Kernel
* Kernel
Line 24: Line 24:
* ISC DHCP
* ISC DHCP


== Notable networking problems ==
=== Notable networking problems ===


Only platform bugs that can influence various application and/or the overall behavior of the system belong here.
Only platform bugs that can influence various application and/or the overall behavior of the system belong here.


=== Kernel ===
==== Kernel ====


* Bridge: Adding first interface after setting MAC address changes the MAC address
* Bridge: Adding first interface after setting MAC address changes the MAC address
Line 38: Line 38:
* IPv6: Kernel doesn't provide prefix route information when pinfo is disabled
* IPv6: Kernel doesn't provide prefix route information when pinfo is disabled


=== libnl ===
==== libnl ====


* rtnl_link_bond_add() succeeds when device already exists
* rtnl_link_bond_add() succeeds when device already exists
* rtnl_link_bridge_add() and rtnl_link_vlan_add missing
* rtnl_link_bridge_add() and rtnl_link_vlan_add missing


=== iproute ===
==== iproute ====


* iproute won't distinguish bridges and bonds
* iproute won't distinguish bridges and bonds
* iproute won't show vlan id
* iproute won't show vlan id


=== GLIBC ===
==== GLIBC ====


* IPv4: [http://bugzilla.redhat.com/show_bug.cgi?id=721350 <code>getaddrinfo("127.0.0.1", ...)</code> fail with some AI_ADDRCONFIG configurations]
* IPv4: [http://bugzilla.redhat.com/show_bug.cgi?id=721350 <code>getaddrinfo("127.0.0.1", ...)</code> fail with some AI_ADDRCONFIG configurations]
Line 56: Line 56:
* DNS: [http://sourceware.org/bugzilla/show_bug.cgi?id=2099 <code>getaddrinfo</code> doesn't support SRV records]
* DNS: [http://sourceware.org/bugzilla/show_bug.cgi?id=2099 <code>getaddrinfo</code> doesn't support SRV records]


=== dhclient ===
==== dhclient ====


* Fixed: [http://bugzilla.redhat.com/show_bug.cgi?id=662254 <code>dhclient</code> fails with large values of dhcp-renawal-time, notably the infinity (0xffffffff) value]
* Fixed: [http://bugzilla.redhat.com/show_bug.cgi?id=662254 <code>dhclient</code> fails with large values of dhcp-renawal-time, notably the infinity (0xffffffff) value]
* People say that dhclient exchange is slow, especially on wireless (I can't reproduce)
* People say that dhclient exchange is slow, especially on wireless (I can't reproduce)


=== Avahi ===
==== Avahi ====


* [http://bugzilla.redhat.com/show_bug.cgi?id=719178 Avahi's ''nss-mdns'' returns link-local IPv6 addresses ''without'' scope_id and applications fail to connect]
* [http://bugzilla.redhat.com/show_bug.cgi?id=719178 Avahi's ''nss-mdns'' returns link-local IPv6 addresses ''without'' scope_id and applications fail to connect]
* [http://bugzilla.redhat.com/show_bug.cgi?id=821127 Avahi's IPv6 support is disabled by default (this has been resolved in the past)]
* [http://bugzilla.redhat.com/show_bug.cgi?id=821127 Avahi's IPv6 support is disabled by default (this has been resolved in the past)]


=== NetworkManager ===
==== NetworkManager ====


* Various bugs in [[Tools/NetworkManager|NetworkManager]]
* Various bugs in [[Tools/NetworkManager|NetworkManager]]


=== Testing tools ===
==== Testing tools ====


* ping doesn't support IPv6 (you have to use ping6)
* ping doesn't support IPv6 (you have to use ping6)
* netstat and ss won't mark non-v6only sockets
* netstat and ss won't mark non-v6only sockets


=== Various applications ===
==== Various applications ====


* Assume that <code>getaddrinfo()</code> returns only one address and/or that such the first returned address works. See [[Networking/NameResolution]].
* Assume that <code>getaddrinfo()</code> returns only one address and/or that such the first returned address works. See [[Networking/NameResolution]].
=== Peaces of the puzzle ===
* Interface for static IPv4 and IPv6 configuration (kernel)
* Interface for bridging/bonding/vlan configuration (kernel)
* Interface for DNS configuration (/etc/resolv.conf)
* DHCP client implementation for IPv4 automatic configuration (dhclient)
* RA client implementation for IPv6 address configuration (kernel, with workarounds in NetworkManager)
* RDNSS/DNSSL client implementation for IPv6 DNS configuration (NetworkManager through kernel, with workarounds)
* DHCP client implementation for IPv6 address/DNS/other configuration (dhclient)
* IPsec, VPN and tunneling implementations (various daemons)
* A network management daemon to properly manage all of the above together with user configuration (NetworkManager)
* Networking API for applications (glibc, with many problems)
I may have missed something but the objective is to show that networking is rather complex and the various tools need
to be centrally managed by a network management service in order to make users and administrators happy.
You can only live without network configuration daemons if you use static IP configuration and you avoid encrypted
wireless networks at the same time. You can live with just wpa_supplicant and dhclient only if you are used to do
most of the stuff yourself. Virtually all linux distributions now converge to network solutions based on network
configuration daemons.
Examples of such daemons (without feature comparison):
* NetworkManager
* connman (MeeGo)
* WICD
* netifd (OpenWRT)
* netcfg (Archlinux)
* wicked
Yeah, it's a lot of fun writing new and new network configuration daemons.

Revision as of 08:12, 27 November 2012

Networking features are nowadays important for virtually all users of Fedora and other linux distributions. Fedora's main network use cases are laptops, desktops, servers and virtualization. Fedora could also be used for routers, becoming part of networking infrastructure.

Networking concepts and configuration

Most prominent projects involved in linux networking

Notable networking problems

Only platform bugs that can influence various application and/or the overall behavior of the system belong here.

Kernel

  • Bridge: Adding first interface after setting MAC address changes the MAC address
  • IPv4: Kernel can't store DHCP lifetime and cannot mark IPv6 addresses dynamic (in the DHCP sense)
  • IPv6: Kernel ignores RA router preference
  • IPv6: Tempaddr cycling breaks TCP connections prematurely
  • IPv6: Kernel doesn't cache RDNSS and DNSSL
  • IPv6: Kernel doesn't provide default route information when defrtr is disabled
  • IPv6: Kernel doesn't provide prefix route information when pinfo is disabled

libnl

  • rtnl_link_bond_add() succeeds when device already exists
  • rtnl_link_bridge_add() and rtnl_link_vlan_add missing

iproute

  • iproute won't distinguish bridges and bonds
  • iproute won't show vlan id

GLIBC

dhclient

Avahi

NetworkManager

Testing tools

  • ping doesn't support IPv6 (you have to use ping6)
  • netstat and ss won't mark non-v6only sockets

Various applications

  • Assume that getaddrinfo() returns only one address and/or that such the first returned address works. See Networking/NameResolution.

Peaces of the puzzle

  • Interface for static IPv4 and IPv6 configuration (kernel)
  • Interface for bridging/bonding/vlan configuration (kernel)
  • Interface for DNS configuration (/etc/resolv.conf)
  • DHCP client implementation for IPv4 automatic configuration (dhclient)
  • RA client implementation for IPv6 address configuration (kernel, with workarounds in NetworkManager)
  • RDNSS/DNSSL client implementation for IPv6 DNS configuration (NetworkManager through kernel, with workarounds)
  • DHCP client implementation for IPv6 address/DNS/other configuration (dhclient)
  • IPsec, VPN and tunneling implementations (various daemons)
  • A network management daemon to properly manage all of the above together with user configuration (NetworkManager)
  • Networking API for applications (glibc, with many problems)

I may have missed something but the objective is to show that networking is rather complex and the various tools need to be centrally managed by a network management service in order to make users and administrators happy.

You can only live without network configuration daemons if you use static IP configuration and you avoid encrypted wireless networks at the same time. You can live with just wpa_supplicant and dhclient only if you are used to do most of the stuff yourself. Virtually all linux distributions now converge to network solutions based on network configuration daemons.


Examples of such daemons (without feature comparison):

  • NetworkManager
  • connman (MeeGo)
  • WICD
  • netifd (OpenWRT)
  • netcfg (Archlinux)
  • wicked

Yeah, it's a lot of fun writing new and new network configuration daemons.