NM bugzilla reorganization. Sorry for the bug spam.

Changing the summary to extend the ticket.

*** Current situation ***

Valid IPv4 methods (according to git master):

* auto
* link-local
* manual
* shared
* disabled

Valid IPv6 methods (according to git master):

* ignore
* auto
* dhcp
* link-local
* manual
* shared

*** Requirements ***

What we actually need to set up:

* turn IPv4/IPv6 automatic configuration on/off
* turn IPv4 link-local addresses on/off
* turn IPv4/IPv6 sharing on/off

Notes:

IPv6 link-local addresses are handled by the kernel and are usually expected to be present even if global configuration is not performed. On the other hand, IPv4 link-local addresses are rarely used and should only be present when explicitly requested. That makes the link-local addresses of the two protocols *not* comparable.

Disabling the IPv4/IPv6 protocol itself on a specific device or for the whole system is IMO out of scope of NetworkManager. AFAIK the only IPv6 sysctl that should be used by NetworkManager is accept_ra nad that one should be always set to zero for managed devices. It should *not* be resored to its orinal value while the device is still configured. To be more precise, the only time we should restore accept_ra is *just after* the device is being set down by NetworkManager and it should *always* be set to zero when NetworkManager sets the device up or takes it into management.

*** Proposed actions ***

1) Remove IPv6 'ignore' method as it doesn't make sense to leave IPv6 configuration to the kernel on a per-connection basis. If anyone really needs NetworkManager to ignore IPv6 it should be a global option, otherwise we cannot guarantee the outcome (kernel autonomously writing to the routing tables is always a call for trouble).

2) Remove IPv6 'dhcp' as we aren't expected to run DHCPv6 without router discovery.

3) Rename IPv6 'link-local' method to 'disabled' as NetworkManager doesn't interface with the link-local methods at all. That way 'disabled' would mean to still zero accept_ra but not perform userspace router discovery.

*** The result ***

IPv4+IPv6 methods:

* disabled: like manual but with no addresses
* manual: don't perform any automatic configuration (kernel will do IPv6LL)
* auto: perform standard automatic configuration (DHCPv4, RD+DHCPv6)
* shared: like manual + serve RA, DHCP and DNS

IPv4-only methods:

* link-local: a special method for link-local IPv4 sharing, should only be enabled on one interface to work properly

IPv6-only methods:

N/A

*** Further suggestions ***

The 'disabled' and 'manual' methods could be merged as the key difference between them is only the number of address records (zero for disabled, non-zero for manual).

The 'link-local' IPv4 method should be decoupled into a separate option as IPv4 link local configuration doesn't technically or logically exclude any of the other methods.

When the two above are done, we only have 'disabled/manual', 'auto' and 'shared'. While 'auto' and 'shared' *are* exclusive (in that running dhcp server and client on the same interface is bad), they aren't really the same class of options and should be decoupled:

method=disabled/manual -> auto=off, shared=off
method=auto -> auto=on, shared=off
method=shared -> auto=off, shared=on

(auto=on, shared=on combination would remain INVALID)

