I'm not sure about the specifics for your network, but if you want to set up a similar network using WireGuard as the tunnel, you'd have to set up each peering arrangement manually. (Similar to: https://blog.bella.network/internal-bgp-with-wireguard/) This means adding a new node to your network will require you to create new key pairs, add new interfaces to existing nodes (that you want to peer with), and configure your routing daemon.

This may in fact be desirable to many, as it gives them more control over what happens in their network. I'm sure there might be tools to automate that process, but nylon takes a different approach.

Nylon implements babel at the level of WireGuard, offering:

Simplicity.

- Nylon bypasses the requirement for needing a new WireGuard interface on each end of a peering pair. (Peering arrangements are defined as WireGuard endpoints on a graph, instead of interfaces). This also means there will only be a single nylon interface, and all of the routing logic is hidden away from the user.

- Adding a new node on nylon is pretty trivial. You would set up the node with a private key, put the public key in the central config, and declare the peering on that config. Then, you can use the built-in config distribution mechanism to push it to all of your nodes.

- Both the control packets (for routing) and data packets (IP) are also sent encrypted in the same WireGuard tunnel, so you would only have to expose the bare minimum to the public.

Usability.

- Nylon is more portable, as it does not depend on your system's routing table, routing daemon or special kernel features such as network namespaces. Therefore, we can support Linux, macOS and Windows (pretty much any platform that wireguard-go supports).

- As it's built as an extension into the WireGuard protocol, it remains backwards compatible. There is even special handling, which allows "vanilla" wg devices to roam freely between configured nylon nodes. (Nylon will re-advertise the new "gateway" node and expire routes accordingly)

Currently, there is no special handling for the default route, meaning that if you were to advertise 0.0.0.0/0, there might be a loop. Personally, I never tried it, but I don't think it would work. Do you know of a workaround?

When I get some time, I will try to improve docs a little bit, maybe add a setup script, and docker image like you suggested :)