Hi, I'm Tom, this is David, we work for Red Hat, and we're going to talk today about a new project called NetTools, which is a collection of libraries that implement network configuration discovery.

So our focus with this project is to create a suite of low-level libraries that implement various standards for network configuration, such as DHCP and related things. So we are not trying to do a full networking configuration solution, so we're not going to configure IP addresses and so on, but we want to discover the network configuration

that should be applied to your machine. So this should be a low-level library that should be integrated into a bigger network configuration solution, such as NetworkManager, NetworkD, and so on. We don't really invent anything new here. These standards we are implementing are old, from the 80s or whatever, and we just want

to have the lowest possible abstraction above it in C, so that you can work with them easily. So it's not about making any heuristics or any policy decisions at all, just a low-level

library. So the protocols we are implementing are old, and the existing solution for them are also old. So we have ...

Let me start that sentence again. So we are implementing old protocols, and the existing tools typically were made a long

time ago when the world was a very different place. We have stuff like DHCP CD, we have DH client, and so on, and these are typically black-box solutions. So you tell the DHCP CD to do DHCP on a certain link, and it does everything for you.

You start it, it runs, configures your link, sets up networking, and that's it. So you just have an on-off button, and that's all. You cannot interact with it in any other way. And that made sense back in the day, when you had a static machine where your network card existed at boot and it stayed the whole time, and you were just doing the standard thing. You wanted one IP address, and that's it.

But these days, DHCP and other protocols are used in, firstly, more dynamic situations, where things are coming and going, and you have more than one device, and you have all sorts of different things, and you have also newer technologies that want to use the same protocols, such as Wi-Fi direct, IP over Bluetooth, and so on.

So they're using the same protocols, but in slightly different ways. So it doesn't really work anymore to take the existing black-box solutions where there are lots of assumptions built in on top of the protocols, and apply them in new settings. You really need to just work with the protocol itself so you can tweak it to whatever use case that you have. So what ended up happening is that lots of network configuration tools, such as Conman,

Lucie, NetworkD, and so on, they would bundle their own implementations as libraries inside of them of the different protocols. And because they needed more access to what was going on, then some sort of black-box

would allow that. And we worked on that as well, and SystemD is part of NetworkD, we did DHCP and other protocols, and we got requests from people saying, wouldn't it be nice if you could pull out this stuff from SystemD, or at least expose the APIs from SystemD so that all the people could also be using the same protocols.

Which basically is what this project is all about. It's about making a publicly reusable API for network configuration. Though it's not as simple as simply taking the library that exists already in SystemD and exposing it to the outside. It suffers from the same thing as all the black-box solutions did, that it comes

with all the assumptions that we could make because we knew the setting was being used. It was used in NetworkD, so whatever assumptions were made because we knew how NetworkD works was inside the library. So we wanted to make some libraries that didn't have any assumptions on top of the basic protocols. So we are not just taking out the libraries that exist, but we are sort of reworking

the APIs quite a lot, and reworking out some of the code. So as Tom already mentioned, and I want to show this with one example.

We have a library called NACD, which is part of the NetTools project, and it implements

IPv4 address conflict detection. You might not have heard of it. The RFC that defines it is basically technology to detect on a local network whether anybody else on the network uses the same IP address as you do. This is useful to debug network interfaces to see if something is going wrong on your

network. Maybe the problem is that other people use the same IP address. It was used in that way for a long time, but there are several different more modern use cases where NACD is also used, where ACD in general is also used.

And when we developed NACD, we had to keep all of these in mind, and it's not sufficient anymore to just have one black box that works in one of these situations, but we wanted to open it up. So we wanted to open up that black box and give you access to some more details of the protocol. For instance, for NACD, it can be used in three common example scenarios.

You might be on a network where you have a static IP address. You selected it, you want to use it, you use it on the network. Of course you want to make sure that nobody else uses the same IP address, because if they do, you have all kinds of different routing issues and packet loss and so on on your network, and you want to make sure that you at least detect that kind of situation.

But of course in an automatic way you cannot react to it. You cannot say, okay, if that IP address is not there, pick another one, because you explicitly said you wanted a static IP address. So NACD needs to be suited for that use case. It needs to be able to deal with that. But there's also a different scenario.

You might run DHCP, which is probably the most common option, and you get a lease from the server. So you get assigned an IP address. If you detect that there is a conflict, you need to, like even the DHCP RFC mandates that you need to treat this as a hard conflict, and you should decline the lease, reject the lease, and request a new one. So it's a completely different reaction you have to the conflict detection.