(In reply to comment #2)
> To be more precise, the only time we
> should restore accept_ra is *just after* the device is being set down by
> NetworkManager

Just a remark that in bug 683206 I suggest to avoid setting the device down. That doesn't change much for accept_ra, though. Note that on NetworkManager exit, we can't reset accept_ra if we want to keep userspace-autoconfigured IP adresses.

(In reply to comment #2)
> Changing the summary to extend the ticket.
> 
> *** Current situation ***
> 
> Valid IPv4 methods (according to git master):
> 
> * auto
> * link-local
> * manual
> * shared
> * disabled
> 
> Valid IPv6 methods (according to git master):
> 
> * ignore
> * auto
> * dhcp
> * link-local
> * manual
> * shared
> 
> *** Requirements ***
> 
> What we actually need to set up:
> 
> * turn IPv4/IPv6 automatic configuration on/off
> * turn IPv4 link-local addresses on/off
> * turn IPv4/IPv6 sharing on/off

This all looks valid.

> Notes:
> 
> IPv6 link-local addresses are handled by the kernel and are usually expected to
> be present even if global configuration is not performed. On the other hand,
> IPv4 link-local addresses are rarely used and should only be present when
> explicitly requested. That makes the link-local addresses of the two protocols
> *not* comparable.

Correct.

> Disabling the IPv4/IPv6 protocol itself on a specific device or for the whole
> system is IMO out of scope of NetworkManager. AFAIK the only IPv6 sysctl that

Agreed; "disable" in this new scheme should simply mean that NetowrkManager does not perform IPv4 or IPv6 configuration itself.  It should not mean that NM *prevents* that from happening externally, like if the user manually assigns an IPv6 address.

However, what if the user really does not want *any* IPv6 on a specific interface?  AFAIK there's no way to suppress IPv6LL without setting disable_ipv6=1, correct?  That's what the "disable" option currently provides. (see below)

I agree that NM should never set /proc/sys/net/ipv6/conf/all/disable_ipv6 or /proc/sys/net/ipv6/conf/default/disable_ipv6, but NM may need to set /proc/sys/net/ipv6/conf/<ifname>/disable_ipv6 to suppress IPv6LL on an interface-by-interface basis.

> should be used by NetworkManager is accept_ra nad that one should be always set
> to zero for managed devices. It should *not* be resored to its orinal value
> while the device is still configured. To be more precise, the only time we
> should restore accept_ra is *just after* the device is being set down by
> NetworkManager and it should *always* be set to zero when NetworkManager sets
> the device up or takes it into management.

Yes.  This gets a bit tricky though when implementing the "no touching" stuff.  When assuming a foreign connection, we have two options if accept_ra=1 and the interface has kernel-assigned v6 addresses:

1) leave accept_ra=1, read the existing addressing and routing configuration but don't touch the interface until the administrator tells NM to do something.  This means we don't get any DNS information unless we add back some of the old ip6-manager code to read them from the kernel.

2) change accept_ra=0 and use libndp; here we get all the DNS and other information, but we obviously touch the device

I'm not a huge fan of adding back a bunch of netlink code to read the RDNSS stuff, but unless the kernel starts exposing that somewhere, we might have to do that so that we don't touch the interface when assuming it.

Thoughts?

> *** Proposed actions ***
> 
> 1) Remove IPv6 'ignore' method as it doesn't make sense to leave IPv6
> configuration to the kernel on a per-connection basis. If anyone really needs
> NetworkManager to ignore IPv6 it should be a global option, otherwise we cannot
> guarantee the outcome (kernel autonomously writing to the routing tables is
> always a call for trouble).

Ignore was added for backwards compatibility, essentially to say "don't touch IPv6 at all, but don't turn it off either".  Obviously we could combine "ignore" and "disable", but then we'd lose the ability to suppress IPv6LL addressing on interfaces if the user really wanted that.

> 2) Remove IPv6 'dhcp' as we aren't expected to run DHCPv6 without router
> discovery.

That's what we thought before, as DHCPv6 didn't have the ability to send a router/gateway or a prefix.  However I just found:

http://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/

If that is deployed, there would be no requirement for Router Advertisements.  Which brings up an interesting question; in the case where DHCPv6-only is used, and no RAs are given, how would NM know what to do unless the user told NM to ignore RAs and run DHCPv6 only?

NM could always run DHCPv6 in parallel with RA, then we may end up with leases that we shouldn't have acquired, eg if the RA says DHCP is not to be done but the DHCP server has already replied.  Plus, we need the RA to figure out M vs. O flags so that we don't acquire an address lease when we're not supposed to.

I was really hoping that we could get rid of the DHCPv6-only option, but maybe we can't now?

> 3) Rename IPv6 'link-local' method to 'disabled' as NetworkManager doesn't
> interface with the link-local methods at all. That way 'disabled' would mean to
> still zero accept_ra but not perform userspace router discovery.

Tentatively agree, though there is one complication.  NM treats "disabled" as ignoring all IPv6 connectivity on the interface, which means that NM won't run through IPv6 activation stages (which isn't really a problem) but it also won't show the address in the D-Bus interface either, which NM really should do.

