From Fedora Project Wiki
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
== NetworkManager automatic configuration. ==
== Automatic configuration requirements ==
 
Static address configuration is supported well so far with the exception of the ''gateway'' setting not yet separated from the ''addresses'' setting. Automatic configuration is a lot more difficult as it depends on DHCP for IPv4 and on a combination of router discovery and DHCP for IPv6.
 
The main focus will be on IPv6 automatic configuration, as the IPv4 one is working pretty well.


NetworkManager device configuration works in the following sequence:
NetworkManager device configuration works in the following sequence:
Line 12: Line 8:
* Commit resulting configuration to the kernel
* Commit resulting configuration to the kernel


On the other hand, the Linux kernel autoconfiguration support would:
This requires non-destructive support for all dynamic configuration protocols.
 
* Use router discovery only, no DHCPv6
* Push configuration directly to address lists and routing tables
* Notify the userspace daemon about addresses, routes and other parameters
 
And all of this happens before NetworkManager gets to the policy decision. Modifications of kernel network configuration, especially the address list and the routing table, is a violation of the NetworkManager workflow. It has severe consequences on the correctness and reliability of the whole
configuration process.
 
== Proposed solutions ==
 
There is a multitude of ways to solve this problems, some of them are good, some of them are bad. I am going to focus on those that are appealing enough to be discussed.
 
=== Solution #1: Fix kernel autoconfiguration and provide respective API ===
 
Kernel currently doesn't provide API to do router discovery without immediate reconfiguration. API for addresses, routes nad prefixes would have to be added, only DNS options are currently available. Kernel would basically repackage router advertisements to netlink messages with optional caching.
 
=== Solution #2: Use a separate daemon for router discovery ===
 
A daemon could be spawned that would listen on a link-local address, recieve router advertisements, parse them, verify them, cache them and provide an event-based API for NetworkManager.
 
=== Solution #3: Perform router discovery inside NetworkManager ===
 
Basically the same as solution #2 but the logic would be built-in to NetworkManager.
 
=== Solution #4: Use a RD+DHCP daemon ===
 
There are solutions like dhcpcd that are all-in-one network configurators. This solution, however would move the control out of NetworkManager, which may not be acceptable. It also doesn't fit well with the current NetworkManager model where DHCP is handled separately. It's included for the sake of completeness.
 
== Point of view ==


pavlix: I currently prefer just anything in userspace. Already recieved positive feedback for it.
== Current status ==


== Requirements ==
Current status in ''git master'' is good from the design point of view. There's a couple of things missing and there are a couple of issues but that's documented in the bugzilla. Just look for ''rdisc'' in bug report summaries.


=== Router discovery ===
=== IPv4 configuration using DHCP ===


The module (program, library) should be able to perform per-interface router discovery. That consists of sending router solicitation and recieving router advertisements according to NetworkManager needs.
NetworkManager uses ''dhclient'' with its own dhclient ''helper script''. All system configuration actions are thus deferred to NetworkManager to perform policy decisions and commit the result. An alternative ''dhclient'' plugin is also available for IPv4.


Router discovery continues as long as the connection is active. A recieved router advertisement is not a reason to stop router discovery.
=== IPv6 router discovery in the kernel (removed in git master) ===


=== Router advertisement parsing ===
Kernel pushes configuration information directly to the address list and the routing table. That prevents policy decisions and proper configuration handling. It is totally unsuitable for use on hosts with multiple devices, not to say VPNs and other complex scenarios. On top of that, kernel router discovery implementation has many bugs and design flaws that are not even worth fixing in this situation.


It should parse the router advertisement to extract all necessary information.
The solution is to either add a new kernel API to convey router discovery information to NetworkManager without commiting it, or to implement router discovery in userspace. The former is a waste of resources as a router discovery client doesn't need anything more than just a socket with access to ICMP datagrams.


=== Address, route and prefix information ===
=== IPv6 router discovery in userspace ===


It should cache recieved addresses, routes and prefixes and should announce them to NetworkManager along with their lifetimes. Any later changes should be announced too.
The current code in ''git master'' uses ''libndp'' to perform router discovery purely in userspace. While the featureset is not yet complete, this works almost as easily as IPv4 DHCP configuration.


=== DNS information ===
=== IPv6 configuration using DHCP ===


Same as above.
NetworkManager uses ''dhclient'' to perform IPv6 DHCP request in the same way as it does with IPv4. The main difference is that DHCP configuration is currently only started if requested by the router via router advertisement. Router discovery is therefore always the first and mandatory step, before any DHCP communication occurs.

Latest revision as of 00:45, 20 October 2013

Automatic configuration requirements

NetworkManager device configuration works in the following sequence:

  • Gather user configuration and runtime state
  • Use dynamic configuration protocols to gather information
  • Perform policy decisions
  • Commit resulting configuration to the kernel

This requires non-destructive support for all dynamic configuration protocols.

Current status

Current status in git master is good from the design point of view. There's a couple of things missing and there are a couple of issues but that's documented in the bugzilla. Just look for rdisc in bug report summaries.

IPv4 configuration using DHCP

NetworkManager uses dhclient with its own dhclient helper script. All system configuration actions are thus deferred to NetworkManager to perform policy decisions and commit the result. An alternative dhclient plugin is also available for IPv4.

IPv6 router discovery in the kernel (removed in git master)

Kernel pushes configuration information directly to the address list and the routing table. That prevents policy decisions and proper configuration handling. It is totally unsuitable for use on hosts with multiple devices, not to say VPNs and other complex scenarios. On top of that, kernel router discovery implementation has many bugs and design flaws that are not even worth fixing in this situation.

The solution is to either add a new kernel API to convey router discovery information to NetworkManager without commiting it, or to implement router discovery in userspace. The former is a waste of resources as a router discovery client doesn't need anything more than just a socket with access to ICMP datagrams.

IPv6 router discovery in userspace

The current code in git master uses libndp to perform router discovery purely in userspace. While the featureset is not yet complete, this works almost as easily as IPv4 DHCP configuration.

IPv6 configuration using DHCP

NetworkManager uses dhclient to perform IPv6 DHCP request in the same way as it does with IPv4. The main difference is that DHCP configuration is currently only started if requested by the router via router advertisement. Router discovery is therefore always the first and mandatory step, before any DHCP communication occurs.

Retrieved from "https://fedoraproject.org/w/index.php?title=Networking/Ideas/AutomaticConfiguration&oldid=357495"