この文書はRFC 4787の日本語訳(和訳)です。この文書の翻訳内容の正確さは保障 できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者 はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻 訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の 配布は元のRFC同様に無制限です。 Network Working Group F. Audet, Ed. Request for Comments: 4787 Nortel Networks BCP: 127 C. Jennings Category: Best Current Practice Cisco Systems January 2007 ユニキャストUDPのための ネットワークアドレス変換(NAT)の挙動要求 Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). 要約 この文書は、ユニキャストUDPをハンドリングするときの、ネットワーク アドレス変換(NAT)の挙動の異なるタイプを記述するための基本用語と、 マルチメディアコミュニケーションやオンラインゲーム等の多くのアプ リケーションを矛盾無く動くようにさせる要求集を定義する。 この要求集を満たしたNATsの開発が増えることは、これらのアプリケー ションが適切に機能する可能性を大いに増やすだろう。 Audet & Jennings Best Current Practice [Page 1] RFC 4787 NAT UDP Unicast Requirements January 2007 Table of Contents 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Network Address and Port Translation Behavior . . . . . . . . 5 4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5 4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 9 4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 11 4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 11 4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 12 4.4. Conflicting Internal and External IP Address Spaces . . . 13 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 15 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 17 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 18 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 19 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 20 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 25 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 16.1. Normative References . . . . . . . . . . . . . . . . . . . 26 16.2. Informative References . . . . . . . . . . . . . . . . . . 26 Audet & Jennings Best Current Practice [Page 2] RFC 4787 NAT UDP Unicast Requirements January 2007 1. 適用範囲の提示 この仕様書の目的は、マルチメディアコミュニケーションやオンライン ゲームのような多くのアプリケーションを矛盾無く動かせるようにする、 NATsのための要求集を定義することです。この要求集を満たすNATsを開発 することは、これらのアプリケーションが適切に機能する可能性を大いに 増加させるだろう。 この仕様書の要求は、[RFC 2663]に記述されている伝統的なNATsに適用す る。 この文書は、小さい家庭向けNATsから大きな企業向けNATsまでのどの規模 のNATsをカバーしなければならない。しかしながら、企業向けNATsは、通 常、NAT機能だけかそれ以上の機能を供給すると理解されているだろう; 例 えば、一般的にファイアウォール機能を供給するなど。 ファイアウォールの挙動と関連要件の包括的な記述は、明確にこの仕様書 の範囲外である。しかしながら、この仕様書はNATsの現在の基本的なファ イアウォールを含む(第5章参照)。 ミドルボックスのシグナル制御を直接使うアプローチは範囲外である。 UDP中継(例えば、Traversal Using Relay NAT [TURN])は範囲外である。 アプリケーション面は、NATそれ自身に厳密に焦点を置いているので、範囲 外である。 この文書は、IP [RFC0791]上のユニキャストUDP [RFC0768]と、他のプロト コル上のそれらに依存したものに関連したNAT越えだけを含む。 2. 前置き ネットワークアドレス変換器(NATs)は、ペイロード内でIPアドレスを運ぶ アプリケーションで、とても重大な問題を引き起こすのをよく知られてい る([RFC 3027]参照)。 この問題に悩むアプリケーションは、Voice over IP、マルチメディア over IP(例えば、SIP [RFC3261]やH.323 [ITU.H323])が含まれ、オンライ ンゲームもまた同様である。 多くのテクニックは、リアルタイムマルチメディアアプリケーション、オ ンラインゲーム、その他のアプリケーションがNATsを通っても動かすのに 使われている。アプリケーションレベルゲートウェイ [RFC2663]は、その メカニズムの一つである。STUN [RFC3489bis]は、UNilateral Self-Address Fixing (UNSAF)メカニズム [RFC3424]を記述する。 Teredo [RFC4380]は、UDP/IPv4上のIPv6 [RFC2460]トンネリングからなる UNSAFメカニズムを記述する。 UDP中継もまたアプリケーションがNATsを越えるのに使われているが、一 般的に、最後の手段である。 Interactive Connectivity Establishment [ICE]は、これらのテクニック Audet & Jennings Best Current Practice [Page 3] RFC 4787 NAT UDP Unicast Requirements January 2007 の多くを使ったり、UDP中継を使わなくても良いNATタイプならば、UDP中継 を回避する方法論を記述する。この仕様書はNATsを改善するための要求を 定義している。これらの要求を満たすことは、アプリケーションがUDPメ ディア中継を使わないで済むことを保証する。 UNSAF [RFC3424]に指摘されていることとして、"普及したネットワークの 観察結果から、異なるトラフィックやアドレスのケースをどのように処理 するかという観点で、NATボックスの実装が広く変わっているのは明らか だ"。 この広い変化性の程度は、NATsが引き起こす全体的な不安定要素の一つの ファクターであり、与えられたプロトコルが、NATを越えるネットワーク上 でどの様に振る舞うかを予言する違いになる。多くのメジャーNATベンダー での論議は、消費者にNATsが広まらせる要求を満たすまでの間、決定論的 で、アプリケーションへの害が最も少ないNATsを配布することを好むこと をまず明らかにした。NATベンダーが直面する問題は、それをするとどれだ け良いのかや、彼らのNATの挙動をどの様にドキュメント化するのが良いの かを確信できないことである。 この文書のゴールは、NATsの振る舞いを記述するための共通用語集を定義 することと、NATsの具体的な振る舞い集上の要求集を導入することであ る。 この文書は、NATベンダーによって実装することが出来る、音声、動画、 ゲーム等に単純で、かつ有用な共通の要求集を形成する。この文書は この 環境で動くか動かないかを決定するためのプロトコルの解析を簡単にした り、NAT越え問題を抱えたサービスのプロバイダーに、彼らのアプリケー ションがどこで動くか、動かないかについての陳述を、彼ら自身のNAT要求 を作るのと同じぐらいに作ることを許すだろう。 3. 用語 この文書に出てくるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", と "OPTIONAL" は、[RFC 2119]に記述されている様に解釈される。 読者には、NATの分類や用語の情報について、[RFC2263]を参照することを 強く勧める。伝統的なNATは、普及しているNATデバイスの最もありふれた タイプである。読者は、伝統的なNATの詳細な情報のために[RFC 3022]を参 照しても良い。伝統的なNATは2つの主な種類 -- ベーシックNATとネット ワークアドレス/ポート変換器(NAPT)、がある。 NAPTは、ずば抜けてありふれた普及しているNATデバイスである。NAPTは、 複数の内側ホストが同時に、１つのパブリックIPアドレスを共有すること を許す。内側ホストは、NAPTを通る外向きのTCPまたはUDPセッションを開 けた時、NAPTはセッションにパブリックIPアドレスとポート番号を割り当 Audet & Jennings Best Current Practice [Page 4] RFC 4787 NAT UDP Unicast Requirements January 2007 て、それは、外側エンドポイントからのその後のレスポンスパケットが NAPTが受信、変換、そして内側ホストへ転送できるものである。効果は、 NAPTが、タプル(プライベートIPアドレス, プライベートポート番号)から タプル(パブリックIPアドレス, パブリックポート番号)へ変換するNATセッ ションを確立することであり、またセッションの存続期間も同様である。 ピアtoピアアプリケーションへの適切さの問題は、内側ホストが、一つの (プライベートIP, プライベートポート)エンドポイントから、外部ネット ワーク上の複数の宛先エンドポイントへの複数の同時のセッションを開始 した時、NATがどの様に振る舞うかである。この仕様書では、用語"NAT"と は、"ベーシックNAT"と"ネットワークアドレス/ポート変換器(NAPT)"の両 方をさす。 この文書は、RFC 2663に、"TCP/UDPセッションは(ソースIPアドレス, ソー スTCP/UDPポート, ターゲットIPアドレス, ターゲットTCP/UDPポート)のタ プルで一意に特定される"と定義されている用語"セッション"を使う。 この文書は、外側アドレスとポート、内側アドレスとポートの間の変換と して用語"アドレスとポートのマッピング"を使用する。これはRFC 2663で 定義されている"アドレスバインディング"と同じではないことに注意して 欲しい。 この文書はポート範囲にIANA用語を使用する。すなわち、 http://www.iana.org/assignments/port-numbers に定義されているよう に、"Well Known Ports"は0-1023、"Registered"は1024-49151、そして "Dynamic and/or Private"は49152-65535である。 STUN [RFC 3489]では、UDPだけに適用できるNATの様々な差異を差すのに、用 語"フルコーン"、"制限付きコーン"、"ポート制限付きコーン"、"シンメト リック"を使っていた。不運にも、この用語は、実際のNATの挙動を説明す るには不十分と示されている様に、多くの混乱の原因になっている。この 仕様書はそれゆえにコーン/シンメトリック用語を使わないで、明確な個々 のNATの挙動を言及する。 4. ネットワークアドレスとポートの変換挙動 この章では、NATsに適用できる様々なNATの挙動を説明する。 4.1. アドレスとポートのマッピング 内側エンドポイントがNATを通る外向きのセッションを開くとき、NATは、 外側エンドポイントからのその後のレスポンスパケットを、NATが受信し て、変換して、内側エンドポイントに転送することができるように、外側 のIPアドレスとポート番号をセッションに割り当てる。これは、内側のIP アドレスとポートのタプルIP:portと、外側のIP:port間のマッピングであ る。それはセッションの持続時間のために、NATによって実行される変換を 確立します。多くのアプリケーションで、異なる外側エンドポイントに確 Audet & Jennings Best Current Practice [Page 5] RFC 4787 NAT UDP Unicast Requirements January 2007 立された複数の同時セッションがあるときのNATの挙動を区別するのは重要 です。 説明する主要な挙動は、アドレスタプル 内側アドレスとポート X:x と、 外側 Y1:y1間の最初のマッピングが確立した後の、外側エンドポイントへ の新しいセッションのためのマッピングの再利用による基準である。内側 のIPアドレスとポート X:x が この最初のセッションのためにX1':x1' に マップされると仮定しよう。それから、エンドポイントは X:x から 外側 アドレス Y2:y2 へ送信して、NAT上に X2':x2' のマッピングを得る。 Y1:y1 と Y2:y2間の関係の様々な組み合わせについての X1':x1' と X2':x2'間の関係は、NATの挙動を説明するための基準である。この取り決 めを以下に図示する: +------+ +------+ | Y1 | | Y2 | +--+---+ +---+--+ 外 | Y1:y1 Y2:y2 | +----------+ +----------+ | | 側 X1':x1' | | X2':x2' +--+---+-+ ...........| NAT |............... +--+---+-+ | | X:x | | X:x 内 ++---++ | X | +-----+ 側 アドレスとポートのマッピング 以下の、アドレスとポートのマッピング挙動が定義される: エンドポイント非依存マッピング: NATは、同じ内側IPアドレスとポート(X:x)からどの外側IPアドレス とポートへ送信するその後のパケットについて、ポートマッピング を再利用する。つまり、どのY2:y2に対しても、X1':x1'はX2':x2' に等しい。 Audet & Jennings Best Current Practice [Page 6] RFC 4787 NAT UDP Unicast Requirements January 2007 アドレス依存マッピング: NATは、同じ内側IPアドレスとポート(X:x)から、外側ポートに関わ らず、同じ外側IPアドレスへ送信するその後のパケットについて、 ポートマッピングを再利用する。つまり、Y2がY1に等しい場合にの み、X1':x1'はX2':x2'に等しい。 アドレス&ポート依存マッピング: NATは、マッピングが有効である間は、同じ内側IPアドレスとポート (X:x)から、同じ外側IPアドレスとポートへ送信するその後のパケッ トについて、ポートマッピングを再利用する。つまり、Y2:y2が Y1:y1に等しい場合にのみ、X1':x1'はX2':x2'に等しい。 これらの3つの可能な選択は、NATのセキュリティ特性に違いがないことを 言及するのは重要です。セキュリティ特性は、NATが入ってくることを許可 するパケットか、許可しないパケットかで、完全に決定される。これはNAT のフィルタリング部分でのフィルタリング挙動で決定される。 REQ-1: NATは、"エンドポイント非依存マッピング"の挙動でなければなら ない。 根拠: UNSAFの方法が作用するためには、REQ-1が満たされる必要がある。 会われるのが必要です。 REQ-1を満たさないと、非常に多くの場合、非 実用であるUDP中継を使うことを強制するだろう。 いくつかのNATsは、たった1つのIPアドレスを割り当てられるものに対し て、NATの外側にIPアドレスプールからのIPアドレスを割り当てることがで きる。これは、より大きなNATsについて特に一般的である。いくつかの NATsは、任意の流儀で(すなわち、ランダムに)外側IPアドレスマッピング を使用する: 1つの内側IPアドレスは、異なるセッションのために、同時に 有効な、複数の外側IPアドレスマッピングを持つかもしれない。これらの NATsには、"任意"という"IPアドレスプーリング"の挙動がある。いくつか の大きな企業向けNATsは、割り当てをより予測できないようにすることに よって、特定のエンドポイントに割り当てられたIPアドレスを隠蔽する手 段として"任意"というIPアドレスプーリングの挙動を使用する。他のNATs は、同じ内側IPアドレスに関連している全てのセッションに同じ外側IPア ドレスマッピングを使用する。これらのNATsは、"ペア"という"IPアドレス プーリング"の挙動を持つ。"任意"という"IPアドレスプーリング"の挙動を 使用するNATsは、個別にIPアドレスを取り交わさないが、同じエンドポイ ントから複数のポートを使用するアプリケーションで問題を引き起こす場 合がある(例えば、RTPとRTCPを使用するいくつかのアプリケーション)。 Audet & Jennings Best Current Practice [Page 7] RFC 4787 NAT UDP Unicast Requirements January 2007 REQ-2: NATには"ペア"の"IPアドレスプーリング"の挙動を持つことが推奨 される。この要件が、IPアドレスプーリングをサポートしないNATsに適 用できないことに注意すること。 根拠: これで、同じ内側IPアドレスを送信元とする、複数のポートを使用 するアプリケーションが、同じ外側IPアドレスを持つだろう。これは、 RTPのIPアドレスとRTCPのIPアドレスを別々に取り交わすことができな いP2Pアプリケーションを止めるのを避けるためのものだ。そのため、 この要件は、アプリケーションが時間と共にNATフレンドリになるにつ れて、重要でなくなるだろうと想像できる。この要件がここにある主な 理由は、P2Pアプリケーションで、あなたがもう片方のピアのミスを被 りやすいということだ。特に、SIPのコンテキストで、我々のアプリ ケーションが、RTPとRTCPアドレスとポートを個別に示すために、 [RFC3605]に定義されている拡張をサポートして、もう片方のピアがサ ポートしていない場合、ストリームがRTPパケットを見失う形で、今ま でどおり止まるだろう。この要件は、このコンテキストでは、RTCPのロ スがこの特定の例で避けられないかもしれないが、RTPのロスを避ける だろう。RFC 3605が、残念ながらSIP [RFC3261]の必須部分でないのに 注意する価値もある。したがって、この要件は、かなりの時間はびこる だろう特に不快な問題に差し向けるだろう。 Audet & Jennings Best Current Practice [Page 8] RFC 4787 NAT UDP Unicast Requirements January 2007 4.2 ポート割り当て 4.2.1. ポート割り当ての挙動 この章は、例として以下の図を使用する。 +-------+ +-------+ | Y1 | | Y2 | +---+---+ +---+---+ 外 | Y1:y1 Y2:y2 | +---------+ +---------+ | | 側 X1':x1' | | X2':x2' +--+---+--+ ...........| NAT |............... +--+---+--+ | | +---------+ +---------+ 内 | X1:x1 X2:x2 | +---+---+ +---+---+ | X1 | | X2 | 側 +-------+ +-------+ ポート割り当て いくつかのNATsは、外側IPアドレスとポートにマッピングを割り当てると き、内側で使用したポート番号を維持することを試みる(例えば、x1=x1', x2=x2')。このポート割り当ての挙動は"ポート維持"と呼ばれる。ポート衝 突の場合、これらのNATsは対処するための様々さなテクニックを試みる。 例えば、いくつかのNATsは、同じポートを維持するために以前のマッピン グを無効にするだろう。他のNATsは、外側IPアドレスプールから他のIPア ドレスを割り当てるだろう。これはNATに十分な外側IPアドレスがある限り 可能だ。もし全ての利用可能な外側IPアドレスでこのポートが既に使用中 であるなら、これらのNATsは違うポートを選ぶだろう(すなわち、それ以上 ポート維持しない)。 いくつかのNATsは"ポート多重"、すなわち、衝突の場合にさえポート維持 をいつも使用する(すなわち、X1'=X2' かつ x1=x2=x1'=x2')。NATが"ポー ト多重"を使用するなら、ほとんどのアプリケーションは動かないだろう。 どのような場合でも、外側ポート番号に内側ポート番号を合わせることを 試みないNATは、"ポート維持無し"と呼ばれる。 Audet & Jennings Best Current Practice [Page 9] RFC 4787 NAT UDP Unicast Requirements January 2007 NATsが新しいソースポートを割り当てるとき、IANAによって定義された範 囲のどのポートを選ぶかに関する問題がある。その範囲は、0から1023まで が"well-known"、1024から49151までが"registered"、49152から65535まで が"dynamic/private"である。ほとんどのプロトコルについて、これらが ソースポートではなく、ディスティネーションポートであるので、ソース ポートを既に登録されているソースポートにマッピングするのは、なんの 悪い影響も持っていそうにない。いくつかのNATsが、dynamicの範囲のポー トだけを使用することを選ぶかもしれない; この習慣の唯一の性能を下げ る面は、利用できるポートの数を制限するということだ。他のNAT装置は、 well-knownの範囲以外のすべてを使用して、最初にdynamicの範囲を使用す ることか、あるいは、registerdの範囲の実際の登録されたポートをできる 限り避けるのを好むかもしれない。それがwell-knownの範囲にあるなら ば、他のNATsはポート範囲を維持する。[RFC0768]は応答パケットを期待し ないなら、ソースポートを0に設定することを規定している。この場合、 ソースポートが使用されていなければ、NATがそれを何にマップするかは重 要ではない。しかしながら、多くの一般的なOSのAPIsはユーザがポート0か ら送信することを許さず、アプリケーションはポート0を使用できないの で、ソースポートが0のパケットに関して様々な既存のNATの挙動は未知で ある。この文書は、アプリケーションが決定論的な挙動も当てにすること が出来ないことを意味するソースポートが0のパケットを扱うときのNATの どんな標準の挙動も規定しない。 REQ-3: NATには、"ポート多重"の"ポート割り当て"の挙動があってはなら ない。 a) ホストのソースポートが範囲0-1023にあったなら、NATのソースポー トが同じ範囲であることが推奨される。ホストのソースポートが範 囲1024-65535にあったなら、NATのソースポートがその範囲にあるこ とが推奨される。 根拠: NAT内部側の2つのアプリケーションが、同じ宛先で通信しようとす るのに同じポートを使用することを、可能にするために、この要件を満 たさなければならない。ポート維持を実装するNATsは、ポートの衝突 と、しばしば非決定論的挙動の結果をもたらす複数のコードパスを処理 しなければならない。しかしながら、ポートがランダムに割り当てられ るとき、同じポートが割り当てられることがたまたま起こるかもしれな いことを理解しておくべきだ。したがって、アプリケーションは、ポー ト維持とポート維持無しの両方を処理することができなければならな い。 a) あるアプリケーションは、ソースUDPポートがwell-knownの範囲にあ ることを期待する。例として、[RFC2623]のネットワークファイルシ ステムポートの期待を参照。 Audet & Jennings Best Current Practice [Page 10] RFC 4787 NAT UDP Unicast Requirements January 2007 4.2.2. ポートパリティ いくつかのNATsはUDPポートのパリティを維持する、すなわち、偶数ポート は偶数ポートにマップされ、奇数ポートは奇数ポートにマップされるだろ う。この振舞いは、RTPが偶数ポート、RTCPが奇数ポートを使用するという [RFC3550]の規則を尊重している。例えば[RFC3605]を使用して、2つの番号 が別々に指定されるなら、RFC3550は、どんなポート番号もRTPとRTCPに使 用されるのを許容する。しかしながら、いくつかの実装はRFC3605を含まな く、ピアがRFC 3605を使ってRTCPポートを別々に指定するといつも認識し ない。もしそのような実装が(NATによって変換された恐らく後に)ピアから 奇数のRTPポート番号に受け取って、RTPポートを次の偶数に変更するとい うRFC 3550の規則に従うならば、これは明らかにRTPの損失をもたらすだろ う。NATに優しいアプリケーションの見地は、このドキュメントの範囲の外 である。実装が向上するにつれ、時間に応じてこの問題が消え去ると予想 される。ポートパリティを維持することは、RTPとRTCPポート番号の両方の 明示的な列挙をサポートしないピアとの通信をサポートすることを可能に する。 REQ-4: NATは、"ポートパリティ維持"に"Yes"の挙動を持つことが推奨され る。 根拠: これは、明示的かつ別々にRTPとRTCPポート番号を指定しなく、かつ 奇数RTPポートをデクリメントして偶数にするRFC 3550の規則に従うピ アツーピアアプリケーションを止めることを避けるためのものだ。IPア ドレスプーリング要件により、同じ理由が適用される。 4.2.3. ポート隣接性(Contiguity) いくつかのNATsは、RTCP=RTP+1のポート隣接規則を維持するのを試みる。 これらのNATsは連続した割り当てやポートの予約のようなことをする。連 続したポート割り当てはアプリケーションがまずRTPのためにマッピングを 開けて、次に、RTCPのためにマッピングを開けると仮定する。この要件を すべてのアプリケーションに押しつけるのは現実的ではない。 その上、多くのアプリケーション(または、エンドポイント)が同時にマッ ピングを開こうとしているなら、ひどい問題がある。特に、NATが隣接規則 の無い、RTP over UDPと他のUDPパケットとを明確に区別できないというこ とを考えることが無駄であるので、ポート維持にもまた問題が多い。それ らの理由で、特定のNATの挙動を示すことによって隣接規則を維持するのを 試みるのは複雑になり過ぎて、きっとそれは決定論的な挙動を破るだろ う。 したがって、RTPとRTCPの両方をサポートするために、アプリケーションが RTPとRTCPとを別々にネゴシエートする規則に従うのが必要で、そして RTCP=RTP+1規則が壊される非常に現実的な可能性の責任を持つことが必要 だろう。これはアプリケーション要件であるので、このドキュメントの範 囲外である。 Audet & Jennings Best Current Practice [Page 11] RFC 4787 NAT UDP Unicast Requirements January 2007 4.3. マッピングリフレッシュ NATマッピングタイムアウトの実装は、タイマ値や、マッピングタイマが マッピングを残しておくためにリフレッシュされる方法を含んでいる以外 にも、様々だ。 マッピングタイマは、パケットがNATを越えること無しに、マッピングが有 効な状態で留まっている時間と定義される。異なるNATsで使われているそ の値に多くのバリエーションがある。 REQ-5: REQ-5aを適用しない場合、NAT UDPマッピングタイマは、2分未満で 期限が切れてはならない。 a) well-knownポート範囲(ポート0-1023)の特定のディスティネーショ ンポートに関して、NATは特定のポートで走らせるIANAで登録された アプリケーションに特有のより短いUDPマッピングタイマを持っても 良い。 b) NAT UDPマッピングタイマ値は、構成可能にしても良い。 c) NAT UDPマッピングタイマは5分以上のデフォルト値が推奨される。 根拠: この要件は、タイムアウトが、頻繁なタイマリフレッシュパケット を避けるのに十分長いことを保証することだ。 a) UDPを使用するいくつかのUDPプロトコルが非常に短命な接続を使用 する。非常に多くのそのような接続があることがありうる; 接続 テーブルにそれら全てを保持することが、NAT上にかなりの負荷を 引き起こす場合があった。したがって、これらの特定のアプリケー ションのためにより短いタイマを持つことは、最適化手法である。 特定のプロトコルに適用されるより短いタイマが、控えめに、より 短いタイマを持つことが知られていて、どのアプリケーションでも 他の目的に使用されないことが知られているwell-knownディスティ ネーションポートを使用したプロトコルにだけ、使用されるのは重 要である。 b) 構成設定は、特定のネットワークやトラブルシューティングのため に柔軟に改変できることが望ましい。 c) このデフォルトは、頻繁なタイマリフレッシュパケットを避けるた めのものである。 パケットがNATの内側からNATの外側に出て行くとき、いくつかのNATsが マッピングをアクティブに(すなわち、タイマ値をリフレッシュする)維持 する。これはNAT外向きリフレッシュに"True"の挙動を持つと呼ばれる。 Audet & Jennings Best Current Practice [Page 12] RFC 4787 NAT UDP Unicast Requirements January 2007 パケットがNATの外側からNATの内側に入ってくるとき、いくつかのNATsが マッピングをアクティブに維持する。これはNAT内向きリフレッシュに "True"の挙動を持つと呼ばれる。 いくつかのNATsはマッピングを両方でアクティブに維持して、その場合、 両方の特性は"True"である。 REQ-6: NATマッピングリフレッシュ方向は、"NAT外向きリフレッシュの挙 動"に"True"を持たなければならない。 a) NATマッピングリフレッシュ方向は、"NAT内向きリフレッシュの挙 動"に"True"を持つことが望ましい。 根拠: 外向きリフレッシュは、クライアントがマッピングを有効にさせる のに必要である。 a) 内向きリフレッシュは、外向きのUDPトラフィックの無いアプリケー ションに有用だろう。しかしながら、内向きリフレッシュを許容す ることは、外側の攻撃者や不作法にふるまうアプリケーションに マッピングを無期限に有効にするのを許容するだろう。これはセ キュリティリスクだろう。また、プロセスが異なるポートで繰り返 されるなら、時間がたつにつれて、それはNATのすべてのポートを使 いきるかもしれない。 4.4. 内側と外側のIPアドレス空間の衝突 多くのNATs(特に非技術系のユーザに配布するように設計された消費者レベ ルのデバイス)は、上流ISPなどの外側ネットワークから、外側インタ フェースのための外側IPアドレス、デフォルトルータ、およびその他のIP 構成設定情報を決まり切った手順で動的に得る。今度はNATが自動的に、 [RFC1918]でプライベートIPアドレス空間の用途に割り当てられたプライ ベートIPアドレス空間の1つに、それ自身の内側サブネットをセットアップ して、一般的にこの内側ネットワーク上のホストのために動的IP構成設定 サービスを提供する。 しかしながら、NATの外側ネットワークがRFC 1918のプライベートアドレス 空間にあると、NATsとプライベートネットワークの自動構成は問題となる ことがある。よくあるシナリオでは、ISPは、NAT配下に顧客を置き、プラ イベートRFC 1918アドレスを彼らに与える。今度は、これら顧客の何人か に消費者レベルNATsを配布して(事実上、"第2レベル"NATsとして機能する )、ISPによって提供された単独のRFC 1918 IPアドレスに、彼ら自身のプラ イベートRFC 1918 IPサブネットを多重化する。この場合、ISPの"中間の" プライベートなアドレス付けされたネットワークと、顧客の内側のプライ ベートなアドレス付けされたネットワークとが、数字上同一もしくは重 なっているRFC 1918 IPサブネットを使用していないことの、どんな保証も Audet & Jennings Best Current Practice [Page 13] RFC 4787 NAT UDP Unicast Requirements January 2007 ない。さらに、手動で彼らの内側ネットワークを衝突しないRFC 1918サブ ネットに構成することで、このシナリオが起こることを防ぐという技術知 識を、消費者レベルNATsの顧客には期待することはできない。 NATベンダーは、彼らのNATsがそのような問題となるシナリオでさえ、正し く、そして強固に機能するのを保証するようにそれらを設計する必要があ る。1つの可能な解決策は、外側リンクがRFC 1918プライベートIPアドレス に構成されているときはいつも、NATが内側ネットワークのために自動的 に、異なり、衝突しないRFC 1918 IPサブネットを選択することを、NATが 保証することだ。この解決策の不便なことは、内側ネットワークが既に使 用中になった後に、NATの外側インタフェースが動的に構成されるか、また は再構成されて、それから、NATが衝突を検出したら、NATは動的に内側 ネットワーク全体を再番号付けしなければならないかもしれない、という ことだ。 代替の解決策は、NATがその外側と内側インタフェースが、数字上でIPサブ ネットが重複するように構成されるときでさえ、正しくトラフィックを変 換して転送することができるように設計されることだ。このシナリオで は、例えば、NATの外側インタフェースがRFC 1918空間のIPアドレスPを割 り当てられていて、内側ノードIが同一のRFC 1918プライベートIPアドレス Pを持つこともまたあるだろう。送信先アドレスPを持つ外側ネットワーク 上のIPパケットはそのNATに向けられるが、送信先アドレスPを持つ内側 ネットワーク上のIPパケットはノードIに向けられる。したがって、NAT は、内側ノードIをそれ自身の外側インタフェースと間違えるのを避けるた めに"外側IPアドレス"と"内側IPアドレス"の明確な操作上の区別を整備す る必要がある。一般に、NATは、(Iを含む)すべての内側ノードがパブリッ クな(非RFC 1918)IPアドレスを持っているか、内側ネットワークで使用さ れるアドレスと衝突しないプライベートIPアドレスを持っているすべての 外側ノードと通信することを許可する必要がある。 REQ-7: 動的に外側IPインタフェースを構成することができるNATデバイス は、(1) 内側ネットワークが外側ネットワークと衝突しないIPアドレス を使用するのを自動的に保証する、もしくは、(2) IPアドレスが数字上 で内側ネットワークと衝突するすべての内側ノードとすべての外側ノー ドの間のトラフィックを変換して転送することが出来なければならな い。 根拠: NATの外側と内側インタフェースが重複するIPサブネットで構成され ているならば、RFC 1918 IPアドレスQを持つ内側ホストが、同一のRFC 1918アドレスQを持つ外側ノード、または、数字上で内部サブネットと 衝突するIPアドレスを持つ外側ノードと、直接通信セッションを開始す る方法がもちろん無い。しかしながら、そのようなノードは、パブリッ クな非RFC 1918 IPアドレスを持つSTUNサーバなどの第三者サーバの助 Audet & Jennings Best Current Practice [Page 14] RFC 4787 NAT UDP Unicast Requirements January 2007 けを使うNAT越え技術で、今までどおり間接的に通信セッションを開く ことができる。この場合、共通の第1レベルNAT(例えば、上流ISPのNAT) が第6章で説明されるようなヘアピンの挙動をサポートする限り、第2レ ベルNATの反対側のプライベートRFC 1918アドレスに衝突するノード は、幹線インターネット上の各自の一時的なパブリックエンドポイント を通って、互いに通信することができる。 5. フィルタリングの挙動 この章は、NATsで観測された様々なフィルタリングの挙動について説明す る。 内側エンドポイントがNATを通る外向きセッションを開くと、NATは内側IP: ポート (X:x) と外側IP:ポート (Y:y)タプル間のマッピングのためにフィ ルタリングルールを割り当てる。 説明する主要な挙動は、特定の外側エンドポイントから発するパケットを フィルタするために、どんな評価基準がNATによって使われるかである。 エンドポイント非依存フィルタリング: NATは、外側IPアドレスとポートのソース (Z:z) にかかわらず、内 側アドレスとポート X:x に向けられていないパケットだけを無視す る。NATは X:x に向けられたどんなパケットも転送する。言い換え れば、NATの内側からどこかの外側IPアドレスへパケットを送ること は、内側エンドポイントにどんなパケットでも戻すことを十分許容 する。 アドレス依存フィルタリング: NATは、内側アドレス X:x に向けられていないパケットを無視す る。さらに、NATは、X:x が以前(Yで使用されたポートと無関係に) Y:any にパケットを送っていないなら、Y:y から内側エンドポイン ト X:x へ向けられたパケットを無視するだろう。言い換えれば、特 定の外側エンドポイントからのパケットを受信するために、まずそ の特定の外側エンドポイントのIPアドレスにパケットを送ることが 内側のエンドポイントには必要だ。 アドレス&ポート依存フィルタリング: これは、外側ポートもまた関連しているのを除いて、前の挙動と同 様である。NATは、内側アドレス X:x に向けられていないパケット を無視する。さらに、NATは、X:x が以前 Y:y にパケットを送って いないなら、Y:y から内側エンドポイント X:x へ向けられたパケッ トを無視するだろう。言い換えれば、特定の外側エンドポイントか らのパケットを受信するために、まずその特定の外側エンドポイン トのIPアドレスとポートにパケットを送ることが内側のエンドポイ ントには必要だ。 Audet & Jennings Best Current Practice [Page 15] RFC 4787 NAT UDP Unicast Requirements January 2007 REQ-8: アプリケーション透過性が最も重要であるならば、NATは"エンドポ イント非依存フィルタリング"の挙動であることが推奨される。より厳 しいフィルタリングの挙動が最も重要であるならば、NATは"アドレス依 存フィルタリング"の挙動であることが推奨される。 a) フィルタリングの挙動は、NATの管理者が構成可能なオプションとし てもよい。 根拠: エンドポイント非依存フィルタリングを使用することの推薦は、特 に同時に複数の場所(例えば、ゲームをするところ)からメディアを受け 取るアプリケーション、またはランデブー技術を使用するアプリケー ションのために、アプリケーション透過性を最大にすることを目的とさ れている。しかしながら、ある状況では、より厳しいフィルタリングの 挙動を持ってもよいこともまた可能である。外側エンドポイントに無関 係なフィルタリングは安全ではない: ポートが開いているのを見つける ほど幸運であったならば、ポートが開いている間、権限のないパケット は特定のポートを通り抜けるかもしれない。理論上、IPアドレスとポー トの両方に基づくフィルタリングは、IPアドレスだけに基づくフィルタ リングより安全である(外側エンドポイントが、実はもう一つのNATの後 ろにある2つのエンドポイントで、その2つのエンドポイントのうちの1 つが攻撃者であるかもしれないので)。しかしながら、そのような方針 は、1つ以上のUDPポート上でUDPパケットを受けることを期待するアプ リケーションを妨げるかもしれない。また、NAT(NAT-Aとする)で、アド レス&ポート依存フィルタリングの代わりにエンドポイント非依存フィ ルタリングかアドレス依存フィルタリングを使用することは、もう片方 のエンドポイントがREQ-1をサポートしない行儀の良くないNAT(NAT-Bと する)の後ろにあるときに、有利になる。エンドポイントがICEを使用し ている時に、NAT-Aがアドレス&ポート依存フィルタリングを使用するな らば、接続性はUDP中継を必要とするだろう。しかしながら、NAT-Aがエ ンドポイント非依存フィルタリングかアドレス依存フィルタリングを使 用するならば、ICEは結局、UDP中継を必要としないで、接続性を見つけ るだろう。フィルタリングの挙動をNATの管理者に構成可能なオプショ ンであるようにすることは、最も広く様々な展開シナリオでNATを使用 することができることを確実にする。 6. ヘアピンの挙動 2台のホスト(X1, X2と呼ぶ)が同じNATの後ろにいて、トラフィックを交換 しているならば、NATはX2のためにNATの外側に、X2':x2'と呼ばれるアドレ スを割り当てるだろう。X1がトラフィックをX2':x2'に送るなら、それは NATに届き、NATはX1からX2へのトラフィックを中継しなければならない。 このことは、ヘアピンと呼ばれていて、以下に例示する。 Audet & Jennings Best Current Practice [Page 16] RFC 4787 NAT UDP Unicast Requirements January 2007 NAT +----+ X1:x1 から X2':x2' へ +-----+ X1':x1' | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- +----+ | v | | v | | v | | v | +----+ X1':x1' から X2:x2 へ | v | X2':x2' | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- +----+ +-----+ ヘアピンの挙動 ヘアピンは、互いの外側IPアドレスとポートを使用するだけでも、NATの内 側の2つのエンドポイントを通信させる。 より形式的には、ヘアピンをサポートするNATは、内側アドレス X1:x1 か ら発し、内側アドレス X2:x2 へのアクティブなマッピングを持っている外 側アドレス X2':x2' を宛先にしたパケットを転送して、内側アドレス X2: x2 へ戻す。通常、X1'はX2'と同じであることに注意すること。 その上、NATは、内側 (X1:x1) か外側 (X1':x1') のどちらかのソースIPア ドレスとポートで、ヘアピンパケットを提示するだろう。したがって、ヘ アピンNATの挙動は、"外側ソースIPアドレス&ポート"か"内側ソースIPアド レス&ポート"のどちらかになることができる。"内側ソースIPアドレス& ポート"は、外側IPアドレスとポートを期待する実装を混乱させることで、 問題を引き起こすかもしれない。 REQ-9: NATは"ヘアピン"をサポートしなければならない。 a) NATのヘアピンの挙動は、"外側ソースIPアドレス&ポート"でなけれ ばならない。 根拠: この要件は、同じNATの後ろにある2つのエンドポイントが互いの外 側IPアドレスで通信を試みているとき、それらの間の通信を許容するこ とだ。 a) 外側ソースIPアドレスを使用することは、期待されるIPアドレスと 異なるIPアドレスからパケットを受け入れない、という制限方針の アプリケーションにとって必要である。 7. アプリケーションレベルゲートウェイ あるNATsは、SIPなどのP2Pセッションをネゴシエートするためのプロトコ ルを含む様々なプロトコルのために、アプリケーションレベルゲートウェ イ(ALGs)を実装している。 Audet & Jennings Best Current Practice [Page 17] RFC 4787 NAT UDP Unicast Requirements January 2007 あるNATsは、これらのALGsを恒久的に機能オンにしていて、別のものはデ フォルトで機能オンにしているが機能オフにすることができ、また別のも のはデフォルトで機能オフにしているが機能オンにすることができる。 NAT ALGsは、NATに気づこうとするUNSAFの方法かプロトコルを妨げるかも しれなく、したがって、細心の注意を払って使用しなければならない。 REQ-10: UNSAFのNAT越えメカニズムの干渉を排除して、UDP通信の完全性保 護を許すために、UDPベースプロトコルのNAT ALGsは機能オフされるべ きだ。ALGsを定義する将来のスタンダードトラック仕様書は、仕様書が 定義するALGsの規定値を推薦するためにこれを更新することができる。 a) NATがALGsを含んでいるなら、NATの管理者が各ALGを別々に有効、無 効に出来るようにすることを推奨する。 根拠: NAT ALGsはUNSAFの方法を妨げるかもしれない。 a) この要件は、ユーザに、他のアプリケーションの操作を妨げるALGs を有効にしないで、いくつかのアプリケーションの操作を支援する のに必要なALGsを有効にさせる。 8. 決定論的な特性 いくつかの条件のもとで、同じNATが異なった挙動を示すという事実によっ て、NATsの分類はさらに複雑にされる。これは、ポートを維持したり、自 由な方法以外の方法のポートを選択する特定のアルゴリズムを持っている NATsに見られる。NATが使用したいと望んでいる外側ポートが別のセッショ ンで既に使用中ならば、NATは異なるポートを選択しなければならない。こ のことは、この衝突の場合の為の異なるコードパスに帰着し、そのことは 異なる挙動に帰着する。 例えば、3つのホスト X1, X2, X3 全てが同じポート x から送信するなら ば、1つの外側IPアドレス( X1' と呼ぶ)だけでポート維持するNATを通し て、発信する最初のホスト(すなわち X1 )は x の外側ポートを得るだろう が、次の2つのホストは x2' と x3' (これらは x と等しくない)を得るだ ろう。外側NATマッピング特性と外側フィルタ特性が、X1:x と X2:x の マッピング間で変化するNATsがある。より困ったことに、挙動が X1:x と X2:x のマッピングで同じだが、3つ目の X3:x のマッピングで異なるかも しれないNATsがある。 別の例では、2つのエンドポイントが同じ外側方向のセッションを確立して いない限り、いくつかのNATsは"ポート多重"する"エンドポイント非依存 マッピング"であるということだが、これらの確立セッションの競合検出時 Audet & Jennings Best Current Practice [Page 18] RFC 4787 NAT UDP Unicast Requirements January 2007 に、NATsの挙動を"ポート維持"しない"アドレス&ポート依存マッピング"に 切り換える。 構成変更なしでNATマッピングかフィルタリングの挙動を変えるあるNAT は、どんな特定の条件のもとでいつの時点でも、"非決定論的な"NATと呼ば れる。そうしないNATsは"決定論的な"と呼ばれる。 ある種の衝突が起こると、すなわち、通常使用されるポートが別のマッピ ングで既に使用中であるときに、一般的に、非決定論的なNATsは挙動を変 える。衝突のないときにNATマッピングと外側フィルタリングは、第一の挙 動と呼ばれます。最初の衝突の後の挙動は第二の挙動と呼ばれて、第二の 衝突の後の挙動は第三の挙動と呼ばれる。それ以上の衝突で変化するNATs は確認されていないが、明らかに存在するのは可能だ。 REQ-11: NATは決定論的な挙動を持たなければならない、すなわち、それは どんな時点でも、あるいはどんな特定の条件のもとでも、NAT変換(第4 章)やフィルタリング(第5章)の挙動を変えてはならない。 根拠: 非決定論的なNATsは、より徹底的なテストを必要とするため、障害 調査するのが非常に難しい。この非決定論的な挙動は、NATsがアプリ ケーションが働くかどうかについて導くのを不確実にする多くの根本的 原因である。 9. ICMP Destination Unreachableの挙動 NATが、NATの反対側にあるホストに向かってパケットを送るとき、そのパ ケットに返答でICMPメッセージを送るかもしれません。宛先ホストやネッ トワーク経路に沿ったどのルータがそのICMPメッセージを送るかもしれな い。NATのデフォルト構成は、それらのソースIPアドレスに基づくICMPメッ セージをフィルタするべきではない。そのようなICMPメッセージをNAT(明 確にはIPヘッダーとICMPペイロード)で書き直して、適切な内側や外側のホ ストに転送するべきだ。NATは、UDPマッピングが有効である限り、この機 能を実行する必要がある。どの種類のICMPメッセージの受信でもNATマッピ ングを破棄してはならない。上の段落で説明された機能を実行するNATは "ICMP処理サポート"と呼ばれる。 ICMP Destination Unreachableパケットを遮断することに、意義のあるセ キュリティ上の利点は無い。加えて、ICMP Destination Unreachableパ ケットを遮断すると、アプリケーションフェイルオーバー、UDPパスMTU ディスカバリ([RFC1191]と[RFC1435]参照)、およびtracerouteを遮断する ことができる。どのICMPメッセージも遮断することは勧められなく、そし て、ICMP Destination Unreachableを遮断することは非常に勧められな い。 Audet & Jennings Best Current Practice [Page 19] RFC 4787 NAT UDP Unicast Requirements January 2007 REQ-12: どの種類のICMPメッセージの受信でも、NATマッピングを終結して はならない。 a) NATのデフォルト構成は、それらのソースIPアドレスに基づくICMP メッセージをフィルタするべきではない。 b) NATがICMP Destination Unreachableメッセージをサポートすること を推奨する。 根拠: これは行うのが簡単であり、MTUディスカバリ、エラー状態の迅速な 検出を含む多くのものに使用されていて、どんな否定的結果もない。 10. 外向きパケットの断片化 隣接しているリンクのMTUが小さ過ぎる時、NATの内側から外側へ出て行く パケットの断片化が起こるだろう。NATがPoint-to-Point over Ethernet (PPPoE)を使用しているか、またはNATが大きいパケットと小さい高優先度 パケットを送るとき、シリアル化遅延を減少させるため、または他の理由 で小さいMTUに構成されたなら、これは起こりうる。 多くのIPスタックがUDPパケットでパスMTUディスカバリを使用しないこと に注意すべきだ。 そのパケットは、断片化禁止ビットを1 (DF=1)や0 (DF=0)に設定するかも しれない。 REQ-13: 内側IPアドレスで受信したパケットがDF=1だったならば、NAT は、[RFC0792]で説明されているように、ホストへICMPメッセージの"断 片化が必要だったが、DFがセットされている"を返送しなければならな い。 a) パケットがDF=0であるならば、NATはパケットを断片化しなければな らず、順番に断片を送るべきだ。 根拠: これはRFC 792による。 a) これはルータが同様の状況 [RFC1812]で行うのと同じ動作である。 11. 断片化パケットの受信 さまざまな理由で、NATは断片化したパケットを受けるかもしれない。ヘッ ダーを含むIPパケットは、ネットワーク状態、パケットの順序、および断 片を生成したIPスタックの実装に依存するどんな断片の中でも、到着する ことができる。 Audet & Jennings Best Current Practice [Page 20] RFC 4787 NAT UDP Unicast Requirements January 2007 順番(それは、最初のパケットのヘッダにある)に断片を受信して、おのお のの断片を内側ホストに転送することだけが可能なNATは、"断片順で受信 する"と呼ばれる。 順番か順番が狂っても断片を受信して、個々の断片(または、組み立て直さ れたパケット)を内側ホストへ転送することができるNATは、"断片を順番が 狂っても受信する"と呼ばれる。この挙動の議論に関しては、この文書のセ キュリティの考慮の章を見るべし。 これらのどちらもでないNATは、"断片を何も受信しない"と呼ばれる。 REQ-14: NATが、順番でも順番の狂った断片でも受信することをサポートし なければならなく、それには、"断片を順番が狂っても受信する"の挙動 を持たなければならない。 a) NATの順番の狂った断片処理メカニズムは、順番で断片化していない IPパケットを処理するNATの能力を断片化ベースのDoS攻撃が落とさ ないように、設計しなければならない。 根拠: セキュリティの考慮を参照。 12. 要件 この章の要件は、NATsによってリアルタイム通信やオンラインゲームなど のアプリケーションに引き起こされたやっかいな問題を最小にすることを 目的としている。文書で先にリストアップされた要件は、ここで1つの章に 整理される。 しかしながら、通常、NATがこの章で定義された推奨に従うかどうかを、ア プリケーションが前もって知らないことを理解されるべきだ。P2Pメディア アプリケーションは、ICE [ICE]などの標準の手順をまだ用いる必要があ る。 この仕様のすべての必須要件(すなわち、"MUST")をサポートするNATは、 "この仕様に準拠"である。この仕様のすべての要件(すなわち、 "RECOMMENDED"を含む)をサポートするNATは、"この仕様のすべての必須・ 推奨要件で完全準拠"である。 Audet & Jennings Best Current Practice [Page 21] RFC 4787 NAT UDP Unicast Requirements January 2007 REQ-1: NATは、"エンドポイント非依存マッピング"の挙動でなければなら ない。 REQ-2: NATには"ペア"の"IPアドレスプーリング"の挙動を持つことが推奨 される。この要件が、IPアドレスプーリングをサポートしないNATsに適 用できないことに注意すること。 REQ-3: NATには、"ポート多重"の"ポート割り当て"の挙動があってはなら ない。 a) ホストのソースポートが範囲0-1023にあったなら、NATのソースポー トが同じ範囲であることが推奨される。ホストのソースポートが範 囲1024-65535にあったなら、NATのソースポートがその範囲にあるこ とが推奨される。 REQ-4: NATは、"ポートパリティ維持"に"Yes"の挙動を持つことが推奨され る。 REQ-5: REQ-5aを適用しない場合、NAT UDPマッピングタイマは、2分未満で 期限が切れてはならない。 a) well-knownポート範囲(ポート0-1023)の特定のディスティネーショ ンポートに関して、NATは特定のポートで走らせるIANAで登録された アプリケーションに特有のより短いUDPマッピングタイマを持っても 良い。 b) NAT UDPマッピングタイマ値は、構成可能にしても良い。 c) NAT UDPマッピングタイマは5分以上のデフォルト値が推奨される。 REQ-6: NATマッピングリフレッシュ方向は、"NAT外向きリフレッシュの挙 動"に"True"を持たなければならない。 a) NATマッピングリフレッシュ方向は、"NAT内向きリフレッシュの挙 動"に"True"を持つことが望ましい。 REQ-7: 動的に外側IPインタフェースを構成することができるNATデバイス は、(1) 内側ネットワークが外側ネットワークと衝突しないIPアドレス を使用するのを自動的に保証する、もしくは、(2) IPアドレスが数字上 で内側ネットワークと衝突するすべての内側ノードとすべての外側ノー ドの間のトラフィックを変換して転送することが出来なければならな い。 REQ-8: アプリケーション透過性が最も重要であるならば、NATは"エンドポ イント非依存フィルタリング"の挙動であることが推奨される。より厳 しいフィルタリングの挙動が最も重要であるならば、NATは"アドレス依 存フィルタリング"の挙動であることが推奨される。 Audet & Jennings Best Current Practice [Page 22] RFC 4787 NAT UDP Unicast Requirements January 2007 a) フィルタリングの挙動は、NATの管理者が構成可能なオプションとし てもよい。 REQ-9: NATは"ヘアピン"をサポートしなければならない。 a) NATのヘアピンの挙動は、"外側ソースIPアドレス&ポート"でなけれ ばならない。 REQ-10: UNSAFのNAT越えメカニズムの干渉を排除して、UDP通信の完全性保 護を許すために、UDPベースプロトコルのNAT ALGsは機能オフされるべ きだ。ALGsを定義する将来のスタンダードトラック仕様書は、仕様書が 定義するALGsの規定値を推薦するためにこれを更新することができる。 a) NATがALGsを含んでいるなら、NATの管理者が各ALGを別々に有効、無 効に出来るようにすることを推奨する。 REQ-11: NATは決定論的な挙動を持たなければならない、すなわち、それは どんな時点でも、あるいはどんな特定の条件のもとでも、NAT変換(第4 章)やフィルタリング(第5章)の挙動を変えてはならない。 REQ-12: どの種類のICMPメッセージの受信でも、NATマッピングを終結して はならない。 a) NATのデフォルト構成は、それらのソースIPアドレスに基づくICMP メッセージをフィルタするべきではない。 b) NATがICMP Destination Unreachableメッセージをサポートすること を推奨する。 REQ-13: 内側IPアドレスで受信したパケットがDF=1だったならば、NAT は、[RFC0792]で説明されているように、ホストへICMPメッセージの"断 片化が必要だったが、DFがセットされている"を返送しなければならな い。 a) パケットがDF=0であるならば、NATはパケットを断片化しなければな らず、順番に断片を送るべきだ。 REQ-14: NATが、順番でも順番の狂った断片でも受信することをサポートし なければならなく、それには、"断片を順番が狂っても受信する"の挙動 を持たなければならない。 a) NATの順番の狂った断片処理メカニズムは、順番で断片化していない IPパケットを処理するNATの能力を断片化ベースのDoS攻撃が落とさ ないように、設計しなければならない。 Audet & Jennings Best Current Practice [Page 23] RFC 4787 NAT UDP Unicast Requirements January 2007 13. セキュリティの考慮 NATsは、セキュリティ目標を達成するためにしばしば配布される。本書の 推薦と要求の大部分がこれらのデバイスのセキュリティ特性に影響しない が、それらのいくつかは影響して、セキュリティ的意味を持っていて、こ の章で議論する。 この文書は、マッピングのためのタイマが外向きパケットでリフレッシュ されるのを推奨して(REQ-6参照)、内向きパケットがタイマを更新するべき であるかどうかについては推奨を示していない。内向きパケットがタイマ を更新するならば、外側の攻撃者は、いつまでも、マッピングを活かし て、同じ内側アドレスを持つかもしれない将来のデバイスを攻撃すること ができる。プライベートアドレス空間へのDHCPサーバでもあったデバイス は、DHCPリースの期限が切れたとき、どんなマッピングも一掃することに よって、これを緩和するかもしれない。ユニキャストUDPトラフィック(こ の文書の範囲)に関しては、内向きタイマリフレッシュをサポートすること に関連しているように見えないかもしれない; しかしながら、マルチキャ ストUDPにおいて、問題はより難しくなる。マルチキャストトラフィックの NAT挙動について議論する将来の文書は、内向きリフレッシュタイマの扱い 周りの要件が洗練されるだろうと期待する。今日のいくつかのデバイスが 内向きパケットでタイマを更新する。 この文書は、NATフィルタが外側IPアドレスとUDPポートではなく、外側IP アドレスだけに特有であることを推薦する(REQ-8参照)。これがIPとポート を使用する以上、安全でないと主張することができる。IPとポートのフィ ルタに望まれているデバイスは、まだこれらの要件に従っている。 非決定論的なNATsはセキュリティの観点から危険だ。それらはそれらがか なり非決定論的であるので、テストするのが非常に難しい。それを構成す る人がテストすることは、その人がそれが望まれているように作用してい ると思うことに帰着するが、攻撃者が引き起こすことが出来る異なった条 件のもとでは、NATは異なった挙動を示すかもしれない。これらの要件は、 デバイスが決定論的であることを推奨する。 この文書は、NATsには"外部NATマッピングはエンドポイント非依存である" の挙動を持つことを要求する。これはデバイスのセキュリティを下げな い。どのパケットがデバイスの向こう側に流れることができるかは、外側 フィルタリング挙動で決定され、それはマッピング挙動に非依存である。 外側から断片化パケットを受信して、そして、最初の断片が最初に到着し ていないように、そのパケットの順番が狂っていたとき、多くのシステム が順番が狂っているパケットを単に捨てる。そのうえ、いくつかのネット ワークは、大きいパケットの前に小さなパケットを配達するので、多くの 順番の狂った断片があることがある。これらの順番の狂ったパケットを届 けることができるNATsは実現可能だが、それらは、順番の狂った断片を格 Audet & Jennings Best Current Practice [Page 24] RFC 4787 NAT UDP Unicast Requirements January 2007 納する必要があり、不当に利用された場合、サービス不能(DoS)の機会を広 げてしまう。断片化は多くの攻撃に使用されるツールであり、そして、 NATsを通過するいくつかの断片化パケットを伴うものと、状態に基づくDoS 攻撃を伴う他のものは、断片を組み立て直す必要があった。NATの実装は、 [RFC3128]と[RFC1858]を意識しているべきだ。 14. IABの考慮 IABは、クライアントが、協力的なプロトコル反射メカニズム [RFC3424]を 通して、NATの反対側の別領域のアドレスを決定するのを試みる、一般的な 過程である"一方的な自己アドレス決定"の問題を研究した。 この仕様は、それ自体でUNSAFアプリケーションを規定しない。それらのデ バイスがP2Pメディアアプリケーション上、特にそれらのアプリケーション がUNSAFの方法を使用しているときに、持つ負の影響を最小にすることを目 的としたNATsのための一連の要件から成っている。 UNSAFの第3章は、NAT問題の解決策のいくつかでの実際的な問題点を記載す る。この文書は、推奨から、NATsのこれらの実際的な問題点が導く不確実 性や問題を減らすようにする。さらに、UNSAFは5つのアーキテクチャの問 題を記載する。これはUNSAF提案ではないが、これらのアーキテクチャの問 題に対するこの作用の影響を考えることは興味深い。 Arch-1: この文書の範囲は、今日、広く展開している様なNATsのUDPパケッ トに制限される。"解決"は、STUNなどの正しいUNSAF解決策のため にNATsの変化性を抑制することを助ける。 Arch-2: これはNATsが無くなるのと同じ割合で無くなるだろう。それは、 NATsがなくなった後に生き続けるか、またはそれらを取り除くの をより難しくする、どんなプロトコル機構も示さない。 Arch-3: これは、NATsの全ての不安定さを減少させないが、うまくいけ ば、より極悪なNATの挙動を抑えて、与えられた状況におけるNAT の挙動について議論することや予測することを、より簡単にする だろう。 Arch-4: 様々なNATsのこの仕事と結果 [RESULTS]が、VoIPのようなアプリ ケーションの為に、NATsの本当の問題が何であるかに関して、 IETFでの最も包括的な仕事と示す。この仕事とSTUNは、NATsが導 く不安定さとこれらの問題を記述するという困難を、他の何より も指摘した。 Audet & Jennings Best Current Practice [Page 25] RFC 4787 NAT UDP Unicast Requirements January 2007 Arch-5: この仕事と試験の結果 [RESULTS]は、配備されたNATsで遭遇する かもしれないどのUNSAFの提案に対して、リファレンスモデルを提 供する。 15. 謝辞 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh, and Dan Kegel for their multiple contributions on peer-to-peer communications across a NAT. Dan Wing contributed substantial text on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy, Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola, Peter Koch, Jari Arkko, and Alfred Hoenes for their contributions. 16. 参考文献 16.1. 規範的な参考文献 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 16.2. 情報の参考文献 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. Audet & Jennings Best Current Practice [Page 26] RFC 4787 NAT UDP Unicast Requirements January 2007 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. Audet & Jennings Best Current Practice [Page 27] RFC 4787 NAT UDP Unicast Requirements January 2007 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC3489bis] Rosenberg, J., "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", Work in Progress, October 2006. [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2006. [RESULTS] Jennings, C., "NAT Classification Test Results", Work in Progress, October 2006. [TURN] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", Work in Progress, October 2006. [ITU.H323] "Packet-based Multimedia Communications Systems", ITU- T Recommendation H.323, July 2003. Authors' Addresses Francois Audet (editor) Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US Phone: +1 408 495 2456 EMail: audet@nortel.com Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 US Phone: +1 408 902 3341 EMail: fluffy@cisco.com Audet & Jennings Best Current Practice [Page 28] RFC 4787 NAT UDP Unicast Requirements January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 日本語訳 2007/06/19版 訳者 佐藤 良 Audet & Jennings Best Current Practice [Page 29]