Summary

  • IETFは11月2日、draft-ietf-v6ops-nat64-wkp-1918-10をLast Callにかけた。意見の締め切りは11月23日。
  • 案は共通プレフィックスを使った私設IPv4宛て通信の変換を認める。今回追加された第4.3節は、管理型変換器がその初期動作を示せるよう勧告する。

捨てる規則が作った見えない境界

RFC 6052の第3.1節では、64:ff9b::/96に私設などの非グローバルIPv4アドレスを埋め込んだパケットを変換器が捨てる。IPv6だけの端末から社内のIPv4サービスへ向かう経路では、この共通プレフィックスをそのまま使えない。

11月2日の告知が意見を募る第10版は、RFC 1918の私設アドレスやRFC 6598の共有アドレスを共通プレフィックスで表現できるようにする。管理されない端末側CLATは原則として変換し、事業者側PLATも設定で止めない限り変換する。PLATには無効化の設定項目を設ける。従来の一律廃棄を、現場で選ぶフィルタと経路の問題に移す案だ。

端末で二つのプレフィックスを使い分ければ済む、という話にもならない。案の説明では、普及しているNAT64プレフィックス発見手段は、どのIPv4範囲にどちらを使うかまで伝えない。二つを見つけた端末はグローバルな宛先まで両方で合成し得る。草案は既存CLATの挙動が割れているとも述べるが、製品別の台数は示さない。

新しい一節は機器の「性格」を聞く

第9版には既に規則変更の骨格があった。第10版で加わった4.3節は、管理型変換器が非グローバル宛ての初期値を外から確認できる仕組みを勧める。運用者には、明示設定や監視によって意図した方針と実際の変換を照合するよう求める。パケットを転送するなら、変換器と周辺ルータの経路方針も要る。

第5節は古い機器への配慮を同時に書く。RFC 6052に従って初期状態で捨ててきた管理型PLATは、更新だけでその初期値を変えるべきではないという。新しい仕様の方向と、既設装置を守る移行手順を同時に読む必要がある。

現場で必要なのは「NAT64対応」の表示より具体的な記録だ。機種と版、初期値、設定した例外、到達可能な私設宛先、ACL、試験時のパケットの行方。個別のネットワークについては、この設定と試験の記録がまだ示されていない。これがあれば実際にどの門が開くか判断できる。

Sources