Network Working Group D. Senie
Request for Comments: 3235 Amaranth Networks Inc.
Category: Informational January 2002
Network Address Translator (NAT)-Friendly
Application Design Guidelines
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation).
この文書では、アプリケーション設計者は、新しいプロトコルを設計する際に考慮することを望むかもしれないそれらの事を説明します。多くの一般的なインターネットアプリケーションは、ネットワークアドレス変換の存在下できれいに動作しますが、これらのデバイスを横断するとき、他の人が様々な問題に苦しんでいます。ガイドラインは、可能な限り、NAT（ネットワークアドレス変換）との互換性があります新しいプロトコルやアプリケーションを確保するために、本明細書に提示されています。
Other documents that describe Network Address Translation (NAT) discuss the Terminology and Considerations [RFC2663] and Protocol Issues [RFC3022], [RFC3027] or discuss the implications of NAT [RFC2993]. All of those relate to various issues with the NAT mechanism, effects on protocols and effects upon general Internet architecture.
ネットワークアドレス変換（NAT）を記述する他の文書には、用語と考慮事項[RFC2663]とプロトコルの問題[RFC3022]、[RFC3027]を議論したりNAT [RFC2993]の影響を議論します。それらのすべてがNATメカニズムで様々な問題に関連して、プロトコル、および一般的なインターネットアーキテクチャに対する効果への影響。
It is the focus of this document to provide recommendations to authors of new protocols about the effects to consider when designing new protocols such that special handling is not required at NAT gateway points.
特別な処理がNATゲートウェイポイントで必要とされないような新しいプロトコルを設計する際に考慮すべき影響についての新しいプロトコルの作成者に勧告を提供するために、このドキュメントの焦点です。
When a protocol is unable to pass cleanly through a NAT, the use of an Application Level Gateway (ALG) may still permit operation of the protocol. Depending on the encoding used in a protocol, an ALG may be difficult or easy to construct, though in some cases it may not be possible at all. While adjunct to NAT, the formulation of protocols that cannot directly operate through NAT should be considered such that the ALG design may be simple and automated. ALGs typically operate inside small routers along with the NAT component. Ideally, the ALG should be simple and not require excessive computation or state storage.
プロトコルは、NATを介してきれいに通過することができない場合、アプリケーションレベルゲートウェイ（ALG）の使用は、依然としてプロトコルの動作を可能にすることができます。プロトコルで使用されるエンコーディングによっては、ALGは、いくつかのケースではそれがすべてで可能ではないかもしれませんが、構築することが困難または簡単かもしれません。 NATの補助が、直接NATを介して動作することができないプロトコルの製剤は、ALGのデザインはシンプルかつ自動化することができるよう考慮されるべきです。 ALGは、典型的には、NAT構成要素と共に小型ルーターの内部動作します。理想的には、ALGは単純なものや過度の計算やステート・ストレージを必要とすべきではありません。
Many of the same issues in application design that create issues for NAT (and thus can require ALG support) are also issues for firewalls. An application designer would do well to keep this in mind, as any protocol that does require special handling by NAT or firewall products will be more difficult to deploy than those that require no special handling.
（ALGのサポートを必要とすることができるようにして）NATのための問題を作成したアプリケーションの設計で同じ問題の多くは、ファイアウォールのための問題です。 NATやファイアウォール製品で特別な処理を必要としません任意のプロトコルは、特別な処理を必要としないものよりも展開することがより困難になりますように、アプリケーションの設計者は、これを覚えておくためによいでしょう。
Network Address Translation presents a challenge to some existing applications. In many cases, it should be possible for developers of new applications to avoid problems if they understand the issues. This document aims to provide the application designer with information on what things they can do and what to avoid when trying to build applications that are able to function across NAT.
ネットワークアドレス変換は、いくつかの既存のアプリケーションへの挑戦を提示します。彼らは問題を理解していれば、新しいアプリケーションの開発者が問題を回避する多くの場合、それは可能なはずです。この文書では、彼らが行うことができますし、NAT越えて機能することができるアプリケーションを構築しようとしたときに何を避けるために、どのようなものに情報をアプリケーション設計を提供することを目的とします。
The proliferation of NAT, especially in homes and small offices cannot be dismissed. The marketing of these technologies to homes and small businesses is often focused on a single-computer environment, and thus providers only give out a single IP address to each user. NAT has become a popular choice for connecting more than a single system per location.
特に家庭や小規模オフィスでのNATの増殖は、却下することはできません。家庭や中小企業へのこれらの技術のマーケティングは、多くの場合、単一のコンピュータ環境に焦点を当てているため、プロバイダは、各ユーザーに単一のIPアドレスを与えます。 NATは、場所ごとに単一のシステムよりも多くを接続するための一般的な選択肢となっています。
Clearly the most common problem associated with NAT implementations is the passing of addressing data between stations. Where possible, applications should find alternatives to such schemes. Studying a few existing protocols will serve to highlight the different approaches possible.
明らかにNATの実装に関連した最も一般的な問題は、ステーション間のデータを扱うの通過です。可能であれば、アプリケーションは、このような制度に代わるものを見つける必要があります。いくつかの既存のプロトコルを研究することの可能な異なるアプローチを強調するのに役立つであろう。
Two common forms of Traditional NAT exist. With Basic NAT, only the IP addresses of packets are altered by the NAT implementation. Many applications will operate correctly with Basic NAT. The other common form is Network Address Port Translation. With NAPT, both the IP addresses and the source and destination ports (for TCP and UDP) are potentially altered by the gateway. As such, applications passing only port number information will work with Basic NAT, but not with NAPT.
従来のNATの二つの一般的な形態が存在します。基本的なNATでは、パケットのIPアドレスのみがNATの実装によって変更されています。多くのアプリケーションでは、基本的なNATで正しく動作します。他の一般的な形式は、ネットワークアドレスポート変換です。 NAPTと、IPアドレスと（TCPおよびUDPの）送信元ポートと宛先ポートの両方が、潜在的にゲートウェイによって変更されます。そのため、ポート番号だけ情報を渡すアプリケーションは、基本的なNATではなく、NAPTで動作します。
Application designers should strive for compatibility with NAPT, as this form of NAT is the most widely deployed. This is also the form of NAT that will likely see the greatest penetration in homes and small offices. Not all applications lend themselves to the architectural model imposed by NAPT.
NATのこのフォームは、最も広く展開されているように、アプリケーションの設計者は、NAPTとの互換性のために努力すべきです。また、これはおそらく家庭や小規模オフィスでの最大の浸透が表示されますNATの一形態です。いないすべてのアプリケーションは、NAPTによって課せられた建築モデルに自分自身を貸します。
Application designers who work within the constraints of NAT, and who do not rely on the presence of ALGs will generally find the easier acceptance in user communities where NAT is common. When designing a new application or service, the requirement for an ALG will limit deployment until the required additional code is incorporated into the many devices which implement NAT.
NATの制約内で作業し、誰がのALGの存在に依存しないアプリケーションの設計者は、一般的にNATが一般的であるユーザーのコミュニティで簡単に受け入れを見つけるでしょう。新しいアプリケーションやサービスを設計するときに必要な追加のコードはNATを実装する多くのデバイスに組み込まれるまで、ALGのための要件は、展開が制限されます。
Each of the areas called out below are examples of issues to consider when building an application. This list is likely not comprehensive, but does cover a number of important issues and considerations.
以下に呼ばれる領域のそれぞれには、アプリケーションを構築する際に考慮すべき問題の例です。このリストは包括的可能性はありませんが、重要な問題と考慮事項の数をカバーしません。
3.1 Issues and Recommendations affecting all types of Network Address Translators
ネットワークアドレス変換のすべてのタイプに影響を与える3.1問題および推奨事項
Peer to peer applications are problematic in a NAT world. Client-server applications are more generally workable. Peer-to-peer applications rely on each peer being reachable as a server (i.e., bound to a listening port, and able to accept connections) for the other to connect to. With NAPT, there are likely many machines behind one address. With other types of NAT such as Basic NAT with Static Address Assignment (providing one-to-one mappings), there is a greater chance of making such applications work.
アプリケーションはNAT世界で問題となっているピアツーピア。クライアントサーバーアプリケーションは、より一般的に実行可能です。ピアツーピアアプリケーションは、それぞれに接続する他のためのサーバ（すなわち、リスニングポートにバインドされ、そして接続を受け入れることができる）などの到達可能であるピアに依存しています。 NAPTでは、一つのアドレスの後ろにそう多くのマシンがあります。静的アドレスの割り当て（1対1のマッピングを提供する）と、このような基本的なNATなどのNATの他のタイプでは、このようなアプリケーションを機能させるの大きなチャンスがあります。
Some implementations of NAT can be made to function for UDP-based peer-to-peer applications. This capability is dependent on the methodology used to implement the UDP sessions in the NAT device. If the NAT device tracks the tuple (private address, private port, public port) then it is possible for an outbound UDP packet to establish a channel by which incoming traffic can flow from a source other than that originally contacted by the system. The source IP address is NOT used in this case to match incoming packets to UDP sessions, allowing any source address using the UDP port number to be translated.
NATの一部の実装では、UDPベースのピア・ツー・ピア・アプリケーション向けに機能させることができます。この機能は、NATデバイスでUDPセッションを実装するために使用される方法に依存しています。 NATデバイスは、タプル（プライベートアドレス、プライベートポート、パブリックポート）を追跡する場合は、アウトバウンドUDPパケットは、着信トラフィックは、もともとシステムが接触している以外のソースから流れることができることにより、チャネルを確立するために、それが可能です。送信元IPアドレスは、UDPポート番号を使用して、任意の送信元アドレスを変換することができるように、UDPセッションへの着信パケットを一致させるために、この場合には使用されません。
NAT devices which track source and destination IP addresses, in addition to port numbers, will not permit third-party packets. NAT is often implemented in conjunction along with stateful-inspection firewall functionality. As such the latter implementation of UDP association tracking would be considered more secure.
送信元と宛先のIPアドレスを追跡するNATデバイスは、ポート番号に加えて、サードパーティのパケットを許可しません。 NATは、多くの場合、ステートフル・インスペクションファイアウォール機能と一緒に関連して実施されます。 UDP関連付けトラッキングのような後者の実装は、より安全であると考えられるように。
NAT/Firewall device implementations could be constructed to have a software switch within them, permitting the consumer the ability to select whether they want the greater security, or greater ability to run peer-to-peer applications.
NAT /ファイアウォールデバイスの実装は、消費者に彼らがより高いセキュリティをしたいかどうかを選択する機能、またはピア・ツー・ピア・アプリケーションを実行するためのより大きな能力を許可、その中にソフトウェアスイッチを持つように構成することができます。
Use of IPSec for end-to-end security will not function in the presence of a NAT implementation. Application designers may want to explore the use of Transport Layer Security (TLS) [RFC2246] as a transport mode that will traverse NAT cleanly. See [RFC2709] for additional discussion on combining NAT with Tunnel-mode IPSec security on the same device.
エンドツーエンドのセキュリティのためのIPSecの使用は、NATの実装の存在下では機能しません。アプリケーション設計者は、きれいにNATを横断するトランスポートモードとして、トランスポート層セキュリティ（TLS）[RFC2246]の使用を検討することをお勧めします。同じデバイス上でトンネルモードIPSecセキュリティでNATを組み合わせることで、追加の議論については、[RFC2709]を参照してください。
Applications should, where possible, use fully qualified domain names rather than IP addresses when referring to IP endpoints. When endpoints are across a NAT gateway, private addresses must not be allowed to leak to the other endpoint. An example of where this can happen today is with the HTTP and HTML protocols. It is possible for web pages to be specified with numeric IP addresses, rather than with names, for example http://192.168.1.10/index.html could be used as a URL, but would likely create a problem if this address is on a server located behind a NAT gateway. Users outside the gateway would not be able to reach the address 192.168.1.10, and so would not see the page.
IPエンドポイントを参照する際にアプリケーションは、可能な場合、完全修飾ドメイン名ではなくIPアドレスを使用する必要があります。エンドポイントがNATゲートウェイを越えている場合は、プライベートアドレスは、他のエンドポイントに漏れ出ることを許容してはいけません。これが今日起こることができる場所の例は、HTTPとHTMLプロトコルです。それは、例えば、http://192.168.1.10/index.htmlがURLとして使用することができ、むしろ名前を持つよりも、数値のIPアドレスで指定するWebページの可能ですが、このアドレスがオンになっている場合は可能性の高い問題を作成しますNATゲートウェイの背後にあるサーバー。ゲートウェイ以外のユーザーはアドレス192.168.1.10に到達することができない、などのページが表示されないでしょう。
Further exacerbating the problem is the possibility of duplicate addresses between realms. If a server offers a link with a private address space IP address embedded within it, such as 192.168.1.10, the page referenced may resolve to a system on the local network the browser is on, but would be a completely different server. The resulting confusion to end-users would be significant. Sessions involving multiple NAT implementations would be exceptionally vulnerable to address reuse issues of this sort.
さらに問題を悪化させることは、レルム間で重複したアドレスの可能性があります。サーバーは、192.168.1.10のように、その中に埋め込まれたプライベートアドレス空間のIPアドレス、とのリンクを提供する場合、参照されたページは、ブラウザがオンになっているローカルネットワーク上のシステムに解決されることがありますが、完全に異なるサーバーになります。エンドユーザーに結果として混乱が重要になります。複数のNATの実装を含むセッションは、この種の再利用の問題に対処するために非常に脆弱になります。
Not all NAT devices implement multicast routing protocols. Application designers should verify whether the devices in the networks where their applications will be deployed are able to process multicast traffic if their applications rely on that capability.
すべてのNATデバイスは、マルチキャストルーティングプロトコルを実装していません。アプリケーション設計者は、アプリケーションがその機能に依存している場合は、そのアプリケーションが展開されるネットワーク内のデバイスがマルチキャストトラフィックを処理できるかどうかを確認する必要があります。
With the exception of statically configured NAT bindings, applications should not assume address mapping will be maintained from one session (association between machines, for whatever protocol for a period of time) to another. An example of this is RSVP, which forms one connection to reserve the resources, then the actual session for which resources were reserved is started. The sessions do not necessarily overlap. There is no guarantee that the NAT implementation will keep the binding association. As such, applications that rely on subsequent sessions being mapped to the same host IP address may not function without an ALG.
静的に構成されたNATバインディングを除いて、アプリケーションは、アドレスマッピングが別のセッション（時間の期間のためにどのようなプロトコルのマシンとの間の関連付け）から維持されると仮定してはなりません。この例は、リソースを確保するために、1つの接続を形成RSVP、その後、リソースが予約されたため、実際のセッションが開始されています。セッションは必ずしも重なりません。 NATの実装は、バインディングの関連付けを維持する保証はありません。このように、後続のセッションに依存するアプリケーションは、ALGなしに機能しない可能性が同一のホストIPアドレスにマッピングされます。
Another consideration is the number of addressing realms. It is entirely possible to have multiple levels of NAT implementations between the two end points involved. As such, one must think about the lifetime of such mappings at all such levels.
もう1つの考慮事項は、アドレス範囲の数です。関与する2つのエンドポイント間のNAT実装の複数のレベルを有することが全く可能です。そのように、人はそのようなすべてのレベルで、このようなマッピングの寿命を考える必要があります。
Load balancers and other devices may use a single IP address and port to map to multiple actual end points. Many products implement variations on this theme, sometimes using NAT, sometimes using other technologies. The lack of guarantee of mapping is important to understand, since the mapping to one actual system to another may not survive across such intermediate boxes.
ロードバランサや他のデバイスは、複数の実際のエンドポイントにマッピングする単一のIPアドレスとポートを使用することができます。多くの製品は、時には他の技術を使用して、NATを使用して、このテーマにバリエーションを実装します。別の実際のシステムへのマッピングは、このような中間ボックス間では耐えられないかもしれませんので、マッピングの保証の欠如は、理解することが重要です。
Don't assume systems know their own IP addresses. A system behind a NAT may be reachable via a particular IP address, but that address may not be recognized by the system itself. Consider the case of Static, one-to-one mapping using Basic NAT. A server in this context will have an IP address from the private realm, and may not know the public address which maps to it. Similarly, some such systems may not know their own DNS names, while others may. This is largely dependent on the configuration of the servers and the network within the private realm.
システムは、独自のIPアドレスを知っていると仮定しないでください。 NATの背後にあるシステムは、特定のIPアドレスを経由して到達可能かもしれないが、そのアドレスはシステム自体が認識されないことがあります。静的の場合、基本的なNATを使って1対1のマッピングを考えてみましょう。この文脈では、サーバーは、プライベート領域からのIPアドレスを持つことになり、それにマップパブリックアドレスを知らないかもしれません。他の人がかもしれないが同様に、いくつかのこのようなシステムは、自身のDNS名を知らないかもしれません。これは、サーバの設定とプライベート領域内のネットワークに大きく依存しています。
As many of the issues specifically address NAPT issues, this section will group these issues. NAPT is the most common form of NAT in actual deployment in routers, especially in smaller offices and home offices.
問題の多くは、特にNAPTの問題に対処するように、このセクションでは、グループ、これらの問題でしょう。 NAPTは、特に小規模オフィスやホームオフィスでは、ルータの実際の展開でNATの最も一般的な形式です。
Avoid the use of IP address and port number information within the payload of packets. While in some cases ALGs will permit such protocols to function, this presupposes every NAT device can be updated in a timely fashion to support a new protocol. Since this is unlikely, application writers are urged to avoid placing addressing information in payloads all together.
パケットのペイロード内のIPアドレスとポート番号情報の使用は避けてください。いくつかのケースでのALGが機能するためにそのようなプロトコルを許可しますが、これはすべてのNATデバイスが新しいプロトコルをサポートするために、タイムリーに更新することができ前提としています。これはほとんどありませんので、アプリケーション作成者は、すべて一緒にペイロードにアドレス情報を置くことを避けるために促しています。
In addition to avoiding addresses and port numbers within packet payloads, it is important to avoid assumptions of (address, port) tuples are unique beyond the scope of the present session. Load balancing devices implementing NAT may, for example, map subsequent sessions to other systems in the private realm.
パケットペイロード内のアドレスとポート番号を回避することに加えて、（アドレス、ポート）タプルの仮定を避けることが重要である現在のセッションの範囲を超えてユニークです。 NATを実装する負荷分散装置には、例えば、プライベート領域内の他のシステムへの以降のセッションをマッピングすることができます。
Independent sessions, such as used by POP or SMTP, are preferred to protocols that attempt to manage a bundle of related sessions, such as FTP. The term "session" here is used to refer to any association between end systems, and may be using any transport protocol or combination of protocols (UDP, TCP, SCTP).
POPやSMTPによって使用されるような独立したセッションは、FTPなどの関連セッション、の束を管理しようとプロトコルに好まれます。ここで用語「セッション」とは、エンドシステムとの間の任意の関連を指すために使用される、任意のトランスポートプロトコルまたはプロトコル（UDP、TCP、SCTP）の組み合わせを用いてもよいです。
In the FTP protocol, port information is passed over one TCP connection and is used to construct a second TCP connection for passing the actual data. Use of a separate connection to transfer the file data makes determination of file end quite simple, however other schemes could be envisioned which could use a single connection.
FTPプロトコルでは、ポート情報は、1つのTCP接続を介して渡され、実際のデータを通過させるための第二のTCP接続を構築するために使用されます。ファイルデータを転送するために別々の接続を使用すると、単一の接続を使用することができますが、他のスキームを想定することができ、非常に単純なファイル終わり、の判定を行います。
The HTTP protocol, for example, uses a header and content length approach to passing data. In this model, all data is transferred over the single TCP connection, with the header portion indicating the length of the data to follow. HTTP has evolved to allow multiple objects to be passed on a single connection (thereby cutting the connection establishment overhead). Clearly a new file transfer function could be built that would perform most of the functions of FTP without the need for additional TCP connections.
HTTPプロトコルは、例えば、データの受け渡しに、ヘッダおよびコンテンツ長アプローチを使用します。このモデルでは、すべてのデータが従うべきデータの長さを示すヘッダ部分と、単一のTCP接続を介して転送されます。 HTTPは、複数のオブジェクトが（それによって接続確立のオーバーヘッドを切断する）単一の接続に渡すことができるように進化してきました。明らかに新しいファイル転送機能は、追加のTCP接続を必要とせずにFTPの機能のほとんどを実行することを構築することができます。
The goal is to keep to single connections where possible. This keeps us from needing to pass addressing information of any sort across the network. However, multiplexing traffic over a single connection can create problems as well.
目標は、可能な単一の接続を維持することです。これは、ネットワークを介して任意の並べ替えのアドレス情報を渡すために必要から私たちを保持します。しかし、1つの接続で多重化トラフィックは、同様の問題を作成することができます。
Origination of connections is an important consideration. Where possible, the client should originate all connections. The FTP protocol is the most obvious example, where by default the server opens the data connection to a port on the client (the client having specified the port number via a PORT command over the control TCP session).
接続の発信は重要な考慮事項です。可能であれば、クライアントはすべての接続を開始する必要があります。 FTPプロトコルは、デフォルトでは、サーバは、クライアント（制御TCPセッションでPORTコマンドを使ってポート番号を指定したクライアント）上のポートへのデータ接続を開きます最も明白な例です。
As pointed out in [RFC1579], the use of the passive open option in FTP (PASV) remedies this situation as the client is responsible for opening the connection in this case. With client-opened connections, the standard functions of NAPT will process the request as it would any other simple TCP connection, and so an ALG is not required.
[RFC1579]で指摘したように、クライアントとFTPでの受動オープンオプションの使用（PASV）救済このような状況は、この場合、接続を開くための責任があります。クライアント・開かれた接続では、NAPTの標準機能は、それが他の単純なTCP接続と同じように要求を処理し、そのためALGは必要ありません。
In cases where session bundles are unavoidable, each session in the bundle should originate from the same end station.
セッション束が避けられない場合には、バンドル内の各セッションは、同じエンドステーションから発信すべきです。
NAPT gateways must track which sessions are alive, and flush old sessions. TCP has clear advantages in this area, since there are specific beginning and end of session indicators in the packets (SYN and FIN packets). While UDP works for some types of applications with NAT, there can be issues when that data is infrequent. Since there is no clean way to know when an end station has finished using a UDP session, NAT implementations use timeouts to guess when a UDP session completes. If an application doesn't send data for a long period of time, the NAT translation may time out.
NAPTゲートウェイは生きているどのセッションを追跡し、古いセッションをフラッシュする必要があります。特定の開始とパケット（SYNとFINパケット）のセッション指標の終わりがあるので、TCPは、この分野での明確な利点があります。 UDPは、NATとアプリケーションのいくつかのタイプのために動作しますが、データがまれであるとき、問題が発生することができます。エンドステーションは、UDPセッションの使用を終了したときに知って何のクリーンな方法が存在しないため、NATの実装はUDPセッションが完了したときに推測するタイムアウトを使用します。アプリケーションは、長期間のデータを送信しない場合、NAT変換がタイムアウトすることがあります。
NAT implementations also use timers to guess when TCP sessions have disappeared. While TCP sessions should disappear only after FIN packets are exchanged, it is possible that such packets may never come, for example if both end stations die. As such, the NAT implementation must use a timer for cleaning up its resources.
NATの実装はまた、TCPセッションが消えた時に推測するタイマーを使用します。 TCPセッションがFINパケットが交換された後にのみ消えるはずですが、両方のエンドステーションが死ぬならば、このようなパケットは、例えば、来ないかもしれないということも可能です。そのため、NATの実装は、そのリソースをクリーンアップするためにタイマーを使用する必要があります。
NAT implementers in many cases provide several timeouts, one for live TCP sessions, one for TCP sessions on which a FIN has been seen, and one for UDP sessions. It is best when such flexibility is provided, but some implementations appear to apply a single timer to all traffic.
多くの場合、NAT実装は、いくつかのタイムアウト、ライブTCPセッションの1、FINが見されたTCPセッションの1、およびUDPセッションのための1つを提供しています。このような柔軟性が提供されている場合には最高ですが、いくつかの実装は、すべてのトラフィックに単一のタイマーを適用するように見えます。
Protocols other than TCP and UDP can work with Traditional NAT in many cases, provided they are not carrying addressing information. For NAPT implementations use of any protocols other than TCP and UDP will be problematic unless or until such protocols are programmed into the implementations.
多くの場合、従来のNATで動作することができ、TCPおよびUDP以外のプロトコルでは、彼らはアドレス情報を持っていない提供されます。そのようなプロトコルが実装にプログラムされていない限りまで、またはNAPTの実装では、TCPおよびUDP以外のプロトコルの使用は、問題になる可能性があります。
It's important to note that NAPT deployments are based on the assumption of a client-server application model, with the clients in the private realm.
これは、NAPTの導入が民間分野でのクライアントと、クライアント・サーバ・アプリケーションモデルの仮定に基づいていることに注意することが重要です。
Applications should attempt to avoid fragmentation when packets pass over NAPT devices. While not always practical or possible, there are failures that can occur with NAPT. Specifically, if two stations in the private realm pick matching fragmentation identifiers, and talk to the same remote host, it may be impossible to determine which fragments belong to which session. A clever NAPT implementation could track fragmentation identifiers and map those into a unique space, though it is not clear how many do so.
アプリケーションは、パケットがNAPT機器上を通過するときの断片化を避けるために試みるべきです。常に実用的または可能ではないが、NAPTで発生する可能性がある障害があります。民間分野での2つのステーションが断片化識別子に一致する選択し、同じリモートホストに話せば具体的には、どのセッションに属するフラグメントを決定することは不可能かもしれません。賢いNAPTの実装では、断片化識別子を追跡し、そう何明確ではないものの、独特の空間にそれらをマッピングすることができます。
Ideally, applications should limit packet size, use Path MTU Discovery or both. Unfortunately, at least some firewall/NAT devices block Path MTU Discovery, apparently believing all ICMP packets are evil.
理想的には、アプリケーションでは、パケットのサイズを制限するパスMTUディスカバリ、またはその両方を使用する必要があります。残念ながら、少なくともいくつかのファイアウォール/ NATデバイスは、明らかに、すべてのICMPパケットが悪されていると信じ、パスMTUディスカバリをブロックします。
Some implementations of NAT may implement fragment reassembly prior to Forwarding, however many do not. Application designers are advised to design assuming the devices do not reassemble fragments.
NATの実装によっては、前の転送にフラグメント再構成を実装することが多くはありません。アプリケーション設計者は、フラグメントを再構成していないデバイスを想定して設計することをお勧めします。
If only Basic NAT implementations are involved, not NAPT, then many of the issues above do not apply. This is not to say that this form of NAT is better or worse than NAPT. Application designers may think they could just specify users must use Basic NAT, and many application issues would go away. This is unrealistic, however, as many users have no real alternative to NAPT due to the way their providers sell service.
唯一の基本的なNATの実装が含まれている場合は、NAPTは、上記の問題の多くは適用されませんではありません。これは、NATのこのフォームはNAPTより良いか悪いかであると言っているわけではありません。アプリケーション設計者は、彼らはただ、ユーザーが基本的なNATを使用する必要があります指定することができ、多くのアプリケーションの問題を離れて行くだろうと思うかもしれません。多くのユーザーがNAPTへの真の選択肢を持っていないとして、これは、そのプロバイダがサービスを販売する方法に、しかし、非現実的です。
Many of the issues raised earlier still apply to Basic NAT, and many protocols will not function correctly without assistance.
先に提起された問題の多くは、まだ基本的なNATに適用され、多くのプロトコルは、支援なしで正しく機能しません。
Applications that use only the information in the IP and TCP or UDP headers for communication (in other words, do not pass any additional addressing information in the payload of the packets), are clearly easier to support in a NAT environment. Where possible, applications designers should try to limit themselves in this area.
IPおよびTCPまたは通信のためのUDPヘッダの情報のみを使用するアプリケーションは、明確にNAT環境でサポートするのが容易である、（つまり、パケットのペイロードに追加のアドレス情報を渡すことはありません）。可能であれば、アプリケーションの設計者は、この分野で自分自身を制限しようとする必要があります。
This comes back to the same recommendation made for NAPT, that being to use a single connection whenever possible.
これは、可能な限り、単一の接続を使用していることを、バックNAPTのために作られた同勧告に来ます。
The X windowing system, for example, uses fixed port numbers to address X servers. With X, the server (display) is addressed via ports 6000 through 6000 + n. These map to hostname:0 through hostname:n server displays. Since only the address and port are used, the NAT administrator could map these ports to one or more private addresses, yielding a functioning solution.
Xウィンドウシステムは、例えば、Xサーバに対処するために、固定ポート番号を使用しています。 Xと、サーバ（表示）は6000 + Nを介してポート6000を介してアドレス指定されます。これらは、ホスト名にマップ：0ホスト名によって：n個のサーバが表示されます。唯一のアドレスとポートが使用されているので、NAT管理者が機能して溶液を得、一つ以上のプライベートアドレスにこれらのポートをマッピングすることができます。
The X example, in the case of NAPT, requires configuration of the NAT implementation. This results in the ability for no more than one station inside the NAT gateway to use such a protocol. This approach to the problem is thus OK for NAT but not recommended for NAPT environments.
Xの例は、NAPTの場合には、NAT実装の構成を必要とします。これは、プロトコルを使用するNATゲートウェイの内部には、複数のステーションのための能力をもたらします。問題へのこのアプローチは、このようにNATのためのOKが、NAPT環境では推奨されません。
As with NAPT, transporting IP address and/or port number information in the payload is likely to cause trouble. As stated earlier, load balancers and similar platforms may well map the same IP address and port number to a completely different system. Thus it is problematic to assume an address or port number which is valid in the realm on one side of a NAT is valid on the other side.
NAPTと同様に、ペイロードにIPアドレスおよび/またはポート番号の情報を輸送することは、トラブルを引き起こす可能性があります。先に述べたように、ロードバランサと同様のプラットフォームは、十分完全に異なるシステムに対して同じIPアドレスとポート番号をマッピングすることができます。したがって、NATの一方の側の領域で有効であるもう一方の側で有効なアドレスやポート番号を想定する問題があります。
Bi-directional NAT makes use of DNS mapping of names to point sessions originating outside the private realm to servers in the private realm. Through use of a DNS-ALG [RFC2694], lookups are performed to find the proper host and packets are sent to that host.
双方向NATは、プライベート領域内のサーバーにプライベート領域外に発信さのセッションを指すように名前のDNSマッピングを使用しています。 DNS-ALG [RFC2694]を使用することにより、ルックアップは、適切なホストを見つけるために実行され、パケットがそのホストに送信されます。
Requirements for applications are the same as for Basic NAT. Addresses are mapped one-to-one to servers. Unlike Traditional NAT devices, Bi-directional NAT devices (in conjunction with DNS-ALG) are amenable to peer-to-peer applications.
アプリケーションの要件は、基本的なNATと同じです。アドレスは1対1のサーバーにマップされます。伝統的なNAT装置とは異なり、（DNS-ALGと一緒に）双方向NATデバイスは、ピア・ツー・ピアへのアプリケーション適しています。
Twice NAT is address translation where both source and destination IP addresses are modified due to addressing conflicts between two private realms. Two bi-directional NAT boxes connected together would essentially perform the same task, though a common address space that is not otherwise used by either private realm would be required.
二回NATは、送信元と宛先の両方のIPアドレスが原因2つのプライベートレルムの間の競合に対処することに変更されたアドレス変換です。それ以外の場合は、民間分野のいずれかで使用されていない一般的なアドレス空間が必要になるものの互いに接続された2つの双方向NATボックスは、基本的に、同じタスクを実行することになります。
Requirements for applications to work in the Twice NAT environment are the same as for Basic NAT. Addresses are mapped one to one.
二度NAT環境で動作するアプリケーションのための要件は、基本的なNATと同じです。アドレスは一から一をマッピングされます。
Multi-homed NAT is the use of multiple NAT implementations to provide redundancy. The multiple implementations share configuration information so that sessions might continue in the event of a fail-over. Unless the multiple implementations share the same external addresses, sessions will have to restart regardless.
マルチホームのNATは、冗長性を提供するために、複数のNATの実装を使用することです。複数の実装共有設定情報セッションは、フェイルオーバーの際に続ける場合がありますように。複数の実装が同じ外部アドレスを共有していない限り、セッションは関係なく、再起動する必要があります。
Requirements for multi-homed NAT are the same as for Basic NAT or NAPT, depending on how the multi-homed NAT is implemented and configured.
マルチホームのNATの要件は、マルチホームのNATが実装され、構成されている方法に応じて、基本的なNATやNAPTの場合と同じです。
Realm Specific IP is described in [RFC2663] and defined in [RSIP] and related documents. Clients within a private realm using RSIP are aware of the delineation between private and public, and access a server to allocate address (and optionally port) information for use in conversing with hosts in the public realm. By doing this, clients create packets that need not be altered by the RSIP server on their way to the remote host. This technique can permit IPSec to function, and potentially makes any application function as if there were no special processing involved at all.
レルム特定IPは[RFC2663]に記載の[RSIP]および関連文書に定義されています。 RSIPを使用してプライベート領域内のクライアントは、プライベートとパブリックの間に線引きを認識し、公共分野におけるホストとの会話で使用するためのアドレス（およびオプションでポート）の情報を割り当てるためにサーバーにアクセスします。これにより、クライアントはリモートホストへの道にRSIPサーバによって変更する必要がないパケットを作成します。この技術は機能するためにIPSecを許可し、すべての関連する特別な処理がなかったかのように潜在的に任意のアプリケーションを機能させることができます。
RSIP uses a view of the world in which there are only two realms, the private and public. This isn't always the case. Situations with multiple levels of NAT implementations are growing. For example, some ISPs are handing out [RFC1918] addresses to their dialup users, rather than obtaining real addresses. Any user of such an ISP who also uses a NAT implementation will see two levels of NAT, and the advantages of RSIP will have been wasted.
RSIPは唯一の2つのレルム、プライベートとパブリックの存在する世界観を使用しています。これは必ずしもそうではありません。 NATの実装の複数のレベルでの状況は、成長しています。例えば、いくつかのISPは、むしろ実アドレスを取得するよりも、自分のダイヤルアップユーザーに[RFC1918]アドレスを配っています。また、NATの二つのレベルが表示されますNATの実装を使用して、このようなISPのすべてのユーザー、およびRSIPの利点が無駄にされています。
Resource utilization on the NAT gateway should be considered. An application that opens and closes many TCP connections, for example, will use up more resources on the NAT router than an application performing all transfers over a single TCP connection. HTTP 1.0 opened a connection for each object on a web page, whereas HTTP 1.1 permits the TCP session to be held open for additional objects that may need to be transferred. Clearly the latter imposes a lower overhead on the NAT gateway, as it is only maintaining state on a single connection instead of multiple connections.
NATゲートウェイ上のリソース使用率を考慮すべきです。多くのTCP接続を開閉するアプリケーションは、例えば、単一のTCP接続を介してすべての転送を実行するアプリケーションよりもNATルータ上でより多くのリソースを使用します。 HTTP 1.1許可TCPセッションを転送する必要があるかもしれない追加のオブジェクトのためのオープン開催されるのに対し、HTTP 1.0は、Webページ上の各オブジェクトの接続をオープンしました。それが唯一の代わりに複数の接続の単一接続に状態を維持しているように、明らかに後者は、NATゲートウェイに低いオーバーヘッドを課します。
New session establishment will typically remain a software function even in implementations where the packet-by-packet translation work is handled by hardware forwarding engines. While high-performance NAT boxes may be built, protocols that open many sessions instead of multiplexing will be slower than those that do not.
新しいセッションの確立は、通常、パケットごとの翻訳作業は、ハードウェア転送エンジンによって処理された実装でも、ソフトウェアの機能をままになります。高性能NATボックスを構築することができるが、代わりに多重の多くのセッションを開くプロトコルはそうでないものよりも遅くなります。
Applications with different types of data, such as interactive conferencing, require separate streams for the different types of data. In such cases the protocol needs of each stream must be optimized. While the goal of multiplexing over a single session is preferred, clearly there are cases where this is impractical.
インタラクティブな会議などの異なる種類のデータを持つアプリケーションでは、データの種類ごとに別々のストリームを必要とします。このような場合には、各ストリームのプロトコルの必要性は最適化されなければなりません。単一セッションでの多重化の目標が好ましいが、明らかにこれは非現実的である場合があります。
The latency of NAT translation overhead is implementation dependent. On a per-packet basis, for established sessions only the source or destination IP address is replaced, the source or destination port (for NAPT) and the checksums for IP, and TCP or UDP are recalculated.
NAT変換のオーバーヘッドのレイテンシは実装依存です。パケット単位で（NAPT用）、唯一の送信元または宛先IPアドレスを交換する確立されたセッションのために、送信元ポートまたは宛先ポートとIP、およびTCPやUDPのチェックサムが再計算されます。
The functionality can be efficiently implemented in hardware or software.
機能性は、効率的にハードウェアまたはソフトウェアで実現することができます。
Network Address Translators have implications for IPSec, as noted above. When application developers are considering whether their applications function with NAT implementations, care should be given to selection of security methodology. Transport Layer Security (TLS) [RFC2246] operates across translation boundaries. End-to-end IPSec will prove problematic in many cases.
上述のようにネットワークアドレス変換は、IPSecの意味を持っています。アプリケーション開発者は、アプリケーションがNATの実装で機能するかどうかを検討している場合は、注意がセキュリティ方法の選択には注意が必要です。トランスポート層セキュリティ（TLS）[RFC2246]は、翻訳の境界を越えて動作します。エンドツーエンドのIPSecは、多くの場合、問題になるだろう。
[RFC1579] Bellovin, S., "Firewall Friendly FTP", RFC 1579, February 1994.
[RFC1579] Bellovin氏、S.、 "ファイアウォールフレンドリーFTP"、RFC 1579、1994年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", RFC 3027, January 2001.
[RFC3027]ホールドレッジ、M.とP. Srisuresh、RFC 3027 "IPネットワークアドレス変換（NAT）とプロトコル合併症"、2001年1月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[RFC2709] Srisuresh、P.、 "NATドメインのトンネルモードのIPsecとセキュリティモデル"、RFC 2709、1999年10月。
[RFC3102] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RFC3102]ボレッラ、M.、ロー、J.、Grabelsky、D.およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、2001年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[RFC2694] Srisuresh、P.、Tsirtsis、G.、Akkiraju、P.およびA. Heffernanのは、RFC 2694、1999年9月の "ネットワークへのDNS拡張は、翻訳者（DNS_ALG）をアドレス"。
I'd like to thank Pyda Srisuresh for his invaluable input and feedback, and Keith Moore for his extensive comments.
私は彼の豊富なコメントのための彼の貴重な入力とフィードバックのためのPyda Srisuresh、およびキースムーアに感謝したいと思います。
Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton, MA 01740
ダニエルSenieアマランスネットワークス株式会社324それでもリバーロードボルトン、MA 01740
Phone: (978) 779-6813 EMail: dts@senie.com
電話：（978）779-6813 Eメール：dts@senie.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。