要約

  • RFC 3091はπの数字を314.159.265.359というグループへマルチキャストするよう求めたが、これは有効なIPv4マルチキャストアドレスではない。
  • TCP・UDP用の314159と220007も16ビットのポート欄に入らず、記憶に残る数字はそのままではパケットに載らなかった。

RFC 3091の目的だけを見ると、仕組みは単純に見える。手元でπを計算できないワークステーションがサーバーへ接続し、数字を受け取る。あるいは位置を指定して一桁だけ尋ねる。さらに、第三の案ではマルチキャストを使い、参加者が時間をかけて数字を集め、一貫した値を作る。対話方法は三つあるが、どれもまず宛先をネットワークのフィールドに表現できなければ始まらない。

マルチキャストの指定が、その食い違いを最も端的に示す。RFC 3091は314.159.265.359をグループと呼んだ。IPv4のドット区切り10進表記は四つのオクテットから成り、それぞれ0から255までの値を取る。RFC 1112が定めるIPv4ホストグループの範囲は224.0.0.0から239.255.255.255だ。RFC 3091の文字列は五つの要素を持ち、先頭の314だけですでに範囲外である。これは未割り当てのグループではない。そもそもIPv4グループを表すアドレスとして解釈できず、ホストは記載どおりのグループに参加できない。

ポートにも同じ問題がある。RFC 793ではTCPの送信元ポートと宛先ポートがそれぞれ16ビット、RFC 768ではUDPの各ポートも16ビットだ。符号なし16ビット値の上限は65,535である。それなのにRFC 3091は必須のTCPサービスに314159番を指定し、任意のUDPサービスにも同じ数字を使う。22/7を返す近似サービスは220007番を指定した。どの数字もTCPまたはUDPのポート値として符号化できない。後年のRFC 6335が定めるIANAの割り当て範囲は、表現可能な領域内の管理手順であり、登録によってフィールド幅が広がるわけではない。

これはπをもじった数字の見落としだけではない。TCP版はクライアントが閉じるまで数字を送り続ける。UDP版は第n桁を問い合わせ、位置を伴う応答を返す。マルチキャスト版には問い合わせがなく、プロバイダー候補は30秒間ほかの提供者を見つけられなければ送信側となり、ランダムに選んだ数字を配信し、受信側が時間をかけて一貫した値にする。ストリーム、照会、分散収集という動作はそれぞれ説明されているが、最初の接続先がプロトコル上表せないため、どの経路も記述どおりには到達できない。

この文書は2001年4月1日付で、カテゴリはInformationalである。IETF DatatrackerはIndependent Submissionの文書と分類し、IETFの支持を受けたものでも標準化プロセスに正式な効力を持つものでもないと明記している。日付、符号化不能な定数、そして信頼できるPIgenサーバーを使わなければインターネットが差し迫って崩壊するというセキュリティ節の警告を合わせると、冗談として読むのが自然だ。ただし、それは文脈に基づく解釈であり、著者の内心を裏付ける独立証拠ではない。記録から確かに言えるのは、RFC形式で説明されたサービスの宛先が、呼び出しているプロトコルでは表せないということだ。

RFC番号も実装の証明書ではない。出版記録は文書の内容と公開経路を示すが、指定ポートで待ち受けるホストがあったこと、マルチキャストグループが存在したこと、導入時に定数が修正されたこと、あるいは受信者が実ネットワークでπを再構成したことは示さない。計算手法やDNS SRVによるサービス発見への言及は設計をもっともらしくするが、ビット幅の問題を解消しない。SRVがポートを告知できても、その数値を運ぶのはトランスポート側だ。

RFC 3091が残すインターネット技術史上の教訓は明快である。文章として流暢な仕様も、名前をワイヤ上の表現へ移す境界で失敗しうる。πらしい番号も、数字を並べたように見えるアドレスも、それだけで有効なネットワーク識別子にはならない。サービス発見、負荷分散、受信側の収束を論じる前に、宛先を符号化できるビットがあるか確かめる必要がある。

出典