今仕事関係で、IPsec 関連の RFC を再読している。
再読というからには一度読んだことがあって、それは二年前、ちょうど改訂版 IPsec の仕様が RFC2401〜2412 にまとめられた前後だった。詳しくない方のために少し書いておくと、IPsec というのは、IP 層レベルで暗号化、認証機能といったセキュリティを提供するためのプロトコルで、メールの機密性を確保する PGP、EC サイトでは欠かせない SSL といったアプリケーションレベルのセキュリティ・プロトコルとは別のレイヤで動くものである（ので共存も可能）。
二年前に一通り読んでいるのだから、今読み返すとしてもそれは飽くまで「確認」程度に過ぎない・・・はずなのだけど、結構「発見」があったりする。要は忘れてしまっていたということで、加齢による記憶力低下なのだろう。
しかし、それとは別に、以前には見過ごしていたところでも「発見」があった。
それは RFC2410 を読んだときのことである。これは "The NULL Encryption Algorithm and Its Use With IPsec" というタイトル通り、「暗号化なし」というアルゴリズムを IPsec に適用する場合について規定したものである。「暗号化なし」のどこがセキュリティやねん、と突っ込まれそうだが、実装する側からするとこれが必要なのだ。つまり、IPsec の枠組み自体がきちんと実装できているか確かめるには、「暗号化しない」という選択肢がなくてはならない。
ただそれは飽くまで実装する側の話であり、実際のユーザがこれを「暗号化アルゴリズム」として選択することはまずない。単に通信のオーバーヘッドになるだけだし、選択肢に入れてない IPsec 搭載製品も多い。
そういった事情もあり、二年前にはほとんど素通り状態だったが、他の RFC の忘れっぷりに愕然としたこともあり、一応をちゃんと目を通しておこうと読んでみた。すると冒頭のところで？となり、やがてそれがジョークであることに気付き、笑ってしまった。
馬場達也氏による日本語訳から引用してみる。
NULL は、その起源が随分昔の古いブロック暗号である。
National Security Agency がこのアルゴリズムの発表を禁止したという噂はあるが、彼らが実際にそうしたという証拠はない。
むしろ、最近の考古学的発見によると、NULL アルゴリズムはローマ時代に、シーザ暗号の代替として輸出できるアルゴリズムとして開発されたことが示されている。
しかし、ローマ時代の数字には 0 を現わす記号が存在しなかったため、このアルゴリズムの開発に関する記録は、2000 年以上にわたって歴史家には不明であった。
このニュアンス、分かりますか？ こういったのを「サムい理系ギャグ」とバカにする向きも一部にはあるが、真剣に読んでいるところにこういう表現を見つけると心が和むものだ。
RFC は、たまに「インターネットの標準仕様を定める文書」と解説されることがある。もちろんこの定義は一面的で、RFC になっても普及しなかったプロトコルもあるし、RFC にはならなかったが実際のネットワーキングに欠かせないものも多い（SSL や IP マスカレードが代表例でしょうか）。
またインターネット標準とは関係のない RFC というのも多数存在する。俗に「ジョーク RFC」と呼ばれるものであるが、これについては Yotti さんが日本語訳のポインタも含めてまとめた秀逸なページがあるので、是非そちらをご一読いただきたい。
ただジョーク RFC といってバカにはしないでいただきたい。RFC1925 はなかなか深いし、「伽藍とバザール」を読んだことのある方ならニヤリとする「真実」があったりもする（ヒントは、サンテグジュペリつながり）。
そもそも RFC は Request for Comments の略であり、直訳すれば「コメント求む」ということになり、例えば ITU-T が出す Recommendation（勧告）と比べれば、受ける印象が随分と異なる。RFC の方がずっと柔軟で自由度の高い印象があるが、それがそのまま The Internet の柔軟性、非中央集権性につながっている、とまとめるのは強引だろうか。
しかし、プロトコル草案（Internet Draft）が RFC になるには先に実装例がないといけない。それが "Rough consensus and running code" と呼ばれるポリシーであって、これを直訳すると「仲の良い友達と旨いバーボンがあればそれでいい」となる。つまりはそういうことだ（どういうことじゃ！）。
RFC の位置付け、策定過程、そして ISOC や IAB や IETF や IANA といった団体の関係性については、@IT にある「詳説TCP/IPプロトコル 第２回 Internet StandardsとRFC」あたりを参考にしていただくとよいでしょう。
柔軟、rough といったキーワードで RFC を表現したが、もちろんのこと RFC、並びにインターネット標準はいい加減に策定されているのではない。そんなお気楽なものではなく、Steve Crocker（RFC1 の著者）が語るように、「忍耐と献身によって、ささやかな一連の RFC が大きく発展した」のである。
そしてその中心に、しかも謙虚に君臨していたのは、130以上の RFC に著者・編者として名前を連ねる Jon Postel で、何より彼こそが、インターネットの精神を体現していたように思う。
だからこそ彼が1998年10月に死去した際には、「IANAを偲ぶ」と「ジョンと共に働いて」という弔辞が、それぞれ RFC2468、RFC2441 として RFC 化されたりもした[註釈]。
Postel、並びにスタッフの柔軟かつオープンで、同時に非常に厳しい姿勢については、力武健次氏の「インターネット大暴落のきざし」の中に完璧な（氏の文章が嫌いな僕が書くのだから間違いない）解説がある。少し長いが引用させてもらう。
インターネットに価値を付けてきたのは、故Jon Postel氏のように、世俗の雑事に惑わされない環境で多くのプロトコルを考え、そして寄ってたかってそれらを改良していった技術者達である。彼らの多くは、障害は乗り越えるものであり、「癒される」ものではないことを知っており実践している。彼らは苦言を呈することを怖れない。そして、彼らの多くは、マスコミには出ない。マスコミはストーリーをあらかじめ作っておいて、それに素材をはめこむことしかしないからだ。
さて、その RFC も30年以上の歴史を持つまでになった。Postel 氏の弔辞や、冒頭で述べた IPsec 関連の RFC が策定された二年前が大体 RFC2400 台だったのが、この文章を書いている時点で3000台を突破している。この二年間で凡そ500以上の RFC が策定されたということになるが、これはインターネットを巡る状況のめまぐるしさを反映したものだろうか。
そうなってくると追っかけるのもなかなか大変である。一度読破したプロトコルの仕様でも後に改訂され、自分が読んだ RFC が obsolete になるのはよくあることで、大部の RFC を英語で読むのがしんどくなり、日本語訳はないものかと弱気になったりもする。
実はここに落とし穴があって、RFC の類は非常に論理的に書かれているので、下手に日本語にするよりは英語のまま直で読んだ方が実は分かりやすい。日本語訳をネット上で見つけて大喜びして読んでみたものの、どうもしっくりこずに結局原語で読みなおし、という経験を持つネットワーク技術者も多いだろう。
ただそれでもオルタナティブがあるというのはよいことには違いないし、日本語の方が頭に馴染みやすいのは間違いない。
アスキーからは「インターネットRFC事典」という大部の書籍が出ていて（RFC 事典というのは世界初らしい）、僕自身会社でこれをたまに参照したりするが、前述の通り出版後も新しい RFC がどんどん策定されている。紙媒体には patch をあてられないのが痛い。
そうなるとネット上で公開されている日本語訳を探すわけだが、これを集積したもので、僕のブックマークに入っているものに以下のサイトがある。
当然ながら、以上のサイトが指すポインタには重複があるし、URL は忘れたが、上記サイト以上に充実したところもあったはずだ。できればどこか一ヶ所決定的なサイトができるとよいのだが。
あと思うのだが、各 RFC の関係性を図化するようなソフトウェアってないのだろうか。例えば RFC793 が大本にあり、TCP についての RFC が系図のようにつながるような表示の仕方や、あるプロトコルの最新版の RFC がどれで、それまでにどの RFC が obsolete になったか分かるような表示の仕方など。図中の RFCxxxx をクリックすればポップアップでその RFC が表示されるとか、矢印をクリックすればその両端の RFC の関係性、差異の解説が表示されればなおよい。
まあ、僕が知らないだけで既にあるのかもしれないし、そんなソフトウェアの需要は実はまったくないのかもしれない。Debian のように RFC がまるごとパッケージとして入っているような Linux ディストリビューションもあったりはするが。
とりあえず上記アイデアに関する「コメント求む」（そういうオチですか？）。
[註釈]：リンクした二つの追悼文 RFC の訳者でもある山根信二さんからご指摘いただいたのだが、僕ははじめ RFC2468 を 2460 と書き間違えていた。原因は、今僕の頭の中が IPv6 のことでいっぱいだからだ（大嘘）。
そしてこれも山根さんから教えていただいたのだが、Jon Postel への追悼 RFC 番号が 2468 になったのは意図的なもので、本文中でもリンクされている RFC2555 でもそのことが書かれてある。本文では RFC の中身にユーモアが潜んでいることに触れたが、こうした番号割当にもそれがあるということで、例えば RFC1984 は、 暗号技術に関するステートメントであるが、これなどオーウェルの「1984年」にひっかけているのかもしれない。[本文に戻る]