要約

  • RFC 4008はインターフェースを中心にNATの設定、サービス分類、状態を整理した。RFC 7658は、その前提が多くの実装に適合しなかった理由を明記した。
  • NATV2-MIBは共通の書き込み可能な設定面を縮小する一方、論理インスタンス、アドレス領域、加入者、プール、状態を観測する情報を広げた。

最初の行は変換ルールではない

RFC 4008が示すSNMPによる設定手順は、natInterfaceTableに行を作るところから始まる。管理者は既存のifIndexを知り、そのインターフェースがプライベート側かパブリック側かを登録しなければならない。次に、同じインデックスに結びつけたアドレスマップを作り、最後にデフォルトのタイムアウトを設定する。つまり、このモデルの最初の問いは「どんな変換か」ではなく、「どのインターフェースにNATを結びつけるか」だった。

これは観測しやすい構成ではある。パケットは装置のインターフェースを通過し、運用者はそこを境に異なるアドレス領域を区別できる。RFC 4008は、インターフェース、アドレスマップ、そこから派生するアドレス／ポートのバインド、プライベート側とパブリック側のセッションを表すテーブルを連ねた。統計値とタイムアウトも定義し、設定と監視の両方を担うMIBを目指していた。 RFC 4008, Sections 1 and 4

しかし、物理的に見やすい境界が、あらゆる実装に共通する管理単位とは限らない。論理的なNAT機能が複数のインターフェースにまたがることもある。ひとつのマッピングを複数のインターフェースに関連付ける実装もある。装置内部に単一のインターフェース対応関係が存在しない場合、MIBを埋めるためだけにその関係を作らせることになる。

2015年の規格による自己診断

RFC 7658は、旧NAT-MIBのオブジェクトを非推奨にした理由を具体的に説明する。NATのアルゴリズムやデータ構造は実装ごとに大きく異なり、設定パラメーターも互換性を欠いた。そのため完全準拠を主張できる実装は少なかった。タイムアウトなどの設定値を読み取り専用にしても基本的な準拠を主張しにくかったという。規格の教訓は、MIBは可能な限り読み取り専用とし、NATの設定を広く公開する目的にしないことだった。 RFC 7658, Section 3

インターフェースとの結びつきも独立した問題だった。RFC 7658によれば、多くの実装はマッピングがどのインターフェースに対応するかを追跡していないか、ひとつのマッピングを複数のインターフェースに関連付けていた。ところがRFC 4008では、ifIndexがインターフェース表だけでなくマップ、バインド、セッションの構造にも入り込んでいる。内部モデルにその関係がなければ、期待された行を適切に表現できない。そこでRFC 7658は、NATをインターフェースから独立し得る論理機能と位置づけた。

サービス分類とプロトコル番号にも同じ緊張が見える。RFC 4008はbasicNat、napt、bidirectionalNat、twiceNatを使った。RFC 7658は、実装によって分類が異なるか、そもそも分類がないため、この区分は曖昧だと述べる。これはRFC 3489のコーン型NAT分類ではなく、旧MIBのサービス分類である。後継MIBはRFC 4787のNAT動作の用語を参照した。プロトコルについても、other、ICMP、UDP、TCPという独自の列挙値ではDCCPやSCTPを自然に扱えない。NATV2-MIBはIANAの標準プロトコル番号を用いる。

オブジェクトを増やすのではなく、軸を変える

2015年の移行は二つの規格文書に分かれた。RFC 7658はRFC 4008の定義を残しつつ、オブジェクトの状態をdeprecatedに変えた。RFC 7659はNATV2-MIBを新たに定義する。旧オブジェクト識別子が新しい意味を持つかのような再解釈は行われない。 RFC 7658 RFC 7659

NATV2-MIBの主な用途は監視だ。読み取り専用の設定情報は、状態や統計を解釈するために必要な範囲まで絞られた。書き込み可能な設定も、通知の生成制御とNATリソースの割当上限を除いて取り除かれた。制御がなくなったわけではない。資源を守る制限は残る。変わったのは、異なる変換エンジンをひとつの共通設定画面で動かそうとする約束をやめたことだ。

モデルの中心は論理NATインスタンスになった。マッピングはインターフェースではなく、インスタンスとアドレス領域、プロトコル、プール、加入者との関係で把握する。ひとつの装置で複数のインスタンスを扱い、任意の数のアドレス領域を表せる。CGNでは、加入者が公開アドレスやポートを共有し、インスタンスごとに資源の枠を分けることがあるため、こうした区別が運用上の意味を持つ。

ポートマップのインデックスも、外部から観測できるパケット情報を出発点に内部エンドポイントを調べやすくするため改められた。これは管理や調査の手がかりであって、加入者の実在性を証明したり、パケットの到達やアプリケーションの成功を保証したりするものではない。 RFC 7659, Sections 2 and 3

RFC 6888は共有資源の背景を示す。CGNでは複数加入者がポートや状態メモリーを共有するため、加入者ごとの上限を設けることで過度な消費を抑えられる。NATV2-MIBは加入者を認識し、こうした限界や関連カウンターを管理モデルに含めた。だが各事業者がどのオブジェクトを使い、どう閾値を決め、どんな結果を得たかは規格だけからは分からない。 RFC 6888, Sections 4 and 5

管理レコードはサービス結果ではない

この変更は、管理モデルの抽象化を修正した事例である。RFC 4008は共通の表を介してNATを設定しようとした。RFC 7658は、インターフェースという単位、公開する設定値、サービス分類、閉じたプロトコル列挙が多くの実装に合わない理由を記した。RFC 7659は共通の書き込み面を小さくしながら、論理インスタンスと共有状態の観測を広げた。

ここから導けるのは、管理モデルがより広い実装を表すために変わったという限定的な結論だ。すべてのベンダーがNATV2-MIBを実装したとも、普遍的に普及したとも、変換性能が改善したとも言えない。RFC 7659は最初のNAT-MIBがあまり実装されなかったと述べるが、比率は示しておらず、後継MIBの普及も測定していない。

ファイアウォールとの境界も明示されている。RFC 4008とRFC 7658はいずれも、これらのMIBはファイアウォール機能を対象とせず、その設定や監視に使ってはならないとする。NATのマッピング行はフィルタールールの代わりにはならない。

さらに、管理オブジェクトはサービスの結果ではない。設定済みのプールは稼働中のマッピングではなく、加入者インデックスは本人確認ではない。カウンターの差分は連続性の時刻と併せて解釈する必要があり、通知もパケット到達を証明しない。NATV2-MIBが管理視点を整えても、設定、現在状態、転送、端末の同一性、アプリケーションの結果は別々の問いとして残る。

歴史的な教訓は限定的で実務的だ。管理規格は、実装ごとの制御を共通インターフェースに押し込めると、かえって標準準拠を難しくする。RFC 7658はインターフェース表に列を足すのではなく、何を管理対象にするのかを問い直した。後継MIBは普遍的な設定を減らし、論理インスタンスの文脈を見えるようにした。問いは「どのインターフェースがこのマップを所有するか」から、「どのNATインスタンス、領域、加入者、プール、状態をこの観測が表すか」へ移った。

出典