DaAPI is a mondern DHCPv6 server developed with the needs of small ISP in mind
DaAPI is a modern, cross-platform, web-based DHCPv6 (DHCPv4 is in the roadmap) server designed with the need of ISP in mind.
It enabled you to assign IPv6 addresses and networks to your customers dynamically. Unlike many other solutions, there is no need (and possibility) to write a config file - and learning all the possible syntax.
The integrated HTTP REST API lets you integrate DaAPI in your existing workflow seamlessly.
I worked on a technical lead/consulting job for small ISPs - ISPs in the classical sense of offering access to the public internet. Most devices from various vendors have excellent support for DHCPv4. They are offering server capabilities with a lot of configurational freedom. However, compared to that, the DHCPv6 capabilities are fundamental and limited. This situation created a need for a dedicated piece of software. After a bit of research and a lot of testing, none of the existing solutions seemed like a viable solution.
Sometimes, other solutions were not cross-platform. The config file could become very messy if you need to administrate thousands of customers. They had limited support for prefix delegation. Overall, it seems that this project hasn’t the needs of small ISPs in mind, where extensibility and integration (Syslog, SNMP, etc.) is an essential factor to consider.
Another - and this point is fundamental - aspect of other existing solutions is not easy to use and understand. Of course, some companies have a considerable customer base and can afford specialists in each part of a network: Engineering knowing all the bits about every protocol. Yet, there are smaller ones too, and they need a solution that is easily understood and delivers results quickly.
Long story short: DaAPI is my approach to solving these explained issues.
Currently, DaAPI is in its very, very early stage. I like to call this stage proof of concept. One ISP is running a field test with DaAPI to validate the ideas.
In this stage, DaAPI has a lack of maturity, and use it only in the context of experimental nature. However, I invite you to give DaAPI - even in its early stage, with many limitations - a try. Conclude for yourself if it solves one of your problems, too. Share your thoughts and help to make DaAPI more useful for others.
The next release is titled “Making DaAPI useful.” Besides the ongoing focus on stability, the goal is to leverage the possibility and uniqueness of DaAPI by developing the ecosystem around it. Client applications will be able to use the API endpoints. DaAPI will send logs to Syslog servers. Moreover, to improve the log system radically is a high priority task, too. As well as authenticate users via RADIUS. The notification engine will have more triggers, conditions, and more generic actors like executing scripts and webhooks.
From the infrastructure point of view, the goal is to make DaAPI easier to integrate into existing systems by various steps. You can choose between different databases technologies, DaAPI will be available as a docker container, and the repo will include binaries files for a more painless installation process.
For now, the only way to get DaAPI is to compile it by yourself. After compilation, you can copy the result to any machine or just run it on your compiling machine.
DaAPI is a .NET Core application. For building the application, you need the .NET Core 3.1 SDK. You can find detailed steps here.
For front-end assets to compile, you need node and npm. You can find detailed steps here.
A Git client needs to be installed too. Here, you can find the official documentation and how to accomplish it.
git clone https://github.com/just-the-benno/DaAPI.gitcd ../daapi/src/DaAPI.Hostdotnet run --urls "https://localhost:5001;http://localhost:5002"
Because DaAPI uses well-known ports, under Linux, the user running the process needs to have the right to open such ports.
DaAPI is a .NET Core application. For building the application, you need the .NET Core 3.1 SDK. You can find detailed steps here.
For front-end assets to compile, you need node and npm. You can find detailed steps here.
A Git client needs to be installed too. Here, you can find the official documentation and how to accomplish it.
git clone https://github.com/just-the-benno/DaAPI.gitdotnet publish ./daapi/src/DaAPI.Host/DaAPI.Host.csproj -c release -o ./publish
The result is a folder publish with all needed files to run DaAPI. Copy his folder onto the running machine.
If you want to avoid installing the runtime on the running machine, you can include the runtime in the publishing process. You need to add the -r parameter with an Runtime Identifer like -r linux-arm
If you want to run a compiled binary, the .NET Core Runtime is enough. Here, you can find the official documentation.
Copy the files from the step before into a folder and run
dotnet .\DaAPI.Host.dll --urls "https://localhost:5001;http://localhost:5002"
Because DaAPI uses well-known ports, under Linux, the user running the process needs to have the right to do so. Windows will prompt a dialog, asking to create firewall rules.
The examples above assume you are running and managing DaAPI on the same machines. Hence, using the localhost is the right choice. If you want to have different ports or different URLs, this page in the wiki describes what else needs to change accordingly.
DaAPI will occupy, despite the DHCPv6 ports, two ports: 5001 and 5002. The web application uses port 5001, and HTTPS is mandatory. DaAPI will use a self-signed certificate. The second port is technically a workaround for certificate issues. The second port 5002, is only used by DaAPI itself to communicate with the authentication service, living “inside” of DaAPI. The wiki page “OpenId Interaction” elaborates on this issue in more detail.
You can open a browser and access DaAPI via https://localhost:5001 (or any other URL you have chosen). The first step is to create a local user. (This part is not essential if you are using an external OpenId system.)
After you create the user, the page refreshes, and you need to use the credentials to log in to the system. After a successful login, you are redirected to an empty dashboard.
By default, DaAPI is not listening to any interface unless explicitly to said so. You can choose the interface point in the menu and select the interfaces used by DaAPI. If you have multiple interfaces, a name can be an excellent hint to identify it. Besides, the name will be displayed in logs and analysis later.
DaAPI has a unique concept of “Scopes“ and “Hierarchy of Scopes.” Scopes can be created in a hierarchy, allowing child scopes to inheritance properties from parent Scopes. The concept is explained in detail in the documentation, and you should be familiar with the ideas to unleash the potential of DaAPI.
For now, we focus on creating the first Scope. Choose Scope on the menu, and after that, the »Create« button. Give your Scope a name and move on to the next card with the start and end address. You can choose any start and end range. You can even select the same address for both values if you want to assign always the same address. Feel free to type in any valid IPv6 address you like. You can see there is a lot more configuration possible, which is explained in the documentation. As a reminder, you can use the infoboxes. You don’t need to change anything for now.
The section »Properties« is for all the additional options like the DNS server. To create a Scope, you don’t need to have any of these options.
The section »Resolver« is a specialty of DaAPI. In a nutshell: A resolver is like a matchmaker, finding the best match between an incoming packet and a Scope. A very generic match can be a relay agent address. But there are also very picky ones. Please have a look at the documentation to find out more about each of them.
There is also an example of how you can quickly write your own. You can also create an issue and describe what type of resolvers you need and what kind of packets should match.
After you entered a valid IPv6 address for your relay agent, you can create your first Scope. All you need now is to have at least one client requesting an IPv6 address and observe either the Dashboard or the Scope Details. (Unfortunately, there is no auto-update capability yet, so you have to reload the page to see updated data).
The documentation has an article about how to create a complex scope hierarchy and a corresponding resolver structure. The real power of DaAPI. :)
This page is an overview. Check out the documentation for articles and an in-depth cover of certain aspects of DaAPI.
If you have any issues using DaAPI, create an issue. Usually, I’ll reply within a couple of hours.
Every contribution is highly and honestly appreciated. I’d love to see a vibrant community around this project, and there is so much that can be done!
You can use the issue tracker for any concerns, corrections, or feedback.
Everyone using DaAPI is, in my view, a technical contributor. Point to errors or misunderstanding by filling out an issue. Request new features, give feedback, explain your use case, and shape this product to become more and more useful.
I’m still on the learning curve to master English. There is no doubt that the localization and documentation can be significantly improved from correctness and clarity. Or you want to add another language.
For developers, there is a section in the documentation explaining the architectures and thoughts behind it. It should speed up the understanding process. As a reference to understand the “business logic,” RFC8415 is an excellent starting point.
DaAPI can be used under the MIT license.
I want to say thanks to all project authors and contributors that I used to build DaAPI. All these libraries make life so much easier. Thanks, I sincerely appreciate your work and endurance.
(The list is not completed nor a ranking)