New upstream version 1.47.90 upstream/1.47.90

1 files changed, 59 insertions, 0 deletions

diff --git a/src/core/README.next.ip-config.md b/src/core/README.next.ip-config.md
new file mode 100644
index 00000000..e5be74f1
--- /dev/null
+++ b/src/core/README.next.ip-config.md
@@ -0,0 +1,59 @@
+Rework `NMIP[46]Config` for `next` branch
+=========================================
+
+The `next` branch is a large rework of internals, how IP configuration is done by `NMDevice`.
+
+Previously, there are two `GObject`s named `NMIP4Config` and `NMIP6Config`. These
+serve different purposes:
+
+1) They are data containers that can track IP configuration. As such, `NMDevice`
+   and various parts (like `NMDhcpClient`) create them, pass them around and
+   mutate/merge them to track the IP configuration.
+
+2) They are also subclasses of `NMDBusObject` and exported on D-Bus as
+   `/org/freedesktop/NetworkManager/IP4Config/1`, etc. As such, see their
+   [D-Bus API](../../introspection/org.freedesktop.NetworkManager.IP4Config.xml)
+   (and [for IPv6](../../introspection/org.freedesktop.NetworkManager.IP6Config.xml)).
+
+`next` branch will replace use 1) with `NML3ConfigData`. `NML3ConfigData` are immutable
+(sealable) data containers with little logic. This leaves `NMIP4Config` to only
+implement 2).
+
+This needs to be reworked.
+
+* Now `NMIP4Config` and `NMIP6Config` are subclasses of `NMIPConfig`. The goal
+  is to treat IPv4/IPv6 similar and generically. Probably there should be very
+  little code in the subclasses left and most should move to the parent classes.
+  We still need separate GObject types though, because that is how `NMDBusObject`'s
+  glue code can handle different D-Bus paths.
+
+* Now `NML3Cfg` is a handle for the IP configuration parameters of a device (ifindex).
+  As `NMIPConfig` mostly is about exporting the current IP configuration, it probably
+  can get most of it from there (and by listening to signals to that).
+
+* Note that `NMDevice`, `NMActiveConnection` refer `NMIP[46]Config`s, and most
+  importantly, the respective D-Bus objects refer to them. As `NMVpnConnection`
+  (and "org.freedesktop.NetworkManager.VPN.Connection" interface) are modeled
+  as "subclasses" of `NMActiveConnection`, they also have one. That means,
+  it's not entirely clear what these properties even are. For example, currently,
+  `NMDevice` does a (terrible) dance of tracking external `NMIP[46]Config` objects,
+  merging, intersecting and subtracting them with other `NMIP4Config` objects
+  to get the merged one, which is then exported on D-Bus. That merged object
+  does therefore not directly expose the IP addresses that are actually
+  configured on the interface (`ip addr`), but more what NetworkManager
+  wanted to configure and the (terrible) feedback loop where the platform
+  addresses get synced. With `next` branch and `NML3Cfg` there is a clear distinction
+  between what NetworkManager wants to configure vs. what is actually configured.
+  I think for `NMDevice` and `NMActiveConnection`, the IP addresses on
+  "org.freedesktop.NetworkManager.IP4Config" should expose the IP addresses
+  that are actually in platform (`ip addr`). If there is a need to expose
+  additional information (like things that NetworkManager wanted to configure),
+  then this should be different/new API.
+  On the other hand, currently `NMVpnConnection`'s `NMIP4Config` only tracks the 
+  IP addresses that come from the VPN plugin. So it's much more what it wants
+  to configure (from the VPN plugin), and not at all about what is configured
+  on the interface.
+  I think that needs to change. A `NMIPConfig` object on D-Bus exposes IP configuration
+  information about an netdev interface. Period. That also means that a `NMVpnConnection`
+  (which currently is like a active connection associated with the device) links to
+  the same `NMIPConfig` object as the underlying device.