However, if we are split the options apart like suggested below, then we don't need to do any renaming for the 'method' property in the setting right?

> *** The result ***
> 
> IPv4+IPv6 methods:
> 
> * disabled: like manual but with no addresses

But with #3 above, doesn't 'disabled' mean the kernel will still do IPv6LL?  To really have no addresses here, NM would have to disable_ipv6 in /proc for the interface.

> * manual: don't perform any automatic configuration (kernel will do IPv6LL)

Yes.

> * auto: perform standard automatic configuration (DHCPv4, RD+DHCPv6)

Yes.

> * shared: like manual + serve RA, DHCP and DNS

Yes; though currently the private address cannot be modified; I did have some patches a while back to change that to be configurable but they never got tested and finished on BE arches (see dcbw/shared-ip).

> IPv4-only methods:
> 
> * link-local: a special method for link-local IPv4 sharing, should only be
> enabled on one interface to work properly

Actually not true, any and all interfaces can have IPv4LL addresses, it's a class B and avahi-autoipd takes care of DAD for us.

> IPv6-only methods:
> 
> N/A
> 
> *** Further suggestions ***
> 
> The 'disabled' and 'manual' methods could be merged as the key difference
> between them is only the number of address records (zero for disabled, non-zero
> for manual).

Right; but in the case of the user wanting no IPv6 addressing on the interface at all (even link-local) what do we do? (see below)

> The 'link-local' IPv4 method should be decoupled into a separate option as IPv4
> link local configuration doesn't technically or logically exclude any of the
> other methods.

Correct, though typically the IPv4LL address is only assigned to interfaces that don't have any other IPv4 address.  eg on Mac OS X and Windows, you only have an IPv4LL address assigned when the system cannot find a DHCP server or when there is no static IP defined for the interface.

So in practice, it's always mutually exclusive with manual/automatic configuration, but technically there's no reason you couldn't have both an IPv4LL address and normal static/dhcp/etc addresses at the same time.

Note that we periodically get requests for IPv4LL "fallback" too, such that if the DHCP server cannot be found, NM would assign an IPv4LL address to the interface.  This is what both Windows and Mac OS X do, but they don't have any concept of "connections" and AFAIK, you cannot have one WiFi SSID be static and another be DHCP like NM allows.

> When the two above are done, we only have 'disabled/manual', 'auto' and
> 'shared'. While 'auto' and 'shared' *are* exclusive (in that running dhcp
> server and client on the same interface is bad), they aren't really the same
> class of options and should be decoupled:
> 
> method=disabled/manual -> auto=off, shared=off
> method=auto -> auto=on, shared=off
> method=shared -> auto=off, shared=on
> 
> (auto=on, shared=on combination would remain INVALID)

Without addressing this yet, I think a few questions remain, which I've asked above but I'll summarize here:

1) Given that DHCPv6 will apparently be able to supply the default router or prefix in the future, can we really remove the "DHCPv6-only" option?  If so, and we bundle it into "auto", how do we handle cases where the user may want to ignore RAs in preference to DHCPv6?

2) If a user really wants no IPv6 addressing on a specific interface (eg, really does not want IPv6LL) then how does this proposal express that?

3) We need backwards compatibility, so how does that get achieved?  I think this could be done by making the auto/shared/LL/etc booleans *ints*, where -1 = undefined, 0 = off, 1 = on.  If any of these are valid (eg, not -1) then the split options are used instead.  For older clients reading the connection, the 'method' could be synthesized from the split options I think.

(In reply to comment #4)
> Yes.  This gets a bit tricky though when implementing the "no touching" stuff.

From my point of view the "no touching" policy is of highest priority. That would mean it's the only exception to the rule of always setting accept_ra=0.

> 1) leave accept_ra=1, read the existing addressing and routing configuration
> but don't touch the interface until the administrator tells NM to do something.

+1 

>  This means we don't get any DNS information

1b) Use libndp (and DHCP info query) to get DNS information

