[要約] RFC 3235は、NATに対応したアプリケーションの設計ガイドラインを提供しています。その目的は、NAT環境でのアプリケーションの問題を解決し、通信の信頼性とパフォーマンスを向上させることです。
Network Working Group D. Senie
Request for Comments: 3235 Amaranth Networks Inc.
Category: Informational January 2002
Network Address Translator (NAT)-Friendly Application Design Guidelines
ネットワークアドレス翻訳者（NAT） - フレンドリーなアプリケーション設計ガイドライン
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.
Copyright（c）The Internet Society（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）の使用により、プロトコルの動作が可能になります。プロトコルで使用されるエンコーディングに応じて、アルグは困難または構築が容易になる場合がありますが、場合によってはまったく不可能かもしれません。NATを補助しますが、ALG設計がシンプルで自動化されるように、NATを介して直接動作できないプロトコルの定式化を考慮する必要があります。アルグは通常、NATコンポーネントとともに小さなルーター内で動作します。理想的には、アルグは単純でなければならず、過度の計算や状態ストレージを必要としないはずです。
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.
NATの問題を作成する（したがってALGサポートが必要になる可能性がある）アプリケーション設計における同じ問題の多くも、ファイアウォールの問題です。アプリケーションデザイナーは、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は、場所ごとに1つ以上のシステムを接続するための一般的な選択肢となっています。
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の2つの一般的な形式が存在します。Basic NATでは、PacketのIPアドレスのみがNAT実装によって変更されます。多くのアプリケーションは、Basic NATで正しく動作します。もう1つの一般的なフォームは、ネットワークアドレスポート翻訳です。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が一般的なユーザーコミュニティで容易な受け入れを見つけます。新しいアプリケーションまたはサービスを設計するとき、ALGの要件は、必要な追加コードがNATを実装する多くのデバイスに組み込まれるまで展開を制限します。
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.
以下の領域は、アプリケーションを構築する際に考慮すべき問題の例です。このリストは包括的ではない可能性がありますが、多くの重要な問題と考慮事項をカバーしています。
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対1のマッピングを提供する）を備えたBasic 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は、Stateful-Inspection Firewall機能と組み合わせて実装されていることがよくあります。そのため、後者のUDP Associationトラッキングの実装はより安全であると見なされます。
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]の使用を調査したい場合があります。NATと同じデバイス上のトンネルモードIPSECセキュリティを組み合わせることに関する追加の議論については、[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など、名前ではなく、数値IPアドレスでWebページを指定することが可能です。Nat Gatewayの後ろにあるサーバー。ゲートウェイの外側のユーザーは、アドレス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であり、リソースを予約するための1つの接続を形成し、リソースが予約された実際のセッションが開始されます。セッションは必ずしも重複しているわけではありません。NATの実装が拘束力のある関連性を維持するという保証はありません。そのため、同じホスト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.
別の考慮事項は、アドレス指定領域の数です。関係する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接続に渡され、実際のデータを渡すために2番目の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.
目標は、可能であれば、単一の接続を維持することです。これにより、ネットワーク上のあらゆる種類のアドレス指定情報に合格する必要がなくなります。ただし、単一の接続を介したマルチプレックストラフィックも問題を引き起こす可能性があります。
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セッション上のポートコマンドを介してポート番号を指定しました）。
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 Gatewaysは、どのセッションが生きているかを追跡し、古いセッションをフラッシュする必要があります。TCPには、パケットに特定の開始と終了インジケーター（SynおよびFinパケット）があるため、TCPには明確な利点があります。UDPはNATを使用したいくつかのタイプのアプリケーションで動作しますが、そのデータがまれな場合に問題が発生する可能性があります。End Stationが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セッション用です。このような柔軟性が提供される場合に最適ですが、一部の実装はすべてのトラフィックに単一のタイマーを適用するように見えます。
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.
TCPおよびUDP以外のプロトコルは、多くの場合、従来のNATで動作します。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.
理想的には、アプリケーションはパケットサイズを制限し、PATH MTU発見、またはその両方を使用する必要があります。残念ながら、少なくとも一部のファイアウォール/NATデバイスは、すべてのICMPパケットが悪であると信じているようです。
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.
以前に提起された問題の多くは依然としてBasic 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〜6000 nを介してアドレス指定されます。これらのマップからホスト名：0からHOSTNAME：nサーバーが表示されます。アドレスとポートのみが使用されるため、NAT管理者はこれらのポートを1つ以上のプライベートアドレスにマッピングして、機能するソリューションを生成できます。
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ゲートウェイ内の1つ以下のステーションがそのようなプロトコルを使用する能力が得られます。したがって、この問題へのこのアプローチはNATでは問題ありませんが、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.
Bi-Directional 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.
アプリケーションの要件は、Basic Natの場合と同じです。アドレスは、サーバーに1対1でマッピングされます。従来のNATデバイスとは異なり、双方向NATデバイス（DNS-Algと併せて）は、ピアツーピアアプリケーションに適しています。
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.
2回のNATは、2つのプライベートレル間の対立に対処するために、ソースと宛先のIPアドレスの両方が変更されるアドレス変換です。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.
2回のNAT環境で動作するアプリケーションの要件は、Basic NATの場合と同じです。アドレスは1対1マッピングされます。
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は、実際のアドレスを取得するのではなく、ダイヤルアップユーザーにアドレスを配布しています。NATの実装も使用するこのようなISPのユーザーは、2つのレベルのNATが表示され、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.0は、Webページ上の各オブジェクトの接続を開きましたが、HTTP 1.1では、転送する必要がある可能性のある追加のオブジェクトのためにTCPセッションを開いています。明らかに、後者は、複数の接続の代わりに単一の接続で状態のみを維持しているため、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変換オーバーヘッドの遅延は、実装に依存します。パケットごとに、確立されたセッションの場合、ソースまたは宛先IPアドレスのみが交換され、ソースまたは宛先ポート（NAPT用）および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] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、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] Holdrege、M。およびP. Srisuresh、「IPネットワークアドレス翻訳者（NAT）とのプロトコル合併症」、RFC 3027、2001年1月。
[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）用語と考慮事項」、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] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm固有の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、「DNS拡張翻訳者（DNS_ALG）、RFC 2694、1999年9月。
I'd like to thank Pyda Srisuresh for his invaluable input and feedback, and Keith Moore for his extensive comments.
彼の貴重な入力とフィードバックをしてくれたPyda Srisureshと、彼の広範なコメントについてKeith Mooreに感謝したいと思います。
Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton, MA 01740
Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton、MA 01740
Phone: (978) 779-6813 EMail: dts@senie.com
電話：（978）779-6813メール：dts@senie.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。