インターネットプロトコルにおけるパケットサイズに関して
拙著「プロフェッショナルIPv6」で、IPv6がリンクにおいて1280オクテット以上のMTUを要求していることに関して「最小MTU」という表現をしており、その表現が間違っているのではないかというご指摘をいただき、その点について調べなおしました。
その過程で、そもそも関連する部分で自分が間違って理解していたことに気がつきました。 その間違いを発信していたという恥を晒す内容ですが、せっかくなのでブログの記事として共有することにしました。
IPv4におけるデータグラムのサイズに関して
IPv4の仕様が規定されているRFC 791では、IPv4ヘッダのTotal Lengthに関して、以下のように書かれています。
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams.
576オクテットに関しては、MTUとして576オクテット以上でなければならないという仕様ではなく、受信側が最低限576オクテットを受信できるように準備してなければならないという仕様です。そして、送信に関しては、相手側が576オクテット以上のデータグラムを受け取れる確証がある場合にのみ、それ以上の大きさのデータグラムを送ることが推奨されている、という内容です。
さらに、Path MTU DiscoveryのRFC 1191では、以下のような文章もあります。
Furthermore, current practice does not prevent fragmentation in all cases, since there are some paths whose PMTU is less than 576.
このように、576オクテットよりも小さなPMTUが存在していると明記してあります。
私が間違った理解は、IPv6において、すべてのリンクが1280以上のMTUである必要があるという内容に対して、IPv4ではその数値が576オクテットであるというものでした。 IPv4における576オクテットは、IPv6における1280オクテットとは、まったく別の話だったのです。
間違った理解をもとに情報発信をしてしまい、申し訳ありませんでした。
IPv6におけるパケットサイズ
IPv4を規定したRFC 791のTotal Lengthフィールドの部分では、MTUという表現は登場していません。 RFC 791でMTUという表現が登場するのは、フラグメンテーションの部分だけです。
その一方で、IPv6の基本仕様を規定したRFC 8200では、以下のように、MTUという表現をパケットサイズに関する話題で使っています。
5. Packet Size Issues
IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. This is known as the IPv6 minimum link MTU. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.
IPv6では、インターネットにおける全てのリンクが1280オクテット以上のMTUであることが必須であるとされています。 RFC 8200では、そのことを「IPv6 minimum link MTU」としています。 日本語訳としては「IPv6最小リンクMTU」になるかも知れませんが、それを「最小MTU」とするのは、おそらく間違いです。 PMTU(Path MTU)との違いがわかりにくいですし、RFC 8200にあるのは、あくまで「IPv6 minimum link MTU」であって、「minimum MTU」と書いてあるわけではないのです。
そして、上記箇所を再度ゆっくりと読み直して思ったのですが、その次にある「On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.」という部分も、かなり大きなポイントなのかも知れません。 下位層において何らかの仕組みによってフラグメンテーションや再構成を行ってでも、IP層であるIPv6からの視点で1280オクテット以上のMTUであるようにするようにとのことだと、読解しました。
この部分、いままでは正しく着目してなかったんだなぁという感じです。反省。
これまで、「最小MTU」という表現に対して自分がなぜ全く疑問にすら思えなかったのか反省したのですが、実は過去に、その表現を色々なところで聞いていた可能性も考えています。 日本国内における各種イベントなどで、過去に「最小MTU」と表現している発表があった気がしているので、昔のイベントで公開されていた資料を確認しましたが、その資料内で「最小MTU」と書かれているものが存在していることを確認しました。 おそらく、私と類似する間違った理解をしている人が他にもいるのではないかと思ったのも、今回の私の恥を晒すことにした理由のひとつです。
プロフェッショナルIPv6を修正しました
これらの間違いを修正するとともに、「最小MTU」という表現を間違いであると考え、複数箇所を修正することにしました。
「プロフェッショナルIPv6」用のリモートレポジトリに対してgit push済ですが、出版社であるラムダノート社の中の人の時間がなさそうなのと、ほかにもゾーンインデックスに関して誤りの報告を受けている部分があるので、PDF版の更新をお届けするのはもう少し先になりそうです。 紙書籍については、現在のバージョン(2刷)が売り切れてからの増刷になるので、まだしばらくかかりそうです。
最近作り始めたIPv6解説動画にも、同様の間違いが一部含まれているので、間違いが含まれる動画を作り直します。 YouTubeでは、動画の内容を訂正することができないので、いまある動画は削除した上で新しい動画として掲載される予定です。
無知の知に関して
自分が何を知らないのか、自分が何を誤解しているのか、何を間違って理解したつもりになっているのか、そういった部分には気がつきにくいです。 色々な情報発信をしていて非常に大きな穴が発生しがちなのが、自分が明らかに知らない内容をまとめているときよりも、学生時代などに中途半端に勉強したときに勘違いしたままの部分が多かったりします。
そして、間違いを含む内容を発信してしまったときに、その間違いを間違いであると指摘してもらえる頻度が年齢を重ねるとともに減少しているのではないかと思うこともあります。 そのことが割と怖いです。
その一方で、間違いが指摘された瞬間には、正直、多少の気分の悪さが自分の中で発生することもあります。 なかには、単に中傷したいだけとしか思えないものや、間違っているとだけケチをつけて何がどう間違っているのかを言及しようとしないような場合もあります。
しかし、指摘の内容が正しかった場合には、その指摘に感謝し、正すべき場所は正すべきだという考えに気分の悪さが上書きされ、色々と調べ始めると指摘によって一瞬でも不機嫌になった自分の未熟さを思い知らされます。 もう、ずっと、そんなことの繰り返しです。
年齢が上昇したからといって、知識や技能が単調増加するわけでもないのに、油断すると不要で変なプライドばかりが増加してしまうのは、なぜでしょうか。 気をつけたいと思います。
最後に、本書はクラウドファンディングでの執筆時点から広くレビュー版を公開して皆さんからの意見を聞きながら修正を重ねてきていますが、まだまだ誰も気づいていない間違いがあると思うので、今後ともたくさんの方に読んでいただいて指摘をもらえるとうれしいです。 よろしくお願いいたします。
最近のエントリ
- 「ピアリング戦記」の英訳版EPUBを無料配布します!
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
- ShowNetのローカル5G企画(2022年、2023年)
過去記事