Summary

  • IPv4 オプション 130 は、分類レベルと任意の保護機関フラグをデータグラムに持たせ、送信・配送の検証と経路保護に結び付けた。
  • これは暗号化でもインターネット全体の共通政策でもなく、ラベル、経路情報、運用規則を共有する限定領域を前提としていた。

数字だけでは読めない一バイト

分類欄は一オクテットに収まる。しかし、その値を普通の整数として大小比較することはできなかった。RFC 1108 は間隔を空けた符号を定義し、予約値や一覧にない値をエラーとした。受信側には、数値計算ではなく定義済みの対応表が必要だった。

オプション全体は可変長で、最短三オクテットだった。タイプは 130、同じデータグラムには一度だけ置かれる。コピービットが立っているため、断片化後の各フラグメントにも残さなければならない。分類の後ろには保護機関を示すビット列を置けたが、省略も可能だった。

複数の機関フラグは同時に立ち得る。ここで示されるのは、どのプログラムの取扱規則が関係するかであり、認定を与える機関そのものではない。ラベルは必要な保護を主張するが、その保護が実施済みであることを自動的に証明しない。

仕様が想定した役割は、送信の妥当性確認、配送の妥当性確認、そして表示された全機関に適した保護を備える経路の確保だった。最後の役割にはルーター側の共通知識が要る。ラベルに応じて経路を選ぶなら、ルーティングプロトコルもセキュリティラベル情報を伝えなければならない。

つまり、ヘッダーのビットだけで制度は完成しない。オプションはペイロードを暗号化せず、送信者の身元を単独で証明せず、各ホップが同じ規則を適用したとも保証しない。端末、ルーター、分類語彙、経路管理が一つの統制領域に属するときに初めて意味を持つ。

公開網の判断と閉域の判断

RFC 7126 は IPv4 オプションを運用上の負担として再評価したが、タイプ 130 については例外的な事情も記録した。当時、特定の高セキュリティ環境で利用され、OS やルーターにも実装例があった。そのため、境界で常に破棄する方針は正当な閉域運用を壊し得る。

これは広範な普及を示さない。現在の利用率、共通のファイアウォール既定値、現行の機関一覧を資料は示していない。確認できるのは、公開トランジットには扱いにくい仕組みでも、意味と執行を共有する領域では残り得るという限定的な事実である。

Sources