Nothing prevents us from using libndp (and dhclient) with any value of accept_ra. Router Discovery doesn't even have side effects like DHCP, as we're only picking up information (RA, stateless DHCP), not starting a contract (DHCP lease).

1c) Use an external tool to keep the DNS information (e.g. unbound, bug #699810)

1d) Use filesystem to store and retrieve the DNS information (works only between NetworkManager instances or compatible software)

> 2) change accept_ra=0 and use libndp

-1

Ignores the "no-touching" policy.

> here we get all the DNS and other
> information, but we obviously touch the device

As we do with #1b.

> > * shared: like manual + serve RA, DHCP and DNS
> 
> Yes; though currently the private address cannot be modified; I did have some
> patches a while back to change that to be configurable but they never got
> tested and finished on BE arches (see dcbw/shared-ip).

We should finish your patches + keep the feature that if no address is specified, NM adds a default one.

> > IPv4-only methods:
> > 
> > * link-local: a special method for link-local IPv4 sharing, should only be
> > enabled on one interface to work properly
> 
> Actually not true, any and all interfaces can have IPv4LL addresses, it's a
> class B and avahi-autoipd takes care of DAD for us.

glibc's sockaddr_in doesn't have a sin_scope_id attribute, unfortunately. Are you aware of any way to route properly to multiple interfaces with the IPv4LL prefix?

> 1) Given that DHCPv6 will apparently be able to supply the default router or
> prefix in the future, can we really remove the "DHCPv6-only" option?  If so,
> and we bundle it into "auto", how do we handle cases where the user may want to
> ignore RAs in preference to DHCPv6?

We could use something like:

[ipv6]
auto = disabled|enabled (default enabled)
dhcp = disabled|enabled|standalone (default yes)

See the following mapping:

method=auto ~ auto=enabled,dhcp=enabled
method=dhcp-only ~ auto=enabled,dhcp=standalone

For 'auto=disabled' the other options would be irrelevant. For 'auto=enabled,dhcp=disabled', only router advertisements would be allowed.

> 2) If a user really wants no IPv6 addressing on a specific interface (eg,
> really does not want IPv6LL) then how does this proposal express that?

We could use this:

[ipv6]
link_local = undefined|disabled|enabled (default undefined)

(optional 'undefined' would mean disabled/enabled based on the value of interface-specific sysctl 'disable_ipv6')

Mapping:

method=disabled ~ link_local=disabled
method=* ~ link_local=enabled

[ipv4]
link_local = disabled|enabled|fallback (default disabled)

Mapping:

method=link_local ~ link_local=enabled
method=* ~ link_local=disabled

Where IPv4 'disabled' would match current non-link-local methods, 'fallback' would be the requested feature and 'enabled/always' would mean use IPv4 link-local from the beginning (in parallel with any other configuration).

> 3) We need backwards compatibility, so how does that get achieved?  I think
> this could be done by making the auto/shared/LL/etc booleans *ints*, where -1 =
> undefined, 0 = off, 1 = on.

I'm OK with using integer values as well as using -1 for undefined. Values from 0 upwards can be used for the actual options.

I would also avoid true booleans just in case any of the options needs to be extended in the future. An example of value that I didn't expect in advance is ipv4.link-local=fallback:

[ipv4]
link-local = undefined(-1)|disabled(0)|enabled(1)|fallback(2)

> If any of these are valid (eg, not -1) then the
> split options are used instead.  For older clients reading the connection, the
> 'method' could be synthesized from the split options I think.

+1 for synthesizing the 'method' for old clients (and letting them set the method to get expected behavior).

For link-local IPv6, see also:

https://bugzilla.gnome.org/show_bug.cgi?id=707155#c1

So... This has grown over the size that's suitable for a bugzilla comment ping-pong. I've started a page with a more thorough description and analysis:

https://fedoraproject.org/wiki/Networking/Ideas/NetworkManagerMethods

Looking forward to your feedback.

Just realized that even the good old ifcfg's BOOTPROTO=none works more or less as method=disabled and method=manual merged into one option.

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/reader.c#n1312

Proposing to be considered for 1.2.

bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).