XLAT草案は公開IPv4がない場合に192.0.0.8を使う

要約

10月28日付のv6ops作業部会草案第02版は、外側のIPv6送信元を変換できないICMPv6エラーについて、翻訳装置が公開IPv4を利用できればそれをICMPv4の送信元に使うべきとし、ない場合は192.0.0.8を使わなければならないとする。第01版には、この優先順位が明示されていなかった。
元のIPv6送信元はNode Identificationオブジェクトに入れることが推奨される。Packet Too Bigでは変換後にしか拡張を追加できず、追加しない実装も認められるが、エラー自体は返すべきだ。IANAの登録簿は192.0.0.8/32をダミーアドレスと記している。

返信を出す住所と、エラーを起こした場所は違う

IPv4の通信がIPv6専用の区間を通ると、その途中からICMPv6の到達不能、時間超過、Packet Too Bigが返ることがある。エラーの外側のIPv6送信元が翻訳用プレフィックスに合わず、静的な対応も状態付きの対応もない場合、IPv4側の返信にそのアドレスをそのまま書けない。IPv4の送信元欄は32ビットだ。元のIPv6アドレスは128ビットであり、対応表もない。装置に公開IPv4がなければ、自分の公開住所を借りる手もない。

草案第4.1節は、この状況を二段階に分ける。公開IPv4アドレスまたはプールを利用できれば、RFC 6791の考え方に従ってそれを使うべきだ。利用できない場合には、ダミーの192.0.0.8を使う義務がある。旧版は変換できない送信元に対してダミーアドレスを広く推奨した。新版の分岐は、公開IPv4を持つ翻訳装置と持たない翻訳装置を区別する。欠けている資源を現場にあるかのように扱わず、エラーの返送経路を残す。

この数字には、ほかの機器を指す権限はない。IANAの特殊用途アドレス登録簿は192.0.0.8/32をIPv4 dummy addressと呼び、送信元としての使用を認める一方、宛先として有効、転送可能、全世界から到達可能とはしていない。診断画面にこれが表示されても、経路上に「192.0.0.8というルーター」が実在すると読むのは誤りだ。表示されているのは、元の送信元をIPv4欄に書けなかった翻訳の痕跡である。

元のIPv6アドレスを運ぶには別の欄が要る。草案はNode IdentificationオブジェクトとIP Addressサブオブジェクトを追加するよう推奨する。追加するなら元のIPv6送信元を含め、拡張ヘッダーのチェックサムも更新しなければならない。IPv6送信元が普通に変換できる場合は、ダミーアドレスもこの追加拡張も使ってはならない。正常な対応があるケースを、わざわざ後備経路として見せかけないためだ。

ただしパケットの中に情報があっても、運用者の画面に出るとは限らない。草案第8節はtracerouteなどのツールがNode Identificationを解釈して表示する必要を挙げる。ツールがIPv4送信元だけを読めば、画面に残るのはダミーの番号だけだ。パケットを作る翻訳装置と、証拠を見せる診断ソフトが別々に仕事をする。

Packet Too Bigは都合のよい順序を許さない

Packet Too Bigは送信側に適切なパケットサイズを知らせるエラーだ。これを落とせば必要な調整の手がかりが失われる。ところがICMPv6 Packet Too Bigには、必要な拡張を変換前に付けられない。草案は、まずICMPv4へ変換し、その後にNode Identificationを追加する順序を示す。実装はこの場合に拡張を省いてもよい。それでもダミー送信元でエラーを翻訳し、捨てないことが推奨される。

その結果、IPv4側はサイズの知らせを受けても、誰が送ったかを完全には知らないことがある。知らせを届ける役と発信元を特定する役を分けて考えれば、これは欠陥を隠す表現ではない。付加的な身元情報を入れられない場面で、基礎的な診断を犠牲にしない判断だ。

適用対象を見分ける仕事も残る。翻訳済みのIPv4通信から生じたICMPv6と、普通のIPv6通信から生じたICMPv6を区別しなければならない。専用のIPv6アドレスや/64を使えば区別しやすい。両方に同じIPv6アドレスを使う構成なら、状態の保持や元のパケットヘッダーの検査が必要になりうる。登録簿にダミー番号があるだけでは、この分別はできない。

Datatrackerの現在の表示は、IESGに提出されAD評価中の作業部会Internet-Draftだ。承認されればRFC 6791とRFC 7915を更新する構想で、IANAへの新規割当要求はない。実装のパケット記録は本文に示されていない。既存のNode Identification記事が一般的な開示方針や未知AFIの読み取りを扱ったのに対し、ここでは公開IPv4を持たない翻訳装置の送信元選択とエラーの生存を問う。