And the third use case is, for instance, quite recent RFC, it's IPv4 link local address configuration. It's a way which was copied over from IPv6. It allows you to get an IP address on a local link, so on a local network, without configuring

anything. And it uses exactly this as the core technology, because it just picks, based on a heuristic, a random address, and uses conflict detection to see whether anybody else on the network uses that address as well. And if you do, it just picks the next one. So ACD is a quite crucial part of one of these protocols, and it's expected that you

get conflicts, at least on bigger networks. In other parts, it's really just used to have better diagnostics, for instance, if you have a static IP address. And we need to keep all of these situations in mind when we develop these libraries, and this is also why we make these libraries that can be deployed in all of these use

cases. So one of our crucial rules is to open up the black boxes, to not say there's a black box, there's one button, use it. But we say, we explain how ACD works, we give you access to the API. You can use it as a black box, you can just say, run on this thing, tell me when there's a conflict. But you can also interact with it, you can react to the different events you get and

so on. Moreover, we don't only want to make sure that our APIs work in all of the different kinds of use cases, as the ones that David spoke about, but we also want to make sure that you can integrate the library that we're writing in any sort of other software.

We don't want to commit to some sort of specific library that you need to use, some sort of event loop or whatever else. So you should be able to, whether you're using Network Manager with GLib, or if you're using Network D with STEvent, or anything else, we want the library to still work,

or to integrate nicely. So basically there should be no reason to use anything else, basically that's one of our aims. So the way that we are doing that naturally is that we are making things not depend on any external event loop, just using the kernel EPOL-FT API directly, and making things as

low level as possible so you can integrate it nicely wherever you want. So far it's worth mentioning that the NACD library that David spoke about has been integrated into Network Manager, and it will be part of the next release as far as I know,

if it's not already. And we are of course keeping in mind Network D, which is what we worked on before, so we want to integrate it there as well in the future. We have, in the case of NACD, we have integrated into also our own library, so this is just not using any external library, no event loop library, this is just a small

wrapper on top of NACD. So IPv4 link local, as David mentioned, is a way of just picking for yourself an IP address without any external configuration at all. And this relies crucially on NACD, and this is where ACD first originated.

So the idea is basically the library in IPv4 link local will grab an address at random, do ACD on it, if it turns out to be already in use, it tries another one until it finds one that works, and it will give it to you. So this shows that we can integrate our own libraries easily into each other.

And lastly, I guess all of that is sort of expected and straightforward, but lastly we also had one last use case in mind, and that was the one nice thing we had about the old tools, the black boxes, we just fork off a binary to do whatever setup we wanted, because you've got some sort of isolation. And when you're doing networking, that's typically a good thing.

You want to be able to have your network facing binaries, processes, not in the same address space as everything else. And if you're just using a library, you sort of lose that, because now the library context will be part of network manager, and if it's an exploit in the DHCP library,

suddenly you've exploited all the network manager, or stuff like that. So in order to still get back the isolation that the black boxes allowed, keep in mind that we want all our APIs to be designed so that they could easily, naturally be exposed over IPC. So we want to, at least in principle, you should be able to just make a binary

out of the API we have, and expose exactly the same, sorry, make a binary out of the library we have, and expose exactly the same API over VAR link, or D-Bus, or any other sort of IPC protocol. And then on the remote side, the API should work basically the same,

whether you use it remotely or in process. So that basically means that our APIs are designed to be asynchronous, so that you can basically present message passing, even if it's running in the same process. So if we talk about, whether we're trying to have universal APIs that we

try to open up the black boxes, give direct access to the underneath part. So the question really becomes, what do we provide? Like, does that mean you have to understand all the underlying RCs to make the use of that? And this is where our last part of this talk comes in.

The things we do provide is that we try to integrate all these RCs with Linux and how Linux works today. A lot of the protocols were implemented or developed in the 80s, in the 90s, and implemented back then. And there were completely different constraints and different assumptions that people placed. And they were right back in the time, but they might no longer apply today.

So we took this opportunity, when we rewrote most of the things or extracted them, to look how these things apply today and whether they are new technologies we can use. And all of our libraries, we made sure that they use Linux, modern Linux kernel features at least, in the best possible way.

And I want to explain it with one example, which is the DHCP4 library, which is also part of the NetTools project. It's probably the most common protocol that we talk about today, the dynamic host configuration protocol. There was one, like when we implemented it back in System D.

