From Fedora Project Wiki

< Networking‎ | Ideas

Revision as of 23:52, 4 March 2013 by Pavlix (talk | contribs) (Point of view)

NetworkManager automatic configuration.

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:

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

On the other hand, the Linux kernel autoconfiguration support would:

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


Router discovery

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.

Router discovery continues as long as the connection is active. A recieved router advertisement is not a reason to stop router discovery.

Router advertisement parsing

It should parse the router advertisement to extract all necessary information.

Address, route and prefix information

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.

DNS information

Same as above.