DN42 Registry

Introduction

The DN42 registry is a git-based Network Information Center (NIC) registry, used to keep track of allocations taken by members (IP address space). It uses simple files to defined maintainers, address blocks, and more, and cryptographic signatures to ensure modifications can only be performed by authorized users.

Before proceeding, read the Getting Started instructions on the Wiki, including joining the mailing list.

Registry Authentication

Besides the normal SSH key authentication used to communicate with the Git server, commits to the registry should also be signed using a GPG or SSH key to prevent modifications by other users, accidental or otherwise. I chose to use an ED25519 SSH key, which is a slightly more involved process, but is equally secure. Begin by generating an SSH key, and make sure to back it up. It's possible to modify this key in the future if it's lost, but it's best not to.

Records

After creating an account on the DN42 Git site, wait 10 or more minutes, then clone the dn42/registry project. All new users are automatically added as collaborators, but this takes some time to take effect. Then, check out a new branch using the format <username>-<date>/<name>, where the username is your Gitea username, the date contains today's date in UTC in the format YYYYMMDD, and name is a decriptive name of the purpose of the branch (register for new members setting up the initial records). Once on the new branch, immediately push the branch upstream, as it must be added on the date in the branch name.

Note that all records should have the second column at exactly 20 characters into the line, padded with spaces from the property name. The script fmt-my-stuff will fix improperly indented fields. Also note that most objects support the option remarks field, to add comments to a record. See the data/schema/ directory to see the requirements for individual fields in an object.

Maintainer

The first object, which will be a part of every other registry object, is the maintainer object. Think of the maintainer object as the user account to log into the registry. In the data/mntner/ folder, create a new file called <name>-MNT, where the name is your chosen username for the DN42. Add the following contents.

mntner:             DHELLSTERN-MNT
admin-c:            DHELLSTERN-DN42
tech-c:             DHELLSTERN-DN42
mnt-by:             DHELLSTERN-MNT
abuse-mailbox:      dn42-abuse@daniel.hellstern.org
auth:               ssh-ed25519 <pubkey> <comment>
source:             DN42

The admin-c (for Admin Contact) and tech-c (for Tech Contact) will point to a person object created in the next step, containing contact information for this maintainer. mnt-by indicates that the current object is maintained (owned) by the given maintainer, which in this case points at itself. It's a good idea, but not required, to add an abuse-mailbox to which abuse complaints can be sent. The auth field can contain either a PGP or an SSH key, with more information about the format in the Registry Authentication section in the wiki. The source field is a part of every object and must contain DN42 (the only time this differs is for objects imported from other interconnected networks like ICVPN or ChaosVPN.

Person

A person object contains the details to reach a point of contact for a given registry object. Unlike the maintainer object which is more like a user account, this object should associate with an actual person, including their email, Twitter, or other contact details. Create a new person object with the below contents in data/person/, with the filename <name>-DN42.

person:             Daniel Hellstern
e-mail:             dn42@daniel.hellstern.org
nic-hdl:            DHELLSTERN-DN42
mnt-by:             DHELLSTERN-MNT
source:             DN42

In the above, the person can be a nickname, first name, or full name, whichever is preferred. The e-mail must be valid and reachable, this will usually be the main point of contact for other users. Typically the nic-hdl and mntner names should match, with the difference just being that the NIC handle ends in DN42 instead of MNT. Additional contact details can be specified using contact, such as contact: twitter: <username>, and a personal website can be specified with www.

Organization

An optional additional step is to create an organization object, which does not have an additional functional purpose, it merely serves to represent that resources are owned by an organization rather than an individual. Create an organization in the folder data/organisation/, with the format ORG-<name>. I created a Champlain College organization using the below, to act as an umbrella for the resources I provisioned.

organisation:       ORG-CHAMPLAIN
org-name:           Champlain College
admin-c:            DHELLSTERN-DN42
tech-c:             DHELLSTERN-DN42
mnt-by:             DHELLSTERN-MNT
www:                https://www.champlain.edu
source:             DN42

Like other resources, the admin-c, tech-c, and mnt-by fields link this to existing contacts and to a valid maintainer. Organization objects also support optional metadata like a website with www.

Autonomous Systems

The first actual resource that must be allocated is an autonomous system number. This identifier must be in the range of AS4242420000 - AS4242423999, and an available ASN from that range can be generated here. Create a file in data/aut-num/, with the file name containing the ASN, including AS.

aut-num:            AS4242421878
as-name:            Champlain College
admin-c:            DHELLSTERN-DN42
tech-c:             DHELLSTERN-DN42
mnt-by:             DHELLSTERN-MNT
org:                ORG-CHAMPLAIN
source:             DN42

The field aut-num must match the AS number in the filename. Note the use of org to link this resource to an organization, which is optional.

Address Blocks

IPv4 and IPv6 address space can be allocated using the inetnum and inet6num objects. They are saved in data/inetnum/ and data/inet6num/, respectively. The filenames should be the CIDR/prefix notation with the / replaced with _, for example 2001:db8:c184:_48 These objects are nearly identical otherwise. Available address blocks can be generated here (v4) and here (v6). IPv6 addresses are generally preferred on the network, and taking larger than a /26 IPv4 block should be done with care and reasonable justifications.

inet6num:           fde6:a552:874f:0000:0000:0000:0000:0000 - fde6:a552:874f:ffff:ffff:ffff:ffff:ffff
cidr:               fde6:a552:874f::/48
netname:            CHAMPLAIN-NETWORK
status:             ASSIGNED
country:            US
admin-c:            DHELLSTERN-DN42
tech-c:             DHELLSTERN-DN42
mnt-by:             DHELLSTERN-MNT
org:                ORG-CHAMPLAIN
source:             DN42

Of course, for IPv4 records inet6num should be replaced with inetnum, and CIDR should contain an IPv4 netblock. Note again the optional use of org to associate the resources with the organization. This object also includes the optional field country, which most members provide as a way of geolocating address space. The status field is required as a way of stated that the netblock is allocated, not reserved or in some other state. There is no hierarchical geographical distribution of networks, so consecutive netblocks may not be anywhere close to each other.

Routes

Routes are not technically a required object, but if left out it's likely that routes advertised over BGP will be filtered out. Routes are used to compile a route origin authorization list, which ensures that routes are originating from the correct ASN (think of it as a link between ASNs and address space). Create a route object using the same file name as the netblocks in either data/route/ or data/route6/, depending on the version.

route6:             fde6:a552:874f::/48
origin:             AS4242421878
max-length:         64
mnt-by:             DHELLSTERN-MNT
source:             DN42

Replace route6 with route and an IPv4 netblock for IPv4 routes. The field max-length specifies the maximum netblock that can be advertised, meaning that in the above, the smallest netblock that can be advertised would be a /64 and the largest would be the entire block of /48. The use of max-length is not required, but is encouraged.

References