From: Ariadne Conill <ariadne@dereferenced.org>
To: ~alpine/devel@lists.alpinelinux.org
Subject: Proposed system change: ifupdown-ng as default network device manager
Date: Tue, 28 Jul 2020 09:36:13 -0600
Message-ID: <12372156.q0HFhEdf7Z@localhost>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

Hello,

At present, Alpine uses BusyBox ifupdown as default network device manager, 
and a few additional 'addon' packages which provide additional scripts that 
interact with ifupdown.

We additionally provide Debian ifupdown and, more recently, ifupdown-ng as 
alternatives.

This has gotten us very far over the past decade.  However, in many 
situations, ifupdown is quite limited, such as in dual-stack scenarios and 
complex configurations where virtual devices depend on parent devices to be 
brought up first.

## What is ifupdown-ng?

ifupdown-ng is a lightweight network device manager that is backwards 
compatible with Debian ifupdown and busybox ifupdown.  Unlike other 
implementations, it uses a dependency solver to determine the interface bring-
up and take-down order.  This allows for the user to significantly simplify 
their network configuration.

Finally, ifupdown-ng allows for an interface to have multiple addresses 
associated with it in a simple way.  For example, we can use the /e/n/i file 
from my main server:

   auto br0
   iface br0
        use bridge
        requires bond0
        address 172.93.5.34/28
        address 10.150.241.1/24
        gateway 172.93.5.33

   iface bond0
        use bond
        requires eth0 eth1
        bond-mode 802.3ad
        bond-xmit-hash-policy layer2+3

The equivalent in traditional ifupdown is almost twice as long, as every 
detail has to be explicitly spelled out, while ifupdown-ng can figure out the 
necessary details by using the dependency solver.

Another benefit to ifupdown-ng is the executor concept.  With the current addon 
scripts, they automatically run for every interface at bring-up and take-down.  
This means that a misconfiguration may result in the addon script doing 
something to an interface that was not intended.  By contrast, if you use 
ifupdown-ng's executors, they will only run when explicitly requested with a 
use statement.

ifupdown-ng is 100% backwards compatible with ifupdown, and can even 
automatically convert an /e/n/i file to use the new syntax with the new 
ifquery(8) utility, but that's optional.

## Benefits to Alpine

* The networking initscript can start interfaces more intelligently by 
leveraging ifquery(8).  Right now this is achieved by attempting to parse the 
/e/n/i file with awk.  Instead, we can change networking initscript to bring 
interfaces up in order according to the dependency tree.

* Configuration of IPv4+IPv6 dual-stack environment is simplified, as you can 
just specify a dual-stack configuration.  Right now to use dual-stack, you have 
to either use up/down statements or use Debian ifupdown which is still limited 
to configuring a single address.

* Future plans for ifupdown-ng include hotplug support, wifi configuration, 
openrc integration, etc.  Early adoption of ifupdown-ng as default network 
device manager allows for streamlined adoption of these later features.

* If ifupdown is dropped from BusyBox, the difference in install size 
requirement is only 8KB.

## Testing

ifupdown-ng is available in edge right now, in the testing repository.  Simply 
do `apk add ifupdown-ng`.

## Contingency Plan

If ifupdown-ng has release-critical problems, we will simply revert the change 
and continue using BusyBox ifupdown as default, with ifupdown-ng as an 
optional package and revisit this in a future release cycle.

## Timeline

I would like to flip the default sometime in September, before feature freeze, 
but allowing users enough time to test and validate ifupdown-ng with their 
setups.

Ariadne