毎年恒例のエイプリルフールに公開されるジョークRFCですが、今年も公開されました。本記事では、2026年版ジョークRFCの内容を紹介しつつ、エンジニア目線で共感した点や、印象に残った点を交えながらご紹介します。
まだ読んでいない方にとってはネタバレになりますので、ご注意ください。

以前の記事を読まれていない方は、ぜひこちらもご覧ください。

2026年ジョークRFC

2026年のジョークRFCは、IETFのレビュー文化そのものをネタにしたものと、TLS 1.3という本格的な題材に独特のこだわりを持ち込んだものの2本立てです。

RFC9948 インターネットプロトコル警察（IPP） - 罰則一覧

実は、この「インターネットプロトコル警察（IPP）」というネタは、今年いきなり始まった話ではありません。もとになっているものは、2021年のジョークRFC RFC 8962 “Establishing the Protocol Police” です。RFC8962では、「We are not the Protocol Police.」というIETF界隈でよく知られた言い回しを逆手に取り、あえて「Protocol Police」を正式に設立する、という設定が示されていました。今回のRFC9948は、その流れを受けた続編のような位置づけで読むと、より面白く感じられます。
また、この種の“規律”や“道徳”を大真面目に持ち込むジョークは以前からあり、2005年のジョークRFC RFC4041 “Requirements for Morality Sections in Routing Area Drafts” では、Routing Areaの文書に「Morality Considerations（道徳に関する考慮）」節を求めるという、いかにもIETFらしいネタが展開されていました。そうした系譜を踏まえると、RFC9948もまた、IETF的なユーモアの流れを受け継いだ1本と言えそうです。RFC9948では、その流れを引き継ぐ形で、今度は「Internet Protocol Police（IPP）」がどのような処罰を与えるのか、その罰則一覧が公開されています。

処罰の内容も絶妙です。たとえば軽微な違反には「Raised Eyebrow（眉をひそめる）」、もう少し深刻になると「Frown（眉間にしわを寄せる）」、さらに「Shaking of the Head（頭を左右に振る）」、「Finger Wag（人差し指を左右に振る）」と続きます。対象となる違反も、悪い文法、用語の不統一、IANA管理のコードポイントの未登録利用、行き止まりのある状態遷移表、Unicode considerationsのないcase-fold、重要な部分を “implementation defined” で片付けてしまうことなど、見覚えのありそうなものから、少し調べたくなるようなものまで並んでいました。

このRFCの秀逸なところは、仕様レビューや設計レビューの場に漂う、あの独特の圧力を言語化しているところです。RFC9948には、開発中に飛んでくる “This part needs elaboration.” や “This may work in the lab, but ...” といったおなじみの一言も並んでおり、しかもその裏にある本音まで身も蓋もなく説明されています。特に “You have not thought this through.” に対して、実質的な意味を “Go home and start over.（いったん帰って考え直してきてください）” と言い切っているのは強烈でした。
このRFCは、IETFのレビュー文化をネタにしつつ、仕様策定や設計レビューに漂う独特の緊張感をよく表していると思いました。経験のあるエンジニアほど、「笑えるけど笑えない」と感じるのではないでしょうか。

RFC9949 BUSA-TLS

TLS 1.3については以前の記事で、TLS 1.2との違いやハンドシェイクの流れを、パケットのデコードを比較しながら紹介しました。今回のRFC9949は、そのTLS 1.3のさらに深い部分を題材にしたジョークRFCです。ひと言でいえば、TLS 1.3の初期鍵導出で使う最初のゼロ列を音楽データで置き換えるRFCと言ってよいかもしれません。PSK を使わない場合の最初のHKDF-Extractで使うゼロ列を、2 Live Crewの“Banned in the U.S.A.”の音源由来データに置き換える、という発想です。変更箇所だけを見るとごく小さな差分なのに、前提として要求しているものがあまりにも大きい。この落差が、いかにもジョークRFCらしいところでした。

ちなみに、私は “Banned in the U.S.A.” という曲自体を今回初めて知りました。調べてみると、これは米ヒップホップグループ「2 Live Crew」が1990年に発表した作品で、当時の表現規制やわいせつ裁判への反発という文脈を持つ曲です。（参照URL：Wiki - Banned_in_the_U.S.A.）
単に変わったタイトルの曲を持ってきたのではなく、「禁止されたもの」「検閲の対象になったもの」をあえてプロトコルの材料にする、という含みがあると考えると、このRFCのネタの置き方も少し違って見えてきます。なお、RFCでいう「canonical form」は、この曲の正本として扱う版という意味で、1990年盤の“Banned in the U.S.A.”の Track 1を指します。コンピレーション盤やラジオエディット版ではなく、その正本音源の非圧縮PCMデータからハッシュを計算する、というところまで指定されているのが、このRFCらしいところです。

ほかにも、Mandatory Audio Component、略してMACと名付けながら、わざわざMessage Authentication Codeとは別物であることを説明し、さらにMP3やAACなどの非可逆圧縮は不可、使うべきなのは「1990年盤 “Banned in the U.S.A.”」の「canonical form」であり、FLACは可、ストリーミング版や別バージョンは不可、という具合に条件が真顔で積み上げられていきます。実装者は原盤をlawful meansで入手し、自分でハッシュ値を導出することまで求められており、この徹底ぶりも含めて、仕様が実に細部まで作り込まれていました。

個人的に印象に残ったのは、TLS 1.3 という本来とても真面目に練られた仕様の、かなり深い部分に独特の美学を持ち込んでくるところです。本文では、TLS 1.3がnull encryptionや古い暗号方式を排除してきた一方で、鍵スケジュールの最初だけゼロで始まるのは「技術的には問題ないが、精神的に“troubling”」だと説明されています。さらに、BUSA-TLSに非対応の相手と接続を拒否することについては、「これはセキュリティ上の推奨ではない。プロトコルに符号化されたライフスタイルの選択だ」と言い切っています。技術仕様の顔をしながら、最後は思想の話に着地してしまうところが、このRFCの妙だと感じました。

あとがき

2026年のジョークRFCは、IETFのレビュー文化をネタにした内容と、TLS 1.3 に音楽を持ち込む内容の2本でした。片方は「レビューで感じる圧」を言語化したもの、もう片方は「暗号仕様に思想を持ち込む」という大胆な発想を本気で書き切ったもの、という対照的な面白さがありました。
ジョークRFCは、単なる冗談に見えて、その年の技術者コミュニティの空気や仕様書文化のクセがよく出るので、毎年楽しみにしています。今年も、技術ネタがわかる人ほどじわじわくる内容でした。

この記事が、RFCを読むきっかけになればうれしいです。来年もどんなジョークRFCが出てくるのか楽しみにしたいと思います。
RFC関連の記事はこちらにまとめてありますので、ほかの記事もぜひご覧ください。