< Networking | Ideas
(Created page with "== NetworkManager automatic configuration. == Static address configuration is supported well so far with the exception of the ''gateway'' setting not yet separated from the '...") |
|||
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== | == Automatic configuration requirements == | ||
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 | ||
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. | |||
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.