この文書はRFC 5780の日本語訳(和訳)です。この文書の翻訳内容の正確さは保障 できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者 はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻 訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の 配布は元のRFC同様に無制限です。 Internet Engineering Task Force (IETF) D. MacDonald Request for Comments: 5780 B. Lowekamp Category: Experimental Skype ISSN: 2070-1721 May 2010 NATのためのセッショントラバーサルユーティリティ(STUN)によるNAT挙動検出 要約 この仕様は、STUNクライアントとSTUNサーバ間のNATsとファイアウォールの 存在と現在の挙動を検出する、Session Traversal Utilities for NAT (STUN)プロトコルの実験的な用法を定義する。 このメモの位置づけ この文書はインターネット標準トラック仕様書ではない。それは試験、実験 的実装、および評価のために発行される。 この文書はインターネットコミュニティのための実験プロトコルを定義す る。この文書はthe Internet Engineering Task Force (IETF)の成果であ る。それはIETFコミュニティの合意を示す。それは、公開レビューを受け て、発行のためにthe Internet Engineering Steering Group(IESG)によって 承認された。IESGで承認されたというわけではない全ての文書が、インター ネット標準のいかなるレベルの候補である。RFC 5741の2章を参照のこと。 この文書の現在の状態、正誤表、そしてそれのフィードバックをどのように 提供するかに関する情報を、http://www.rfc-editor.org/info/rfc5780 で得 ることができる。 MacDonald & Lowekamp Experimental [Page 1] RFC 5780 NAT Behavior Discovery May 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. MacDonald & Lowekamp Experimental [Page 2] RFC 5780 NAT Behavior Discovery May 2010 目次 1. 適用範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 要求用語 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. 前置き . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. 診断の使用例 . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. P2Pオーバレイでの使用例 . . . . . . . . . . . . . . . . . 7 2.3. 実験の目標 . . . . . . . . . . . . . . . . . . . . . . . . 8 3. 操作の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. NATマッピングの判定 . . . . . . . . . . . . . . . . . . . 10 3.2. NATフィルタリングの判定 . . . . . . . . . . . . . . . . . 10 3.3. バインディング存続期間検出 . . . . . . . . . . . . . . . . 10 3.4. NATヘアピニングの診断 . . . . . . . . . . . . . . . . . . 11 3.5. フラグメント取り扱いの判定 . . . . . . . . . . . . . . . . 11 3.6. 汎用アプリケーションレベルゲートウェイ(ALG)の検知 . . . . 11 4. 検出処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. 送信元ポート選択 . . . . . . . . . . . . . . . . . . . . . 12 4.2. STUNサーバとのUDP接続性のチェック . . . . . . . . . . . . 13 4.3. NATマッピング挙動の判定 . . . . . . . . . . . . . . . . . 14 4.4. NATフィルタリング挙動の判定 . . . . . . . . . . . . . . . 14 4.5. テストの結合と順番 . . . . . . . . . . . . . . . . . . . . 15 4.6. バインディング存続期間検出 . . . . . . . . . . . . . . . . 15 5. クライアントの挙動 . . . . . . . . . . . . . . . . . . . . . . 17 5.1. 検出 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. セキュリティ . . . . . . . . . . . . . . . . . . . . . . . 18 6. サーバの挙動 . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. レスポンスの準備 . . . . . . . . . . . . . . . . . . . . . 18 7. 新しいアトリビュート . . . . . . . . . . . . . . . . . . . . . 20 7.1. トランスポートアドレスの表現 . . . . . . . . . . . . . . . 21 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 21 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22 7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 22 7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. IABの検討事項 . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. 問題定義 . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. 出口戦略 . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.3. STUN NAT挙動検出でもたらされる不確実さ . . . . . . . . . . 24 8.4. 長期的な解決策への要求 . . . . . . . . . . . . . . . . . . 24 8.5. 現存するNAPT装置での問題 . . . . . . . . . . . . . . . . . 24 9. IANAの検討事項 . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. STUNアトリビュートレジストリ . . . . . . . . . . . . . . . 25 9.2. ポート番号/SRVレジストリ . . . . . . . . . . . . . . . . . 25 10. セキュリティの検討事項 . . . . . . . . . . . . . . . . . . . . 25 11. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. 規範的な参考文献 . . . . . . . . . . . . . . . . . . . . . 26 12.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . 27 MacDonald & Lowekamp Experimental [Page 3] RFC 5780 NAT Behavior Discovery May 2010 1. 適用範囲 この実験的なNAT挙動検出STUN用法は、NAT装置の観察できる過渡的挙動の情 報を提供する。それは、テストが実行される時に使用していたSTUNサーバと 使用していた特定のクライアントポートに関するNATの挙動を判定する。この STUN用法で、NAT配下のアプリケーションはNATの特性の絶対的な判定を行う ことができない。NAT装置には将来の挙動を予測した様に十分矛盾なく振る舞 うどんな保証もない。2つの特定のエンドポイント間で信頼できるリーチを必 要とするアプリケーションは、別のテクニックを使用してNATを通り抜ける通 信チャネルを確立しなければならない。IETFは、パブリックに利用できるラ ンデブーサービスが利用可能であるときに、通信チャネルを確立するための [RFC5245]と[RFC5626]を含む標準を提案した。 この文書に含まれているSTUNアトリビュートの想定された用途は、アプリ ケーションの診断とリアルタイムチューニングである。例えば、どんな動作 をする可能性があるか、何を最初に試すべきかの判定は、よりコストの高い 方法と比較された。そのアトリビュートもまたアプリケーションの通信が失 敗を引き起こす挙動を観察するのに使用され、それ故、回復方法のより良い 選択を可能とする。また、そのSTUNアトリビュートは、NATの挙動を観察する ための、ネットワーク技術者の診断ツールの基盤になるかもしれない。 この文書は、パブリックに利用できるランデブーサービスが利用可能でない 状況におけるプロトコル用のパラメータのリアルタイム最適化のために、こ れらのアトリビュートの実験的用法を提案する。これらのテクニックのその ような利用法は結果が最適化として適用されるときにだけ可能であり、そし て、信頼性のあるフォールバックはNATの挙動が挙動検出テストで判定された ものより制限が厳しくなったときに利用可能である。1つの応用可能性は、さ まざまなピアと、直接接続を確立したりNATの挙動を診断したりすることでの 統計的な経験に基づくピアツーピア(P2P)ネットワークでの役割選択である。 実験の論点はそのようなテストが役に立つかどうかということである。NATが 十分な接続性を妨げている時に完全なピアとしてオーバレイを参加しようと しているノードを考えてみよう。参加やオーバレイからの離脱が高コストに なったり、不信頼性や操作の不十分な実行を招いたりするかもしれない。た とえ挙動検出チェックが75%の割合で"正しい"だけでも、相対的に低コストで オーバレイネットワークの挙動の最適化に非常に役立つようになるかもしれ ない。2.2節は、さらに詳細にこの実験的応用について説明して、成否を評価 する方法を論じる。 このSTUN用法の応用は、STUN(元々のRFC 3489 [RFC3489]、現在のRFC 5389 [RFC5389])の本来の利用法と異なる。この仕様書は、この用法で集められた 情報が100%の割合で正しくなく、かつ正しくすること出来ないことを認めて MacDonald & Lowekamp Experimental [Page 4] RFC 5780 NAT Behavior Discovery May 2010 いて、STUNは正しくかつ静的であると知ることができた情報を得ることにだ け焦点を合わせていた。 また、この仕様をICEと比較するとよい。ICEはTURNへのフォールバックが利 用可能であることを要求するが、RFC 3489ベースのアプリケーションは、そ れらがリレーが必要かどうか、それらのピアリフレクシブアドレス(通常どち らかが達成可能ではない)が何になるかを前もって判定しようとした。 このSTUN用法は、それを使用するアプリケーションがフォールバックの仕組 みを持つことを要求する。しかしながら、VoIPセッションでの固有の問題に 関するICEの焦点と異なって、このSTUN用法は1組のマシン間の接続を確立す るためにそれが使用されると仮定しないので、代替のフォールバック機構が 利用可能であるだろう。 例えば、P2Pアプリケーションで、ピアが、実際に、その接続の10%が失敗を 試みているのを検出しているなら、そのような接続が確立される必要がある か、もしくは代替の間接経路を選択することが必要がある役割から単純に切 り替えるのは可能であるだろう。 適切な統計的基礎や、最終的に経験を積んだ接続性パターンに基づくアプリ ケーションの挙動に適用されるときに、供給する知識なしで利用可能である ことよりも安定性向上と性能改善を導くことができる実験的なプロトコルと して、インターネットコミュニティに寄託される。 標準トラック文書がこのSTUN用法のどこかの部分の利用法を規定するなら、 その文書はこれらの方法を使用して得られた不正確な情報がどのように管理 されるかを、NATの挙動がいつ変化したかを特定することを通じてか、もしく はNATの挙動が変化するときに機能を維持するのではなく最適化としてプロト コルがそのような知識を使用することのいずれかで、記述しなければならな い(MUST)。また、参照する文書はフォールバック機構がいつ呼び出されるか を定義しなければならない。フォールバック機構がどれくらい積極的に利用 されているかで異なったドメインにあるアプリケーションが大いに異なるも のになるかもしれないので、フォールバック機構が呼び出される時に関する 明確な定義がなければならない(MUST)。 1.1. 要求用語 この文書中のキーワード "しなければならない(MUST)", "してはならない( MUST NOT)", "要求されている(REQUIRED)", "することになる(SHALL)", "す ることはない(SHALL NOT)", "する必要がある(SHOULD)", "しないほうがよい (SHOULD NOT)", "推奨される(RECOMMENDED)", "してもよい(MAY)", と"選択 できる(OPTIONAL)" は、RFC 2119 [RFC 2119]に記述されている様に解釈され る。 MacDonald & Lowekamp Experimental [Page 5] RFC 5780 NAT Behavior Discovery May 2010 2. 前置き "NATのためのセッショントラバーサルユーティリティ (STUN)" [RFC5389] は、Bindingリクエストを使用して、STUNサーバの方へのリフレクシブトラン スポートアドレスを検出するためのメカニズムを提供する。この仕様書はNAT 挙動検出STUN用法を定義して、これでSTUNクライアントはクライアントと STUNサーバ間のNAT/ファイアウォール(NAT/FW)装置の現在の挙動を調べるこ とができる。この用法はBindingリクエストとBindingレスポンスに新しい STUNアトリビュートを定義する。 多くのNAT/FW装置は一貫した振る舞いをせず、負荷時や時間が経つと、それ らの挙動を変えるだろう。高信頼性を必要とするアプリケーションは、NATの 挙動がより制限されるようになることに準備しなければならない。特に、負 荷時にNATsが最も制限されたフィルターとマッピングの挙動に遷移したり、 新しいバインディングや既存のものの存続期間を短くするのが見られた。要 するに、アプリケーションは、現在状況がどれくらい悪くて、状況がどれく らい悪くならないかを検出できる。 この制限にもかかわらず、瞬間的な観測はネットワーク問題のトラブル シューティングで頻繁に役に立ち、そして長い時間を掛けたり、既知の負荷 状態で繰り返されたテストは、NATの挙動の特性を示すのに用いることができ る。特に、アプリケーションのニーズとアプリケーションが通信する必要が あるノードに関して博識な人の手中では、それは強力なツールでありうる。 2.1. 診断の使用例 実験室でうまく動作するが、展開で失敗するアプリケーションは、分散シス テムにおいては悪名高くよくある。どんな実ネットワークの挙動が実験室で 見逃されたかについての洞察のために、環境の違いを判定する調査経験を持 たないシステム開発者は殆どいない。挙動検出用法は、アプリケーションが 実行中のNATとファイアウォールの挙動をチェックするのに使用できる強力な ツールを提供する。例えば、実行中に重大な通信問題に直面したときはす ぐ、挙動検出テストを実行するようにアプリケーションを設計できるかもし れない。そのような分析はアプリケーションで記録された診断情報の一部と して含めてもよい。 それらが経験豊富な開発者や管理者による分析を目的として瞬間的な挙動を 検知するのに使用されているので、NAT挙動検出STUN用法のこのアプリケー ションに関する心配は比較的わずかしかない。しかしながら、ユーザは以下 を知っているべきだ。 o 新しい宛先(STUNサーバ)への新しいトラフィックを加えること、それ自身 がNATの挙動を変える可能性があること、そして、 MacDonald & Lowekamp Experimental [Page 6] RFC 5780 NAT Behavior Discovery May 2010 o ユーザは、アプリケーションが直面したネットワーク状態に結果が適切と なるように、適切に設置されているSTUNサーバを選択すること、つまり問 題のアプリケーションの通信相手と理想的に配置されている(もっと言え ば、統合されている)ことに、気を付けなければならない。 2.2. P2Pオーバレイでの使用例 アプリケーションは、特定のエンドポイントがピアかスーパーノード(オーバ レイネットワークの他のメンバーやクライアントにメッセージルーティング を含めた、サービスを提供する、オーバレイ内のピアとここで定義する)とし て参加するために妥当な候補であるかどうかを判定するのに、P2Pプロトコル で挙動検出を使用することができる。このP2Pネットワークアプリケーション は、専用サーバの費用を避けるためにNATs配下に配置されているかもしれな いスーパーノードを選択しても構わない。スーパーノードの候補は、その NAT、あるいはNATs(訳注:経路中にある複数のNAT機器全体としてのNAT)がエ ンドポイント非依存フィルタリングを提供することを要求する。定期的にテ ストを再実行してもよく、その一連のNAT/FWがこの特性を失ったなら、スー パーノードとしてそれ自身を削除することになる。これらのテストは、専用 STUNサーバで実行されるのと同様に、STUNサーバとして作動する他のスー パーノードで実行されることもあり得る。多くのP2Pアルゴリズムがピアの一 部分間の非透過な接続性を許容するように、2点間で保証された確実なリーチ は、ユーザの大部分が直接連絡できるピアを経由するP2Pオーバレイの負荷を 分散するために犠牲にされるかもしれない。 さらに仮定しているP2Pプロトコルからの例を詳細に考えてみよう。P2Pノー ドAが起動するとき、それは既にオーバレイにいる他のピアに関連するNAT(s) をテストする。テストの結果が、Aが"良い"NAT(エンドポイント非依存マッピ ングかつフィルタリング)下であるのを示すなら、Aはオーバレイに参加し て、オーバレイのトポロジーに参加するために、オーバレイにいる適切なピ アと接続を確立するだろう。Aはメッセージをルーティングすることでオーバ レイトポロジー全体に到達可能ではあるが、Aもまた、Aが最初のテストで検 出したリフレクシブIPアドレス(あるいはアドレス群)を使用することで直接A に到達することができる他のノードとの通信に含まれるだろう。後者を仮定 して、ノードBがAにメッセージを送りたがっていて、Bがオーバレイトポロ ジーでAの隣接ノードでないとする。BはAのIPアドレスにメッセージを直接送 信して、タイマーを始動するだろう。Bがある時間以内にレスポンスを受信し ないなら、それからその代わりに直接接続を試みたが失敗したのを示すフラ グを含めて、オーバレイを経由してAにメッセージを転送する。(あるいはま た、Bはオーバレイを経由してAのIPアドレスにメッセージを同時に送信する ことができ、それは最小レスポンス遅延を保証するが、帯域幅を浪費する可 能性がある。)長い期間をかけて、Aは試みられたものの中からAが受信した直 接メッセージの成功割合を観測する。直接接続の成功割合がある閾値(おそら く75%)未満であるなら、直接メッセージを試みるコストを正当化するために 十分信頼できる接続性をNATsが実際には提供していないことが判明している MacDonald & Lowekamp Experimental [Page 7] RFC 5780 NAT Behavior Discovery May 2010 ので、Aは直接接続を広告するのを止めてもよい。しかし、割合が十分高いな ら、成功した直接接続がオーバレイに課されたルーティング負荷を減らすこ とによってオーバレイの性能を向上させているので、Aは広告し続ける。ある 時点で、AのNATもしくはNATsが挙動を変えるなら、Aは直接接続の成功割合の 変化に気付いて、パブリックアドレスを広告するという決定を再評価するか もしれない。この仮説例では、挙動検出はAの初期動作モード選択に使用され るが、そのパブリックIP/ポートの対を広告し続けるかどうかの実際の決定 は、実際の動作データに基づいてなされる。試みられた直接接続が失敗する 場合、Aはいつもオーバレイを通じて接続性を確立できるので、挙動検出用法 の結果は性能最適化としてもまた使用される。 そのようなアプリケーションのための挙動検出の利用は以下を要求する。 o ノード対間の信頼性の無いリンクを使用している間に、信頼性のあるエン ドユーザ性能を提供できるプロトコルの利用。 o 挙動検出調査の結果に基づいて試みられた接続に、信頼性のあるフォール バックを提供するプロトコル。 o エンドポイント非依存フィルタリングを提供して、アプリケーションがそ れらの挙動を特定できるまでの時間はこのモードのままでいるNATs配下に 配置されて、オーバレイの残りの部分にこの情報を配信して、アプリケー ションに有益な労力を提供するアプリケーション。 公開プロトコルを実装しているアプリケーションが、これらの3つの要求を満 たしているのを示すためのそのような環境にまだ展開されていないというこ とで、この文書は実験的である。しかしながら、事例証拠は、家庭と中小企 業をターゲットにしたNATsが、特にそれらの配下にわずかなクライアントし かいないとき、安定した挙動を取ることを示す。多数のP2Pアプリケーション は、それらのプロトコルが標準化団体によってまだ厳格な評価にかけられて いないが、これらの特性を持つように展開されている。 2.3. 実験の目標 アプリケーションがNAT挙動検出STUN用法の用途をうまく示す基準は、以下が 挙げられるだろう。 o そのネットワーク接続で直面したことに基づいてその後調整されるオプ ションの初期選択肢を決定するのにたいがいそれを使用する、実行時の挙 動を判定するためにこの用法を当てにする実装。 MacDonald & Lowekamp Experimental [Page 8] RFC 5780 NAT Behavior Discovery May 2010 o 複数のIPアドレスを持つ専用STUNサーバ群をプロバイダが配置するのを期 待するのが現実的である環境での適用性を示さなければならないか、もし くは、この用法で要求されたアドレス変更操作を提供する役割を共有する 2ノードでそのような専用STUNサーバの挙動を再現することを示さなけれ ばならないかのいずれかの実装。 o この用法のアプリケーションが現実世界の状況におけるアプリケーション の改善された挙動をもたらす実験的根拠。この改善のための正確な測定基 準は異なるかもしれなく、いくつかの可能性は次のものがある。適切なパ ラメータへのより速い収束、初期接続を張るためのより少ない作業、起動 後に要求されるより少ない再構成、など。 o 実装がどのようにこの用法を適用するかを定義するプロトコル仕様。 上で説明されたP2Pシナリオはこの用法の適当な実験的テストケースだが、他 の応用も可能である。 3. 操作の概要 典型的な構成では、STUNクライアントはプライベートネットワークに接続さ れ、1つまたはそれ以上のNATを通ってパブリックインターネットに接続され る。クライアントはパブリックインターネット上にあるSTUNサーバのアドレ スを設定される。挙動検出用法は、サーバがこの用法に他の用法とは異なっ たトランスポートアドレスを使用できるように、SRVレコードを利用する。こ の用法はクライアントにもサーバにもRFC 3489 [RFC3489]との後方互換性を 提供しない。RFC 3489サーバに準拠したいクライアントの実装者はその仕様 書を見る必要がある。サーバの実装者は、そのプロトコルのオリジナルの利 用法が推奨していないので、RFC 3489クライアントのサポートを入れないほ うがよい(SHOULD NOT)。 STUNはサーバにクライアントへの新しいTCPやTCP/TLS接続の生成を許さない ので、多くのテストがUDPだけに適用される。様々なテストの適用性は以下に 示される。 STUN NAT挙動検出用法は、STUN BindingリクエストとSTUN Bindingレスポン スに新しいアトリビュートを定義して、これらのメッセージをクライアント とサーバ間のNATの現在の挙動を診断することに使用できるようにする。 この章はこれらのアトリビュートの典型的な使用法についての記述的概要を 載せる。挙動規定は5、6、および7章に記述される。 MacDonald & Lowekamp Experimental [Page 9] RFC 5780 NAT Behavior Discovery May 2010 3.1. NATマッピングの判定 NAT配下のクライアントは、そのNATが現在、エンドポイント非依存、アドレ ス依存、またはアドレス/ポート依存マッピング[RFC4787]であるかどうかを 判定したい。クライアントはOTHER-ADDRESSアトリビュートを利用する一連の テストを実行する。これらのテストは4章で詳細に説明される。これらのテス トはマッピング挙動を判定するためにSTUNサーバの代替アドレス/ポートに Bindingリクエストを送信する。UDP、TCP、あるいはTCP/TLS接続にこれらの テストを使用できる。 3.2. NATフィルタリングの判定 NAT配下のクライアントは、そのNATが現在、エンドポイント非依存、アドレ ス依存、またはアドレス/ポート依存フィルタリング[RFC4787]であるかどう かを判定したい。クライアントはOTHER-ADDRESSとCHANGE-REQUESTアトリ ビュートを利用する一連のテストを実行する。これらのテストは4章で説明さ れる。これらのテストはSTUNサーバの代替アドレス/ポートからのレスポンス を要求する。これらのテストへの前提条件はバインディングが代替アドレス/ ポートに確立されないことである。詳しい情報は以下を参照のこと。NATは代 替アドレス/ポートがプライマリアドレス/ポートと同じサーバの所有物であ ることを知らないので、インターネット上のその他のホストからのものと同 じようにこれらのレスポンスを処理する。したがって、代替アドレス/ポート から送信されたBindingレスポンスの成功は、NATが現在、エンドポイント非 依存フィルタリングか、アドレス依存フィルタリングか、アドレス/ポート依 存フィルタリングであるかどうかを示す。このテストはUDPデータグラムにだ け適用される。 3.3. バインディング存続期間検出 VoIPなどの多くのシステムは、クライアントとサーバ間、もしくはP2Pシステ ムのピア間で接続を開き続けられることをを当てにする。NATバインディング は時間とともに期限が切れるので、それを維持するために接続の向こう側に キープアライブメッセージを送らなければならない。キープアライブがネッ トワークとサーバに何らかのオーバーヘッドを与えるので、キープアライブ の頻度を減らすことは有用な可能性がある。 最初のリクエストがバインディングタイマーをリセットするので、バイン ディング存続期間をテストするのに通常のリクエスト/レスポンスプロトコル を使用できない。挙動検出は、クライアント上に割り当てられた別のポート のバインディング存続期間をテストするのに使用されるクライアント上の1 ポートを使用する"制御チャネル"を、クライアントとサーバが張れるように するために、RESPONSE-PORTアトリビュートを定義する。より大まかには、 RESPONSE-PORTは、クライアントが2つのポートを割り当てて、片方のポート から送信されたクエリへのレスポンスがもう片方のポートに送られるよう要 求できるようにする。クライアントは、クライアント上でトラフィックを送 MacDonald & Lowekamp Experimental [Page 10] RFC 5780 NAT Behavior Discovery May 2010 信しない既存のバインディングが時刻T後にまだ開いているかどうかチェック するのに、その2番目のポートとSTUNサーバの代替アドレスを使用する。この アプローチを4.6節で詳細に説明する。このテストはUDPデータグラムだけに 適用される。 3.4. NATヘアピニングの診断 STUN Bindingリクエストは、クライアントが、接続のヘアピニングをサポー トするNAT配下であるかどうかを判定できるようにする。このテストを実行す るために、クライアントはまずマップドアドレスを判定するためにSTUNサー バにBindingリクエストを送信する。そして、クライアントはSTUN Bindingリ クエストを異なるポートからこのマップドアドレスに送信する。クライアン トがそれ自身のリクエストを受け取るなら、NATは接続をヘアピンする。この テストはUDP、TCP、あるいはTCP/TLS接続に適用される。 3.5. フラグメント取り扱いの判定 あるNATsは、シングルフレームのデータグラムをフォワードするときと、フ ラグメントをフォワードするときとでは異なった挙動を示す。特に、ある NATsはフラグメントを全くヘアピンせず、あるプラットホームは負荷時にフ ラグメントを破棄する。この挙動を診断するために、STUNメッセージを、 メッセージに追加スペースを単に挿入するだけの、PADDINGアトリビュート付 きで送信することができる。STUNメッセージが複数のフラグメントに分割さ れることを強制することで、NATの挙動を観測できる。 NATのフラグメントの挙動がアプリケーションにとって重要であるなら、これ までのすべてのテストをPADDING付きで実行するか、もしくはアプリケーショ ンが最も興味があるそれらのテストだけ再テストできる。PADDINGはUDPデー タグラムにだけ適用する。PADDINGはRESPONSE-PORTと共に使用できない。 3.6. 汎用アプリケーションレベルゲートウェイ(ALG)の検知 多くのNAT装置が現在、"汎用"ALG機能を提供しようとして市場に展開されて いる。これらの汎用ALGsは、パケット中にあるテキストまたはバイナリ形式 のIPアドレスを探して、それらがバインディングに一致するなら、それらを 書き換える。STUNサーバは同一レスポンスでMAPPED-ADDRESSとXOR-MAPPED- ADDRESSの両方を返すので、この挙動を検知できる。その二つの結果が一致し ないなら、経路中に汎用ALGを持つNATがある。このテストはUDPとTCPに適用 されるが、TLS over TCP接続には適用されない。 4. 検出処理 この章は、配下にアプリケーションがあるNAT、もしくはNATsの、現在の挙動 を、NAT挙動検出用法プリミティブがチェックでどのように検出させるかに関 する記述的概要を提供する。これらのテストはNATの瞬間的な挙動を知らせる ことができるだけであり、NATsは負荷と時間が経つにつれて挙動を変える可 能性があることがわかっている。したがって、これらのテストの結果を上限 MacDonald & Lowekamp Experimental [Page 11] RFC 5780 NAT Behavior Discovery May 2010 と見なすことができる。つまり、アプリケーションは、NATの挙動がいつでも より制限されるようになる可能性があると仮定しなければならない。また、 4.1節で説明されるように、クライアント上の特定のポートを使用して実行さ れたテストからの結果は、異なるポートによって得られる挙動を示さないか もしれない。 NATフィルタリング/マッピング挙動に関する定義は[RFC4787]から来ている。 ここで説明されたテストは、UDP接続性、NATマッピング挙動、NATフィルタリ ング挙動、およびNATバインディング存続期間検出に関するものである。この 用法のメカニズムを使用して追加テストを設計できるかもしれない。以下で 説明されるテストは、一つのIPアドレスを持つクライアントを使用して実行 できるテストだけから成る。同一NAT配下で、複数のIPアドレスを持つクライ アント(もしくは協調動作する複数のクライアント)は、ポート多重のよう な、NATの挙動の付加的な側面をテストするためにそれらの調査を組み合わせ ることができる。この章はこの仕様書のSTUNアトリビュートによって規定さ れたプリミティブが、挙動テストを実行するのにどう使用される可能性があ るかについての記述的概要を載せる。 アトリビュートに関する仕様規定は後の章で定義される。 4.1. 送信元ポート選択 適切な送信元ポート選択は挙動検出テストの有用性と精度を確実にするのに 重要である。テストには以下の2つの前提条件がある。 o マッピング挙動はポート毎に異なることがあるので、アプリケーション は、可能な時はいつもアプリケーションで使用するつもりの送信元ポート を使用して、テストを実行すべきである。複数の送信元ポートを使用する つもりであるなら、各送信元ポートについてこれらのテストを繰り返すべ きである。このようなテストは、NATの負荷を減らすために順々に実行さ れるべきである。 o いくつかの診断チェックの結果が前のトラフィックで生じたNAT内の以前 の状態に左右されるので、テストは最近トラフィックを発生させていない 送信元ポートを使用して実行されるべきである。したがって、アプリケー ションはランダムな送信元ポートを使用するか、あるいは選択されたポー ト上でテストの実行前にトラフィックが全く発生していないように、一般 的にはポート割り当てまで少なくともテスト前の15分間、そのポートを未 使用にしておくべきである。 これらの前提条件の両方を確実にすることは、特に挙動検出テストを起動時 に実行したい装置やアプリケーションでは困難な可能性がある。問題の可能 性を減少させるために以下のガイドラインを提案する。 MacDonald & Lowekamp Experimental [Page 12] RFC 5780 NAT Behavior Discovery May 2010 o NAT配下で作動することを意図するアプリケーションは、特定のポートや ウェルノウンポートを割り当てることを試みるべきではない。そのような ソフトウェアは、NATでそれにどんなポートがマップされても使用して相 互接続するように設計されなければならないので、特定のポートは不要で ある。代わりに、起動時に、ランダムなポートが選択されるべきである (推奨される範囲は以下を参照)。アプリケーションは、特に組み込み機器 上で、各再スタート時に同じポートを受け取るアプリケーションの原因に なるかもしれないので、次に利用可能なポートを選択するためにホストオ ペレーティングシステムを当てにすべきではない。再スタート間で同じ ポートを使用するアプリケーションは、フィルタリングやバインディング の存続期間のような、NATsの状態に関連した挙動をテストすることを目的 とする挙動検出テストから正確な結果を受け取らないかもしれない。 o 制御とメディアのための別々のポートなど、複数のポートを必要とするア プリケーションは、可能ならば起動時にそれらのポートを割り当てるべき だ。メディアフローが即座に必要がなくても、挙動検出テストがそれらの ポートで実行されるなら、早くそれらを割り当てることがそれらを待機状 態のままにできて、挙動検出テストから正確な結果を得る可能性を増やす だろう。 o アプリケーションが使用する特定のポートでテストを実行するとき、最も 信頼できる結果を得るが、多くの場合、アプリケーションは、それらの ポートで完全な挙動検出テストを実行できずに、ポートを割り当てて使用 する必要があるだろう。そのような場合、アプリケーションはNATで同じ 扱いを受けそうな範囲からランダムにポートを選択すべきだ。この文書 は、32768-49151(IANAのレジスタードポート範囲の上の方)と49152-65535 (IANAのダイナミック/プライベートポート範囲)の範囲をランダム選択用 に推奨する。これらの範囲のポートの、NATの一般的な扱いを特徴付けよ うとするためには、範囲中の少数のポートをランダムに選択して特徴付け るとよい。 特にNATの以前の状態に影響を受けるそれらのテストを後ほど示すつもりであ る。 4.2. STUNサーバとのUDP接続性のチェック クライアントはSTUN Bindingリクエストをサーバに送信する。これはサーバ にリクエストが来たアドレス/ポートにレスポンスを返送させる。このテスト がレスポンスを得ないなら、クライアントはすぐにSTUNサーバとのUDP接続性 がないことが分かる。このテストはSTUN [RFC5389]機能だけを要求する。 MacDonald & Lowekamp Experimental [Page 13] RFC 5780 NAT Behavior Discovery May 2010 4.3. NATマッピング挙動の判定 これは多くとも3つのテストを必要とするだろう。テストIで、クライアント はUDP接続性テストを実行する。サーバはBindingレスポンス内のOTHER- ADDRESSにサーバの代替アドレス/ポートを返すだろう。OTHER-ADDRESSが返さ れないなら、サーバはこの用法をサポートしておらず、このテストを実行で きない。クライアントはXOR-MAPPED-ADDRESSアトリビュートを調べる。この アドレス/ポートが、リクエストを送信するのに使用したソケットのローカル IPアドレス/ポートと同じであるなら、クライアントはNATされていないこと が分かり、実効マッピングはエンドポイント非依存だろう。 テストIIで、クライアントは代替アドレスのプライマリポートにBindingリク エストを送信する。Bindingレスポンス内のXOR-MAPPED-ADDRESSがテストIと 同じであるなら、NATは現在、エンドポイント非依存マッピングである。同じ でなければ、次のテストIIIが実行される。クライアントは代替アドレス/ ポートにBindingリクエストを送信する。XOR-MAPPED-ADDRESSがテストIIと合 致するなら、NATは現在、アドレス依存マッピングである。合致しないなら、 それは現在、アドレス/ポート依存マッピングである。 4.4. NATフィルタリング挙動の判定 これもまた多くとも3つのテストを必要とするだろう。これらのテストはNAT の以前の状態に影響を受ける。 テストIで、クライアントはUDP接続性テストを実行する。サーバはBinding レスポンス内のOTHER-ADDRESSにその代替アドレス/ポートを返すだろう。 OTHER-ADDRESSが返されないなら、サーバはこの用法をサポートしておらず、 このテストを実行できない。 テストIIで、クライアントはCHANGE-REQUESTアトリビュートにポート変更と IP変更をセットしてサーバのプライマリアドレスにBindingリクエストを送信 する。これはサーバにその代替IPアドレス/代替ポートからそのレスポンスを 送信させるだろう。クライアントがレスポンスを受信するなら、NATの現在の 挙動はエンドポイント非依存フィルタリングである。 レスポンスが受信されない場合は、アドレス依存フィルタリングとアドレス/ ポート依存フィルタリングを見分けるためにテストIIIを実行しなければなら ない。テストIIIで、クライアントはCHANGE-REQUESTにポート変更をセットし て元のサーバアドレスにBindingグリクエストを送信する。クライアントがレ スポンスを受信するなら、現在の挙動はアドレス依存フィルタリングであ る。どんなレスポンスも受信されないなら、現在の挙動はアドレス/ポート依 存フィルタリングである。 MacDonald & Lowekamp Experimental [Page 14] RFC 5780 NAT Behavior Discovery May 2010 4.5. テストの結合と順番 クライアントは、送信されるパケット数を減らすのと検出処理の速度を上げ るために、これらのテストを結合・並列化したがっているかもしれない。例 えば、フィルタリングとマッピングのテストIは、UDPがブロックされている かどうかを同様にチェックする。その上、アプリケーションやユーザは、こ れらのサンプルテストが提供しているほど多くの詳細を必要としないかもし れない。例えば、NATが、4.3節のテストIとIIだけを必要とするエンドポイン ト非依存マッピング以外の何らかの挙動であると、ノード間の接続性を確立 するのはかなり難しくなる。NATがエンドポイント非依存マッピングを必ずし も提供するとは限らないことを判定するアプリケーションは、リレーが設定 されていない場合にユーザに通知するかもしれないのに対して、エンドポイ ント非依存マッピングを提供するNAT配下のアプリケーションは、後続の接続 が実際に失敗するまでユーザに通知しないか、あるいはリレーが設定されて いないというそれほど緊急ではない通知を行うかもしれない。そのようなテ ストは[RFC5245]の必要性を緩和しないが、リレーしない接続を確立すること が成功する見込みがあるかどうかの何らかの情報をICEが提供する。 テストを結合・並列化するとき、特定のテストがNATの以前の状態から受ける 影響の理由から、そしていくつかのNAT装置はどれくらい速くバインディング を割り当てるかに関する上限値があるので、注意しなければならない。5章は クライアントが新しいSTUNトランザクションを始めてもよい速度を制限す る。 4.6. バインディング存続期間検出 NATによって作成されたバインディングの存続期間を調べるのにもまたSTUNを 使用できる。当該テストはNATの以前の状態に影響を受ける。多くのNAT装置 に関して、絶対リフレッシュ間隔は判定できない。バインディングは、高負 荷下でより早く外されるかもしれないし、テストが示すように振る舞わない かもしれない。この理由で、信頼できるバインディングを必要とするアプリ ケーションは、通過するすべてのNAT装置で要求される間隔でキープアライブ を送信しなければならない。推奨リフレッシュ間隔はこの文書の範囲外であ る。[RFC5245]とOUTBOUND [RFC5626]がリフレッシュ間隔を提案している。 バインディング存続期間を判定するには、STUN BindingリクエストをSTUN サーバに送信するのに使用される2つの別々の送信元ポートに頼る。一般的な 手法は、クライアントが一つのBindingリクエストを送信するのに送信元ポー トXを使用するということである。送信元ポートXが使用されていない間にし ばらくすると、クライアントは、レスポンスがポートXに確立されたバイン ディングに送信されるよう示すBindingリクエストをSTUNサーバに送信するの に、2番目の送信元ポートYを使用する。ポートXのバインディングがタイムア ウトしていたならば、そのレスポンスは受信されないだろう。Xから送信され た最初のBindingリクエストとYから送信された後続リクエスト間で時間を変 えることによって、クライアントはバインディング存続期間を判定できる。 MacDonald & Lowekamp Experimental [Page 15] RFC 5780 NAT Behavior Discovery May 2010 バインディング存続期間を判定するために、クライアントはまず、Bindingリ クエストを特定の送信元ポート(X)からサーバに送信する。これはNATの中に バインディングを作成する。サーバからのレスポンスは、NAT上のパブリック アドレス/ポートを提供するMAPPED-ADDRESSアトリビュートを含んでいる。こ れをそれぞれPa/Ppと呼ぶ。そして、クライアントはT秒の値でタイマを始動 する。このタイマが発動するとき、クライアントは、同じ宛先アドレス/ポー トを使用するが、別の送信元ポート(Y)から、別のBindingリクエストをサー バに送信する。このリクエストは、レスポンスが(Pa, Pp)に配信されるよう 要求するために、Ppに設定されたRESPONSE-PORTアトリビュートを含んでい る。これはNAT上に新しいバインディングを作成して、古いバインディング (Pa, Pp)がまだ存在しているなら、それと一致することになるBindingレスポ ンスをSTUNサーバに送信させるだろう。クライアントがポートX上でBinding レスポンスを受信するなら、それはバインディングが期限切れでないことが 分かる。クライアントが(古いバインディングが期限切れで、NATが同じパブ リックアドレス/ポートを新しいバインディングに割り当てることが可能であ る)ポートY上でBindingレスポンスを受信するか、あるいはレスポンスを全く 受信しないなら、バインディングが期限切れしていることが分かる。 あるNATsは外向きトラフィックが送信されるときだけバインディングをリフ レッシュするので、別の値Tで2番目のテストを始める前に、クライアントは 初めの送信元ポートからBindingリクエストを再送しなければならない。クラ イアントはTを二分探索をすること、つまりレスポンスがTより大きいどんな タイマで受信されなくなり、T未満のどんなタイマで受信される値に最終的に 到達することで、バインディング存続期間の値を見つけることができる。ま た、バインディングリフレッシュの挙動(外向きだけ、または全てのトラ フィック)は、初めの送信元ポートXからリフレッシュせずに、ポートYから複 数のBindingリクエストを送信することで判定できることに注意すること。 この検出処理はかなりの時間が掛かり、そして装置が起動する時に一度、そ のバックグラウンドで通常実行されるであろうことである。 この処理が実行されるたびにクライアントは矛盾した結果を得る可能性があ ることが考えられる。例えば、NATが再起動するか、もしくはある理由でリ セットされることがあれば、処理は実際のものより短い存続期間を検出する かもしれない。また、バインディング存続期間もNATのトラフィック負荷に依 存しているかもしれない。この理由で、実装は、テストを何度も実行するこ とと、矛盾した結果を得る準備ができていることが推奨される。 他の診断法と同様に、このテストは本質的に不安定である。特に、高負荷状 態のNATは負荷を減らすためにバインディング存続期間を短くするかもしれな い。例えば、このチェックを開始する時にサーバへのその接続の初期キープ アライブ間隔を10秒に設定すれば、クライアントは起動時にこの診断法が有 用だと思うかもしれない。現在の存続期間を判定した後、サーバへの接続で MacDonald & Lowekamp Experimental [Page 16] RFC 5780 NAT Behavior Discovery May 2010 使用されるキープアライブ間隔はこの適当な値に設定できる。そして、サー バ接続にそのキープアライブを使用することで、バインディング存続期間の 次のチェックを実行できる。STUNキープアライブ用法 [RFC5626]は、接続が 開いているのを確認するレスポンスを供給して、クライアントがそのマップ ドアドレスが今まで変わっていないことをチェックできるようにする。その ことが、うまく動作するためのキープアライブの動作と診断法の両方を提供 するので、派生技術で接続を特徴付けるどんな試みよりも選ばれるべきであ る。 5. クライアントの挙動 特にここで定義しない限り、STUN Binding用法 [RFC5389]に記述されている ように、メッセージを準備、送信、処理するためのすべての手順に従う。 RESPONSE-PORTのサポートはオプションであり、クライアントはRESPONSE- PORTを含んでいるリクエストに420(未知のアトリビュート)エラーを受信する 準備ができていなければならない(MUST)。OTHER-ADDRESSとCHANGE-REQUESTの サポートはオプションだが、以下で説明されるように、SRVによって広告され るサーバではサポートしなければならない(MUST)。これは、サーバが複数の IPアドレスを持っていないアプリケーションでPADDINGとRESPONSE-PORTの使 用を可能にするためのものである。クライアントは、OTHER-ADDRESSがサーバ からのBindingレスポンスメッセージで受信されなかったとき、CHANGE- REQUESTを含んでいるリクエストに対して420を受信する準備ができていなけ ればならない(MUST)。 アプリケーションが、アプリケーショントラフィックのフロー中でNAT挙動検 出STUN用法を多重化して利用するなら、アプリケーションのヘッダーに基づ いたアプリケーションメッセージから、STUNメッセージを区別することがい つも可能というわけでない限り、FINGERPRINTアトリビュートを含める必要が ある(SHOULD)。 PADDINGが使用されているとき、それは外向きインタフェースのMTUと等しく する必要がある(SHOULD)。 実行されるテストのトポロジー要求を知っているSTUNサーバの提供者との認 証を使用していない限り、クライアントはレスポンス内のALTERNATE-SERVER アトリビュートを無視する必要がある(SHOULD)。 クライアントが1秒あたり10個以上の新しいSTUNトランザクションを発生させ ない方がよくて(SHOULD NOT)、再送タイムアウト(RTOs)がそれぞれのトラン ザクションの再送を同期しないように、それらのトランザクションを調整 する必要がある(SHOULD)。 5.1. 検出 ユーザもしくはアプリケーションがNAT挙動検出用法をサポートするSTUNサー バのトランスポートアドレスを他の手段で知らない限り、クライアントは MacDonald & Lowekamp Experimental [Page 17] RFC 5780 NAT Behavior Discovery May 2010 STUNサーバ提供者のドメイン名で設定される。そのドメインは、SRV手順 [RFC2782]を使用してトランスポートアドレスに名前解決される。STUNサーバ のドメイン名、または明示的なトランスポートアドレスを取得するドメイン 名でクライアントを設定するためのメカニズムは、この文書の範囲外であ る。 挙動検出用法に関して、サービス名はUDPとTCPに関して"stun-behavior"であ る。サービス名はTLS over TCPに関して"stun-behaviors"である。 "stun-behaviors"のプロトコルとして"tcp"だけが定義される。障害とデフォ ルトポートの取り扱いの他の局面は、STUN [RFC5389]の記述に従う。 5.2. セキュリティ サーバは、クライアントにサービス利用させる前に、認証を要求してもよい (MAY)。サーバがこれらの資格情報を必要とする場合、それらを得るための方 法はこの用法の範囲外である。おそらく、この用法に頼る管理者もしくはア プリケーションは、資格情報を得るためのそれ自身のメソッドを持っている はずだ。クライアントがリクエストへの401(認証失敗)のレスポンスを受信す るなら、それは、再試行する前にアプリケーションから適切な資格情報を取 得しなければならないか、または永続的な障害を報告しなければならない。 リクエストのMESSAGE-INTEGRITYアトリビュートをエンコードするための手順 はSTUN [RFC5389]で説明される。 6. サーバの挙動 特にここで定義しない限り、STUN [RFC5389]のSTUN Binding用法のために記 述されているように、メッセージを準備、送信、処理するためのすべての手 順に従う。 NAT挙動検出用法を実装しているサーバは、パブリックインターネット上に2 つの別々のIPアドレスで設定される必要がある(SHOULD)。起動時に、サーバ は、それぞれのIPアドレスの同じポートを使用してデータグラムを送受信す ることができるように(通常、ワイルドカードバインディングがこれを達成す る)、UDP、TCP、およびTCP/TLSトランスポートプロトコルのそれぞれに2つの ポートを割り当てる必要がある(SHOULD)。TCPとTCP/TLSは異なったポートを 使用しなければならない(MUST)。サーバが2つの異なったIPアドレスの同じ ポートを割り当てることができないなら、どんなレスポンスにもOTHER- ADDRESSアトリビュートを含めてはならなく(MUST NOT)、CHANGE-REQUESTアト リビュートがあるどんなリクエストにも420(未知のアトリビュート)で応答し なければならない(MUST)。1つのIPアドレスだけのサーバを、SRVサービス名 に"stun-behavior"や"stun-behaviors"を使用して広告してはならない(MUST NOT)。 6.1. レスポンスの準備 すべての認証と検証ステップを実行した後に、Bindingリクエストがこの文書 で定義されたどんなリクエストアトリビュート(RESPONSE-PORT、CHANGE- REQUEST、またはPADDING)でも含んでいるなら、サーバはこの用法に特有の処 MacDonald & Lowekamp Experimental [Page 18] RFC 5780 NAT Behavior Discovery May 2010 理を開始する。Bindingリクエストがこの文書が提供しているどんなアトリ ビュートを含んでいなくても、それでもOTHER-ADDRESSとRESPONSE-ORIGINは Bindingレスポンス中に含まれる。 サーバはレスポンスにMAPPED-ADDRESSとXOR-MAPPED-ADDRESSの両方を含まな ければならない(MUST)。 リクエストがCHANGE-REQUESTアトリビュートを含んでいて、サーバが前述の ように代替アドレス/ポートを持っていないなら、サーバはタイプ420のエ ラーレスポンスを生成しなければならない(MUST)。 Bindingレスポンスの送信元アドレス/ポートは、CHANGE-REQUESTアトリ ビュートの値と、Bindingリクエストが受信されたアドレス/ポートに依存し ている。これを表1にまとめる。 A1とA2をサーバによって使用される2つのIPアドレスとし、P1とP2をサーバに よって使用されるポートとする。DaはBindingリクエストの宛先IPアドレス (A1かA2のどちらかになる)を表し、DpはBindingリクエストの宛先ポート(P1 かP2のどちらかになる)を表す。Caはもう一方のアドレスを表して、DaがA1で あれば、CaはA2である。DaがA2であれば、CaはA1である。同様に、Cpはもう 一方のポートを表して、DpがP1であれば、CpはP2である。DpがP2であれば、 CpはP1である。"ポート変更"フラグがBindingリクエストのCHANGE-REQUESTア トリビュートに設定されていて、"IP変更"フラグが設定されていないなら、 Bindingレスポンスの送信元IPアドレスはDaでなければならなく(MUST)、 Bindingレスポンスの送信元ポートはCpでなければならない(MUST)。"IP変更" フラグがBindingリクエストに設定されていて、"ポート変更"フラグが設定さ れていないなら、Bindingレスポンスの送信元IPアドレスはCaでなければなら なく(MUST)、Bindingレスポンスの送信元ポートはDpでなければならない (MUST)。両方のフラグが設定されるとき、Bindingレスポンスの送信元IPアド レスはCaでなければならなく(MUST)、Bindingレスポンスの送信元ポートはCp でなければならない(MUST)。どちらのフラグも設定されていないか、または CHANGE-REQUESTアトリビュートが完全に無いなら、Bindingレスポンスの送信 元IPアドレスはDaでなければならなく(MUST)、Bindingレスポンスの送信元 ポートはDpでなければならない(MUST)。 +-------------------+----------------+--------------+---------------+ | フラグ | 送信元アドレス | 送信元ポート | OTHER-ADDRESS | +-------------------+----------------+--------------+---------------+ | なし | Da | Dp | Ca:Cp | | IP変更 | Ca | Dp | Ca:Cp | | ポート変更 | Da | Cp | Ca:Cp | | IP変更と | Ca | Cp | Ca:Cp | | ポート変更 | | | | +-------------------+----------------+--------------+---------------+ 表1: パケット送信元とOTHER-ADDRESSへのフラグの影響 MacDonald & Lowekamp Experimental [Page 19] RFC 5780 NAT Behavior Discovery May 2010 サーバは、Bindingレスポンスを送信するのに使用される送信元アドレス/ ポートを含んでいるRESPONSE-ORIGINアトリビュートを、Bindingレスポンス に付加しなければならない(MUST)。 サーバが代替アドレス/ポートをサポートするなら、サーバはBindingレスポ ンスにOTHER-ADDRESSアトリビュートを付加しなければならない(MUST)。これ は、クライアントがBindingリクエストに"IP変更"と"ポート変更"フラグを設 定した場合に使用される送信元IPアドレス/ポートを含んでいる。表1にまと められるように、これらはCHANGE-REQUESTフラグの値に関わらずそれぞれCa とCpである。 リクエストがPADDINGアトリビュートを含んでいたなら、Bindingレスポンス にPADDINGを含まなければならない(MUST)。サーバは、外向きインタフェース の、4バイトの倍数に切り上げられたMTUと等しいPADDING長を使用する必要が ある(SHOULD)。リクエストがRESPONSE-PORTアトリビュートもまた含んでいる ならば、サーバはタイプ400のエラーレスポンスを返さなければならない (MUST)。 それに続いて、サーバはSTUN [RFC5389]が提供している処理の残りを終え る。認証が要求されているなら、サーバはMESSAGE-INTEGRITYと必要に応じて 関連アトリビュートを含まなければならない(MUST)。STUNメッセージを区別 するためにFINGERPRINTの使用を必要とするアプリケーショントラフィックと STUNメッセージを多重化している場合にだけ、FINGERPRINTアトリビュートが 要求される。 ALTERNATE-SERVERアトリビュートは、この仕様書で定義されているいかなる アトリビュートとともに含まれてはならない(MUST NOT)。 サーバがレスポンスを送信するとき、上で判定される送信元アドレスから、 そしてリクエストの送信元アドレスへ送信される。RESPONSE-PORTが存在して いるなら、サーバは発信元ポートの代わりにそのポートにレスポンスを送信 する。 7. 新しいアトリビュート この文書はNAT挙動検出に要求されるいくつかのSTUNアトリビュートを定義す る。これらのアトリビュートはBindingリクエストとBindingレスポンスだけ ですべてが使用される。CHANGE-REQUESTは元々RFC 3489 [RFC3489]で定義さ れたが、その文書が[RFC5389]によって廃止されたので、ここで再定義され る。 理解必須な範囲 (0x0000-0x7FFF): 0x0003: CHANGE-REQUEST 0x0026: PADDING 0x0027: RESPONSE-PORT MacDonald & Lowekamp Experimental [Page 20] RFC 5780 NAT Behavior Discovery May 2010 理解任意な範囲 (0x8000-0xFFFF): 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS 7.1. トランスポートアドレスの表現 アトリビュートがトランスポートIPアドレス/ポートを含んでいるときはいつ も、それはMAPPED-ADDRESSと同じ形式にする。同様に、XOR-アトリビュート はXOR-MAPPED-ADDRESS [RFC5389]と同じ形式にする。 7.2. CHANGE-REQUEST CHANGE-REQUESTアトリビュートは、サーバがレスポンスを送信するのに使用 するIPアドレス/ポートを制御するための2つのフラグを含んでいる。これら のフラグは"IP変更"と"ポート変更"フラグと呼ばれる。CHANGE-REQUESTアト リビュートはBindingリクエストだけに許容されている。"IP変更"と"ポート 変更"フラグはNATの現在のフィルタリング挙動を判定することに役立つ。そ れらは、代替送信元IPアドレスと代替ポートの両方またはいずれか一方から Bindingレスポンスを送信するようサーバに命令する。CHANGE-REQUESTアトリ ビュートはBindingリクエストでオプションである。 アトリビュートは32ビット長であり、2ビット(AとB)だけが以下のように使用 される: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ フラグの意味は以下の通りである: A: これは"IP変更"フラグである。真であるなら、Bindingリクエストが受信 されたものとは異なったIPアドレスでBindingレスポンスを送信するよう サーバに要求する。 B: これは"ポート変更"フラグである。真であるなら、Bindingリクエストが 受信されたものとは異なったポートでBindingレスポンスを送信するよう サーバに要求する。 7.3. RESPONSE-ORIGIN RESPONSE-ORIGINアトリビュートはサーバで挿入され、レスポンスが送信され た送信元IPアドレス/ポートを示す。それは二段NAT構成を検知することに役 立つ。それはBindingレスポンスにだけ存在している。 MacDonald & Lowekamp Experimental [Page 21] RFC 5780 NAT Behavior Discovery May 2010 7.4. OTHER-ADDRESS OTHER-ADDRESSアトリビュートはBindingレスポンスで使用される。それは、 クライアントが"IP変更"と"ポート変更"の挙動を要求した場合に使用される だろう送信元IPアドレス/ポートについてクライアントに知らせる。サーバに 2番目のIPアドレスがない場合、OTHER-ADDRESSをBindingレスポンスに挿入し てはならない(MUST NOT)。 OTHER-ADDRESSは単にCHANGED-ADDRESSと同じ動作の新名であるので、それは RFC 3489 [RFC3489]が提供しているCHANGED-ADDRESSと同じアトリビュート番 号を使用する。より明確にその機能を示すために改名された。 7.5. RESPONSE-PORT RESPONSE-PORTアトリビュートはポートを含んでいる。RESPONSE-PORTアトリ ビュートはBindingリクエストに存在することができ、Bindingレスポンスが どのポートに送られるかを示す。RESPONSE-PORTアトリビュートをサポートす るサーバにおいて、Bindingリクエストの送信元IPアドレスかつRESPONSE- PORTに含まれていたポートに、Bindingレスポンスを送信しなければならない (MUST)。それは4.6節などのテストで使用される。存在していないとき、サー バはBindingリクエストの送信元IPアドレス/ポートにBindingレスポンスを送 信する。サーバはRESPONSE-PORTとPADDINGアトリビュートを含むリクエスト を処理してはならない(MUST NOT)。RESPONSE-PORTアトリビュートはBinding リクエストでオプションである。RESPONSE-PORTのサーバサポートはオプショ ンである。 RESPONSE-PORTはネットワークバイトオーダーの16ビット符号無し整数に続い て2バイトのパディングである。RESPONSE-PORTの許容値は0-65536である。 7.6. PADDING PADDINGアトリビュートは、STUNメッセージがIPフラグメントに分割されるの を強制するように、メッセージ全体をパディングできるようにする。PADDING は完全にフリー形式の文字列から成り、その値は重要ではない。Bindingリク エストとBindingレスポンスのどちらでもPADDINGを使用できる。 PADDINGは総IPデータグラムサイズが64Kになる長さより長くしてはならない (MUST NOT)。それは長さにおいて、4バイトの倍数に切り上げられた、外向き インタフェースのMTUと等しくする必要がある(SHOULD)。PADDINGがあるSTUN メッセージはUDPフラグメントの挙動をテストすることを意図されるため、そ れらは、STUNメッセージが経路のMTUより小さくなる、ということが通常規則 に対する例外である。 MacDonald & Lowekamp Experimental [Page 22] RFC 5780 NAT Behavior Discovery May 2010 8. IABの検討事項 IABは"Unilateral Self-Address Fixing" (UNSAF)の問題を研究していて、そ れは、クライアントが、協力的プロトコル反射メカニズム [RFC3424]を通じ てNATの反対側にある別レルムでのそのアドレスを判定することを試みる一般 的な処理である。STUN NAT挙動検出用法は、この類の機能を行うプロトコル の実例である。IABは、この目的のために開発されたどんなプロトコルも、規 定された一連の検討事項を記述することを要求している。この章はそれらの 要求を満たす。 8.1. 問題定義 RFC 3424 [RFC3424]から、どんなUNSAF提案も以下を提供しなければならな い: UNSAF提案で解決されることになっている特定の、そして限られた範囲の 問題の厳密な定義。短期的解決策は他の問題を解決するために一般化され るべきではない。そのような一般化は短期的解決策への長期依存とそれを 前提とした用法につながり、このことは"短期的"と呼ぶのがもう正確でな いことを意味する。 STUN NAT挙動検出用法で解決されている特定の問題は、どのタイプのNAT配下 にも設置されている可能性があるクライアントが、そのNATの瞬間的な特性を 判定することである。この判定は、それや他のアプリケーションで得られた 問題の原因の診断、あるいはそのNATの現在の挙動に基づいたアプリケーショ ンの挙動とアプリケーションが成功するのに要求される挙動の適正な統計モ デルの変更のいずれも可能にする。 8.2. 出口戦略 RFC 3424 [RFC3424]から、どんなUNSAF提案も以下を提供しなければならな い: 出口戦略/移行計画の記述。より良い短期的解決策は、適正技術が展開さ れるとき、自然にだんだんと利用が少なくなることが見込まれるだろう。 STUN NAT挙動検出用法はそれ自身でv4 NATsのための出口戦略を提供しない。 この書いている時点で、ある種のNATがv6クライアントとv4サーバ間で必要で あるように思われるが、IETFがそれらの運用を適切に記述することを計画し ているので、この仕様書はそれらのv6からv4へのNATsでは必要ではないだろ う。この仕様書はv6からv6への接続性に関して興味が無い。 MacDonald & Lowekamp Experimental [Page 23] RFC 5780 NAT Behavior Discovery May 2010 8.3. STUN NAT挙動検出でもたらされる不確実さ RFC 3424 [RFC3424]から、どんなUNSAF提案も以下を提供しなければならな い: システムをより"不安定"にするかもしれない特定の問題の議論。例えば、 複数のネットワークの層でデータを使用することを伴うアプローチは、よ り多くの依存状態を引き起こし、デバッグ仕事を増やし、そして移行をよ り困難にする。 STUN NAT挙動検出用法で、クライアントはNATの現在の挙動を判定できる。こ の情報はアプリケーションの他に開発者やネットワーク管理者にかなり役に 立つ場合があり、そしてそれ自体は別のアプリケーションでもたらされた不 安定さを診断するのに使用できる。アプリケーション自体の中で使用される 場合は、STUN NAT挙動検出で、NATの現在の挙動に応じて、アプリケーション が挙動を調整できる。挙動検出用法を当てにするアプリケーションにもたら される不確実さの程度が不明瞭であるのと、それを使用するプロトコルの設 計者によって慎重に評価されなければならないので、この文書は実験的であ る。このプロトコルのための実験的なテストは、トラフィックが通過しなけ ればならないNATsを少しも意識しないでネットワークを使用しようとするよ りも、挙動検出情報を使用することでアプリケーションをより不確実では無 く出来るかどうかを、本質的に判定することである。 8.4. 長期的な解決策への要求 RFC 3424 [RFC3424]から、どんなUNSAF提案も以下を提供しなければならな い: より長期的な要求、適切な技術的解決策の特定。それらは、正しいより長 期的な解決策を発見する過程に貢献する。 v4 NATsが存在している限り、それらの存在に順応する手段が必要だろう。上 記のように、行儀の良いv6からv4 NATsへの接続とv6からv6への直接接続は挙 動特性評価を必要としないだろう。 8.5. 現存するNAPT装置での問題 RFC 3424 [RFC3424]から、どんなUNSAF提案も以下を提供しなければならな い: 現存する展開されたNATsと体験報告にある有名な実際の問題の影響の議 論。 この用法は、NATの挙動の多くのタイプをテストするために組み立てることが できる一般的なアトリビュート一式を提供する。一般に知られているNAT装置 の挙動のためのテストは説明されるが、BEHAVEメーリングリストには定期的 MacDonald & Lowekamp Experimental [Page 24] RFC 5780 NAT Behavior Discovery May 2010 に新しい挙動の記述があり、その一部はここに説明されたテストを使用して も簡単には検知されないかもしれない。しかしながら、この用法で説明され たテクニックは、今は知られていない、もしくは想定されていないNATの挙動 をテストするために、異なる組み合わせで組み立てることができる可能性が ある。 9. IANAの検討事項 9.1. STUNアトリビュートレジストリ この仕様書はいくつかの新しいSTUNアトリビュートを定義する。IANAはこれ らの新しいプロトコル要素を"STUNアトリビュート"レジストリに追加した。 0x0003: CHANGE-REQUEST 0x0027: RESPONSE-PORT 0x0026: PADDING 0x8027: CACHE-TIMEOUT 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS 9.2. ポート番号/SRVレジストリ デフォルトで、STUN NAT挙動検出用法はSTUNと同じポート(UDPとTCP上では 3478、およびTLS上ではTCPの5349)で実行する。また一方、挙動検出用法に は、独自のサービスレコード(SRV)名(UDPとTCPでは"stun-behavior"、および TLSでは"stun-behaviors")を設けている。5章の推奨に従って、異なるポート で挙動検出を実行するのにSRV手順かALTERNATE-SERVER手順のどちらかを用い ることができる。 この仕様書は"stun-behavior"と"stun-behaviors"のSRVサービス名を定義す る。"stun-behavior"はSRVプロトコル指定子の"udp"と"tcp"で使用できる。 "stun-behaviors"は"tcp"でだけ指定できる。したがって、許容できるSRVク エリは以下である。 _stun-behavior._udp UDP _stun-behavior._tcp TCP _stun-behaviors._tcp TLS over TCP 10. セキュリティの検討事項 この用法はSTUN [RFC5389]のセキュリティ問題を継承する。この用法はいく つかの新しいアトリビュートを追加する。それらのためのセキュリティの検 討事項はここに詳述される。 MacDonald & Lowekamp Experimental [Page 25] RFC 5780 NAT Behavior Discovery May 2010 OTHER-ADDRESSはどんな新しい攻撃もできない。それは攻撃者がSTUNサーバの ふりをすることができる別の環境をもたらすが、それは面白い攻撃ではな い。Bindingレスポンスを侵害することができるところに位置する攻撃者は、 STUNサーバをクライアントから完全に隠すことができる。 o RESPONSE-PORTとPADDINGの両方を含むリクエストはサーバで破棄される。 これは発信元アドレスを標的とする増幅攻撃を防ぐ。 PADDINGアトリビュートで可能な唯一の攻撃は、サーバが多量のメモリを割り 当てることがあり得る大きいパディング長を持つことである。サーバは64Kよ り大きいどんなパディング長も無視するので、この攻撃の範囲は限定され る。一般に、サーバは受信されたデータグラムのサイズより多くのメモリを 割り当てるべきではない。この攻撃は非準拠な実装に影響するだけだろう。 RESPONSE-ORIGINとRESPONSE-PORTはどんな付加的な攻撃もできない。 11. 謝辞 執筆者は、この文書の多くのアイデア、アトリビュート、そして記述を引用 したSTUN仕様書の原文 [RFC3489]の執筆者に感謝致します。詳細なコメント を戴いたDan Wing氏、Cullen Jennings氏、そしてMagnus Westerlund氏に感 謝します。 12. 参考文献 12.1. 規範的な参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. MacDonald & Lowekamp Experimental [Page 26] RFC 5780 NAT Behavior Discovery May 2010 12.2. 有益な参考文献 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. 執筆者の連絡先 Derek C. MacDonald Skype Palo Alto, CA USA EMail: derek.macdonald@gmail.com Bruce B. Lowekamp Skype Palo Alto, CA USA EMail: bbl@lowekamp.net 日本語訳 2010/12/1版 訳者 佐藤 良 MacDonald & Lowekamp Experimental [Page 27]