ネットワークバイトオーダーの公式な参照先はエイプリルフール

2017/12/19-1

インターネットは、その場しのぎの拡張を繰り返して迷路のようになってしまった古い旅館のような側面があります。

インターネットは、インターネットプロトコル(Internet Protocol/IP)を使った通信によって成り立つ世界規模のネットワークですが、そこで使われる非常に多くのプロトコルが「ネットワークバイトオーダー(network byte order)」というデータ転送の順番を採用しています。

ネットワークバイトオーダーはビッグエンディアンという大きな桁を表すビットを含むバイトから最初に並べる方式を示す用語で、TCP/IPに関連する非常に多く(もしくは大半)のプロトコルが、ネットワークバイトオーダーを採用しています。しかし、ネットワークバイトオーダーがTCP/IPの標準であることを示したRFCは存在しません。

そもそも、ネットワークバイトオーダーを明確に定義したRFCも存在しません。ネットワークバイトオーダーに対して参照(reference)を示したRFCもありますが、それらはIEN 137(もしくはIEEE Computerの記事になったもの)を参照しています。最も新しいRFCでは、2006年のRFC 4506「XDR: External Data Representation Standard」がIEN 137を参照しています(RFC 4846も参照していますが少し意味合いが違います)。

そして、ガリバー(ガリヴァー)旅行記という切り口でデータの転送順序に関して考察したIEN 137はエイプリルフールネタなのです。なんと、ネットワークバイトオーダーの正式な参照先として存在しているのは、1980年4月1日のエイプリフールなのです！(IEN 137はネットワークバイトオーダーを解説したものではありませんが)

IEN

IENは、Internet Experiment Notesの略です。和訳するとインターネット実験ノートという意味です。

1993年に発行されたRFC 1391(obsolete)を見ると、IENは以下のようなものです。実験的な「ノート」は、IENとしてまとめられていたようです。

Internet Experiment Notes (IEN) were created to become a new informal document series about the early experimental work on TCP and IP. It was thought that having "Notes" as part of the name would prevent them from being cited as standards. As the work matured, the documentation was done as RFCs.

RFC 1391は「The Tao of IETF A Guide for New Attendees of the Internet Engineering Task Force」というタイトルなのですが、1993年の段階ではIETFに初参加の人々に向けての資料に、IENという文書の存在が紹介されていたことがわかります。

しかし、現在ではIENが果たしていた役割はRFCに統合されています。 Tao of the IETFは、以下のように度々上書き廃止されていますが、2001年に発行されたRFC 3160の段階でIENの紹介は消えています。

RFC 1391 (1993年)
RFC 1539 (1993年)
RFC 1718 (1994年)
RFC 3160 (2001年)
RFC 4677 (2006年)
RFC 6722 (2012年)

いまでは、IENという文書のジャンルは消え、IEN 137だけが意味を持ち続けているのかも知れません。

IEN 137

さて、では、各種RFCからネットワークバイトオーダーの参照先として示されている、IEN 137とはどういうものなのでしょうか？

IEN 137は、ON HOLY WARS AND A PLEA FOR PEACEというタイトルで、1980年4月1日に発行されています。このタイトルを和訳すると、「聖戦における平和のための嘆願書」のようになります。

ON HOLY WARS AND A PLEA FOR PEACE

IEN 137の冒頭部分は、次のようになっています。

This is an attempt to stop a war. I hope it is not too late and that somehow, magically perhaps, peace will prevail again.
The latecomers into the arena believe that the issue is: "What is the proper byte order in messages?".
The root of the conflict lies much deeper than that. It is the question of which bit should travel first, the bit from the little end of the word, or the bit from the big end of the word? The followers of the former approach are called the Little-Endians, and the followers of the latter are called the Big-Endians. The details of the holy war between the Little-Endians and the Big-Endians are documented in [6] and described, in brief, in the Appendix. I recommend that you read it at this point.

