Preparations to join the CRXN network

To join the CRXN network, three things are basically required:

Prior knowledge

For this blog post, I assume the following prior knowledge:

Patience and motivation

IP routing can be very difficult. On the one hand, there are sometimes quite heavy concepts behind it - on the other hand, the practical implementation is often associated with problems. Therefore it can happen that some give up. One should therefore consider in advance whether one really wants to join the network.

A device

Furthermore, you need a device that has access to the Internet / Clearnet and preferably runs 24/7. For example, an old computer that you still have standing around (attention: power consumption) or a single-board computer such as a Pi. The device should be connected to the Internet via cable. With WiFi / WLAN it can lead to slower speeds and high latencies. Alternatively, you can rent a virtual machine online. You can see my providers at A small virtual machine with one CPU core and one gigabyte of memory is usually sufficient. If you rent a VM, you should make sure that it is a VM and not a container. With virtual machines, you install a kernel yourself and can precisely control the routing and kernel parameters accordingly. A container shares the kernel with the host and also “inherits” the settings and modules. For example, if the host does not have a WireGuard module, WireGuard cannot be used in the container without a detour. Containers are often advertised as “LXC”, “Docker” or “OpenVZ”. Virtual machines, on the other hand, with “KVM”, “WMware” and “Hyper-V”.

You can now install an operating system on this machine. In general, no Windows and no Apple will work.

General it is not relevant if you have the device with IPv4, IPv6 or both. Because over the Internet only the connection to other CRXN members will be established. In CRXN itself only IPv6 is used.

The registration

To participate in the CRXN network you need an entity in the EntityDB short edb. This can be found on Codeberg. To register, you can “fork” this. In the fork you create a new JSON file with the name <entity>.json. Replace <entity> with a name. This can be for example a nickname. You can use the following as an example:

  "person": {
    "name": "Marek Küthe",
    "email": "",
    "gpg": "9AA28159FCEB3CD83BC212017E869146699108C7"
  "route": {
    "fd92:58b6:2b2::/48": {
      "description": "Bandura Communications",
      "max-len": "48",
      "device": {
        "fd92:58b6:2b2::1": {
          "type": "router",
          "description": "My first router"

An indentation of two spaces is used. The information under people is optional. If you don’t want to enter any information, you can omit the people part. You can also use other attributes in the people part. For example, I put my name, my e-mail address and the fingerprint of my GPG key there.

Under route you enter the relevant information. The following rules apply:

For me the prefix would be fd92:58b6:2b2::/48. You can use a random prefix from the ULA range fd00::/8. For example, on one can have ULA prefixes generated. One can optionally specify a description. If you give one, it must be at least one character long and (currently) at most 2048 characters long.

You do not have to specify max-len. However, I strongly recommend it. Later, if you have more than one device that is doing routing on the CRXN network, you don’t have to request a new prefix for each device, but can split your prefix into small pieces - for example /56 or /60. max-len specifies the length of the smallest prefix. The minimum is 64. If you do not specify max-len, you may be vulnerable to route hjacking. More information about this can be found at - max-len filter.

device must specify at least one (optimally reachable) device. A distinction is made between generic, router or server. If the type is omitted, generic is assumed. The description is voluntary. Normally a network has at least one device - the router. This is often assigned the address xxxx::1. However, you can give the router any other address from your prefix.

After creating the JSON file, you can validate the JSON. For example, you can use jq or JSONLint. After that you can check the attributes using the schema file schema.json. For this you can use a tool like check-jsonschema (Python): check-jsonschema --schemafile schema.json <entity>.json.

After that you can create a pull request. Normally an EntityDB administrator will check the request within a week and merge it. After that you are registered.

If you are inactive for a longer time, the network is not reachable and the entity contact is not reachable either, it can happen that the entity is deleted in EntityDB.


There can always be places where you don’t know what to do. In this case you can ask other members of the CRXN network. You can find them on Matrix in the room