摘要

  • RFC 3091要求组播提供者把π的小数位发往314.159.265.359，但这串字符不是有效的IPv4组播地址。
  • 它的TCP/UDP端口314159和220007也超过了16位传输端口字段的上限；这些醒目的数字无法按原样写入数据包。

如果只看服务目标，RFC 3091似乎很容易实现：缺少本地π计算能力的工作站可以向服务器要数字，也可以按位置查询某一位，或者加入组播接收随机分布的数字，再逐步拼出一致的π值。三条路径各自有完整的交互设想，但它们首先依赖一件更基本的事：目的地址和端口必须能进入网络真正使用的字段。

组播路径把问题暴露得最清楚。RFC 3091把314.159.265.359称作组地址。IPv4点分十进制由四个八位组构成，每组只能在0至255之间；RFC 1112把IPv4组播地址范围界定为224.0.0.0至239.255.255.255。RFC 3091给出的字符串有五段，第一段已经大于255。它不是一个尚未分配、等着管理员登记的组播地址，而是无法表示为IPv4地址的字符串。主机不能加入文中所写的那个组。

端口也犯了同一类错误。RFC 793规定TCP源端口和目的端口各占16位；RFC 768对UDP也是如此。无符号16位数字的最大值为65,535。RFC 3091要求的TCP服务却要监听314159，普通UDP服务也复用这个端口；处理有理数22/7的近似服务则指定220007。这些数都无法编码为TCP或UDP端口。RFC 6335后来划分的IANA端口范围只负责在可表示的数字空间内安排分配；申请登记并不能扩大字段本身。

因此，这不是一串有趣数字的小疏忽。TCP方案让服务器持续发送π的小数位，直到客户端关闭连接；UDP方案让客户端请求第n位并收到带位置的回答；组播方案则取消请求，让提供者等待30秒确认没有其他提供者后，再广播随机分布，接收者随时间拼出数值。RFC分别描述了流、索引查询和组播收敛，但每一种机制的第一步都是访问一个传输层或网络层根本表示不了的目的地。

RFC 3091标注为2001年4月1日发布、类别为Informational。IETF Datatracker将它归为Independent Submission，并明确说明该文档并未获得IETF背书，也不属于IETF正式标准流程。日期、无法编码的常量，以及“几乎所有安全互联网协议都需要高精度π、若不信任PIgen服务器互联网即将崩溃”的安全警告，让它显然像一篇玩笑。这样的判断是基于上下文的编辑解读，并不能证明作者私下的意图。可以确认的档案事实更窄：这份RFC形式的文档描述了协议服务，但它给出的地址无法被所调用的协议承载。

RFC编号本身也不是实现证明。出版记录说明了文档写了什么、通过什么出版渠道发布，却不能证明有主机绑定过指定端口、指定组播组曾存在、某个部署修正过这些数字，或客户端曾在真实网络上拼出π。文中提到的计算方法和DNS SRV服务发现让方案看起来更完整，但并没有解决字段宽度问题。SRV记录可以公布端口，底层传输仍必须能携带它。

RFC 3091留下的互联网工程史提醒很具体：一份文字上自洽的说明，也可能在“名称”变成线上“表示”的关口失败。端口数字像π、地址字符串像一串小数位，并不会因此成为有效的网络标识。在讨论服务发现、负载均衡和接收端收敛之前，先要确认线上比特是否有能力编码目的地。

来源