RFC4787 日本語訳
4787 Network Address Translation (NAT) Behavioral Requirements forUnicast UDP. F. Audet, Ed., C. Jennings. January 2007. (Format: TXT=68693 bytes) (Also BCP0127) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Audet, Ed.
Request for Comments: 4787 Nortel Networks
BCP: 127 C. Jennings
Category: Best Current Practice Cisco Systems
January 2007
ワーキンググループF.Audet、エドをネットワークでつないでください。コメントのために以下を要求してください。 4787 ノーテルはBCPをネットワークでつなぎます: 127C.ジョニングスカテゴリ: 最も良い現在の練習シスコシステムズ2007年1月
Network Address Translation (NAT) Behavioral Requirements
for Unicast UDP
ユニキャスト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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
このドキュメントは、Unicast UDPを扱うとき、異なったタイプのNetwork Address Translation(NAT)の振舞いについて説明するために基本的な用語を定義して、また、一貫して働くためにマルチメディア通信かオンラインゲームなどの多くのアプリケーションを許容する1セットの要件を定義します。 このセットの必要条件を満たす展開しているNATsがこれらのアプリケーションが適切に機能する可能性を大いに広げるでしょう。
Audet & Jennings Best Current Practice [Page 1] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[1ページ]RFC4787NAT UDPユニキャスト要件2007年1月
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
1. 適用性証明. . . . . . . . . . . . . . . . . . . 3 2。 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 アドレスとポート翻訳の振舞い. . . . . . . . 5 4.1をネットワークでつないでください。 マッピング. . . . . . . . . . . . . . . . . 5 4.2を記述して、移植してください。 課題. . . . . . . . . . . . . . . . . . . . . 9 4.2.1を移植してください。 課題の振舞い. . . . . . . . . . . . . . . 9 4.2.2を移植してください。 パリティ. . . . . . . . . . . . . . . . . . . . . 11 4.2.3を移植してください。 接触. . . . . . . . . . . . . . . . . . . 11 4.3を移植してください。 写像して、.124.4をリフレッシュしてください。 闘争している内部の、そして、外部のIPアドレス空間. . . 13 5。 振舞い. . . . . . . . . . . . . . . . . . . . . . 15 6をフィルターにかけます。 振舞い. . . . . . . . . . . . . . . . . . . . . 16 7をHairpinningします。 アプリケーションレベルゲートウェイ. . . . . . . . . . . . . . . . . . 17 8。 決定論的な特性. . . . . . . . . . . . . . . . . . . 18 9。 ICMPの目的地の手の届かない振舞い. . . . . . . . . . . . 19 10。 出発しているパケット. . . . . . . . . . . . . . 20 11の断片化。 受信はパケット. . . . . . . . . . . . . . . . . 20 12を断片化しました。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 21 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 24 14。 IAB問題. . . . . . . . . . . . . . . . . . . . . . 25 15。 承認. . . . . . . . . . . . . . . . . . . . . . . 26 16。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 26 16.1。 引用規格. . . . . . . . . . . . . . . . . . . 26 16.2。 有益な参照. . . . . . . . . . . . . . . . . . 26
Audet & Jennings Best Current Practice [Page 2] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[2ページ]RFC4787NAT UDPユニキャスト要件2007年1月
1. Applicability Statement
1. 適用性証明
The purpose of this specification is to define a set of requirements for NATs that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
この仕様の目的は一貫して働くためにマルチメディア通信かオンラインゲームなどの多くのアプリケーションを許容するNATsのための1セットの要件を定義することです。 このセットの必要条件を満たす展開しているNATsがこれらのアプリケーションが適切に機能する可能性を大いに広げるでしょう。
The requirements of this specification apply to Traditional NATs as described in [RFC2663].
この仕様の要件は[RFC2663]で説明されるようにTraditional NATsに適用されます。
This document is meant to cover NATs of any size, from small residential NATs to large Enterprise NATs. However, it should be understood that Enterprise NATs normally provide much more than just NAT capabilities; for example, they typically provide firewall functionalities. A comprehensive description of firewall behaviors and associated requirements is specifically out-of-scope for this specification. However, this specification does cover basic firewall aspects present in NATs (see Section 5).
このドキュメントは小さい住宅のNATsから大きいエンタープライズNATsまでどんなサイズのNATsも覆うことになっています。 しかしながら、通常、エンタープライズNATsがまさしくNAT能力よりはるかに提供するのが理解されるべきです。 例えば、彼らはファイアウォールの機能性を通常提供します。 ファイアウォールの振舞いと関連要件の包括的な記述はこの仕様のために明確に範囲の外にあります。 しかしながら、この仕様はNATsの現在の基本的なファイアウォール局面をカバーしています(セクション5を見てください)。
Approaches using directly signaled control of middle boxes are out of scope.
範囲の外に中央箱の直接合図されたコントロールを使用するアプローチがあります。
UDP Relays (e.g., Traversal Using Relay NAT [TURN]) are out of scope.
範囲の外にUDP Relays(例えば、Traversal Using Relay NAT[TURN])があります。
Application aspects are out of scope, as the focus here is strictly on the NAT itself.
ここの焦点が厳密にNAT自体にあるとき、範囲の外にアプリケーション局面があります。
This document only covers aspects of NAT traversal related to Unicast UDP [RFC0768] over IP [RFC0791] and their dependencies on other protocols.
このドキュメントは他のプロトコルでUnicast UDP[RFC0768]に関連するNAT縦断の局面をIP[RFC0791]と彼らの依存の上にカバーするだけです。
2. Introduction
2. 序論
Network Address Translators (NATs) are well known to cause very significant problems with applications that carry IP addresses in the payload (see [RFC3027]). Applications that suffer from this problem include Voice Over IP and Multimedia Over IP (e.g., SIP [RFC3261] and H.323 [ITU.H323]), as well as online gaming.
ネットワークAddress Translators(NATs)は、ペイロードのIPアドレスを載せるアプリケーションに関する非常に重要な問題を引き起こすためによく知られています([RFC3027]を見てください)。 この問題に苦しむアプリケーションがVoice Over IPとMultimedia Over IP(例えば、SIP[RFC3261]とH.323[ITU.H323])を含んでいます、オンラインゲームと同様に。
Many techniques are used to attempt to make realtime multimedia applications, online games, and other applications work across NATs. Application Level Gateways [RFC2663] are one such mechanism. STUN [RFC3489bis] describes a UNilateral Self-Address Fixing (UNSAF) mechanism [RFC3424]. Teredo [RFC4380] describes an UNSAF mechanism consisting of tunnelling IPv6 [RFC2460] over UDP/IPv4. UDP Relays have also been used to enable applications across NATs, but these are generally seen as a solution of last resort. Interactive
多くのテクニックが、リアルタイムでマルチメディア応用、オンラインゲーム、および他のアプリケーションをNATsの向こう側に働かせるのを試みるのに使用されます。 アプリケーションLevel Gateways[RFC2663]はそのようなメカニズムの1つです。 STUN[RFC3489bis]はUNilateral Self-アドレスFixing(UNSAF)メカニズム[RFC3424]について説明します。 船食虫[RFC4380]はUDP/IPv4の上でトンネルIPv6[RFC2460]から成るUNSAFメカニズムについて説明します。 また、UDP RelaysはNATsの向こう側にアプリケーションを可能にするのに使用されましたが、一般に、これらは切り札の解決と考えられます。 インタラクティブ
Audet & Jennings Best Current Practice [Page 3] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[3ページ]RFC4787NAT UDPユニキャスト要件2007年1月
Connectivity Establishment [ICE] describes a methodology for using many of these techniques and avoiding a UDP relay, unless the type of NAT is such that it forces the use of such a UDP relay. This specification defines requirements for improving NATs. Meeting these requirements ensures that applications will not be forced to use UDP relay.
接続性特権階級[ICE]はこれらのテクニックの多くを使用して、UDPリレーを避けるために方法論について説明します、NATのタイプがそのようなものであるのでそのようなUDPリレーの使用を強制しない場合。 この仕様はNATsを改良するための要件を定義します。 これらの必要条件を満たすのは、アプリケーションがUDPがリレーする使用に押し込まれないのを確実にします。
As pointed out in UNSAF [RFC3424], "From observations of deployed networks, it is clear that different NAT box implementations vary widely in terms of how they handle different traffic and addressing cases". This wide degree of variability is one factor in the overall brittleness introduced by NATs and makes it extremely difficult to predict how any given protocol will behave on a network traversing NAT. Discussions with many of the major NAT vendors have made it clear that they would prefer to deploy NATs that were deterministic and caused the least harm to applications while still meeting the requirements that caused their customers to deploy NATs in the first place. The problem NAT vendors face is that they are not sure how best to do that or how to document their NATs' behavior.
UNSAF[RFC3424]で指摘されるように、「配備されたネットワークの観測によって、それらがどう異なった交通とアドレシングケースを扱うかに関して異なったNAT箱の実現がばらつきが大きいのは、明確です」。 この広い度の可変性で、NATsによって導入された総合的なもろさの1つの要素であり、どんな与えられたプロトコルもネットワークでどう振る舞うかを予測するのは、NATを横断しながら、非常に難しくなります。 一流のNAT業者の多くとの議論は、まだ彼らの顧客が第一にNATsを配備した必要条件を満たしている間、彼らが、決定論的であったNATsを配備するのを好むと断言して、最少の害をアプリケーションに引き起こしています。 問題NAT業者表面は彼らが確実に、どのように最も上手にそれをするか、そして、またはどのように彼らのNATsの振舞いを記録するかということでないということです。
The goals of this document are to define a set of common terminology for describing the behavior of NATs and to produce a set of requirements on a specific set of behaviors for NATs.
このドキュメントの目標は、NATsの動きについて説明するために1セットの一般的な用語を定義して、特定の振舞いのときにNATsのために1セットの要件を作り出すことです。
This document forms a common set of requirements that are simple and useful for voice, video, and games, which can be implemented by NAT vendors. This document will simplify the analysis of protocols for deciding whether or not they work in this environment and will allow providers of services that have NAT traversal issues to make statements about where their applications will work and where they will not, as well as to specify their own NAT requirements.
このドキュメントはNAT業者が実行できる一般的なセットの声に簡単で役に立つ要件、ビデオ、およびゲームを形成します。 このドキュメントは、この環境で働いて、NAT縦断問題があるサービスのプロバイダーが彼らのアプリケーションが動作するところに関する声明を出すのを許容して、決めないところで決めて、それら自身のNAT要件を指定するためにプロトコルの分析を簡素化するでしょう。
3. Terminology
3. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Readers are urged to refer to [RFC2663] for information on NAT taxonomy and terminology. Traditional NAT is the most common type of NAT device deployed. Readers may refer to [RFC3022] for detailed information on traditional NAT. Traditional NAT has two main varieties -- Basic NAT and Network Address/Port Translator (NAPT).
読者がNAT分類学と用語の情報について[RFC2663]を参照するよう促されます。 伝統的なNATは装置が配備したNATの最も一般的なタイプです。 読者は伝統的なNATの詳細な情報について[RFC3022]を参照するかもしれません。 伝統的なNATには、2つの主なバラエティーがあります--基本的なNATとNetwork Address/ポートTranslator(NAPT)。
NAPT is by far the most commonly deployed NAT device. NAPT allows multiple internal hosts to share a single public IP address simultaneously. When an internal host opens an outgoing TCP or UDP session through a NAPT, the NAPT assigns the session a public IP
NAPTは最も一般的に断然配備されたNAT装置です。 NAPTは複数の内部のホストに同時に、ただ一つの公共のIPアドレスを共有させます。 内部のホストがNAPTを通して出発しているTCPかUDPセッションを開くと、NAPTは公立のIPをセッションに割り当てます。
Audet & Jennings Best Current Practice [Page 4] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[4ページ]RFC4787NAT UDPユニキャスト要件2007年1月
address and port number, so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. The effect is that the NAPT establishes a NAT session to translate the (private IP address, private port number) tuple to a (public IP address, public port number) tuple, and vice versa, for the duration of the session. An issue of relevance to peer-to-peer applications is how the NAT behaves when an internal host initiates multiple simultaneous sessions from a single (private IP, private port) endpoint to multiple distinct endpoints on the external network. In this specification, the term "NAT" refers to both "Basic NAT" and "Network Address/Port Translator (NAPT)".
数を記述して、移植してください、外部の終点からのその後の応答パケットを内部のホストにNAPTが受け取って、翻訳して、送ることができるように。 効果はNAPTが(公共のIPアドレス、公共のポートナンバー)tupleに(プライベートIPアドレス、個人的なポートナンバー)tupleを翻訳するためにNATセッションを確立するということです、逆もまた同様に、セッションの持続時間のために。 ピアツーピアアプリケーションへの関連性の問題は内部のホストが外部のネットワークの複数の同時の単一(プライベートアイピー、個人的なポート)の終点から異なった複数の終点までのセッションを開始するとき、NATがどう振る舞うかということです。 この仕様では、「NAT」という用語は「基本的なナット」と「ネットワーク・アドレス/ポート翻訳者(NAPT)」の両方について言及します。
This document uses the term "session" as defined in RFC 2663: "TCP/ UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP ports, target IP address, target TCP/UDP Port)".
このドキュメントはRFC2663で定義されるように「セッション」という用語を使用します: 「TCP/ UDPセッションは(ソースIPアドレス、ソースTCP/UDP港、目標IPアドレス、目標TCP/UDP Port)のtupleによって唯一特定されます。」
This document uses the term "address and port mapping" as the translation between an external address and port and an internal address and port. Note that this is not the same as an "address binding" as defined in RFC 2663.
このドキュメントは外部アドレスと、ポートと、内部のアドレスとポートの間の翻訳として「アドレスとポートマッピング」という用語を使用します。 これがRFC2663で定義される「アドレス結合」と同じでないことに注意してください。
This document uses IANA terminology for port ranges, i.e., "Well Known Ports" is 0-1023, "Registered" is 1024-49151, and "Dynamic and/or Private" is 49152-65535, as defined in http://www.iana.org/assignments/port-numbers.
すなわち、「よく知られているポート」は0-1023です、「登録」であることは、1024-49151です、そして、「ダイナミックである、そして/または、個人的」であることは、49152-65535です、このドキュメントがポート範囲にIANA用語を使用して、 http://www.iana.org/assignments/port-numbers で定義されるように。
STUN [RFC3489] used the terms "Full Cone", "Restricted Cone", "Port Restricted Cone", and "Symmetric" to refer to different variations of NATs applicable to UDP only. Unfortunately, this terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior. This specification therefore refers to specific individual NAT behaviors instead of using the Cone/Symmetric terminology.
STUN[RFC3489]は「完全な円錐」、「ポートは円錐を制限してい」て、UDPだけに適切なNATsの異なった変化について言及するために「左右対称」の「制限された円錐」という用語を使用しました。 残念ながら、現実のNATの振舞いについて説明するところで不十分であると判明したようにこの用語は多くの混乱の源です。 したがって、この仕様はCone/左右対称の用語を使用することの代わりに特定の個々のNATの振舞いについて言及します。
4. Network Address and Port Translation Behavior
4. ネットワーク・アドレスとポート翻訳の振舞い
This section describes the various NAT behaviors applicable to NATs.
このセクションはNATsに適切な様々なNATの振舞いについて説明します。
4.1. Address and Port Mapping
4.1. アドレスとポートマッピング
When an internal endpoint opens an outgoing session through a NAT, the NAT assigns the session an external IP address and port number so that subsequent response packets from the external endpoint can be received by the NAT, translated, and forwarded to the internal endpoint. This is a mapping between an internal IP address and port IP:port and external IP:port tuple. It establishes the translation
内部の終点がNATを通して外向的なセッションを開くと、NATは、外部の終点からのその後の応答パケットを内部の終点にNATで受け取って、翻訳して、送ることができるように外部のIPアドレスとポートナンバーをセッションに割り当てます。 これはポートの内部のIPアドレスと、IP: ポートと外部のIPの間のマッピングです: ポートtuple。 それは翻訳を確立します。
Audet & Jennings Best Current Practice [Page 5] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[5ページ]RFC4787NAT UDPユニキャスト要件2007年1月
that will be performed by the NAT for the duration of the session. For many applications, it is important to distinguish the behavior of the NAT when there are multiple simultaneous sessions established to different external endpoints.
それはセッションの持続時間のためにNATによって実行されるでしょう。 多くのアプリケーションに、異なった外部の終点に確立された複数の同時のセッションがあるときのNATの振舞いを区別するのは重要です。
The key behavior to describe is the criteria for reuse of a mapping for new sessions to external endpoints, after establishing a first mapping between an internal X:x address and port and an external Y1:y1 address tuple. Let's assume that the internal IP address and port X:x are mapped to X1':x1' for this first session. The endpoint then sends from X:x to an external address Y2:y2 and gets a mapping of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' for various combinations of the relationship between Y1:y1 and Y2:y2 is critical for describing the NAT behavior. This arrangement is illustrated in the following diagram:
説明する主要な振舞いは外部の終点への新しいセッションのためのマッピングの再利用の評価基準です、外部のY1: 内部のX: xのアドレスと、ポートとy1の間でアドレスtupleを写像しながら第1を設立した後に。 '内部のIPアドレスとポートX: xがX1に写像されると仮定しましょう。この最初のセッションのための': x1'。 'そして終点は、外部のアドレスY2: X: xからy2まで発信して、NATで': x2'というX2に関するマッピングを得ます。 'X1の間のNATの振舞いについて説明するY1: y1とY2: y2との関係の様々な組み合わせのための': x1と'X2': x2'が重要である関係。 このアレンジメントは以下のダイヤグラムで例証されます:
E
+------+ +------+ x
| Y1 | | Y2 | t
+--+---+ +---+--+ e
| Y1:y1 Y2:y2 | r
+----------+ +----------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+-+
...........| NAT |...............
+--+---+-+ I
| | n
X:x | | X:x t
++---++ e
| X | r
+-----+ n
a
l
E+------+ +------+ x| Y1| | Y2| t+--+---+ +---+--+ e| Y1:y1 Y2:y2| r+----------+ +----------+ n| | 'X1': x1、'| | 'X2': x2'l+--+---+-+ ...........| NAT|............... +--+---++I| | n X: x| | X: x t++---+ + e| X| r+-----+ n a l
Address and Port Mapping
アドレスとポートマッピング
The following address and port mapping behavior are defined:
振舞いを写像する以下のアドレスとポートが定義されます:
Endpoint-Independent Mapping:
終点から独立しているマッピング:
The NAT reuses the port mapping for subsequent packets sent
from the same internal IP address and port (X:x) to any
external IP address and port. Specifically, X1':x1' equals
X2':x2' for all values of Y2:y2.
NATはどんな外部のIPアドレスと同じ内部のIPアドレスとポート(X: x)からポートにも送られたその後のパケットのためのポートマッピングを再利用します。 '明確にすべてのための': x2'が評価するY2: y2のX1': x1'同輩X2。
Audet & Jennings Best Current Practice [Page 6] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[6ページ]RFC4787NAT UDPユニキャスト要件2007年1月
Address-Dependent Mapping:
アドレス依存するマッピング:
The NAT reuses the port mapping for subsequent packets sent
from the same internal IP address and port (X:x) to the same
external IP address, regardless of the external port.
Specifically, X1':x1' equals X2':x2' if and only if, Y2 equals
Y1.
NATは同じ内部のIPアドレスとポート(X: x)から外部の同じIPアドレスに送られたその後のパケットのためのポートマッピングを再利用します、外部のポートにかかわらず。 '明確にX1': x1'同輩X2':、x2、'、唯一、Y2はY1と等しいです。
Address and Port-Dependent Mapping:
アドレスとポート依存するマッピング:
The NAT reuses the port mapping for subsequent packets sent
from the same internal IP address and port (X:x) to the same
external IP address and port while the mapping is still active.
Specifically, X1':x1' equals X2':x2' if and only if, Y2:y2
equals Y1:y1.
NATはマッピングがまだアクティブですが、同じ外部のIPアドレスと同じ内部のIPアドレスとポート(X: x)からポートに送られたその後のパケットのためのポートマッピングを再利用します。 '明確にX1': x1'同輩X2':、x2、'、唯一、Y2: y2はY1と等しいです: y1
It is important to note that these three possible choices make no difference to the security properties of the NAT. The security properties are fully determined by which packets the NAT allows in and which it does not. This is determined by the filtering behavior in the filtering portions of the NAT.
これらの3つの可能な選択がNATのセキュリティの特性に重要でないことに注意するのは重要です。 セキュリティの特性はNATが中に許容して、それがそうしないどのパケットで完全に決定しているか。 これはNATのフィルタリング部分でのフィルタリングの振舞いで決定します。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
REQ-1: NATには、「終点から独立しているマッピング」の振舞いがなければなりません。
Justification: In order for UNSAF methods to work, REQ-1 needs to be
met. Failure to meet REQ-1 will force the use of a UDP relay,
which is very often impractical.
正当化: 働くUNSAF方法の注文では、REQ-1は、会われる必要があります。 (頻繁に使用はそうです)。REQ-1に会わないと、UDPリレーの使用を強制するでしょう。非実用的。
Some NATs are capable of assigning IP addresses from a pool of IP addresses on the external side of the NAT, as opposed to just a single IP address. This is especially common with larger NATs. Some NATs use the external IP address mapping in an arbitrary fashion (i.e., randomly): one internal IP address could have multiple external IP address mappings active at the same time for different sessions. These NATs have an "IP address pooling" behavior of "Arbitrary". Some large Enterprise NATs use an IP address pooling behavior of "Arbitrary" as a means of hiding the IP address assigned to specific endpoints by making their assignment less predictable. Other NATs use the same external IP address mapping for all sessions associated with the same internal IP address. These NATs have an "IP address pooling" behavior of "Paired". NATs that use an "IP address pooling" behavior of "Arbitrary" can cause issues for applications that use multiple ports from the same endpoint, but that do not negotiate IP addresses individually (e.g., some applications using RTP and RTCP).
いくつかのNATsがNAT外部側でIPアドレスのプールからの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
Audetとジョニングス最も良い現在の習慣[7ページ]RFC4787NAT UDPユニキャスト要件2007年1月
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling"
behavior of "Paired". Note that this requirement is not
applicable to NATs that do not support IP address pooling.
REQ-2: NATには「対にされること」の「IPアドレス合同」の振舞いがあるのは、RECOMMENDEDです。 この要件がIPアドレス合同をサポートしないNATsに適切でないことに注意してください。
Justification: This will allow applications that use multiple ports
originating from the same internal IP address to also have the
same external IP address. This is to avoid breaking peer-to-peer
applications that are not capable of negotiating the IP address
for RTP and the IP address for RTCP separately. As such it is
envisioned that this requirement will become less important as
applications become NAT-friendlier with time. The main reason why
this requirement is here is that in a peer-to-peer application,
you are subject to the other peer's mistake. In particular, in
the context of SIP, if my application supports the extensions
defined in [RFC3605] for indicating RTP and RTCP addresses and
ports separately, but the other peer does not, there may still be
breakage in the form of the stream losing RTCP packets. This
requirement will avoid the loss of RTP in this context, although
the loss of RTCP may be inevitable in this particular example. It
is also worth noting that RFC 3605 is unfortunately not a
mandatory part of SIP [RFC3261]. Therefore, this requirement will
address a particularly nasty problem that will prevail for a
significant period of time.
正当化: また、これで、同じ内部のIPアドレスから発する複数のポートを使用するアプリケーションは同じ外部のIPアドレスを持つことができるでしょう。 これは、RTCPのために別々にRTPのためのIPアドレスを交渉できないピアツーピアアプリケーションとIPアドレスを破るのを避けるためのものです。 そのようなものとして、思い描かれて、時間に従って、この要件がアプリケーションとして、より重要でなくなるのは、よりNATに優しくなります。 この要件がここにある主な理由はピアツーピアアプリケーションでは、あなたがもう片方の同輩の誤りを被りやすいということです。 私のアプリケーションが別々にRTP、RTCPアドレス、およびポートを示すために[RFC3605]で定義された拡大を支持しますが、もう片方の同輩が支持するというわけではないなら、流れの喪失RTCPパケットの形には特に、折損がまだSIPの文脈に、あるかもしれません。 この要件はこのような関係においてはRTPの損失を避けるでしょう、RTCPの損失がこの特定の例で必然であるかもしれませんが。 また、残念ながら、RFC3605がSIP[RFC3261]の義務的な部分でないことに注意する価値があります。 したがって、この要件は重要な期間の間に広がっているその特に不快な問題を訴えるでしょう。
Audet & Jennings Best Current Practice [Page 8] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[8ページ]RFC4787NAT UDPユニキャスト要件2007年1月
4.2. Port Assignment
4.2. ポート課題
4.2.1. Port Assignment Behavior
4.2.1. ポート課題の振舞い
This section uses the following diagram for reference.
このセクションは参照に以下のダイヤグラムを使用します。
E
+-------+ +-------+ x
| Y1 | | Y2 | t
+---+---+ +---+---+ e
| Y1:y1 Y2:y2 | r
+---------+ +---------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+--+
...........| NAT |...............
+--+---+--+ I
| | n
+---------+ +---------+ t
| X1:x1 X2:x2 | e
+---+---+ +---+---+ r
| X1 | | X2 | n
+-------+ +-------+ a
l
E+-------+ +-------+ x| Y1| | Y2| t+---+---+ +---+---+ e| Y1:y1 Y2:y2| r+---------+ +---------+ n| | 'X1': x1、'| | 'X2': x2'l+--+---+--+ ...........| NAT|............... +--+---+--+ 私| | n+---------+ +---------+ t| X1:x1 X2:x2| e+---+---+ +---+---+ r| X1| | X2| n+-------+ +-------+ a l
Port Assignment
ポート課題
Some NATs attempt to preserve the port number used internally when assigning a mapping to an external IP address and port (e.g., x1=x1', x2=x2'). This port assignment behavior is referred to as "port preservation". In case of port collision, these NATs attempt a variety of techniques for coping. For example, some NATs will overridden the previous mapping to preserve the same port. Other NATs will assign a different IP address from a pool of external IP addresses; this is only possible as long as the NAT has enough external IP addresses; if the port is already in use on all available external IP addresses, then these NATs will pick a different port (i.e., they don't do port preservation anymore).
'外部のIPアドレスとポート(例えば、x1=x1、'x2=x2')にマッピングを割り当てるとき、ポートナンバーを保存する何らかのNATs試みが内用しました。 このポート課題の振舞いは「ポート保存」と呼ばれます。 ポート衝突の場合には、これらのNATsは対処するためのさまざまなテクニックを試みます。 例えば、いくつかのNATsは優越するでしょう。同じポートを保持する前のマッピングに優越します。 他のNATsは外部のIPアドレスのプールからの異なったIPアドレスを割り当てるでしょう。 NATに十分な外部のIPアドレスがある限り、これは可能であるだけです。 ポートがすべての利用可能な外部のIPアドレスで既に使用中であるなら、これらのNATsは異なったポートを選ぶでしょう(すなわち、彼らはそれ以上ポート保存をしません)。
Some NATs use "Port overloading", i.e., they always use port preservation even in the case of collision (i.e., X1'=X2' and x1=x2=x1'=x2'). Most applications will fail if the NAT uses "Port overloading".
'いくつかのNATsが「ポート積みすぎ」を使用します、すなわち、彼らは衝突の場合にさえポート保存をいつも使用します(すなわち、X1が'X2と等しいです'、そして、x1=x2=x1は'x2と等しいです')。 NATが「ポート積みすぎ」を使用すると、ほとんどのアプリケーションが失敗するでしょう。
A NAT that does not attempt to make the external port numbers match the internal port numbers in any case is referred to as "no port preservation".
どのような場合でも、外部のポートナンバーに内部のポートナンバーを合わせるのを試みないNATは「ポート保存がありません」と呼ばれます。
Audet & Jennings Best Current Practice [Page 9] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[9ページ]RFC4787NAT UDPユニキャスト要件2007年1月
When NATs do allocate a new source port, there is the issue of which IANA-defined range of port to choose. The ranges are "well-known" from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ private" from 49152 through 65535. For most protocols, these are destination ports and not source ports, so mapping a source port to a source port that is already registered is unlikely to have any bad effects. Some NATs may choose to use only the ports in the dynamic range; the only downside of this practice is that it limits the number of ports available. Other NAT devices may use everything but the well-known range and may prefer to use the dynamic range first, or possibly avoid the actual registered ports in the registered range. Other NATs preserve the port range if it is in the well-known range. [RFC0768] specifies that the source port is set to zero if no reply packets are expected. In this case, it does not matter what the NAT maps it to, as the source port will not be used. However, many common OS APIs do not allow a user to send from port zero, applications do not use port zero, and the behavior of various existing NATs with regards to a packet with a source of port zero is unknown. This document does not specify any normative behavior for a NAT when handling a packet with a source port of zero which means that applications cannot count on any sort of deterministic behavior for these packets.
NATsが新しいソース港を割り当てるとき、それのIANAによって定義された範囲のポートを選ぶかに関する問題があります。 範囲は、49151、1024年から「ダイナミックであるか個人的になる」まで49152〜65535まで「周知で」0〜1023年まで、「登録されています」。 ほとんどのプロトコルのために、これらがソース港ではなく、仕向港であるので、既に登録されるソース港にソース港を写像するのにおいて、どんな悪い効果もありそうにはありません。 いくつかのNATsが、ダイナミックレンジにポートだけを使用するのを選ぶかもしれません。 この習慣の唯一の下落傾向は有効なポートの数を制限するということです。 他のNAT装置は、周知の範囲以外のすべてを使用して、最初にダイナミックレンジを使用するのを好むか、またはことによると登録された範囲の実際の登録されたポートを避けるかもしれません。 それが周知の範囲にあるなら、他のNATsはポート範囲を保持します。 [RFC0768]は、回答パケットが全く予想されないならソース港がゼロに設定されると指定します。 この場合、NATがそれを何に写像するかは重要ではありません、ソース港が使用されないとき。 しかしながら、多くの一般的なOS APIで、ユーザはアプリケーションにポートからゼロをポートゼロを使用させないことができません、そして、ポートゼロの源があるパケットへの尊敬による様々な既存のNATsの動きは未知です。 アプリケーションがこれらのパケットのためのどんな種類の決定論的な振舞いも頼りにすることができないことを意味するゼロのソース港でパケットを扱うとき、このドキュメントはNATのための少しの標準の振舞いも指定しません。
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading".
REQ-3: NATには、「ポート積みすぎ」の「ポート課題」の振舞いがあってはいけません。
a) If the host's source port was in the range 0-1023, it is
RECOMMENDED the NAT's source port be in the same range. If the
host's source port was in the range 1024-65535, it is
RECOMMENDED that the NAT's source port be in that range.
a) ホストのソース港が範囲0-1023にあったなら、コネが同じ範囲であったなら、それはRECOMMENDED NATのソース港です。 ホストのソース港が範囲1024-65535にあったなら、NATのソース港がその範囲にあるのは、RECOMMENDEDです。
Justification: This requirement must be met in order to enable two
applications on the internal side of the NAT both to use the same
port to try to communicate with the same destination. NATs that
implement port preservation have to deal with conflicts on ports,
and the multiple code paths this introduces often result in
nondeterministic behavior. However, it should be understood that
when a port is randomly assigned, it may just randomly happen to
be assigned the same port. Applications must, therefore, be able
to deal with both port preservation and no port preservation.
正当化: NAT内部側における2つのアプリケーションが同じ目的地で交信しようとするためにともに同じポートを使用するのを可能にするためにこの必要条件を満たさなければなりません。 ポート保存を実行するNATsはポートにおける闘争に対処しなければなりません、そして、これが導入する複数のコード経路がしばしば非決定論的振舞いをもたらします。 しかしながら、ポートが手当たりしだいに割り当てられるとき、同じポートが割り当てられるのがちょうど手当たりしだいに起こるかもしれないのが理解されるべきです。 したがって、アプリケーションはポート保存とポート保存がない両方に対処できなければなりません。
a) Certain applications expect the source UDP port to be in the
well-known range. See the discussion of Network File System
port expectations in [RFC2623] for an example.
a) あるアプリケーションは、ソースUDP港が周知の範囲にあると予想します。 ネットワークファイルシステムの議論が例のために[RFC2623]で期待を移植するのを見てください。
Audet & Jennings Best Current Practice [Page 10] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[10ページ]RFC4787NAT UDPユニキャスト要件2007年1月
4.2.2. Port Parity
4.2.2. ポートの同等
Some NATs preserve the parity of the UDP port, i.e., an even port will be mapped to an even port, and an odd port will be mapped to an odd port. This behavior respects the [RFC3550] rule that RTP use even ports, and RTCP use odd ports. RFC 3550 allows any port numbers to be used for RTP and RTCP if the two numbers are specified separately; for example, using [RFC3605]. However, some implementations do not include RFC 3605, and do not recognize when the peer has specified the RTCP port separately using RFC 3605. If such an implementation receives an odd RTP port number from the peer (perhaps after having been translated by a NAT), and then follows the RFC 3550 rule to change the RTP port to the next lower even number, this would obviously result in the loss of RTP. NAT-friendly application aspects are outside the scope of this document. It is expected that this issue will fade away with time, as implementations improve. Preserving the port parity allows for supporting communication with peers that do not support explicit specification of both RTP and RTCP port numbers.
いくつかのNATsがUDPポートの同等を保存します、そして、すなわち、同等のポートは同等のポートに写像されるでしょう、そして、変なポートは変なポートに写像されるでしょう。 この振舞いはRTPがポートさえ使用して、RTCPが変なポートを使用するという[RFC3550]規則を尊敬します。 2つの番号が別々に指定されるなら、RFC3550は、どんなポートナンバーもRTPとRTCPに使用されるのを許容します。 例えば、[RFC3605]を使用すること。 しかしながら、いくつかの実現は、RFC3605を含まないで、また同輩が指定したとき、RTCPが別々に使用RFC3605を移植すると認めません。 そのような実現が変なRTPポートナンバーに、同輩(恐らくNATによって翻訳された後の)を受け取って、次に、RTPポートを次の下側の偶数に変えるためにRFC3550規則に従うなら、これは明らかにRTPの損失をもたらすでしょう。 このドキュメントの範囲の外にNATに優しいアプリケーション局面があります。 実現が向上するとき、時間に応じてこの問題が消え去ると予想されます。 ポートの同等を保存するのは、RTPとRTCPポートナンバーの両方の明白な仕様を支持しない同輩とのコミュニケーションを支持すると考慮します。
REQ-4: It is RECOMMENDED that a NAT have a "Port parity
preservation" behavior of "Yes".
REQ-4: NATには「はい」の「ポートパリティ保存」の振舞いがあるのは、RECOMMENDEDです。
Justification: This is to avoid breaking peer-to-peer applications
that do not explicitly and separately specify RTP and RTCP port
numbers and that follow the RFC 3550 rule to decrement an odd RTP
port to make it even. The same considerations apply, as per the
IP address pooling requirement.
正当化: これは、明らかに別々にRTPとRTCPポートナンバーを指定しないで、それを作るのさえ変なRTPポートを減少させるためにRFC3550規則に従う壊れているピアツーピアアプリケーションを避けるためのものです。 同じ問題はIPアドレス合同要件に従って適用されます。
4.2.3. Port Contiguity
4.2.3. ポートの接触
Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs do things like sequential assignment or port reservation. Sequential port assignment assumes that the application will open a mapping for RTP first and then open a mapping for RTCP. It is not practical to enforce this requirement on all applications. Furthermore, there is a problem with glare if many applications (or endpoints) are trying to open mappings simultaneously. Port preservation is also problematic since it is wasteful, especially considering that a NAT cannot reliably distinguish between RTP over UDP and other UDP packets where there is no contiguity rule. For those reasons, it would be too complex to attempt to preserve the contiguity rule by suggesting specific NAT behavior, and it would certainly break the deterministic behavior rule.
いくつかのNATsが、RTCP=RTP+1のポート接触規則を保存するのを試みます。 これらのNATsは連続した課題やポートの予約のようなことをします。 連続したポート課題はアプリケーションがRTP1番目のために地図を広げて、次に、RTCPのために地図を広げると仮定します。 この要件にすべてのアプリケーションに押しつけるのは実用的ではありません。 その上、多くのアプリケーション(または、終点)が同時にマッピングを開こうとしているなら、ギラギラと眩しい光に関する問題があります。 また、それが無駄であるので、ポート保存も問題が多いです、NATがUDPと他のUDPパケットの上の接触規則が全くないRTPを確かに見分けることができないと特に考える場合。 それらの理由で、特定のNATの振舞いを示すことによって接触規則を保存するのを試みるのが複雑過ぎるだろう、確かに、それは決定論的な振舞い規則を破るでしょう。
In order to support both RTP and RTCP, it will therefore be necessary that applications follow rules to negotiate RTP and RTCP separately, and account for the very real possibility that the RTCP=RTP+1 rule
したがって、RTPとRTCPの両方をサポートするために、アプリケーションが別々にRTPとRTCPを交渉するために規則に従って、RTCP=RTP+1が統治する非常に本当の可能性を説明するのが必要でしょう。
Audet & Jennings Best Current Practice [Page 11] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[11ページ]RFC4787NAT UDPユニキャスト要件2007年1月
will be broken. As this is an application requirement, it is outside the scope of this document.
壊れるだろう。 これがアプリケーション要件であるので、このドキュメントの範囲の外にそれはあります。
4.3. Mapping Refresh
4.3. 写像して、リフレッシュしてください。
NAT mapping timeout implementations vary, but include the timer's value and the way the mapping timer is refreshed to keep the mapping alive.
タイムアウト実装を写像するNATが、タイマの値とマッピングタイマがマッピングを生かすためにリフレッシュされる方法を変えますが、含んでいます。
The mapping timer is defined as the time a mapping will stay active without packets traversing the NAT. There is great variation in the values used by different NATs.
マッピングタイマはパケットがNATを横断しないでマッピングがアクティブな状態で残っている時と定義されます。 異なったNATsによって使用された値のすばらしい変化があります。
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two
minutes, unless REQ-5a applies.
REQ-5: REQ-5aが適用しない場合、NAT UDPマッピングタイマは2分未満後に期限が切れてはいけません。
a) For specific destination ports in the well-known port range
(ports 0-1023), a NAT MAY have shorter UDP mapping timers that
are specific to the IANA-registered application running over
that specific destination port.
a) ウェルノウンポート範囲(ポート0-1023)の特定の仕向港に関しては、NATで、より短いUDPはその特定の仕向港中を走らせるIANAによって登録されたアプリケーションに特定のタイマを写像するかもしれません。
b) The value of the NAT UDP mapping timer MAY be configurable.
b) NAT UDPマッピングタイマの値は構成可能であるかもしれません。
c) A default value of five minutes or more for the NAT UDP mapping
timer is RECOMMENDED.
c) NAT UDPマッピングタイマのための5分以上のデフォルト値はRECOMMENDEDです。
Justification: This requirement is to ensure that the timeout is
long enough to avoid too-frequent timer refresh packets.
正当化: この要件はタイムアウトがまた、頻繁なタイマを避けることができるくらいの長い間パケットをリフレッシュすることであることを保証することです。
a) Some UDP protocols using UDP use very short-lived connections.
There can be very many such connections; keeping them all in a
connections table could cause considerable load on the NAT.
Having shorter timers for these specific applications is,
therefore, an optimization technique. It is important that the
shorter timers applied to specific protocols be used sparingly,
and only for protocols using well-known destination ports that
are known to have a shorter timer, and that are known not to be
used by any applications for other purposes.
a) UDPを使用するいくつかのUDPプロトコルが非常に短命な接続を使用します。 そこでは、非常に多くのそのようなものが接続であったならそうすることができます。 接続テーブルに彼らがすべてであることを保つのがNATでかなりの負荷を引き起こす場合がありました。 したがって、これらの特定のアプリケーションのための、より短いタイマを持つのは、最適化手法です。 特定のプロトコルに適用されたより短いタイマが控えめに、そして、単にプロトコルにより短いタイマを持っているのが知られていて、他の目的のためのどんなアプリケーションでも使用されないのが知られているよく知られる仕向港を使用することで使用されるのは、重要です。
b) Configuration is desirable for adapting to specific networks
and troubleshooting.
b) 構成は、特定のネットワークに順応するのに望ましい、そして、障害調査します。
c) This default is to avoid too-frequent timer refresh packets.
c) このデフォルトはまた、頻繁なタイマを避けるのがパケットをリフレッシュするということです。
Some NATs keep the mapping active (i.e., refresh the timer value) when a packet goes from the internal side of the NAT to the external side of the NAT. This is referred to as having a NAT Outbound refresh behavior of "True".
パケットがNAT内部側から外部のNATの端まで行くとき、いくつかのNATsがアクティブに(すなわち、タイマ値をリフレッシュします)マッピングを保ちます。 これはNAT Outboundに「本当」の振舞いをリフレッシュさせると呼ばれます。
Audet & Jennings Best Current Practice [Page 12] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[12ページ]RFC4787NAT UDPユニキャスト要件2007年1月
Some NATs keep the mapping active when a packet goes from the external side of the NAT to the internal side of the NAT. This is referred to as having a NAT Inbound Refresh Behavior of "True".
パケットがNAT外部側から内部のNATの端まで行くとき、いくつかのNATsがマッピングをアクティブに保ちます。 これは「本当」のNAT Inbound Refresh Behaviorを持っていると呼ばれます。
Some NATs keep the mapping active on both, in which case, both properties are "True".
いくつかのNATsが両方でアクティブにマッピングを保ちます、その場合、両方の特性は「本当です」。
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound
refresh behavior" of "True".
REQ-6: 「NAT Outboundは振舞いをリフレッシュします」。Refresh Directionを写像するNATがaを持たなければならない、「本当」について。
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
refresh behavior" of "True".
a) 「NAT Inboundは振舞いをリフレッシュします」。Refresh Directionを写像するNATがaを持っているかもしれない、「本当」について。
Justification: Outbound refresh is necessary for allowing the client
to keep the mapping alive.
正当化: 外国行き、リフレッシュ、クライアントがマッピングを生かすのを許容するのに必要です。
a) Inbound refresh may be useful for applications with no outgoing
UDP traffic. However, allowing inbound refresh may allow an
external attacker or misbehaving application to keep a mapping
alive indefinitely. This may be a security risk. Also, if the
process is repeated with different ports, over time, it could
use up all the ports on the NAT.
a) リフレッシュしてください。本国行き、外向的なUDPトラフィックなしでアプリケーションの役に立ってもよいです。 外部の攻撃者を許容するかもしれないか、またはふらちな事をしながら、リフレッシュしてください。しかしながら、許容本国行き、マッピングを無期限に生かすアプリケーション。 これはセキュリティリスクであるかもしれません。 また、プロセスが異なったポートで繰り返されるなら、時間がたつにつれて、それはNATのすべてのポートを使いきるかもしれません。
4.4. Conflicting Internal and External IP Address Spaces
4.4. 闘争している内部の、そして、外部のIPアドレス空間
Many NATs, particularly consumer-level devices designed to be deployed by nontechnical users, routinely obtain their external IP address, default router, and other IP configuration information for their external interface dynamically from an external network, such as an upstream ISP. The NAT, in turn, automatically sets up its own internal subnet in one of the private IP address spaces assigned to this purpose in [RFC1918], typically providing dynamic IP configuration services for hosts on this internal network.
多くのNATs(特に非技術系のユーザによって配布されるように設計された消費者レベルデバイス)が外部のネットワークから彼らの外部のインタフェースのための彼らの外部のIPアドレス、デフォルトルータ、および他のIP設定情報をきまりきってダイナミックに得ます、上流のISPのように。 NATは順番に自動的にこの意味に[RFC1918]で割り当てられたプライベートアイピーアドレス空間の1つにおけるそれ自身の内部サブネットをセットアップします、この内部のネットワークでホストのためのダイナミックなIP構成サービスを通常提供して。
Auto-configuration of NATs and private networks can be problematic, however, if the NAT's external network is also in RFC 1918 private address space. In a common scenario, an ISP places its customers behind a NAT and hands out private RFC 1918 addresses to them. Some of these customers, in turn, deploy consumer-level NATs, which, in effect, act as "second-level" NATs, multiplexing their own private RFC 1918 IP subnets onto the single RFC 1918 IP address provided by the ISP. There is no inherent guarantee, in this case, that the ISP's "intermediate" privately-addressed network and the customer's internal privately-addressed network will not use numerically identical or overlapping RFC 1918 IP subnets. Furthermore, customers of consumer-level NATs cannot be expected to have the technical
しかしながら、1918年のRFCの個人的なアドレス空間にもNATの外部のネットワークがあるなら、NATsと私設のネットワークの自動構成は問題が多い場合があります。 共通したシナリオでは、ISPは、NATの後ろに顧客を置いて、個人的なRFC1918アドレスをそれらに与えます。 何人かのこれらの顧客が順番に、消費者レベルNATsを配布します、ISPによって提供された独身のRFC1918IPアドレスにそれら自身の個人的なRFC1918IPサブネットを多重送信して。(事実上、NATsは「第2レベル」NATsとして機能します)。 ISPの個人的に扱われた「中間的な」ネットワークと顧客の内部の個人的に扱われたネットワークが数の上で同じであるか重なっているRFC1918IPサブネットを使用しないというこの場合、どんな固有の保証もありません。 その上、消費者レベルNATsの顧客には技術があることを期待できません。
Audet & Jennings Best Current Practice [Page 13] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[13ページ]RFC4787NAT UDPユニキャスト要件2007年1月
knowledge to prevent this scenario from occurring by manually configuring their internal network with non-conflicting RFC 1918 subnets.
このシナリオが起こるのを非闘争RFC1918サブネットで手動でそれらの内部のネットワークを構成することによって防ぐ知識。
NAT vendors need to design their NATs to ensure that they function correctly and robustly even in such problematic scenarios. One possible solution is for the NAT to ensure that whenever its external link is configured with an RFC 1918 private IP address, the NAT automatically selects a different, non-conflicting RFC 1918 IP subnet for its internal network. A disadvantage of this solution is that, if the NAT's external interface is dynamically configured or re- configured after its internal network is already in use, then the NAT may have to renumber its entire internal network dynamically if it detects a conflict.
NATベンダーは、彼らがそのような問題の多いシナリオでさえ正しさに、そして強壮に機能するのを保証するようにそれらのNATsを設計する必要があります。 1つの可能なソリューションはNATが、外部のリンクが1918年のRFCプライベートIPアドレスによって構成されるときはいつも、NATが内部のネットワークのために自動的に異なって、非闘争しているRFC1918IPサブネットを選択するのを保証することです。 このソリューションの不都合は次に、内部のネットワークが既に使用中になった後に、NATの外部のインタフェースがダイナミックに構成されているか、または再構成されているなら闘争を検出するならNATが全体の内部のネットワークにダイナミックに番号を付け替えさせなければならないかもしれないということです。
An alternative solution is for the NAT to be designed so that it can translate and forward traffic correctly, even when its external and internal interfaces are configured with numerically overlapping IP subnets. In this scenario, for example, if the NAT's external interface has been assigned an IP address P in RFC 1918 space, then there might also be an internal node I having the same RFC 1918 private IP address P. An IP packet with destination address P on the external network is directed at the NAT, whereas an IP packet with the same destination address P on the internal network is directed at node I. The NAT therefore needs to maintain a clear operational distinction between "external IP addresses" and "internal IP addresses" to avoid confusing internal node I with its own external interface. In general, the NAT needs to allow all internal nodes (including I) to communicate with all external nodes having public (non-RFC 1918) IP addresses, or having private IP addresses that do not conflict with the addresses used by its internal network.
代替のソリューションはNATが正しくトラフィックを翻訳して、進めることができるように設計されていることです、外部の、そして、内部のインタフェースが数の上でIPサブネットを重ね合わせるのに構成さえされるとき。 このシナリオでは、例えば、内部のノードが私であったなら同じRFCを持ちながら1918年のRFCスペース、そこのその時のPがそうするかもしれないIPアドレスもNATの外部のインタフェースに割り当ててあるなら、NATは外部のネットワークに関する送付先アドレスPがある1918年のプライベートIPアドレスP.An IPパケットに向けられます; ノードI.は内部のネットワークに関する同じ送付先アドレスPがあるIPパケットに向けられますが、したがって、NATは、内部のノードIをそれ自身の外部のインタフェースに間違えるのを避けるために「外部のIPアドレス」と「内部のIPアドレス」の明確な操作上の区別を維持する必要があります。 一般に、NATは、すべての内部のノード(含んでいる私)が公共(非RFC1918)のIPアドレスを持っているか、または内部のネットワークによって使用されるアドレスと闘争しないプライベートIPアドレスを持っているすべての外部ノードとコミュニケートするのを許容する必要があります。
REQ-7: A NAT device whose external IP interface can be configured
dynamically MUST either (1) automatically ensure that its internal
network uses IP addresses that do not conflict with its external
network, or (2) be able to translate and forward traffic between
all internal nodes and all external nodes whose IP addresses
numerically conflict with the internal network.
REQ-7: ダイナミックに外部のIPインタフェースを構成できるNATデバイスはIPアドレスが数の上で内部のネットワークと衝突するすべての内部のノードとすべての外部ノードの間の(1)が翻訳するために内部のネットワーク用途外部のネットワークと衝突しないIPアドレス、または(2)ができるのを自動的に確実にするどちらか、前進のトラフィックがそうしなければなりません。
Justification: If a NAT's external and internal interfaces are
configured with overlapping IP subnets, then there is, of course,
no way for an internal host with RFC 1918 IP address Q to initiate
a direct communication session to an external node having the same
RFC 1918 address Q, or to other external nodes with IP addresses
that numerically conflict with the internal subnet. Such nodes
can still open communication sessions indirectly via NAT traversal
techniques, however, with the help of a third-party server, such
as a STUN server having a public, non-RFC 1918 IP address. In
正当化: NATの外部の、そして、内部のインタフェースがIPサブネットを重ね合わせるのに構成されるなら、RFC1918IPアドレスQをもっている内部のホストが同じRFC1918アドレスQを持っている外部ノード、または、IPアドレスがある数の上で内部サブネットと衝突する他の外部ノードにダイレクトコミュニケーションセッションを開始する方法が全くもちろんありません。 しかしながら、そのようなノードは第三者サーバの助けで間接的にNAT縦断のテクニックでまだコミュニケーションセッションを開くことができます、1918年の公共の、そして、非RFCのIPアドレスを持っているSTUNサーバのように。 コネ
Audet & Jennings Best Current Practice [Page 14] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[14ページ]RFC4787NAT UDPユニキャスト要件2007年1月
this case, nodes with conflicting private RFC 1918 addresses on
opposite sides of the second-level NAT can communicate with each
other via their respective temporary public endpoints on the main
Internet, as long as their common, first-level NAT (e.g., the
upstream ISP's NAT) supports hairpinning behavior, as described in
Section 6.
個人的なRFC1918が第2レベルNATの反対側で扱う闘争を伴うノードは主なインターネットのそれらのそれぞれの一時的な公共の終点を通って互いにコミュニケートできます、それらの一般的で、最初に平らなNAT(例えば、上流のISPのNAT)がhairpinningに振舞いをサポートする限り、本件、セクション6で説明されるように。
5. Filtering Behavior
5. 振舞いをフィルターにかけます。
This section describes various filtering behaviors observed in NATs.
このセクションはNATsで観測された様々なフィルタリングの振舞いについて説明します。
When an internal endpoint opens an outgoing session through a NAT, the NAT assigns a filtering rule for the mapping between an internal IP:port (X:x) and external IP:port (Y:y) tuple.
内部の終点がNATを通して外向的なセッションを開くと、NATは内部のIP: ポート(X: x)と外部のIPの間のマッピングのためにフィルタリング規則を割り当てます: ポート(Y: y)tuple。
The key behavior to describe is what criteria are used by the NAT to filter packets originating from specific external endpoints.
説明する主要な振舞いはどんな評価基準がNATによって使用されるか、そして、特定の外部の終点から発するパケットをフィルターにかけるということです。
Endpoint-Independent Filtering:
終点から独立しているフィルタリング:
The NAT filters out only packets not destined to the internal
address and port X:x, regardless of the external IP address and
port source (Z:z). The NAT forwards any packets destined to
X:x. In other words, sending packets from the internal side of
the NAT to any external IP address is sufficient to allow any
packets back to the internal endpoint.
NATは内部のアドレスとポートXに運命づけられなかったパケットだけを無視します: 外部のIPアドレスとポートソースにかかわらずx(Z: z)。 NATはX: xに運命づけられたどんなパケットも進めます。 言い換えれば、NAT内部側から外部のどんなIPアドレスにもパケットを送るのは、内部の終点にどんなパケットも許容して戻すために十分です。
Address-Dependent Filtering:
アドレス依存するフィルタリング:
The NAT filters out packets not destined to the internal
address X:x. Additionally, the NAT will filter out packets
from Y:y destined for the internal endpoint X:x if X:x has not
sent packets to Y:any previously (independently of the port
used by Y). In other words, for receiving packets from a
specific external endpoint, it is necessary for the internal
endpoint to send packets first to that specific external
endpoint's IP address.
NATは内部のアドレスXに運命づけられなかったパケットを無視します: x。 さらに、X: xが以前に(Yによって使用されるポートの如何にかかわらず)Y: いずれにもパケットを送らないと、NATはY: 内部の終点Xに運命づけられたy: xからパケットを無視するでしょう。 言い換えれば、特定の外部の終点からパケットを受けるのに、内部の終点が最初に、その特定の外部の終点のIPアドレスにパケットを送るのが必要です。
Address and Port-Dependent Filtering:
アドレスとポート依存するフィルタリング:
This is similar to the previous behavior, except that the
external port is also relevant. The NAT filters out packets
not destined for the internal address X:x. Additionally, the
NAT will filter out packets from Y:y destined for the internal
endpoint X:x if X:x has not sent packets to Y:y previously. In
other words, for receiving packets from a specific external
endpoint, it is necessary for the internal endpoint to send
packets first to that external endpoint's IP address and port.
また、外部のポートも関連しているのを除いて、これは前の振舞いと同様です。 NATは内部のアドレスXのために運命づけられなかったパケットを無視します: x。 さらに、X: xが以前にY: yにパケットを送らないと、NATはY: 内部の終点Xに運命づけられたy: xからパケットを無視するでしょう。 言い換えれば、特定の外部の終点からパケットを受けるのに、内部の終点が最初に、その外部の終点のIPアドレスとポートにパケットを送るのが必要です。
Audet & Jennings Best Current Practice [Page 15] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[15ページ]RFC4787NAT UDPユニキャスト要件2007年1月
REQ-8: If application transparency is most important, it is
RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
behavior. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an "Address-Dependent
Filtering" behavior.
REQ-8: アプリケーション透明が最も重要であるなら、NATには「終点から独立しているフィルタリング」の振舞いがあるのは、RECOMMENDEDです。 より厳しいフィルタリングの振舞いが最も重要であるなら、NATには「アドレス依存するフィルタリング」の振舞いがあるのは、RECOMMENDEDです。
a) The filtering behavior MAY be an option configurable by the
administrator of the NAT.
a) フィルタリングの振舞いはNATの管理者が構成可能なオプションであるかもしれません。
Justification: The recommendation to use Endpoint-Independent
Filtering is aimed at maximizing application transparency; in
particular, for applications that receive media simultaneously
from multiple locations (e.g., gaming), or applications that use
rendezvous techniques. However, it is also possible that, in some
circumstances, it may be preferable to have a more stringent
filtering behavior. Filtering independently of the external
endpoint is not as secure: An unauthorized packet could get
through a specific port while the port was kept open if it was
lucky enough to find the port open. In theory, filtering based on
both IP address and port is more secure than filtering based only
on the IP address (because the external endpoint could, in
reality, be two endpoints behind another NAT, where one of the two
endpoints is an attacker). However, such a policy could interfere
with applications that expect to receive UDP packets on more than
one UDP port. Using Endpoint-Independent Filtering or Address-
Dependent Filtering instead of Address and Port-Dependent
Filtering on a NAT (say, NAT-A) also has benefits when the other
endpoint is behind a non-BEHAVE compliant NAT (say, NAT-B) that
does not support REQ-1. When the endpoints use ICE, if NAT-A uses
Address and Port-Dependent Filtering, connectivity will require a
UDP relay. However, if NAT-A uses Endpoint-Independent Filtering
or Address-Dependent Filtering, ICE will ultimately find
connectivity without requiring a UDP relay. Having the filtering
behavior being an option configurable by the administrator of the
NAT ensures that a NAT can be used in the widest variety of
deployment scenarios.
正当化: Endpointから独立しているFilteringを使用するという推薦はアプリケーション透明を最大にするのを目的とされます。 同時に複数の所在地(例えば、勝負事をする)からメディアを受け取るアプリケーション、またはランデブーのテクニックを使用するアプリケーションのために特定で。 しかしながら、また、より厳しいフィルタリングの振舞いを持っているのがいくつかの事情で望ましいのも、可能です。 外部の終点の如何にかかわらずフィルタリングは安全ではありません: それがポートが開いているのがわかるほど幸運であったならポートが開くように保たれていた間、権限のないパケットは特定のポートを通り抜けるかもしれません。 理論上、IPアドレスとポートの両方に基づくフィルタリングはフィルタリングがアドレス(外部の終点がほんとうは別のNATの後ろの2つの終点の1つが攻撃者である2つの終点であるかもしれないので)をIPだけに基礎づけたより安全です。 しかしながら、そのような方針は1つ以上のUDPポートの上でUDPパケットを受けると予想するアプリケーションを妨げるかもしれません。 NATでAddressの代わりにEndpointから独立しているFilteringかAddressの依存するFilteringとPort依存するFilteringを使用する、(たとえば、NAT a)には、REQ-1をサポートしない非BEHAVEの対応するNAT(たとえば、NAT B)の後ろにもう片方の終点があるとき、利益があります。 NAT AがAddressとPort依存するFilteringを使用するなら終点がICEを使用すると、接続性はUDPリレーを必要とするでしょう。 しかしながら、NAT AがEndpointから独立しているFilteringかAddress依存するFilteringを使用すると、UDPリレーを必要としないで、ICEは結局、接続性を見つけるでしょう。 NATの管理者でオプションであるフィルタリングの振舞いを構成可能にするのは、最も広いバラエティーの展開シナリオでNATを使用できるのを確実にします。
6. Hairpinning Behavior
6. 振舞いをHairpinningします。
If two hosts (called X1 and X2) are behind the same NAT and exchanging traffic, the NAT may allocate an address on the outside of the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it goes to the NAT, which must relay the traffic from X1 to X2. This is referred to as hairpinning and is illustrated below.
'2人のホスト(X1とX2と呼ばれます)が同じNATの後ろにいて、トラフィックを交換しているなら、NATはX2のためにNATの外部にアドレスを割り当てるかもしれなくて、呼ばれたX2は': x2'です。 ': x2'、'X1がトラフィックをX2に送るなら、それはNATに行きます。(それは、X1からX2までトラフィックをリレーしなければなりません)。 これは、hairpinningと呼ばれて、以下で例証されます。
Audet & Jennings Best Current Practice [Page 16] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[16ページ]RFC4787NAT UDPユニキャスト要件2007年1月
NAT
+----+ from X1:x1 to X2':x2' +-----+ X1':x1'
| X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
+----+ | v |
| v |
| v |
| v |
+----+ from X1':x1' to X2:x2 | v | X2':x2'
| X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
+----+ +-----+
NAT+----'X1: x1からX2までの+': x2'+-----'+X1': x1、'| X1| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- +----+ | v| | v| | v| | v| +----'X1からの+、X2: x2への': x1'| v| 'X2': x2、'| X2| <<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- +----+ +-----+
Hairpinning Behavior
振舞いをHairpinningします。
Hairpinning allows two endpoints on the internal side of the NAT to communicate even if they only use each other's external IP addresses and ports.
互いの外部のIPアドレスとポートを使用するだけであっても、HairpinningはNAT内部側の上の2つの終点を交信させます。
More formally, a NAT that supports hairpinning forwards packets originating from an internal address, X1:x1, destined for an external address X2':x2' that has an active mapping to an internal address X2:x2, back to that internal address, X2:x2. Note that typically X1' is the same as X2'.
'より正式に、hairpinningをサポートするNATは内部のアドレスからの起因することX1: (x1)がX2内部のアドレスにアクティブなマッピングを持っている': x2'X2: x2の、そして、それへの内部の外部アドレスのために運命づけたパケットにアドレスを転送します、X2: x2。 'X1が通常、'X2と同じであること'に注意してください。
Furthermore, the NAT may present the hairpinned packet with either an internal (X1:x1) or an external (X1':x1') source IP address and port. Therefore, the hairpinning NAT behavior can be either "External source IP address and port" or "Internal source IP address and port". "Internal source IP address and port" may cause problems by confusing implementations that expect an external IP address and port.
'その上、NATがインターナル(X1: x1)か外部のどちらかでhairpinnedパケットを提示するかもしれない、(X1、': x1'、)、ソースIPアドレスとポート。 したがって、hairpinning NATの振舞いは、「外部電源IPアドレスとポート」か「内部のソースIPアドレスとポート」のどちらかであることができます。 「内部のソースIPアドレスとポート」は、外部のIPアドレスとポートを予想する実装を混乱させることによって、問題を起こすかもしれません。
REQ-9: A NAT MUST support "Hairpinning".
REQ-9: NATは"Hairpinning"をサポートしなければなりません。
a) A NAT Hairpinning behavior MUST be "External source IP address
and port".
a) NAT Hairpinningの振舞いは「外部電源IPアドレスとポート」であるに違いありません。
Justification: This requirement is to allow communications between
two endpoints behind the same NAT when they are trying each
other's external IP addresses.
正当化: この要件は彼らが互いの外部のIPアドレスを試みているとき、同じNATの後ろに2つの終点のコミュニケーションを許容することです。
a) Using the external source IP address is necessary for
applications with a restrictive policy of not accepting packets
from IP addresses that differ from what is expected.
a) 外部電源IPアドレスを使用するのが予想されることと異なっているIPアドレスからパケットを受け入れない引締政策でアプリケーションに必要です。
7. Application Level Gateways
7. アプリケーションレベルゲートウェイ
Certain NATs have implemented Application Level Gateways (ALGs) for various protocols, including protocols for negotiating peer-to-peer sessions, such as SIP.
あるNATsはSIPなどのピアツーピアセッションを交渉するためのプロトコルを含む様々なプロトコルのために、Application Level Gateways(ALGs)を実装しました。
Audet & Jennings Best Current Practice [Page 17] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[17ページ]RFC4787NAT UDPユニキャスト要件2007年1月
Certain NATs have these ALGs turned on permanently, others have them turned on by default but allow them to be turned off, and others have them turned off by default but allow them be turned on.
あるNATsが永久に、これらのALGsをつけさせていて、他のものがデフォルトで彼らをつけさせていますが、彼らをオフにさせて、他のものは、デフォルトで彼らをオフにさせますが、彼らを許します。つけられています。
NAT ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and therefore must be used with extreme caution.
NAT ALGsをNAT意識するようになろうとするUNSAFメソッドかプロトコルを妨げるかもしれなくて、したがって、細心の注意を払って使用しなければなりません。
REQ-10: To eliminate interference with UNSAF NAT traversal
mechanisms and allow integrity protection of UDP communications,
NAT ALGs for UDP-based protocols SHOULD be turned off. Future
standards track specifications that define ALGs can update this to
recommend the defaults for the ALGs that they define.
REQ-10: UDPベースのプロトコルSHOULDのためにUNSAF NAT縦断メカニズムの干渉を排除して、UDPコミュニケーション、NAT ALGsの保全保護を許すには、オフにされてください。 ALGsを定義する将来の標準化過程仕様は、彼らが定義するALGsのためにデフォルトを推薦するためにこれをアップデートできます。
a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
the NAT administrator to enable or disable each ALG separately.
a) NATがALGsを含んでいるなら、NAT管理者が別々にNATで各ALGを有効にするか、または無効にするのが、RECOMMENDEDです。
Justification: NAT ALGs may interfere with UNSAF methods.
正当化: NAT ALGsはUNSAFメソッドを妨げるかもしれません。
a) This requirement allows the user to enable those ALGs that are
necessary to aid in the operation of some applications without
enabling ALGs, which interfere with the operation of other
applications.
a) この要件で、ユーザは、他のアプリケーションの操作を妨げるALGsを有効にしないでいくつかのアプリケーションの操作で支援するためにそれらの必要なALGsを有効にすることができます。
8. Deterministic Properties
8. 決定論的な特性
The classification of NATs is further complicated by the fact that, under some conditions, the same NAT will exhibit different behaviors. This has been seen on NATs that preserve ports or have specific algorithms for selecting a port other than a free one. If the external port that the NAT wishes to use is already in use by another session, the NAT must select a different port. This results in different code paths for this conflict case, which results in different behavior.
同じNATがいくつかの条件のもとで異なった振舞いを示すという事実によってNATsの分類はさらに複雑にされます。 自由なもの以外のポートを選択するためにポートを保持するか、または特定のアルゴリズムを持っているNATsでこれを見てあります。 NATが使用したがっている外部のポートが別のセッションで既に使用中であるなら、NATは異なったポートを選択しなければなりません。 これはこの闘争ケースのための異なったコード経路をもたらします。(ケースは異なった振舞いをもたらします)。
For example, if three hosts X1, X2, and X3 all send from the same port x, through a port preserving NAT with only one external IP address, called X1', the first one to send (i.e., X1) will get an external port of x, but the next two will get x2' and x3' (where these are not equal to x). There are NATs where the External NAT mapping characteristics and the External Filter characteristics change between the X1:x and the X2:x mapping. To make matters worse, there are NATs where the behavior may be the same on the X1:x and X2:x mappings, but different on the third X3:x mapping.
'例えば、X1、X2、およびX3が同じポートxから追い出す3人のホストが皆、1つの外部のIPアドレスだけでNATを保存するポートを通してX1と呼んだ'なら、発信する最初のもの(すなわち、X1)はxの外部のポートを手に入れるでしょうが、次の2はx2と'x3'(これらがxと等しくないところ)を手に入れるでしょう。 NATsが特性を写像するExternal NATとExternal Filterの特性がX1: xとX2の間で変化するところにあります: xマッピング。 いっそう困ったことに、NATsが振舞いがX1: xとX2: xマッピングで同じですが、第3X3で異なるかもしれないところにあります: xマッピング。
Another example is that some NATs have an "Endpoint-Independent Mapping", combined with "Port Overloading", as long as two endpoints are not establishing sessions to the same external direction, but then switch their behavior to "Address and Port-Dependent Mapping"
別の例は2つの終点が同じ外部の方向にセッションを確立していない限り、いくつかのNATsには「ポート積みすぎ」に結合された「終点から独立しているマッピング」があるということですが、「アドレスとポート依存するマッピング」に彼らの振舞いを切り換えてください。
Audet & Jennings Best Current Practice [Page 18] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[18ページ]RFC4787NAT UDPユニキャスト要件2007年1月
without "Port Preservation" upon detection of these conflicting sessions establishments.
これらの闘争しているセッション施設の検出の「ポート保存」なしで。
Any NAT that changes the NAT Mapping or the Filtering behavior without configuration changes, at any point in time, under any particular conditions, is referred to as a "non-deterministic" NAT. NATs that don't are called "deterministic".
時間内に任意な点でどんな特定の条件のもとでも構成変更なしでNAT MappingかFilteringの振舞いを変えるどんなNATも「非決定論」NATと呼ばれます。 そうしないNATsは「決定論的である」と呼ばれます。
Non-deterministic NATs generally change behavior when a conflict of some sort happens, i.e., when the port that would normally be used is already in use by another mapping. The NAT mapping and External Filtering in the absence of conflict is referred to as the Primary behavior. The behavior after the first conflict is referred to as Secondary and after the second conflict is referred to as Tertiary. No NATs have been observed that change on further conflicts, but it is certainly possible that they exist.
ある種の闘争が起こると、一般に、非決定論的なNATsは振舞いを変えます、すなわち、通常、使用されるポートが別のマッピングで既に使用中であるときに。 闘争が不在のときNATのマッピングとExternal FilteringはPrimaryの振舞いと呼ばれます。 最初の闘争がSecondaryと呼ばれた後と2番目の闘争の後の振舞いはTertiaryと呼ばれます。 一層の闘争のときに変化するNATsが全く観測されていませんが、確かに、存在するのは可能です。
REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
change the NAT translation (Section 4) or the Filtering
(Section 5) Behavior at any point in time, or under any particular
conditions.
REQ-11: NATには、決定論的な振舞いがなければなりません、すなわち、それは時間内にの任意な点においてどんな特定の条件のもとでもNAT翻訳(セクション4)かFiltering(セクション5)の振舞いを変えてはいけません。
Justification: Non-deterministic NATs are very difficult to
troubleshoot because they require more intensive testing. This
non-deterministic behavior is the root cause of much of the
uncertainty that NATs introduce about whether or not applications
will work.
正当化: 非決定論的なNATsは彼らが、より徹底的なテストを必要とするので障害調査するのは非常に難しいです。 この非決定論的な振舞いはNATsがアプリケーションが働くかどうかを導入する不確実性の多くの根本的原因です。
9. ICMP Destination Unreachable Behavior
9. ICMPの目的地の手の届かない振舞い
When a NAT sends a packet toward a host on the other side of the NAT, an ICMP message may be sent in response to that packet. That ICMP message may be sent by the destination host or by any router along the network path. The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. Such ICMP messages SHOULD be rewritten by the NAT (specifically, the IP headers and the ICMP payload) and forwarded to the appropriate internal or external host. The NAT needs to perform this function for as long as the UDP mapping is active. Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. A NAT that performs the functions described in the paragraph above is referred to as "support ICMP Processing".
NATがNATの反対側でホストに向かってパケットを送るとき、そのパケットに対応してICMPメッセージを送るかもしれません。 あて先ホストかネットワーク経路に沿ったどんなルータもそのICMPメッセージを送るかもしれません。 NATのデフォルト設定SHOULD NOTはそれらのソースIPアドレスに基づくICMPメッセージをフィルターにかけます。 NAT(明確にIPヘッダーとICMPペイロード)によって書き直されて、適切な内部の、または、外部のホストに送られたそのようなICMPメッセージSHOULD。 NATは、UDPマッピングがアクティブである限り、この機能を実行する必要があります。 どんな種類に関するICMPメッセージの領収書もNATマッピングを無効にしてはいけません。 上のパラグラフで説明された機能を実行するNATは「サポートICMP Processing」と呼ばれます。
There is no significant security advantage to blocking ICMP Destination Unreachable packets. Additionally, blocking ICMP Destination Unreachable packets can interfere with application failover, UDP Path MTU Discovery (see [RFC1191] and [RFC1435]), and traceroute. Blocking any ICMP message is discouraged, and blocking ICMP Destination Unreachable is strongly discouraged.
ICMP Destination Unreachableパケットを妨げることへのどんな重要なセキュリティ上の利点もありません。 さらに、ICMP Destination Unreachableパケットを妨げると、アプリケーションフェイルオーバー、UDP Path MTUディスカバリー([RFC1191]と[RFC1435]を見る)、およびトレースルートを妨げることができます。 どんなICMPメッセージも妨げるのはお勧めできないです、そして、ICMP Destination Unreachableを妨げるのは強くお勧めできないです。
Audet & Jennings Best Current Practice [Page 19] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[19ページ]RFC4787NAT UDPユニキャスト要件2007年1月
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping.
REQ-12: どんな種類に関するICMPメッセージの領収書もNATマッピングを終えてはいけません。
a) The NAT's default configuration SHOULD NOT filter ICMP messages
based on their source IP address.
a) NATのデフォルト設定SHOULD NOTはそれらのソースIPアドレスに基づくICMPメッセージをフィルターにかけます。
b) It is RECOMMENDED that a NAT support ICMP Destination
Unreachable messages.
b) NATがICMP Destination Unreachableにメッセージをサポートするのは、RECOMMENDEDです。
Justification: This is easy to do and is used for many things
including MTU discovery and rapid detection of error conditions,
and has no negative consequences.
正当化: これは、するのが簡単であり、MTU発見と急速なエラーの発見状態を含む多くのものに使用されて、どんな否定的結果も持っていません。
10. Fragmentation of Outgoing Packets
10. 出発しているパケットの断片化
When the MTU of the adjacent link is too small, fragmentation of packets going from the internal side to the external side of the NAT may occur. This can occur if the NAT is doing Point-to-Point over Ethernet (PPPoE), or if the NAT has been configured with a small MTU to reduce serialization delay when sending large packets and small higher-priority packets, or for other reasons.
隣接しているリンクのMTUが小さ過ぎるときに、内部側から外部のNATの端まで行くパケットの断片化は起こるかもしれません。 NATがイーサネット(PPPoE)かそれとも大きいパケットを送るとき連載遅れを減少させる小さいMTUと小さいより高い優先度パケット、または他の理由で構成されたかどうかの上にPointからポイントをしているなら、これは起こることができます。
It is worth noting that many IP stacks do not use Path MTU Discovery with UDP packets.
多くのIPスタックがUDPパケットがあるPath MTUディスカバリーを使用しないことに注意する価値があります。
The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 (DF=0).
パケットには、1に設定されたFragmentビット(DF=1)か0(DF=0)ではなくそのドンがいるかもしれません。
REQ-13: If the packet received on an internal IP address has DF=1,
the NAT MUST send back an ICMP message "Fragmentation needed and
DF set" to the host, as described in [RFC0792].
REQ-13: 内部のIPアドレスに受け取られたパケットがDF=1を持っているなら、NATは「必要である断片化とDFセット」というICMPメッセージをホストに返送しなければなりません、[RFC0792]で説明されるように。
a) If the packet has DF=0, the NAT MUST fragment the packet and
SHOULD send the fragments in order.
a) パケットにDF=0があるなら、NATはパケットを断片化しなければなりません、そして、SHOULDは整然とした状態で断片を送ります。
Justification: This is as per RFC 792.
正当化: これはRFC792に従ってあります。
a) This is the same function a router performs in a similar
situation [RFC1812].
a) これはルータが同様の状況[RFC1812]で実行する同じ機能です。
11. Receiving Fragmented Packets
11. 受信はパケットを断片化しました。
For a variety of reasons, a NAT may receive a fragmented packet. The IP packet containing the header could arrive in any fragment, depending on network conditions, packet ordering, and the implementation of the IP stack that generated the fragments.
さまざまな理由で、NATは断片化しているパケットを受けるかもしれません。 ヘッダーを含むIPパケットはどんな断片にも到着できました、断片を生成したIPスタックのネットワーク状態、パケット注文、および実装によって。
Audet & Jennings Best Current Practice [Page 20] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[20ページ]RFC4787NAT UDPユニキャスト要件2007年1月
A NAT that is capable only of receiving fragments in order (that is, with the header in the first packet) and forwarding each of the fragments to the internal host is described as "Received Fragments Ordered".
単にオーダー(すなわち、ヘッダーが最初のパケットにある)で断片を受けて、それぞれの断片を内部のホストに送ることができるNATは、「容認された断片は注文した」として記述されています。
A NAT that is capable of receiving fragments in or out of order and forwarding the individual fragments (or a reassembled packet) to the internal host is referred to as "Receive Fragments Out of Order". See the Security Considerations section of this document for a discussion of this behavior.
受信できるNATはコネか故障していた状態で断片化します、そして、個々の断片(または、組み立て直されたパケット)を内部のホストに送るのは「故障していた状態で断片を受けてください」と呼ばれます。 この振舞いの議論に関してこのドキュメントのSecurity Considerations部を見てください。
A NAT that is neither of these is referred to as "Receive Fragments None".
これらのどちらもでないNATは「なにもに断片を受けてください」と呼ばれます。
REQ-14: A NAT MUST support receiving in-order and out-of-order
fragments, so it MUST have "Received Fragment Out of Order"
behavior.
REQ-14: NATが、受信が注文していて不適切な断片であるとサポートしなければならないので、それには、「受け取って、故障していた状態で断片化してください」という振舞いがなければなりません。
a) A NAT's out-of-order fragment processing mechanism MUST be
designed so that fragmentation-based DoS attacks do not
compromise the NAT's ability to process in-order and
unfragmented IP packets.
a) NATの不適切な断片処理メカニズムは、断片化ベースのDoS攻撃が整然とした状態で処理するNATの能力に感染しないように設計しなければならなくて、IPパケットを非断片化しました。
Justification: See Security Considerations.
正当化: セキュリティ問題を見てください。
12. Requirements
12. 要件
The requirements in this section are aimed at minimizing the complications caused by NATs to applications, such as realtime communications and online gaming. The requirements listed earlier in the document are consolidated here into a single section.
このセクションの要件はNATsによってアプリケーションに引き起こされた複雑さを最小にするのを目的とされます、リアルタイムでコミュニケーションやオンラインゲームのように。 より早くドキュメントにリストアップされた要件はここで1つのセクションに統合されます。
It should be understood, however, that applications normally do not know in advance if the NAT conforms to the recommendations defined in this section. Peer-to-peer media applications still need to use normal procedures, such as ICE [ICE].
しかしながら、通常、アプリケーションが、あらかじめNATがこのセクションで定義された推薦に従うかどうかを知らないのが理解されるべきです。 ピアツーピアメディアアプリケーションは、まだICEなどの正常な手順[ICE]を用いる必要があります。
A NAT that supports all the mandatory requirements of this specification (i.e., the "MUST"), is "compliant with this specification". A NAT that supports all the requirements of this specification (i.e., including the "RECOMMENDED") is "fully compliant with all the mandatory and recommended requirements of this specification".
この仕様のすべての義務的な要件が(すなわち、“MUST")であるとサポートするNATは「この仕様で、言いなりになっています」。 この仕様(すなわち、「お勧め」を含んでいる)のすべての要件をサポートするNATは「この仕様のすべての義務的でお勧めの要件で完全に言いなりになっています」。
Audet & Jennings Best Current Practice [Page 21] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[21ページ]RFC4787NAT UDPユニキャスト要件2007年1月
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
REQ-1: NATには、「終点から独立しているマッピング」の振舞いがなければなりません。
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling"
behavior of "Paired". Note that this requirement is not
applicable to NATs that do not support IP address pooling.
REQ-2: NATには「対にされること」の「IPアドレスプーリング」の振舞いがあるのは、RECOMMENDEDです。 この要件がIPアドレスがプーリングであるとサポートしないNATsに適切でないことに注意してください。
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading".
REQ-3: NATには、「ポート積みすぎ」の「ポート課題」の振舞いがあってはいけません。
a) If the host's source port was in the range 0-1023, it is
RECOMMENDED the NAT's source port be in the same range. If the
host's source port was in the range 1024-65535, it is
RECOMMENDED that the NAT's source port be in that range.
a) ホストのソースポートが範囲0-1023にあったなら、それはRECOMMENDEDです。同じ範囲でNATのソースポートはそうです。 ホストのソースポートが範囲1024-65535にあったなら、NATのソースポートがその範囲にあるのは、RECOMMENDEDです。
REQ-4: It is RECOMMENDED that a NAT have a "Port parity
preservation" behavior of "Yes".
REQ-4: NATには「はい」の「ポートパリティ保存」の振舞いがあるのは、RECOMMENDEDです。
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two
minutes, unless REQ-5a applies.
REQ-5: REQ-5aが適用しない場合、NAT UDPマッピングタイマは2分未満後に期限が切れてはいけません。
a) For specific destination ports in the well-known port range
(ports 0-1023), a NAT MAY have shorter UDP mapping timers that
are specific to the IANA-registered application running over
that specific destination port.
a) ウェルノウンポート範囲(ポート0-1023)の特定の仕向港に関しては、NATで、より短いUDPはその特定の仕向港中を走らせるIANAによって登録されたアプリケーションに特定のタイマを写像するかもしれません。
b) The value of the NAT UDP mapping timer MAY be configurable.
b) NAT UDPマッピングタイマの値は構成可能であるかもしれません。
c) A default value of five minutes or more for the NAT UDP mapping
timer is RECOMMENDED.
c) NAT UDPマッピングタイマのための5分以上のデフォルト値はRECOMMENDEDです。
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound
refresh behavior" of "True".
REQ-6: 「NAT Outboundは振舞いをリフレッシュします」。Refresh Directionを写像するNATがaを持たなければならない、「本当」について。
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
refresh behavior" of "True".
a) 「NAT Inboundは振舞いをリフレッシュします」。Refresh Directionを写像するNATがaを持っているかもしれない、「本当」について。
REQ-7 A NAT device whose external IP interface can be configured
dynamically MUST either (1) Automatically ensure that its internal
network uses IP addresses that do not conflict with its external
network, or (2) Be able to translate and forward traffic between
all internal nodes and all external nodes whose IP addresses
numerically conflict with the internal network.
ダイナミックに外部のIPインタフェースを構成できるREQ-7A NATデバイスはIPアドレスが数の上で内部のネットワークと衝突するすべての内部のノードとすべての外部ノードの間の(1)が翻訳するために内部のネットワーク用途外部のネットワークと衝突しないIPアドレス、または(2)ができるのを自動的に確実にするどちらか、前進のトラフィックがそうしなければなりません。
REQ-8: If application transparency is most important, it is
RECOMMENDED that a NAT have "Endpoint-Independent Filtering"
behavior. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have "Address-Dependent
Filtering" behavior.
REQ-8: アプリケーション透明が最も重要であるなら、NATには「終点から独立しているフィルタリング」の振舞いがあるのは、RECOMMENDEDです。 より厳しいフィルタリングの振舞いが最も重要であるなら、NATには「アドレス依存するフィルタリング」の振舞いがあるのは、RECOMMENDEDです。
Audet & Jennings Best Current Practice [Page 22] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[22ページ]RFC4787NAT UDPユニキャスト要件2007年1月
a) The filtering behavior MAY be an option configurable by the
administrator of the NAT.
a) フィルタリングの振舞いはNATの管理者が構成可能なオプションであるかもしれません。
REQ-9: A NAT MUST support "Hairpinning".
REQ-9: NATは"Hairpinning"をサポートしなければなりません。
a) A NAT Hairpinning behavior MUST be "External source IP address
and port".
a) NAT Hairpinningの振舞いは「外部電源IPアドレスとポート」であるに違いありません。
REQ-10: To eliminate interference with UNSAF NAT traversal
mechanisms and allow integrity protection of UDP communications,
NAT ALGs for UDP-based protocols SHOULD be turned off. Future
standards track specifications that define an ALG can update this
to recommend the ALGs on which they define default.
REQ-10: UDPベースのプロトコルSHOULDのためにUNSAF NAT縦断メカニズムの干渉を排除して、UDPコミュニケーション、NAT ALGsの保全保護を許すには、オフにされてください。 ALGを定義する将来の標準化過程仕様は、彼らがデフォルトを定義するALGsを推薦するためにこれをアップデートできます。
a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
the NAT administrator to enable or disable each ALG separately.
a) NATがALGsを含んでいるなら、NAT管理者が別々にNATで各ALGを有効にするか、または無効にするのが、RECOMMENDEDです。
REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
change the NAT translation (Section 4) or the Filtering
(Section 5) Behavior at any point in time, or under any particular
conditions.
REQ-11: NATには、決定論的な振舞いがなければなりません、すなわち、それは時間内にの任意な点においてどんな特定の条件のもとでもNAT翻訳(セクション4)かFiltering(セクション5)の振舞いを変えてはいけません。
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping.
REQ-12: どんな種類に関するICMPメッセージの領収書もNATマッピングを終えてはいけません。
a) The NAT's default configuration SHOULD NOT filter ICMP messages
based on their source IP address.
a) NATのデフォルト設定SHOULD NOTはそれらのソースIPアドレスに基づくICMPメッセージをフィルターにかけます。
b) It is RECOMMENDED that a NAT support ICMP Destination
Unreachable messages.
b) NATがICMP Destination Unreachableにメッセージをサポートするのは、RECOMMENDEDです。
REQ-13 If the packet received on an internal IP address has DF=1,
the NAT MUST send back an ICMP message "Fragmentation needed and
DF set" to the host, as described in [RFC0792].
内部のIPで受け取られていているパケットが扱うREQ-13 IfはDF=1を持って、NATは「必要である断片化とDFセット」というICMPメッセージをホストに返送しなければなりません、[RFC0792]で説明されるように。
a) If the packet has DF=0, the NAT MUST fragment the packet and
SHOULD send the fragments in order.
a) パケットにDF=0があるなら、NATはパケットを断片化しなければなりません、そして、SHOULDは整然とした状態で断片を送ります。
REQ-14: A NAT MUST support receiving in-order and out-of-order
fragments, so it MUST have "Received Fragment Out of Order"
behavior.
REQ-14: NATが、受信が注文していて不適切な断片であるとサポートしなければならないので、それには、「受け取って、故障していた状態で断片化してください」という振舞いがなければなりません。
a) A NAT's out-of-order fragment processing mechanism MUST be
designed so that fragmentation-based DoS attacks do not
compromise the NAT's ability to process in-order and
unfragmented IP packets.
a) NATの不適切な断片処理メカニズムは、断片化ベースのDoS攻撃が整然とした状態で処理するNATの能力に感染しないように設計しなければならなくて、IPパケットを非断片化しました。
Audet & Jennings Best Current Practice [Page 23] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[23ページ]RFC4787NAT UDPユニキャスト要件2007年1月
13. Security Considerations
13. セキュリティ問題
NATs are often deployed to achieve security goals. Most of the recommendations and requirements in this document do not affect the security properties of these devices, but a few of them do have security implications and are discussed in this section.
NATsは、セキュリティ目標を達成するためにしばしば配布されます。 推薦と要件の大部分が本書ではこれらのデバイスのセキュリティの特性に影響しませんが、それらのいくつかについて、セキュリティ意味を持って、このセクションで議論します。
This document recommends that the timers for mapping be refreshed on outgoing packets (see REQ-6) and does not make recommendations about whether or not inbound packets should update the timers. If inbound packets update the timers, an external attacker can keep the mapping alive forever and attack future devices that may end up with the same internal address. A device that was also the DHCP server for the private address space could mitigate this by cleaning any mappings when a DHCP lease expired. For unicast UDP traffic (the scope of this document), it may not seem relevant to support inbound timer refresh; however, for multicast UDP, the question is harder. It is expected that future documents discussing NAT behavior with multicast traffic will refine the requirements around handling of the inbound refresh timer. Some devices today do update the timers on inbound packets.
このドキュメントは、マッピングのためのタイマが出発しているパケット(REQ-6を見る)の上でリフレッシュされることを勧めて、本国行きのパケットがタイマをアップデートするはずであるかどうかを推薦状をしません。 本国行きのパケットがタイマをアップデートするなら、外部の攻撃者は、いつまでも、マッピングを生かして、同じ内部のアドレスで終わるかもしれない未来の装置を攻撃できます。 またプライベート・アドレススペースへのDHCPサーバであったデバイスは、DHCPリースが期限が切れたときどんなマッピングも掃除することによって、これを緩和するかもしれません。 ユニキャストUDPトラフィック(このドキュメントの範囲)に関しては、本国行きのタイマがリフレッシュするサポートに関連しているように見えないかもしれません。 しかしながら、マルチキャストUDPにおいて、質問は、より困難です。 マルチキャストトラフィックとNATの振舞いについて議論すると要件が扱いながら洗練される本国行きの将来のドキュメントがタイマをリフレッシュすると予想されます。 今日のいくつかのデバイスが本国行きのパケットでタイマをアップデートします。
This document recommends that the NAT filters be specific to the external IP address only (see REQ-8) and not to the external IP address and UDP port. It can be argued that this is less secure than using the IP and port. Devices that wish to filter on IP and port do still comply with these requirements.
このドキュメントは、NATフィルタが外部のIPアドレスとUDPポートではなく、外部のIPアドレスだけに特定であることを推薦します。 これがIPとポートを使用するほど安全でないと主張できます。 IPのフィルタとポートに願われているデバイスはまだこれらの要件に従っています。
Non-deterministic NATs are risky from a security point of view. They are very difficult to test because they are, well, non-deterministic. Testing by a person configuring one may result in the person thinking it is behaving as desired, yet under different conditions, which an attacker can create, the NAT may behave differently. These requirements recommend that devices be deterministic.
非決定論的なNATsはセキュリティ観点から危険です。 それらはそれらがよく非決定論的であるのでテストするのは非常に難しいです。 1つを構成する人でテストするのはそれが望まれているように反応していると考える人をもたらすかもしれません、しかし、異なった条件のもとで、NATは異なって振る舞うかもしれません。(攻撃者は条件を引き起こすことができます)。 これらの要件は、デバイスが決定論的であることを推薦します。
This document requires that NATs have an "external NAT mapping is endpoint independent" behavior. This does not reduce the security of devices. Which packets are allowed to flow across the device is determined by the external filtering behavior, which is independent of the mapping behavior.
このドキュメントは、NATsには「外部のNATマッピングは終点独立者です」という振舞いがあるのを必要とします。 これはデバイスのセキュリティを下げません。 どのパケットがデバイスの向こう側に流れることができるかは外部のフィルタリングの振舞いで決定します。(それは、マッピングの振舞いから独立しています)。
When a fragmented packet is received from the external side, and the packets are out of order so that the initial fragment does not arrive first, many systems simply discard the out-of-order packets. Moreover, since some networks deliver small packets ahead of large ones, there can be many out-of-order fragments. NATs that are capable of delivering these out-of-order packets are possible, but they need to store the out-of-order fragments, which can open up a
外部側から断片化しているパケットを受け取って、パケットが故障しているので初期の断片が先着しないで、多くのシステムが単に故障しているパケットを捨てるとき。 そのうえ、いくつかのネットワークが大きいものの前に小型小包を提供するので、多くの不適切な断片があることができます。 これらの故障しているパケットを提供できるNATsは可能ですが、それらは、不適切な断片を保存する必要があります。(断片はaを開けることができます)。
Audet & Jennings Best Current Practice [Page 24] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[24ページ]RFC4787NAT UDPユニキャスト要件2007年1月
Denial-of-Service (DoS) opportunity, if done incorrectly. Fragmentation has been a tool used in many attacks, some involving passing fragmented packets through NATs, and others involving DoS attacks based on the state needed to reassemble the fragments. NAT implementers should be aware of [RFC3128] and [RFC1858].
サービス妨害(DoS)の機会不当にするなら。 断片化は多くの攻撃に使用されるツールです、そして、いくつかの意味ありげな通過がNATsを通してパケットを断片化しました、そして、状態に基づくDoS攻撃にかかわる他のものは断片を組み立て直す必要がありました。 NAT implementersは[RFC3128]と[RFC1858]を意識しているべきです。
14. IAB Considerations
14. IAB問題
The IAB has studied the problem of "Unilateral Self Address Fixing", which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424].
IABはクライアントが協力的なプロトコル反射メカニズム[RFC3424]を通した別の分野のNATの反対側に関するアドレスを決定するのを試みる一般的なプロセスである「一方的な自己アドレス修理」の問題を研究しました。
This specification does not, in itself, constitute an UNSAF application. It consists of a series of requirements for NATs aimed at minimizing the negative impact that those devices have on peer-to- peer media applications, especially when those applications are using UNSAF methods.
この仕様は本来UNSAFアプリケーションを構成しません。 それらのデバイスが同輩から同輩へのメディアにアプリケーションを持っているのは負の衝撃を最小にするのが目的とされたNATsのための一連の要件から成ります、特にそれらのアプリケーションがUNSAFメソッドを使用しているとき。
Section 3 of UNSAF lists several practical issues with solutions to NAT problems. This document makes recommendations to reduce the uncertainty and problems introduced by these practical issues with NATs. In addition, UNSAF lists five architectural considerations. Although this is not an UNSAF proposal, it is interesting to consider the impact of this work on these architectural considerations.
UNSAFのセクション3はソリューションのいくつかの実用的な問題をNAT問題に記載します。このドキュメントはこれらによって紹介された不確実性と問題を減少させるという推薦状をNATsの実用的な問題にします。 さらに、UNSAFは5つの建築問題を記載します。 これはUNSAF提案ではありませんが、これらの建築問題に対するこの仕事の影響を考えるのはおもしろいです。
Arch-1: The scope of this is limited to UDP packets in NATs like the
ones widely deployed today. The "fix" helps constrain the
variability of NATs for true UNSAF solutions such as STUN.
Arch-1: ものが今日広く展開したようにこの範囲はNATsのUDPパケットに制限されます。 「フィックス」は、STUNなどの本当のUNSAFソリューションのためにNATsの可変性を抑制するのを助けます。
Arch-2: This will exit at the same rate that NATs exit. It does not
imply any protocol machinery that would continue to live
after NATs were gone, or make it more difficult to remove
them.
Arch-2: これは同じレートでそのNATs出口を出るでしょう。 それはNATsがなくなった後に生き続けているか、または彼らを取り除くのをより難しくする少しのプロトコル機械も含意しません。
Arch-3: This does not reduce the overall brittleness of NATs, but
will hopefully reduce some of the more outrageous NAT
behaviors and make it easer to discuss and predict NAT
behavior in given situations.
Arch-3: これはNATsの総合的なもろさを減少させません、希望をいだいていくつかの、より激しいNATの振舞いを変えて、与えられた状況におけるNATの振舞いについて議論して、予測するためにそれをeaserにするのを除いて。
Arch-4: This work and the results [RESULTS] of various NATs
represent the most comprehensive work at IETF on what the
real issues are with NATs for applications like VoIP. This
work and STUN have pointed out, more than anything else, the
brittleness NATs introduce and the difficulty of addressing
these issues.
Arch-4: 様々なNATsのこの仕事と結果[RESULTS]はVoIPのようなアプリケーションのためにIETFに実際の問題がNATsがある何であるかに関して最も包括的な仕事を表します。 この仕事とSTUNはNATsが導入するもろさとこれらの問題を扱うという困難を他の何よりも指摘しました。
Audet & Jennings Best Current Practice [Page 25] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[25ページ]RFC4787NAT UDPユニキャスト要件2007年1月
Arch-5: This work and the test results [RESULTS] provide a reference
model for what any UNSAF proposal might encounter in
deployed NATs.
Arch-5: この仕事と試験の成績[RESULTS]はどんなUNSAF提案も配布しているNATsで遭遇するかもしれないことに規範モデルを提供します。
15. Acknowledgments
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.
エディタはピアツーピアコミュニケーションにおける彼らの複数の貢献のためにNATの向こう側にブライアン・フォード、Pyda Srisuresh、およびダン・ケーゲルを承認したがっています。 ダンWingはIP断片化とICMPの振舞いに関するかなりのテキストを寄付しました。 彼らの貢献をRohanマーイ、ジョナサン・ローゼンバーグ、メアリ・バーンズ、メリンダShore、Lyndsayキャンベル、ジェフ・ヒューストン、ジリKuthan、ハラルドWelte、スティーブCasner、ロバートSanders、スペンサー・ダウキンズ、Saikatグーハ、クリスチャンのHuitema、ユタカ竹田、ポール・ホフマン、リサDusseault、ペッカSavola、ピーター・コッホ、ヤリArkko、およびアルフレッドHoenesをありがとうございます。
16. References
16. 参照
16.1. Normative References
16.1. 引用規格
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
16.2. Informative References
16.2. 有益な参照
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1435] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、1993年3月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
1995年10月の[RFC1858]ZiembaとG.とリード、D.とP.Traina、「IP断片フィルタリングのためのセキュリティ問題」RFC1858。
Audet & Jennings Best Current Practice [Page 26] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[26ページ]RFC4787NAT UDPユニキャスト要件2007年1月
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]RekhterとY.とマスコウィッツとR.とKarrenbergとD.とグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月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.
[RFC2623] アイスラーとM.と「NFSバージョン2とバージョン3安全保障問題とRPCSEC_GSSとケルベロスV5"、RFC2623のNFSプロトコルの使用、1999年6月。」
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2663] SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.
[RFC3027] HoldregeとM.とP.Srisuresh、「IPネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、2001年1月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]ミラー、I.、「小さい断片攻撃の異形に対する保護、(RFC1858)、」、RFC3128、6月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.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3424] DaigleとL.とIAB、「一方的な自己アドレスのためのネットワークアドレス変換の向こう側に(UNSAF)を修理するIAB問題」、RFC3424、2002年11月。
[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.
[RFC3489] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP)
attribute in Session Description Protocol (SDP)",
RFC 3605, October 2003.
[RFC3605]Huitema、C.、「(RTCP)がSession記述プロトコル(SDP)で結果と考える本当のTime Controlプロトコル」、RFC3605、2003年10月。
Audet & Jennings Best Current Practice [Page 27] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[27ページ]RFC4787NAT UDPユニキャスト要件2007年1月
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4380]Huitema、C.、「船食虫:」 「ネットワークアドレス変換(NATs)でUDPの上でIPv6にトンネルを堀る」RFC4380、2006年2月。
[RFC3489bis] Rosenberg, J., "Simple Traversal Underneath Network
Address Translators (NAT) (STUN)", Work in Progress,
October 2006.
「純真な縦断下部のネットワークアドレス変換機構(NAT)(気絶させます)」という[RFC3489bis]ローゼンバーグ、J.は進歩、2006年10月に働いています。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator
(NAT) Traversal for Offer/Answer Protocols", Work
in Progress, October 2006.
ローゼンバーグ、[氷]J.、「対話的な接続性設立(氷):」 「申し出/答えプロトコルのためのネットワークアドレス変換機構(NAT)縦断のための方法論」、処理中の作業、2006年10月。
[RESULTS] Jennings, C., "NAT Classification Test Results", Work
in Progress, October 2006.
「NAT分類試験の成績」という[結果]ジョニングス、C.は進歩、2006年10月に働いています。
[TURN] Rosenberg, J., "Obtaining Relay Addresses from Simple
Traversal Underneath NAT (STUN)", Work in Progress,
October 2006.
[ターンします] 「簡単な縦断下部のNAT(気絶させる)からリレーアドレスを得」て、ローゼンバーグ、J.は進歩、2006年10月に働いています。
[ITU.H323] "Packet-based Multimedia Communications Systems", ITU-
T Recommendation H.323, July 2003.
[ITU.H323]「パケットベースのマルチメディア通信システム」、ITU T推薦H.323、2003年7月。
Authors' Addresses
作者のアドレス
Francois Audet (editor) Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US
フランソアAudet(エディタ)ノーテルは米国でParkwayサンタクララ、4655Great Americaカリフォルニア 95054をネットワークでつなぎます。
Phone: +1 408 495 2456 EMail: audet@nortel.com
以下に電話をしてください。 +1 2456年の408 495メール: audet@nortel.com
Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 US
カレンジョニングスシスコシステムズ170の西タスマンDrive MS: SJC-21/2カリフォルニア95134サンノゼ(米国)
Phone: +1 408 902 3341 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 3341年の408 902メール: fluffy@cisco.com
Audet & Jennings Best Current Practice [Page 28] RFC 4787 NAT UDP Unicast Requirements January 2007
Audetとジョニングス最も良い現在の習慣[28ページ]RFC4787NAT UDPユニキャスト要件2007年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Audet & Jennings Best Current Practice [Page 29]
AudetとジョニングスBest現在の習慣[29ページ]
一覧
スポンサーリンク