これは戦争を止めることを目指した文章です。これが手遅れではないことを願っていますし、なんらかの、もしかしたら魔法的な方法によって、また平和が訪れるかも知れません。
あとから競技場に来た人は、この問題が次のようなことであると信じるでしょう：「メッセージにおける正しいバイトオーダーはなんであるか？」。
紛争の根はもっと深いところにあります。どのビットが最初に運ばれるべきか、ワードの小さい方の終端が先か、それともワードの大きい方の終端が先かです。前者のアプローチを取るのがリトルエンディアンズと呼ばれています。そして、後者のアプローチを取るのがビッグエンディアンズと呼ばれています。リトルエンディアンズとビッグエンディアンズの間の聖戦に関しては参考文献[6]に書かれています。そして、簡単なまとめを付録に記載しています。まずは、それらを現時点で読むことをお勧めします。

そして、参考文献[6]には、1726年作のガリバー旅行記が記載されています。

IEN 137は、ビットやバイトの転送順に関する論争を小説「ガリバー旅行記」のなかに出てくる、第一篇リリパット国渡航記にたとえて表現しているのです。ガリバー旅行記には、小人の国「リリパット」と隣国の「ブレフスキュ」は、卵の殻の正しいむき方をめぐる意見の相違から戦争になっています。卵の殻を大きい側からむく勢力がビッグエンディアン、小さいほう側からむく勢力がリトルエンディアンです。大きい方か小さい方かに関する論争が聖戦になっているのです。

IEN 137では、ビッグエンディアンとリトルエンディアンに関する現状を技術的視点でまとめています。そのうえで、ビッグエンディアンの方が良いのではないかと提案しています。

さらに、最終的に小人の国では巨人であるガリバーが強制的にひとつにまとめるようなことが起きることを望むとまとめています。自分が提案しているビッグエンディアンが採用されることを希望するものの、どちらが採用されようと、そこまで大きな違いはないので、合意できることそのものが大事なので、コイントスでもするか？と最後に書いています。

現在のインターネットの状況を見る限り、このIEN 137によってビッグエンディアンが勝利したようで、いまではビッグエンディアンが「ネットワークバイトオーダー」と呼ばれています。

エイプリルフールネタが公式な参照先に

IEN 137が発行されたのは、1980年4月1日です。いわゆるエイプリルフールの日です。ガリバー旅行記という表現で技術的な論争を表現したのは、エイプリルフールネタだったのです。

しかし、IEN 137は単なるエイプリルフールではなく、実際の技術的な考察が優れていました。ビッグエンディアン、リトルエンディアンというわかりやすい表現もうけたのだと思います。いまではビッグエンディアンとリトルエンディアンは、正式な技術用語になっていますが、それが広がったのは1980年のIEN 137からのようです。

そして、その後のRFCでIEN 137が参照されるようになりました。 RFCにもエイプリフールものはありますが、そういったエイプリルフールRFCではなく、正式なスタンダードとしてのRFCがIEN 137を参照している場合もあるのです。

さらに、時間が経過すると、インターネットの標準的なデータ転送順序はビッグエンディアンによる「ネットワークバイトオーダー」であるというデファクトスタンダードが形作られていきました。

そして、やっと今回のこの記事のタイトルの内容に行き着くわけですが、この文章を執筆している時点において、ネットワークバイトオーダーがTCP/IPの標準であることを示したRFCは存在しません。

そういう視点でネットワークバイトオーダーについて見直すと、ネットワークバイトオーダーの参照先がエイプリルフールネタであることがわかります。

IPv4とIPv6

IPv4とIPv6は、IEN 137を参照していません。

IPv6の基本仕様を示しているRFC 8200には、以下のようにあります。

The data transmission order for IPv6 is the same as for IPv4 as defined in Appendix B of [RFC791].

(和訳)IPv6のデータ転送順序は、RFC 791の付録Bに定義されているIPv4の方式と同じである。

そして、IPv4の基本仕様を示しているRFC 791の付録Bには、以下のようにあります。

The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English.

(和訳) このドキュメントで示されるヘッダとデータのデータ転送順序は、オクテットレベルに分解される。 (このドキュメントにおいて)図が複数のオクテットを示すとき、そのオクテットが転送される順番は、英語が読まれる通常の順番と同じである。

IPv4の仕様の中には、ネットワークバイトオーダーという単語は入っていませんが、内容はネットワークバイトオーダーになっています。

根幹的な仕様が付録(Appendix)であるという点が非常に微妙ですが、大規模な戦争を避けるために、あえて、そういった扱いにしたのかも知れないとは思いました。