After it was implemented, we got a report from somebody who deployed it on their production system. And he told us he got a 30% increase of overall network performance. And we were surprised because, I mean, why does it matter how you configure your network that you get an overall performance increase on

all packets sent over the network? And as it turned out, of course, DHCP runs the entire time during your, while the network's up, because it needs to react when a lease expires and the release is revoked and so on. And it turned out that if you use kernel packet sockets,

even if you filter on them, the filters are actually quite slow compared to when you don't do that. And what we made sure in our library, without knowing that this might even turn out as an issue, is that we always use, for instance, the appropriate or most high-level feature the kernel gives us.

So we only use packet socket, which is a low-level kernel interface to get all kind of packets when it's really required. But as soon as your CPU gives us an IP, we try to use the UDP stack. And there, the kernel has quite sufficient filtering mechanisms that this kind of problems don't apply.

And this is one of the examples where we try to use, try to adapt these old protocols to how Linux works today and try to make use of features like eBPF today of the specific sockets that were created for specific protocols in the kernel. And we spent quite a lot of time just reading how the kernel actually does specific things,

so to make sure we don't have phrase conditions there and so on. This makes us specific to Linux. This means we can no longer run on other systems, but at the same time, this gives us really a lot of benefits and makes it a lot easier to use these things. So, to summarize and to maybe give a future outlook,

the NetTools project, it doesn't invent any new protocols. It's like DHCP is not a revolution and, I mean, it existed before. What we tried to do is, we ourselves had spent several times being required to implement DHCP in different use cases because different use cases popped up and we were always annoyed by the fact

that it's so hard to adapt these protocols or these implementations to new use cases. So, what we try with NetTools is to be as close as possible to the RFC and not place any assumptions ourselves, so we don't want to restrict the user. At the same time, of course, it is a bit more difficult to use

because it's not just a button you press, but at the same time, you can use it in so many use cases and there are so many new situations where, for instance, DHCP these days pops up. We have a dynamic IP over Bluetooth where at any point in time, a new interface might pop up on your system and you need to configure DHCP.

There is the Wi-Fi peer-to-peer specification which allows you to create one-to-one connections between devices but requires DHCP to configure that, so you need to dynamically create a DHCP server and DHCP client just for one interaction. And we have all these use cases in mind when we try to create these libraries or we try to have all these use cases in mind.

And as a future outlook, there is a new specification written by the IETF called the HomeNet specification and what it does, it tries to summarize all the old protocols like DHCP, like ACD, also the related protocols for IPv6

and tries to define how a HomeNet, and with HomeNet they basically mean the network you have at a private home should look like and how the protocols should interact and what things to do and which things might no longer be relevant today. And they also have some new configuration protocols in there and we kind of want the Net2us project

to go into that direction, eventually be a full complete implementation of this specification. The last time I looked, the specification was still a draft but if anybody is interested, I really recommend looking at it. Yes, I think that is it. It is an overview of Net2us. If you have any questions, feel free to ask.

Hi. And the core implementation is in C or something? Yes. We started this project at C and we continued it so far

because most of our users are C users. In particular, we work with the network manager people to try to make sure they can use it at least and we never place any assumptions that wouldn't work with them. We didn't have any plans so far to change this. And one of the problems, like a lot of the things we do

are really low-level kind of APIs where we need to interact and the easiest way to do that is so far C might be no longer true for a long time, but so far we still make this all available as C libraries. And do you see it kind of spreading with other bindings or is it kind of the goal to keep it low-level? What we experimented with our SaaS

is trying to provide, as Tom described earlier, IPC APIs for the same libraries. And we have, for instance, experimental debug wrappers that we try to adapt to make sure we can expose all these APIs over DBaaS and you can fork off your own process

and use a private DBaaS connection to talk to that process and get the same APIs. Of course, other bindings are then possible as well. We have no stable guarantee so far for any of these experimental features except for the C API. Thank you.

So maybe a question for me. Can you show where this project lives, like on GitHub or somewhere, so that interesting people can have a look? Sorry. Ah, good. I thought that was the last slide. Yes. It's, right now it's on GitHub slash net tools. And the different projects are repositories there.

There's also a mailing list called Net Tools Devil at Google Groups where we have announcements whenever a new release is out and where we discuss. Welcome everybody to ask questions there or ask us how it could be integrated with different projects.

It's all in the read me's of the different projects as well. So thanks everyone. Give a round of applause at the third. Thanks a lot for the introduction.