DN42系列 0x01:注册与申请
NIACNET 在一开始就被设定为可以独立运行的内部局域网络,但为了不与 DN42 网络产生冲突,我决定先注册 DN42 并获得几个IP段。
Git
DN42 的 Registry 是以 git 仓库的形式储存在其站点上,对其任何形式的修改都需要使用 push request,因此需要首先创建一个账户。
其次 DN42 要求用户在创建「维护者」时必须指定一个验证方式(ssh/PGP),这里我选择 PGP 密钥。
DN42 在 Getting Started 页面内进行了一系列说明,同时提供了若干模板。
Fork & Clone
对Registry进行修改首先需要自己fork一份,然后把它 git clone
下来。
1 |
|
全部需要的增加的数据都在 data
目录内。
MNT(维护者)
「维护者」,指有权对在 Registry 中所创建的内容有修改权限的个体。这里我使用了 NIA-MNT
作为其名称,而 admin-c
和 tech-c
则指定为一个「个人」,并添加我的 PGP 密钥指纹(后续更改都需要验证在 git commit
上的签名)。
data/mntner/NIA-MNT
1 |
|
这里的 pgp-fingerprint 961D6DD5
是我的 PGP 密钥指纹。
Person(个人)
这里的「个人」是相对于「机构」而言的,毕竟不是所有人都会以机构的名义创建网络。这里我留下了自己的邮箱和名字以供联系。
1 |
|
Org(机构)
与之对应的则是「机构」,这里就直接以 Niantic Project
为名。
1 |
|
AS(自治系统)
DN42 的自治域编号为 424242
开头 + 0000-3999
间的数字,我这里取为 AS4242421331
。
值得一提的是,在很久以前,AS 编号是没有这么长的,因此在 Registry 里依然能查询到 5 位数的 AS 号,同时也可以看到,有 ICVPN/ChaosVPN 等网络与 DN42 相连接。
data/aut-num/AS4242421331
1 |
|
INETNUM(IPv4地址块)
DN42 的 IPv4 网络是 172.20.0.0/14,同时也包括了几个 ChaosVPN 和其他网络的地址段。虽然 DN42 网络规模很小,但 /14 的大小也意味着一般不太可能随意申请 C 段及以上规模的地址段(事实上 DN42 认为。除非有特殊需求,不应大于 /25)。在 这里 可以查询到可用的 IPv4 地址段。
data/inetnum/172.20.158.128_26
1 |
|
在申请 IPv4 地址时,也出现过一个小问题,我打算申请的 IPv4 段被另一个组织使用并抢先合并了,这不得不让我重新选取一个新的。
最后,我选取了 172.20.158.128/26 作为 DN42 骨干部分使用的地址段,172.20.168.128/25 作为国内部分使用的地址段。
INET6NUM(IPv6地址块)
相比而言,DN42 的 IPv6 空间就更大了(fd00::/8),但是在注册上依然建议不要大于 /48,以便为后来加入的人留出空间,同时在审核上也不会接受类似 fd00:1331:1331::/48 的这种过于“不随机”的地址段,理由是避免与其他使用相同地址段的网络冲突(RFC4193)。PS:我就因为使用以上地址被打回,但是我发现也确实有人成功申请较为有规律的地址段。
最终我选定了 fd00:1926:817::/48 这一咋一看比较“随机”并且庄严而神圣的地址段。
data/inet6num/fd00:1926:817::_48
1 |
|
路由
只有IP没有路由的网络是没有灵魂的,为了验证路由是否是某个 AS 所拥有的,以防某些人胡搞毛搞,还需要在 Registry 注册这些路由。
data/route/172.20.158.128_26
1 |
|
相同地,在 route6
下也应写好 IPv6 的路由。
格式化和验证
这一步非常重要,首先使用以下命令对内容(主要是缩进)进行格式化。
1 |
|
随后使用以下指令检查是否有潜在的错误,以免被打回,耗费时间和精力。
1 |
|
如果不存在错误,就可以 commit 并提交 PR 啦。
签名
之前在注册 MNT 的时候提到了使用 PGP 做为凭据,那么如何使用呢?
实际检查提交的时候是根据最后一个 commit 的签名来确定的,输入以下内容就可以对其进行签名。
1 |
|
在签名完毕之后,git push
然后提出 pull request 即可等待被合并啦。
值得注意的是,DN42 要求压缩 commit 数量,每次更改最好是提前规划好,因为检查一次提交可能会花费 Registry 维护者大量的时间。同时,每次变更后都会有一个 bot 对内容进行检查并留言。
等待
一般来说 Registry 的维护者会在北京时间的凌晨对这些内容进行检查和合并,一旦合并,就可以开始愉快地 Peering 啦。
后记
事实上,以上只是进行注册所需要的最小内容,例如AS还可以添加 remarks
字段来介绍和描述该网络,可以填的坑还很多。
接下来的一篇文章,将讲述如何使用 nebula —— 一个 P2P 网络工具,在国内的网络条件下建立一个基本能用的 Overlay Network,并在此基础上建立证书颁发机构和 DNS 服务器(这部分内容与 DN42 关联不大,故将使用另外的标题)。