概述
对于位于实验范围内的签名类型（65280-65534），floodfill 应该接受 netdb 存储而不验证签名。
这将支持对新签名类型的测试。
动机
GOST 提案 134 揭示了先前未使用的实验签名类型范围内的两个问题。
首先，由于实验范围内的签名类型不能被保留，它们可能同时用于多个签名类型。
其次，如果一个具有实验签名类型的路由器信息或租赁集无法存储在 floodfill 上，则新的签名类型难以进行全面测试或试用。
设计
Floodfill 应该接受和传播实验范围内签名类型的 LS 存储，而不检查签名。对 RI 存储的支持尚待确定，可能会有更多安全影响。
规格
对于实验范围内的签名类型，floodfill 应该接受和传播 netdb 存储而不检查签名。
为了防止对非实验路由器和目标的欺骗，floodfill 不应接受与不同签名类型的现有 netdb 条目哈希冲突的实验签名类型存储。 这可以防止劫持先前的 netdb 条目。
此外，floodfill 应该用非实验签名类型的存储覆盖具有哈希冲突的实验 netdb 条目，以防止劫持先前不存在的哈希。
Floodfill 应假设签名公钥长度为 128，或者从密钥证书长度中推导，如果更长。某些实现可能不支持更长的长度，除非签名类型未正式保留。
迁移
一旦在已知路由器版本中支持此功能，实验签名类型 netdb 条目可以存储到该版本或更高版本的 floodfill 中。
如果某些路由器实现不支持此功能，则 netdb 存储将失败，但这与现在的情况相同。
问题
可能还有其他安全影响需要研究（参见提案 137）。
如上所述，某些实现可能不支持超过 128 的密钥长度。此外，可能需要强制限制为 128（换句话说，没有多余的密钥数据在密钥证书中），以减少攻击者生成哈希冲突的可能性。
对于尚未正式提议的非零加密类型，也需要解决类似问题。
备注
不在实验范围内的未知签名类型的 NetDB 存储将继续被 floodfill 拒绝，因为签名无法验证。