[要約] 要約：RFC 3027は、IPネットワークアドレストランスレータ（NAT）に関連するプロトコルの複雑さについて説明しています。NATは、プライベートIPアドレスをパブリックIPアドレスに変換するために使用されます。目的：このRFCの目的は、NATがプロトコルに与える影響と、その複雑さに対処するためのガイドラインを提供することです。
Network Working Group M. Holdrege
Request for Comments: 3027 ipVerse
Category: Informational P. Srisuresh
Jasmine Networks
January 2001
Protocol Complications with the IP Network Address Translator
IPネットワークアドレス翻訳者とのプロトコルの合併症
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IP Network Address Translator (NAT) enroute to bridge the realms. The NAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of Application Level Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered.
エンドノードが同じアドレス領域にない場合、多くのインターネットアプリケーションが悪影響を受ける可能性があり、IPネットワークアドレス翻訳者（NAT）の支援を求めて、領域を橋渡しします。NATデバイスだけでは、すべての場合に必要なアプリケーション/プロトコルの透明性を提供することはできず、可能な限りアプリケーションレベルゲートウェイ（ALG）の支援を求めて、透明性を提供します。このドキュメントの目的は、NAT Anoteで壊れるプロトコルとアプリケーションを識別することです。ドキュメントはまた、既知の回避策を特定しようとします。単一のドキュメントでNATで壊れるすべてのアプリケーションをキャプチャすることはできません。このドキュメントは、できるだけ多くの情報をキャプチャしようとしますが、決して包括的なカバレッジではありません。カバレッジがカバーされていないアプリケーションに十分な手がかりを提供することを願っています。
Table of Contents
目次
1.0 Introduction .............................................. 2
2.0 Common Characteristics of Protocols broken by NAT ......... 2
3.0 Protocols that cannot work with NAT enroute ............... 4
4.0 Protocols that can work with the aid of an ALG ............ 8
5.0 Protocols designed explicitly to work with NAT enroute .... 16
6.0 Acknowledgements .......................................... 17
7.0 Security Considerations ................................... 17
8.0 References ................................................ 17
9.0 Authors' Addresses ........................................ 19
10.0 Full Copyright Statement ................................ 20
This document requires the reader to be familiar with the terminology and function of NAT devices as described in [NAT-TERM]. In a nutshell, NAT attempts to provide a transparent routing solution to end hosts requiring communication to disparate address realms. NAT modifies end node addresses (within the IP header of a packet) en-route and maintains state for these updates so that datagrams pertaining to a session are transparently routed to the right end-node in either realm. Where possible, application specific ALGs may be used in conjunction with NAT to provide application level transparency. Unlike NAT, the function of ALG is application specific and would likely require examination and recomposition of IP payload.
このドキュメントでは、[NAT-Term]で説明されているように、NATデバイスの用語と機能に慣れる必要があります。 一言で言えば、NATは、住所の領域を異なる領域にするために通信を必要とするホストを終了するための透明なルーティングソリューションを提供しようとします。 NATは、エンドノードアドレス（パケットのIPヘッダー内）を変更し、これらの更新の状態を維持し、セッションに関連するデータグラムがどちらの領域でも右のエンドノードに透過的にルーティングされるようにします。 可能であれば、アプリケーションレベルの透明度を提供するために、アプリケーション固有のアルグをNATと組み合わせて使用できます。 NATとは異なり、ALGの関数はアプリケーション固有であり、IPペイロードの検査と再構成が必要になる可能性があります。
The following sections attempt to list applications that are known to have been impacted by NAT devices enroute. However, this is by no means a comprehensive list of all known protocols and applications that have complications with NAT - rather just a subset of the list gathered by the authors. It is also important to note that this document is not intended to advocate NAT, but rather to point out the complications with protocols and applications when NAT devices are enroute.
以下のセクションでは、AnoteのNATデバイスの影響を受けたことが知られているアプリケーションをリストしようとします。 ただし、これは、NATと合併症のあるすべての既知のプロトコルとアプリケーションの包括的なリストではなく、著者によって収集されたリストのサブセットのみではありません。 また、このドキュメントはNATを提唱することではなく、NATデバイスが停止しているときにプロトコルとアプリケーションの合併症を指摘することを意図していることに注意することも重要です。
[NAT-TERM] and [NAT-TRAD] have sections listing the specific nature of problems and limitations to NAT devices. Some of these limitations are being restated in this section to summarize characteristics of protocols that are broken by NAT.
[NAT-TERM]および[NAT-Trad]は、問題の特定の性質とNATデバイスの制限をリストするセクションがあります。これらの制限のいくつかは、NATによって破られたプロトコルの特性を要約するために、このセクションで修正されています。
A wide range of applications fail with NAT enroute when IP packets contain realm-specific IP address or port information in payload. An ALG may be able to provide work around in some cases. But, if the packet payload is IPsec secured (or secure by a transport or application level security mechanisms), the application is bound to fail.
IPパケットにペイロード内のRealm固有のIPアドレスまたはポート情報が含まれている場合、幅広いアプリケーションがNAT Auroneで失敗します。ALGは、場合によっては回避策を提供できる場合があります。ただし、パケットペイロードがIPSecを保護する（またはトランスポートまたはアプリケーションレベルのセキュリティメカニズムによって保護されている場合）、アプリケーションは失敗する可能性があります。
Bundled session applications such as FTP, H.323, SIP and RTSP, which use a control connection to establish a data flow are also usually broken by NAT devices enroute. This is because these applications exchange address and port parameters within control session to establish data sessions and session orientations. NAT cannot know the inter-dependency of the bundled sessions and would treat each session to be unrelated to one another. Applications in this case can fail for a variety of reasons. Two most likely reasons for failures are: (a) addressing information in control payload is realm-specific and is not valid once packet crosses the originating realm, (b) control session permits data session(s) to originate in a direction that NAT might not permit.
FTP、H.323、SIP、RTSPなどのバンドルセッションアプリケーションは、コントロール接続を使用してデータフローを確立することも、通常、NATデバイスで破壊されます。これは、これらのアプリケーションがコントロールセッション内のアドレスとポートパラメーターを交換して、データセッションとセッションのオリエンテーションを確立するためです。NATはバンドルされたセッションの相互依存性を知ることができず、各セッションを互いに無関係であると扱います。この場合のアプリケーションは、さまざまな理由で失敗する可能性があります。障害の2つの最も可能性の高い理由は次のとおりです。（a）コントロールペイロードのアドレス指定は領域固有であり、パケットが発生する領域を越えても有効ではありません。許可しない。
When DNS names are used in control payload, NAT device in conjunction with a DNS-ALG might be able to offer the necessary application level transparency, if NAT has no contention with data session orientation. However, using DNS names in place of realm-specific IP addresses may not be an option to many of these applications (e.g., FTP).
DNS名がコントロールペイロードで使用される場合、DNS-ALGと併せてNATデバイスは、NATにデータセッション指向との競合がない場合、必要なアプリケーションレベルの透明性を提供できる場合があります。ただし、レルム固有のIPアドレスの代わりにDNS名を使用することは、これらのアプリケーションの多く（FTPなど）のオプションではない場合があります。
When realm-specific addressing is specified in payload, and the payload is not encrypted, an ALG may in some cases be able to provide the work around necessary to make the applications run transparently across realms. The complexity of ALG depends on the application level knowledge required to process payload and maintain state.
ペイロードでレルム固有のアドレス指定が指定され、ペイロードが暗号化されていない場合、アルグは場合によっては、アプリケーションを領域全体で透過的に実行するために必要な作業を提供できる場合があります。アルグの複雑さは、ペイロードを処理して状態を維持するために必要なアプリケーションレベルの知識に依存します。
Peer-to-peer applications more than client-server based applications are likely to break with NAT enroute. Unlike Client-server applications, Peer-to-peer applications can be originated by any of the peers. When peers are distributed across private and public realms, a session originated from an external realm is just as likely as the session from a host in private realm. External peers will be able to locate their peers in private realm only when they know the externally assigned IP address or the FQDN ahead of time. FQDN name to assigned address mapping can happen only so long as the enroute NAT device supports DNS-ALG. Examples of Peer-to-peer applications include interactive games, Internet telephony and event-based protocols (such as Instant-Messaging).
クライアントサーバーベースのアプリケーションよりもピアツーピアアプリケーションは、NAT Aunouteで壊れる可能性があります。クライアントサーバーアプリケーションとは異なり、ピアツーピアアプリケーションは、どのピアからも発信できます。ピアがプライベートおよびパブリックの領域に配布されると、外部の領域から生まれたセッションは、プライベートレルムのホストからのセッションと同じくらいありそうです。外部のピアは、外部から割り当てられたIPアドレスまたはFQDNを事前に知っている場合にのみ、個人の領域で仲間を見つけることができます。割り当てられたアドレスマッピングへのfqdn名は、entoute NatデバイスがDNS-Algをサポートしている限り、発生する可能性があります。ピアツーピアアプリケーションの例には、インタラクティブなゲーム、インターネットテレフォニー、イベントベースのプロトコル（インスタントメサージなど）が含まれます。
This is particularly a problem with traditional NAT and may be less of an issue with bi-directional NAT, where sessions are permitted in both directions.
これは特に従来のNATの問題であり、双方向NATの問題ではない場合があります。
A possible work-around for this type of problem with traditional-NAT is for private hosts to maintain an outbound connection with a server acting as their representative to the globally routed Internet.
従来のNATのこのタイプの問題の可能性のある作業は、プライベートホストがグローバルにルーティングされたインターネットの代表として機能するサーバーとのアウトバウンド接続を維持することです。
IP fragmentation with NAPT enroute is not an issue with any single application, but pervades across all TCP/UDP applications. The problem is described in detail in [NAT-TRAD]. Briefly, the problem goes as follows. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, the target host is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted.
NAPT Anoteを使用したIPフラグメンテーションは、単一のアプリケーションでは問題ではありませんが、すべてのTCP/UDPアプリケーションに浸透しています。この問題については、[NAT-Trad]で詳しく説明しています。簡単に言えば、問題は次のとおりです。たとえば、2人のプライベートホストが断片化されたTCP/UDPパケットを同じ宛先ホストに発信しました。そして、彼らはたまたま同じ断片化識別子を使用していました。ターゲットホストが同じ断片化IDを運ぶ2つの無関係なデータグラムを受信し、同じ割り当てられたホストアドレスから、ターゲットホストは、データグラムが属する2つのセッションのどれを決定できません。その結果、両方のセッションが破損します。
NAT will most likely break applications that require address mapping to be retained across contiguous sessions. These applications require the private-to-external address mapping to be retained between sessions so the same external address may be reused for subsequent session interactions. NAT cannot know this requirement and may reassign external address to different hosts between sessions.
NATは、隣接するセッション全体でアドレスマッピングを保持する必要があるアプリケーションを破る可能性が高いでしょう。これらのアプリケーションでは、プライベートからエクステルのアドレスマッピングをセッション間で保持する必要があるため、同じ外部アドレスが後続のセッションの相互作用のために再利用される可能性があります。NATはこの要件を知ることができず、セッション間で外部アドレスを異なるホストに再割り当てする場合があります。
Trying to keep NAT from discarding an address mapping would require a NAT extension protocol to the application that would allow the application to inform the NAT device to retain the mappings. Alternately, an ALG may be required to interact with NAT to keep the address mapping from being discarded by NAT.
NATがアドレスマッピングを破棄しないようにするには、アプリケーションにNAT拡張プロトコルがアプリケーションにマッピングを保持するように通知できるようにする必要があります。あるいは、ALGがNATと対話して、アドレスマッピングがNATによって破棄されないようにするために必要になる場合があります。
This is a problem when the number of private hosts is larger than the external addresses available to map the private addresses into. Take for example the rlogin service initiated from a host in private realm supported by NAPT. Rlogin service clients use well-known rlogin port 512 as their TCP port ID. No more than one host in private realm can initiate the service. This is a case of trying to use a service that fundamentally requires more public addresses than are available. NAT devices can conserve addresses, but they cannot create more addresses.
これは、プライベートホストの数が、プライベートアドレスをマップするために利用可能な外部アドレスよりも大きい場合の問題です。たとえば、NAPTにサポートされているプライベートレルムのホストから開始されたRloginサービスをご覧ください。rloginサービスクライアントは、有名なrloginポート512をTCPポートIDとして使用します。プライベートレルムのホストが1人しかいないのは、サービスを開始できます。これは、利用可能なものよりも多くの公開アドレスを根本的に必要とするサービスを使用しようとする場合です。NATデバイスはアドレスを保存できますが、より多くのアドレスを作成することはできません。
NAT fundamentally operates by modifying end node addresses (within the IP header) en-route. The IPsec AH standard [IPsec-AH] on the other hand is explicitly designed to detect alterations to IP packet header. So when NAT alters the address information enroute in IP header, the destination host receiving the altered packet will invalidate the packet since the contents of the headers have been altered. The IPsec AH secure packet traversing NAT will simply not reach the target application, as a result.
NATは、エンドノードアドレス（IPヘッダー内）を変更することにより、基本的に動作します。一方、IPSEC AH標準[IPSEC-AH]は、IPパケットヘッダーの変更を検出するために明示的に設計されています。したがって、NATがIPヘッダーのアドレス情報を変更すると、ヘッダーの内容が変更されているため、変更されたパケットを受信する宛先ホストがパケットを無効にします。その結果、IPSEC AHセキュアパケットトラバースNATは、ターゲットアプリケーションに到達しません。
IPsec ESP ([IPsec-ESP]) encrypted packets may be altered by NAT device enroute only in a limited number of cases. In the case of TCP/UDP packets, NAT would need to update the checksum in TCP/UDP headers, when an address in IP header is changed. However, as the TCP/UDP header is encrypted by the ESP, NAT would not be able to make this checksum update. As a result, TCP/UDP packets encrypted in transport mode ESP, traversing a NAT device will fail the TCP/UDP checksum validation on the receiving end and will simply not reach the target application.
IPSEC ESP（[IPSEC-ESP]）暗号化されたパケットは、限られた数のケースでのみNATデバイスが変更することができます。TCP/UDPパケットの場合、NATは、IPヘッダーのアドレスが変更されたときに、TCP/UDPヘッダーのチェックサムを更新する必要があります。ただし、TCP/UDPヘッダーはESPによって暗号化されるため、NATはこのチェックサムの更新を行うことができません。その結果、トランスポートモードESPで暗号化されたTCP/UDPパケットは、NATデバイスを移動すると、受信側でのTCP/UDPチェックサム検証に失敗し、ターゲットアプリケーションに到達しません。
Internet Key Exchange Protocol IKE can potentially pass IP addresses as node identifiers during Main, Aggressive and Quick Modes. In order for an IKE negotiation to correctly pass through a NAT, these payloads would need to be modified. However, these payloads are often protected by hash or obscured by encryption. Even in the case where IP addresses are not used in IKE payloads and an IKE negotiation could occur uninterrupted, there is difficulty with retaining the private-to-external address mapping on NAT from the time IKE completed negotiation to the time IPsec uses the key on an application. In the end, the use of end-to-end IPsec is severely hampered anyway, as described earlier.
インターネットキーエクスチェンジプロトコルIKEは、メイン、アグレッシブ、クイックモードの間に、IPアドレスをノード識別子として渡す可能性があります。IKEの交渉がNATを正しく通過するためには、これらのペイロードを変更する必要があります。ただし、これらのペイロードは、しばしばハッシュによって保護されているか、暗号化によって不明瞭になります。IKEアドレスがIKEペイロードで使用されておらず、IKEの交渉が途切れることなく発生する可能性がある場合でも、IKESがIPSECがキーを使用する時までの交渉を完了した時からNATのプライベートからエクステルタナルアドレスマッピングを保持することは困難です。アプリケーション。最終的に、前述のように、とにかくエンドツーエンドのIPSECの使用はとにかくひどく妨げられています。
For all practical purposes, end-to-end IPsec is impossible to accomplish with NAT enroute.
すべての実用的な目的のために、エンドツーエンドのIPSECはNAT Onouteで達成することは不可能です。
Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be written. When the KDC receives a ticket request, it includes the source IP address in the returned ticket. Not all Kerberos 4 services actually check source IP addresses. AFS is a good example of a Kerberos 4 service which does not. Services which don't check are not picky about NAT devices enroute. Kerberos tickets are tied to the IP address that requested the ticket and the service with which to use the ticket.
Kerberos 4チケットは暗号化されています。したがって、アルグを書き込むことはできません。KDCがチケットリクエストを受信すると、返されたチケットにソースIPアドレスが含まれます。すべてのKerberos 4サービスが実際にソースIPアドレスをチェックするわけではありません。AFSは、Kerberos 4サービスの良い例です。チェックしていないサービスは、natデバイスを介してうるさいことはありません。Kerberosのチケットは、チケットを要求したIPアドレスと、チケットを使用するサービスと結び付けられています。
The K4 ticket (response) contains a single IP address describing the interface used by the client to retrieve the ticket from the TGT from the perspective of KDC. This works fine if the KDC is across a NAT gateway and as long as all of the Kerberos services are also across a NAT gateway. The end user on private network will not notice any problems.
K4チケット（応答）には、KDCの観点からTGTからチケットを取得するためにクライアントが使用するインターフェイスを説明する単一のIPアドレスが含まれています。KDCがNATゲートウェイを越えており、すべてのKerberosサービスもNATゲートウェイ全体にある限り、これは正常に機能します。プライベートネットワーク上のエンドユーザーは問題に気付かない。
There is also the caveat that NAT uses the same address mapping for the private host for the connection between the client and the KDC as for the connection between the client and the application server. A work around this problem would be to keep an arbitrary connection open to remote server during throughout the ticket lifetime, so as not to let NAT drop the address binding. Alternately, an ALG will need to be deployed to ensure that NAT would not change address bindings during the lifetime of a ticket and between the time a ticket is issued to private host and the time the ticket is used by private host.
また、クライアントとアプリケーションサーバー間の接続と同じように、クライアントとKDCの間の接続に、NATがプライベートホストに同じアドレスマッピングを使用するという注意もあります。この問題をめぐる作業は、NATがアドレスのバインディングをドロップさせないように、チケットの生涯を通じて任意の接続をリモートサーバーに開いたままにすることです。あるいは、NATがチケットの寿命の間にアドレスバインディングを変更しないようにして、チケットがプライベートホストに発行されるまで、チケットがプライベートホストによって使用されるまでに、ALGを展開する必要があります。
But, the ticket will be valid from any host within the private realm of NAPT. Without NAPT, an attacker needs to be able to spoof the source IP addresses of a connection that is being made in order to use a stolen ticket on a different host. With NAPT, all the attacker needs to do from the private realm of NAPT is to simply gain possession of a ticket. Of course, this assumes, NAPT private domain is not a trusted network - not surprisingly, since many attacks occur from inside the organization.
ただし、チケットは、NAPTのプライベート領域内のホストから有効になります。NAPTがなければ、攻撃者は、別のホストで盗まれたチケットを使用するために、接続されている接続のソースIPアドレスをスプーフィングできる必要があります。NAPTを使用すると、NAPTのプライベート領域から攻撃者が行う必要があるすべての攻撃者は、単にチケットを所有することです。もちろん、これは、NAPTプライベートドメインは信頼できるネットワークではないと仮定します - 組織内から多くの攻撃が発生するため、驚くことではありません。
Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be written.
Kerberos 4と同様に、Kerberos 5のチケットが暗号化されています。したがって、アルグを書き込むことはできません。
In Kerberos 5, the client specifies a list of IP addresses which the ticket should be valid for, or it can ask for a ticket valid for all IP addresses. By asking for an all-IP-addresses ticket or a ticket containing the NAPT device address, you can get krb5 to work with an NAPT device, although it isn't very transparent (it requires the clients to behave differently than they otherwise would). The MIT krb5 1.0 implementation didn't have any configurability for what IP addresses the client asked for (it always asked for the set of its interface addresses) and did not interact well with NAT. The MIT krb5 1.1 implementation allows you to put "noaddresses" somewhere in krb5.conf to request all-IP-addresses-valid tickets.
Kerberos 5では、クライアントはチケットの有効なIPアドレスのリストを指定したり、すべてのIPアドレスに有効なチケットを要求することもできます。All-IP-AddressesチケットまたはNAPTデバイスアドレスを含むチケットを要求することにより、KRB5をNAPTデバイスで動作させることができますが、それはあまり透明ではありません（他の方法とは異なる動作をする必要があります）。MIT KRB5 1.0の実装には、クライアントが要求したIPアドレス（常にインターフェイスアドレスのセットを要求した）の構成可能性がなく、NATとうまくやり取りしませんでした。MIT KRB5 1.1実装により、krb5.confのどこかに「noadresses」を配置して、すべてのIPアドレス - バリッドチケットを要求できます。
The K5 ticket (response) contains IP addresses, as requested by the client node, from which the ticket is to be considered valid. If the services being accessed with Kerberos authentication are on the public side of the NAT, then the Kerberos authentication will fail because the IP address used by the NAT (basic NAT or NAPT) is not in the list of acceptable addresses.
K5チケット（応答）には、クライアントノードが要求するIPアドレスが含まれており、チケットは有効と見なされます。Kerberos認証でアクセスされるサービスがNATのパブリック側にある場合、NAT（Basic NATまたはNAPT）が使用するIPアドレスが許容可能なアドレスのリストにないため、Kerberos認証は失敗します。
There are two workarounds in Kerberos 5 both of which reduce the security of the tickets. The first is to have the clients in NAPT private realm specify the public IP address of the NAPT in the ticket's IP list. But this leads to the same security problem detailed for K4. Plus, it is not obvious for the client in the private domain to find out the public IP Address of the NAPT. That would be a change of application behavior on end-host.
Kerberos 5には2つの回避策があり、どちらもチケットのセキュリティを減らしています。1つ目は、NAPTプライベートレルムのクライアントに、チケットのIPリストでNAPTのパブリックIPアドレスを指定することです。しかし、これはK4について詳述されている同じセキュリティ問題につながります。さらに、プライベートドメインのクライアントがNAPTのパブリックIPアドレスを見つけることは明らかではありません。それは、エンドホストのアプリケーション動作の変更になります。
The second method is to remove all IP addresses from the K5 tickets but this now makes theft of the ticket even worse since the tickets can be used from anywhere. Not just from within the private network.
2番目の方法は、K5チケットからすべてのIPアドレスを削除することですが、これにより、チケットはどこからでも使用できるため、チケットの盗難がさらに悪化します。 プライベートネットワーク内からだけではありません。
The X Windowing system is TCP based. However, the client-server relationship with these applications is reverse compared to most other applications. The X server or Open-windows server is the display/mouse/keyboard unit (i.e., the one that controls the actual Windows interface). The clients are the application programs driving the Windows interface.
XウィンドウシステムはTCPベースです。ただし、これらのアプリケーションとのクライアントサーバーの関係は、他のほとんどのアプリケーションと比較して逆です。XサーバーまたはOpen-Windowsサーバーは、ディスプレイ/マウス/キーボードユニット（つまり、実際のWindowsインターフェイスを制御するユニット）です。クライアントは、Windowsインターフェイスを推進するアプリケーションプログラムです。
Some machines run multiple X Windows servers on the same machine. The first X Windows server is at TCP port 6000. The first Open Windows server can be at port 6000 or port 2000 (more flexible). We will mainly refer X windowing system for illustration purposes here.
一部のマシンは、同じマシンで複数のX Windowsサーバーを実行します。最初のX WindowsサーバーはTCPポート6000にあります。最初のオープンWindowsサーバーは、ポート6000またはポート2000（より柔軟）にあります。ここでは、イラストの目的については、主にXウィンドウシステムを参照します。
X-term Transmits IP addresses from the client to the server for the purpose of setting the DISPLAY variable. When set the DISPLAY variable is used for subsequent connections from X clients on the host to an X server on the workstation. The DISPLAY variable is sent inline during the TELNET negotiations as
X-Termは、表示変数を設定する目的で、クライアントからサーバーにIPアドレスを送信します。設定すると、ディスプレイ変数は、ホストのXクライアントからワークステーションのXサーバーへの後続の接続に使用されます。ディスプレイ変数は、Telnet交渉中にインラインで送信されます。
DISPLAY=<local-ip-addr>:<server>.<display>
where the <local-ip-addr> is retrieved by looking at the local ip address associated with the socket used to connect to <server>. The <server> determines which port (6000 + <server>) should be used to make the connection. <display> is used to indicate which monitor attached to the X server should be used but is not important to this discussion.
ここで、<local-ip-addr>は、<server>に接続するために使用されるソケットに関連付けられているローカルIPアドレスを調べることにより取得されます。<server>は、接続を行うために使用するポート（6000 <server>）を決定します。<display>は、Xサーバーに接続されているモニターを使用する必要があることを示すために使用されますが、この議論にとって重要ではありません。
The <local-ip-addr> used is not a DNS name because:
使用されている<local-ip-addr>は、次の理由でDNS名ではありません。
. The is no ability for the local machine to know its DNS name without performing a reverse DNS lookup on the local-ip-addr
。ローカルマシンがローカルIP-ADDRで逆DNSルックアップを実行せずにDNS名を知る能力はありません
. There is no guarantee that the name returned by a reverse DNS lookup actually maps back to the local IP address.
。逆DNSルックアップによって返された名前が実際にローカルIPアドレスにマッピングされるという保証はありません。
. Lastly, without DNSSEC, it may not be safe to use DNS addresses because they can easily be spoofed. NAT and DNS-ALG cannot work unless DNSSEC is disabled.
。最後に、DNSSECがなければ、DNSアドレスを簡単にスプーフィングできるため、DNSアドレスを使用しても安全ではない場合があります。DNSSECが無効になっていない限り、NATとDNS-ALGは機能しません。
A common use of this application is people dialing in to corporate offices from their X terminals at home. Say, the X client is running on a host on the public side of the NAT and X server is running on a host on the private side of the NAT. The DISPLAY variable is transmitted inline to the host the X client is running in some way. The process transmitting the contents of the DISPLAY variable does not know the address of the NAT.
このアプリケーションの一般的な使用は、自宅のX端子からコーポレートオフィスにダイヤルインする人々です。たとえば、XクライアントはNATのパブリック側のホストで実行されており、XサーバーはNATのプライベート側のホストで実行されています。ディスプレイ変数は、Xクライアントが何らかの方法で実行されているホストにインラインで送信されます。ディスプレイ変数の内容を送信するプロセスでは、NATのアドレスがわかりません。
If the channel transmitting the DISPLAY variable is not encrypted, NAT device might solicit the help of an ALG to replace the IP address and configure a port in the valid display range (ports 6000 and higher) to act as a gateway. Alternately, NAT may be configured to listen for incoming connections to provide access to the X Server(s), without requiring an ALG. But, this approach increases the security risk by providing access to the X server that would not otherwise be available. As the ALG tampers with the IP addresses it will also not be possible for X Authorization methods other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the least secure of all the documented X Authorization methods.
ディスプレイ変数を送信するチャネルが暗号化されていない場合、NATデバイスはALGのヘルプを募集して、IPアドレスを交換し、有効なディスプレイ範囲（ポート6000以降）でポートを構成してゲートウェイとして機能する場合があります。あるいは、ALGを必要とせずに、Xサーバーへのアクセスを提供するために、着信接続をリッスンするようにNATを構成することができます。しかし、このアプローチは、それ以外の場合は利用できないXサーバーへのアクセスを提供することにより、セキュリティリスクを高めます。IPアドレスを備えたアルグはタンパーであるため、MIT-Magic-Cookie-1以外のX承認方法を使用することもできません。MIT-Magic-Cookie-1は、文書化されたすべてのX承認方法の中で最も安全ではありません。
When START_TLS is used there may be client certificate verification problems caused by the NAT depending on the information provided in the certificate.
start_tlsを使用すると、証明書に記載されている情報に応じて、NATによって引き起こされるクライアント証明書検証の問題があります。
RSH uses multiple sessions to support separate streams for stdout and stderr. A random port number is transmitted inline from the client to the server for use as stderr port. The stderr socket is a connection back from the server to the client. And unlike FTP, there is no equivalent to PASV mode. For traditional NAT, this is a problem as traditional NAT would not permit incoming sessions.
RSHは複数のセッションを使用して、STDOUTとSTDERRの個別のストリームをサポートします。ランダムなポート番号は、STDERRポートとして使用するために、クライアントからサーバーにインラインで送信されます。STDERRソケットは、サーバーからクライアントへの接続です。FTPとは異なり、PASVモードに相当するものはありません。従来のNATの場合、これは従来のNATが着信セッションを許可しないため問題です。
RLOGIN does not use multiple sessions. But the Kerberos protected versions of RSH and RLOGIN will not work in a NAT environment due to the ticket problems and the use of multiple sessions.
Rloginは複数のセッションを使用しません。しかし、RSHとRloginのKerberos保護バージョンは、チケットの問題と複数のセッションの使用により、NAT環境では機能しません。
This document predominantly addresses problems associated with Traditional NAT, especially NAPT.
このドキュメントは、主に従来のNAT、特にNAPTに関連する問題に対処しています。
FTP is a TCP based application, used to reliably transfer files between two hosts. FTP uses bundled session approach to accomplish this.
FTPはTCPベースのアプリケーションであり、2つのホスト間でファイルを確実に転送するために使用されます。FTPは、バンドルされたセッションアプローチを使用してこれを達成します。
FTP is initiated by a client accessing a well-known port number 21 on the FTP server. This is called the FTP control session. Often, an additional data session accompanies the control session. By default, the data session would be from TCP port 20 on server to the TCP port client used to initiate control session. However, the data session ports may be altered within the FTP control sessions using ASCII encoded PORT and PASV commands and responses.
FTPは、FTPサーバーで有名なポート番号21にアクセスするクライアントによって開始されます。これは、FTPコントロールセッションと呼ばれます。多くの場合、追加のデータセッションがコントロールセッションに付随します。デフォルトでは、データセッションは、サーバー上のTCPポート20からコントロールセッションの開始に使用されるTCPポートクライアントまでです。ただし、データセッションポートは、ASCIIエンコードされたポートおよびPASVコマンドと応答を使用して、FTP制御セッション内で変更される場合があります。
Say, an FTP client is in a NAT supported private network. An FTP ALG will be required to monitor the FTP control session (for both PORT and PASV modes) to identify the FTP data session port numbers and modify the private address and port number with the externally valid address and port number. In addition, the sequence and acknowledgement numbers, TCP checksum, IP packet length and checksum have to be updated. Consequently the sequence numbers in all subsequent packets for that stream must be adjusted as well as TCP ACK fields and checksums.
たとえば、FTPクライアントはNATサポートされているプライベートネットワークにあります。FTPコントロールセッション（ポートモードとPASVモードの両方）を監視して、FTPデータセッションポート番号を識別し、外部有効なアドレスとポート番号を使用してプライベートアドレスとポート番号を変更するには、FTPアルグが必要です。さらに、シーケンスと確認番号、TCPチェックサム、IPパケットの長さ、チェックサムを更新する必要があります。したがって、そのストリームの後続のすべてのパケットのシーケンス番号は、TCP ACKフィールドとチェックサムと同様に調整する必要があります。
In rare cases, increasing the size of the packet could cause it to exceed the MTU of a given transport link. The packet would then have to be fragmented which could affect performance. Or, if the packet has the DF bit set, it would be ICMP rejected and the originating host would then have to perform Path MTU Discovery. This could have an adverse effect on performance.
まれに、パケットのサイズを大きくすると、特定の輸送リンクのMTUを超える可能性があります。その後、パフォーマンスに影響を与える可能性のあるパケットを断片化する必要があります。または、パケットにDFビットが設定されている場合、ICMPが拒否され、元のホストがPATH MTU発見を実行する必要があります。これはパフォーマンスに悪影響を与える可能性があります。
Note however, if the control command channel is secured, it will be impossible for an ALG to update the IP addresses in the command exchange.
ただし、コントロールコマンドチャネルが保護されている場合、アルグがコマンド交換でIPアドレスを更新することは不可能です。
When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same problems that occur with X-Term/Telnet occur with FTP.
Kerberos 4、Kerberos 5、およびTLSで認証が使用されると、Xターム/Telnetで発生するのと同じ問題がFTPで発生します。
Lastly, it is of interest to note section 4 of RFC 2428 (FTP extensions for IPv6 and NATs) which describes how a new FTP port command (EPSV ALL) can be used to allow NAT devices to fast-track the FTP protocol, eliminating further processing through ALG, if the remote server accepts "EPSV ALL".
最後に、新しいFTPポートコマンド（EPSV ALL）を使用してNATデバイスがFTPプロトコルをファストトラックできるようにする方法を説明するRFC 2428のセクション4（IPv6およびNATのFTP拡張）に注意することは興味深いです。リモートサーバーが「すべて」を受け入れる場合、アルグを介した処理。
RSVP is positioned in the protocol stack at the transport layer, operating on top of IP (either IPv4 or IPv6). However, unlike other transport protocols, RSVP does not transport application data but instead acts like other Internet control protocols (for example, ICMP, IGMP, routing protocols). RSVP messages are sent hop-by-hop between RSVP-capable routers as raw IP datagrams using protocol number 46. It is intended that raw IP datagrams should be used between the end systems and the first (or last) hop router. However, this may not always be possible as not all systems can do raw network I/O. Because of this, it is possible to encapsulate RSVP messages within UDP datagrams for end-system communication. UDP-encapsulated RSVP messages are sent to either port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP-enabled router). For more information concerning UDP encapsulation of RSVP messages; consult Appendix C of RFC 2205.
RSVPは、IP（IPv4またはIPv6のいずれか）の上で動作する輸送層のプロトコルスタックに配置されます。ただし、他の輸送プロトコルとは異なり、RSVPはアプリケーションデータを輸送するのではなく、他のインターネット制御プロトコル（たとえば、ICMP、IGMP、ルーティングプロトコル）のように機能します。RSVPメッセージは、プロトコル番号46を使用して、RSVP対応のルーター間で生のIPデータグラムとしてホップバイホップを送信します。これは、生のIPデータグラムをエンドシステムと最初の（または最後の）ホップルーター間で使用することを意図しています。ただし、すべてのシステムがRaw Network I/Oを実行できるわけではないため、これは常に可能ではない場合があります。このため、UDPデータグラム内のRSVPメッセージをカプセル化して、エンドシステム通信をカプセル化することができます。UDPでカプセル化されたRSVPメッセージは、ポート1698（エンドシステムによって送信される場合）またはポート1699（RSVP対応ルーターによって送信される場合）に送信されます。RSVPメッセージのUDPカプセル化に関する詳細については。RFC 2205の付録Cを参照してください。
An RSVP session, a data flow with a particular destination and transport-layer protocol, is defined by:
特定の宛先と輸送層プロトコルを備えたデータフローであるRSVPセッションは、次のように定義されます。
Destination Address - the destination IP address for the data packets. This may be either a unicast or a multicast address.
宛先アドレス - データパケットの宛先IPアドレス。これは、ユニキャストまたはマルチキャストアドレスのいずれかです。
Protocol ID - the IP protocol ID (for example, UDP or TCP).
プロトコルID -IPプロトコルID（たとえば、UDPまたはTCP）。
Destination Port - a generalized destination port that is used for demultiplexing at a layer above the IP layer.
宛先ポート - IPレイヤーの上のレイヤーで非gultiplexを使用するために使用される一般化された宛先ポート。
NAT devices are presented with unique problems when it comes to supporting RSVP. Two issues are:
NATデバイスには、RSVPをサポートすることに関して、独自の問題が提示されます。2つの問題は次のとおりです。
1. RSVP message objects may contain IP addresses. The result is that an RSVP-ALG must be able to replace the IP addresses based upon the direction and type of the message. For example, if an external sender were to send an RSVP Path message to an internal receiver, the RSVP session will specify the IP address that the external sender believes is the IP address of the internal receiver. However, when the RSVP Path message reaches the NAT device, the RSVP session must be changed to reflect the IP address that is used internally for the receiver. Similar actions must be taken for all message objects that contain IP addresses.
1. RSVPメッセージオブジェクトにはIPアドレスが含まれている場合があります。その結果、RSVP-ALGは、メッセージの方向とタイプに基づいてIPアドレスを交換できる必要があります。たとえば、外部送信者がRSVPパスメッセージを内部レシーバーに送信する場合、RSVPセッションは、外部送信者が内部レシーバーのIPアドレスであると考えているIPアドレスを指定します。ただし、RSVPパスメッセージがNATデバイスに到達すると、RSVPセッションを変更して、受信者に内部で使用されるIPアドレスを反映する必要があります。IPアドレスを含むすべてのメッセージオブジェクトについて、同様のアクションを実行する必要があります。
2. RSVP provides a means, the RSVP Integrity object, to guarantee the integrity of RSVP messages. The problem is that because of the first point, a NAT device must be able to change IP addresses within the RSVP messages. However, when this is done, the RSVP Integrity object is no longer valid as the RSVP message has been changed. Therefore an RSVP-ALG will not work when RSVP Integrity Object is used.
2. RSVPは、RSVPメッセージの整合性を保証する手段、RSVP整合性オブジェクトを提供します。問題は、最初のポイントのために、NATデバイスはRSVPメッセージ内のIPアドレスを変更できる必要があることです。ただし、これが完了すると、RSVPメッセージが変更されたため、RSVP整合性オブジェクトはもはや有効です。したがって、RSVP Integrityオブジェクトが使用される場合、RSVP-Algは機能しません。
DNS is a TCP/UDP based protocol. Domain Names are an issue for hosts which use local DNS servers in NAT private realm. DNS name to address mapping for hosts in private domain should be configured on an authoritative name server within private domain. This server would be accessed by external and internal hosts alike for name resolutions. A DNS-ALG would be required to perform address to name conversions on DNS queries and responses. [DNS-ALG] describes DNS-ALG in detail. If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG will fail because it won't be able to perform payload modifications.
DNSはTCP/UDPベースのプロトコルです。ドメイン名は、NATプライベートレルムのローカルDNSサーバーを使用するホストの問題です。プライベートドメイン内のホストのマッピングにアドレス指定するDNS名は、プライベートドメイン内の信頼できる名前サーバーで構成する必要があります。このサーバーは、名前の解決策のために外部ホストと内部ホストが同様にアクセスします。DNS-ALGは、DNSクエリと応答の名前のコンバージョンにアドレスを実行する必要があります。[DNS-Alg]はDNS-Algを詳細に説明しています。DNSパケットがDNSSECごとに暗号化/認証されている場合、ペイロード変更を実行できないためDNS_ALGは失敗します。
Applications using DNS resolver to resolve a DNS name into an IP address, assume availability of address assignment for reuse by the application specific session. As a result, DNS-ALG will be required to keep the address assignment (between private and external addresses) valid for a pre-configured period of time, past the DNS query.
DNSリゾルバーを使用してDNS名をIPアドレスに解決するアプリケーションは、アプリケーション固有のセッションで再利用するためのアドレス割り当ての可用性を想定しています。その結果、DNS-Algは、DNSクエリを過ぎて、事前に構成された期間にわたってアドレス割り当て（プライベートアドレスと外部アドレスの間）を有効に保つために必要です。
Alternately, if there isn't a need for a name server within private domain, private domain hosts could simply point to an external name server for external name lookup. No ALG is required when the name server is located in external domain.
代わりに、プライベートドメイン内の名前サーバーが必要でない場合、プライベートドメインホストは、外部名検索のために外部名サーバーを単に指すことができます。名前サーバーが外部ドメインにある場合、アルグは必要ありません。
SMTP is a TCP based protocol ([SMTP]), used by Internet email programs such as sendmail to send TCP-based email messages to well-known port 25. The mail server may be located within or outside private domain. But, the server must be assigned a global name and address, accessible by external hosts. When mail server is located within private domain, inbound SMTP sessions must be redirected to the private host from its externally assigned address. No special mapping is required when Mail server is located in external domain.
SMTPは、TCPベースの電子メールプログラムで使用されるTCPベースのプロトコル（[SMTP]）です。TCPベースの電子メールメッセージを有名なポート25に送信するためのインターネット電子メールプログラムが使用されます。メールサーバーは、プライベートドメイン内または外側に配置できます。 ただし、サーバーには、外部ホストがアクセスできるグローバル名とアドレスを割り当てる必要があります。 メールサーバーがプライベートドメイン内にある場合、インバウンドSMTPセッションは、外部に割り当てられたアドレスからプライベートホストにリダイレクトする必要があります。 メールサーバーが外部ドメインにある場合、特別なマッピングは必要ありません。
Generally speaking, mail systems are configured such that all users specify a single centralized address (such as fooboo@company.com), instead of including individual hosts (such as fooboo@hostA.company.com). The central address must have an MX record specified in the DNS name server accessible by external hosts.
一般的に、メールシステムは、個々のホスト（fooboo@hosta.company.comなど）を含める代わりに、すべてのユーザーが単一の集中アドレス（fooboo@company.comなど）を指定するように構成されています。中央アドレスには、外部ホストがアクセスできるDNSネームサーバーで指定されたMXレコードが必要です。
In the majority of cases, mail messages do not contain reference to private IP addresses or links to content data via names that are not visible to outside. However, some mail messages do contain IP addresses of the MTAs that relay the message in the "Received: " field. Some mail messages use IP addresses in place of FQDN for debug purposes or due to lack of a DNS record, in "Mail From: " field.
ほとんどの場合、メールメッセージには、外部に表示されていない名前を介して、プライベートIPアドレスまたはコンテンツデータへのリンクへの参照は含まれていません。ただし、一部のメールメッセージには、「受信」フィールドのメッセージを中継するMTAのIPアドレスが含まれています。一部のメールメッセージでは、DEBUGの目的でFQDNの代わりに、またはDNSレコードが不足しているため、「Mail From：」フィールドを使用しています。
If one or more MTAs were to be located behind NAT in a private domain, and the mail messages are not secured by signature or cryptographic keys, an SMTP-ALG may be used to translate the IP address information registered by the MTAs. If the MTAs have static address mapping, the translation would be valid across realms for long periods of time.
1つ以上のMTAがプライベートドメインのNATの後ろに配置され、メールメッセージが署名キーまたは暗号化キーによって保護されていない場合、MTAが登録したIPアドレス情報を変換するためにSMTP-ALGを使用できます。MTAに静的アドレスマッピングがある場合、翻訳は長期間レルム全体で有効になります。
The ability to trace the mail route may be hampered or prevented by NAT alone, without the ALG. This can cause problems when debugging mail problems or tracking down abusive users of mail.
メールルートをトレースする機能は、ALGなしでNATのみによって妨害または防止される場合があります。これは、メールの問題をデバッグしたり、メールの虐待的なユーザーを追跡したりするときに問題を引き起こす可能性があります。
SIP (Refer [SIP]) can run on either TCP or UDP, but by default on the same port 5060.
SIP（参照[SIP]）は、TCPまたはUDPで実行できますが、デフォルトでは同じポート5060で実行できます。
When used with UDP, a response to a SIP request does not go to the source port the request came from. Rather the SIP message contains the port number the response should be sent to. SIP makes use of ICMP port unreachable errors in the response to request transmissions. Request messages are usually sent on the connected socket. If responses are sent to the source port in the request, each thread handling a request would have to listen on the socket it sent the request on. However, by allowing responses to come to a single port, a single thread can be used for listening instead.
UDPで使用する場合、SIPリクエストへの応答は、リクエストが発生したソースポートに送信されません。むしろ、SIPメッセージには、応答が送信されるポート番号が含まれています。SIPは、要求送信への応答にICMPポートの到達不可能なエラーを使用します。リクエストメッセージは通常、接続されたソケットに送信されます。リクエストで応答がソースポートに送信された場合、リクエストを処理する各スレッドがソケットで聞く必要があります。ただし、応答が単一のポートに到達できるようにすることにより、代わりにリスニングに単一のスレッドを使用できます。
A server may prefer to place the source port of each connected socket in the message. Then each thread can listen for responses separately. Since the port number for a response may not go to the source port of the request, SIP will not normally traverse a NAT and would require a SIP-ALG.
サーバーは、各接続ソケットのソースポートをメッセージ内に配置することを好む場合があります。その後、各スレッドは応答を個別に聞くことができます。応答のポート番号はリクエストのソースポートに移動しない可能性があるため、SIPは通常NATを横断せず、SIP-Algを必要とします。
SIP messages carry arbitrary content, which is defined by a MIME type. For multimedia sessions, this is usually the Session Description Protocol (SDP RFC 2327). SDP may specify IP addresses or ports to be used for the exchange of multimedia. These may loose significance when traversing a NAT. Thus a SIP-ALG would need the intelligence to decipher and translate realm-relevant information.
SIPメッセージには、MIMEタイプで定義される任意のコンテンツがあります。マルチメディアセッションの場合、これは通常、セッション説明プロトコル（SDP RFC 2327）です。SDPは、マルチメディアの交換に使用するIPアドレスまたはポートを指定する場合があります。これらは、NATを横断するときに重要性を失う可能性があります。したがって、SIP-Algは、レルム関連情報を解読および翻訳するためのインテリジェンスが必要です。
SIP carries URL's in its Contact, To and From fields that specify signaling addresses. These URL's can contain IP addresses or domain names in the host port portion of the URL. These may not be valid once they traverse a NAT.
SIPは、シグナリングアドレスを指定するフィールドとの間で、接触中にURLを運びます。これらのURLには、URLのホストポート部分にIPアドレスまたはドメイン名を含めることができます。これらは、NATを横断すると有効ではない場合があります。
As an alternative to an SIP-ALG, SIP supports a proxy server which could co-reside with NAT and function on the globally significant NAT port. Such a proxy would have a locally specific configuration.
SIP-Algの代替として、SIPは、グローバルに重要なNATポートでNATと機能することができるプロキシサーバーをサポートします。このようなプロキシには、局所的に特定の構成があります。
In default mode, RealAudio clients (say, in a private domain) access TCP port 7070 to initiate conversation with a real-audio server (say, located an external domain) and to exchange control messages during playback (ex: pausing or stopping the audio stream). Audio session parameters are embedded in the TCP control session as byte stream.
デフォルトモードでは、RealAudioクライアント（プライベートドメインなど）アクセスTCPポート7070にアクセスして、Real-Audioサーバーとの会話を開始し（たとえば、外部ドメインを配置）、再生中にコントロールメッセージを交換します（Ex：停止またはオーディオの停止ストリーム）。オーディオセッションパラメーターは、TCP制御セッションにバイトストリームとして埋め込まれています。
The actual audio traffic is carried in the opposite direction on incoming UDP based packets (originated from the server) directed to ports in the range of 6970-7170.
実際のオーディオトラフィックは、6970-7170の範囲でポートに向けられた、着信UDPベースのパケット（サーバーから発信された）で反対方向に運ばれます。
As a result, RealAudio is broken by default on a traditional NAT device. A work around for this would be for the ALG to examine the TCP traffic to determine the audio session parameters and selectively enable inbound UDP sessions for the ports agreed upon in the TCP control session. Alternately, the ALG could simply redirect all inbound UDP sessions directed to ports 6970-7170 to the client address in the private domain.
その結果、RealAudioは従来のNATデバイスでデフォルトで破損しています。これの回避は、ALGがTCPトラフィックを調べてオーディオセッションパラメーターを決定し、TCP制御セッションで合意したポートのインバウンドUDPセッションを選択的に有効にすることです。あるいは、ALGは、ポート6970-7170に向けられたすべてのインバウンドUDPセッションをプライベートドメインのクライアントアドレスにリダイレクトすることができます。
For bi-Directional NAT, you will not need an ALG. Bi-directional NAT could simply treat each of the TCP and UDP sessions as 2 unrelated sessions and perform IP and TCP/UDP header level translations.
双方向NATの場合、アルグは必要ありません。Bi-Direectional Natは、TCPおよびUDPセッションのそれぞれを2つの無関係なセッションとして単純に扱い、IPおよびTCP/UDPヘッダーレベルの翻訳を実行できます。
The readers may contact RealNetworks for detailed guidelines on how their applications can be made to work, traversing through NAT and firewall devices.
読者は、RealNetworksに、アプリケーションの動作をどのように作成できるかについての詳細なガイドラインについて、NATおよびファイアウォールデバイスを通過することができます。
H.323 is complex, uses dynamic ports, and includes multiple UDP streams. Here is a summary of the relevant issues:
H.323は複雑で、動的ポートを使用し、複数のUDPストリームが含まれています。関連する問題の要約は次のとおりです。
An H.323 call is made up of many different simultaneous connections. At least two of the connections are TCP. For an audio-only conference, there may be up to 4 different UDP 'connections' made.
H.323コールは、さまざまな同時接続で構成されています。少なくとも2つの接続はTCPです。オーディオのみの会議では、最大4つの異なるUDP「接続」が行われる可能性があります。
All connections except one are made to ephemeral (dynamic) ports.
1つを除くすべての接続は、一時的な（動的）ポートに作成されます。
Calls can be initiated from the private as well as the external domain. For conferencing to be useful, external users need to be able to establish calls directly with internal users' desktop systems.
通話は、プライベートおよび外部ドメインから開始できます。会議が役立つためには、外部ユーザーが内部ユーザーのデスクトップシステムで直接通話を確立できる必要があります。
The addresses and port numbers are exchanged within the data stream of the 'next higher' connection. For example, the port number for the H.245 connection is established within the Q.931 data stream. (This makes it particularly difficult for the ALG, which will be required to modify the addresses inside these data streams.) To make matters worse, it is possible in Q.931, for example, to specify that the H.245 connection should be secure (encrypted). If a session is encrypted, it is impossible for the ALG to decipher the data stream, unless it has access to the shared key.
アドレスとポート番号は、「次の高」接続のデータストリーム内で交換されます。たとえば、H.245接続のポート番号は、Q.931データストリーム内に確立されます。（これにより、これらのデータストリーム内のアドレスを変更するために必要なアルグにとって特に困難になります。）さらに悪いことに、Q.931では、たとえば、H.245接続があるはずであることを指定することが可能です。セキュア（暗号化）。セッションが暗号化されている場合、共有キーにアクセスしない限り、ALGがデータストリームを解読することは不可能です。
Most of the control information is encoded in ASN.1 (only the User-User Information within Q.931 Protocol Data Units, or PDUs, is ASN.1-encoded (other parts of each Q.931 PDU are not encoded). For those unfamiliar with ASN.1, suffice it to say that it is a complex encoding scheme, which does not end up with fixed byte offsets for address information. In fact, the same version of the same application connecting to the same destination may negotiate to include different options, changing the byte offsets.
ほとんどの制御情報はasn.1にエンコードされています（q.931プロトコルデータユニット内のユーザーユーザー情報のみ、またはpdusはasn.1エンコードされています（各q.931 pduの他の部分はエンコードされていません）。asn.1に不慣れな人は、それが複雑なエンコードスキームであると言うだけで十分です。これはアドレス情報の固定バイトオフセットではありません。実際、同じアプリケーションに接続する同じアプリケーションの同じバージョンが交渉する場合があります。さまざまなオプションを含め、バイトオフセットを変更します。
Below is the protocol exchange for a typical H.323 call between User A and User B. A's IP address is 88.88.88.88 and B's IP address is 99.99.99.99. Note that the Q.931 and H.245 messages are encoded in ASN.1 in the payload of an RTP packet. So to accomplish a connection through a NAT device, an H.323-ALG will be required to examine the packet, decode the ASN.1, and translate the various H.323 control IP addresses.
以下は、ユーザーAとユーザーBの間の典型的なH.323コールのプロトコル交換です。AのIPアドレスは88.88.88.88で、BのIPアドレスは99.99.99.99です。Q.931およびH.245メッセージは、RTPパケットのペイロードでASN.1にエンコードされていることに注意してください。したがって、NATデバイスを介して接続を達成するには、パケットを調べ、ASN.1をデコードし、さまざまなH.323コントロールIPアドレスを翻訳するためにH.323-ALGが必要になります。
User A User B A establishes connection to B on well-known Q.931 port (1720)
ユーザーAユーザーB Aは、よく知られているQ.931ポート（1720）でBへの接続を確立します
----------------------------------------------->
Q.931 Setup caller address = 88.88.88.88
caller port = 1120
callee address = 99.99.99.99
callee port = 1720
<-----------------------------------------------
Q.931 Alerting
<-----------------------------------------------
Q.931 Connect H.245 address = 99.99.99.99
H.245 port = 1092
User A establishes connection to User B at 99.99.99.99, port 1092
ユーザーAは、99.99.99.99、ポート1092でユーザーBへの接続を確立します
<---------------------------------------------->
Several H.245 messages are exchanged (Terminal
Capability Set, Master Slave Determination and
their respective ACKs)
<-----------------------------------------------
H.245 Open Logical Channel, channel = 257
RTCP address = 99.99.99.99
RTCP port = 1093
----------------------------------------------->
H.245 Open Logical Channel Ack, channel = 257
RTP address = 88.88.88.88
RTP port = 2002
(This is where User A would like RTP
data sent to)
RTCP address = 88.88.88.88
RTCP port = 2003
----------------------------------------------->
H.245 Open Logical Channel, channel = 257
RTCP address = 88.88.88.88
RTCP port = 2003
<-----------------------------------------------
H.245 Open Logical Channel Ack, channel = 257
RTP address = 99.99.99.99
RTP port = 1092
(This is where User B would like RTP data
sent to)
RTCP address = 99.99.99.99
RTP port = 1093
Also note that if an H.323 Gateway resided inside a NAT boundary, the ALG would have to be cognizant of the various gateway discovery schemes and adapt to those schemes as well. Or if just the H.323 host/terminal was inside the NAT boundary and tried to register with a Gatekeeper, the IP information in the registration messages would have to be translated by NAT.
また、H.323ゲートウェイがNAT境界内に存在する場合、アルグはさまざまなゲートウェイディスカバリースキームを認識し、それらのスキームにも適応する必要があることに注意してください。または、H.323ホスト/ターミナルがNAT境界内にあり、ゲートキーパーに登録しようとした場合、登録メッセージのIP情報をNATによって翻訳する必要があります。
SNMP is a network management protocol based on UDP. SNMP payload may contain IP addresses or may refer IP addresses through an index into a table. As a result, when devices within a private network are managed by an external node, SNMP packets transiting a NAT device may contain information that is not relevant in external domain. In some cases, as described in [SNMP-ALG], an SNMP ALG may be used to transparently convert realm-specific addresses into globally unique addresses. Such an ALG assumes static address mapping and bi-directional NAT. It can only work for the set of data types (textual conventions) understood by the SNMP-ALG implementation and for a given set of MIB modules. Furthermore, replacing IP addresses in the SNMP payload may lead to communication failures due to changes in message size or changes in the lexicographic ordering.
SNMPは、UDPに基づくネットワーク管理プロトコルです。SNMPペイロードにはIPアドレスが含まれている場合があります。または、インデックスを介してIPアドレスをテーブルに参照する場合があります。その結果、プライベートネットワーク内のデバイスが外部ノードによって管理される場合、NATデバイスを通過するSNMPパケットには、外部ドメインに関連しない情報が含まれる場合があります。場合によっては、[SNMP-Alg]で説明されているように、SNMPアルグを使用して、レルム固有のアドレスをグローバルに一意のアドレスに透過的に変換することができます。このようなアルグは、静的アドレスマッピングと双方向NATを想定しています。SNMP-ALG実装によって理解される一連のデータ型（テキストコンベンション）と、特定のMIBモジュールセットでのみ機能します。さらに、SNMPペイロード内のIPアドレスを置き換えると、メッセージサイズの変化や辞書的な順序の変更により、通信障害が発生する可能性があります。
Making SNMP ALGs completely transparent to all management applications is not an achievable task. The ALGs will run into problems with SNMPv3 security features, when authentication (and optionally privacy) is enabled, unless the ALG has access to security keys. [NAT-ARCH] also hints at potential issues with SNMP management via NAT.
SNMPアルグをすべての管理アプリケーションに対して完全に透過的にすることは、達成可能なタスクではありません。ALGは、ALGがセキュリティキーにアクセスできる限り、認証（およびオプションでプライバシー）が有効になっている場合、SNMPV3セキュリティ機能の問題に遭遇します。[NAT-ARCH]は、NATを介したSNMP管理の潜在的な問題も示唆しています。
Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used in conjunction with NAT to forward SNMP messages to external SNMP engines (and vice versa). SNMP proxies are tailored to the private domain context and can hence operate independent of the specific managed object types being accessed. The proxy solution will require the external management application to be aware of the proxy forwarder and the individual nodes being managed will need to be configured to direct their SNMP traffic (notifications and requests) to the proxy forwarder.
あるいは、[SNMP-APPL]で定義されているSNMPプロキシは、NATと組み合わせてSNMPメッセージを外部SNMPエンジンに転送することができます（およびその逆も同様です）。SNMPプロキシは、プライベートドメインコンテキストに合わせて調整されるため、アクセスする特定の管理されたオブジェクトタイプとは無関係に動作できます。プロキシソリューションでは、外部管理アプリケーションがプロキシ転送業者を認識する必要があり、管理されている個々のノードをプロキシフォワーダーにSNMPトラフィック（通知と要求）を向けるように構成する必要があります。
Activision Games were designed to be NAT-friendly so as not to require an ALG for the games to work transparently through traditional NAT devices. Game players within a private domain can play with other players in the same domain or external domain. Activision gaming protocol is proprietary and is based on UDP. The address server uses UDP port number 21157 and is expected to be located in the global address realm.
Activisionゲームは、ゲームが従来のNATデバイスを介して透過的に動作するためにアルグを必要としないように、NATフレンドリーになるように設計されています。プライベートドメイン内のゲームプレーヤーは、同じドメインまたは外部ドメインの他のプレーヤーとプレイできます。Activision Gaming Protocolは独自であり、UDPに基づいています。アドレスサーバーはUDPポート番号21157を使用しており、グローバルアドレスの領域に配置される予定です。
Game players connect to the address server first, and send their private IP address information (such as private IP address and UDP port number) in the initial connect message. The server notes private address information from the connect message and external address information from the IP and UDP headers. The server then sends both the private and external address information of the game player to all the other peer players. At this point, each game player knows the private and public address information of every other peer. Subsequent to this, each client opens up symmetrical direct connection to each other and uses whichever address (private or external) works first.
ゲームプレーヤーは最初にアドレスサーバーに接続し、初期接続メッセージでプライベートIPアドレス情報（プライベートIPアドレスやUDPポート番号など）を送信します。サーバーは、Connectメッセージからのプライベートアドレス情報とIPおよびUDPヘッダーからの外部アドレス情報を記録します。サーバーは、ゲームプレーヤーのプライベートアドレス情報と外部アドレス情報の両方を他のすべてのピアプレーヤーに送信します。この時点で、各ゲームプレーヤーは、他のすべてのピアのプライベートおよびパブリックアドレス情報を知っています。これに続いて、各クライアントは互いに対称的な直接接続を開き、最初に住所（プライベートまたは外部）のいずれかのどのアドレス（プライベートまたは外部）を使用します。
Now, the clients can have a session directly with other clients (or) they can have session with other clients via the gaming server. The key is to allow reuse of the same (global address, assigned UDP port) tuple used for initial connection to the game server for all subsequent connections to the client. A game player is recognized by one of (private address, UDP port) or (global address, assigned UDP port) by all other peer players. So, the binding between tuples should remain unchanged on NAT, so long as the gaming player is in session with one or multiple other players.
これで、クライアントは他のクライアントと直接セッションを行うことができます（または）ゲームサーバーを介して他のクライアントとセッションを行うことができます。重要なのは、クライアントへの後続のすべての接続に対してゲームサーバーへの初期接続に使用される、同じ（グローバルアドレス、割り当てられたUDPポート）タプルを再利用できるようにすることです。ゲームプレーヤーは、他のすべてのピアプレーヤーによって（プライベートアドレス、UDPポート）または（グローバルアドレス、UDPポートが割り当てられた）のいずれかによって認識されます。したがって、ゲームプレーヤーが他の1人または複数のプレーヤーとセッション中にいる限り、タプル間のバインディングはNATで変更されないようにする必要があります。
Opening a connection to a game server in external realm from a private host is no problem. All NAT would have to do is provide routing transparency and retain the same private-to-external address binding so long as there is a minimum of one gaming session with an external node. But, an NAPT configuration must allow multiple simultaneous UDP connections on the same assigned global address/port.
プライベートホストから外部領域のゲームサーバーへの接続を開くことは問題ありません。 NATがしなければならないのは、ルーティングの透明性を提供し、外部ノードを使用した最低1つのゲームセッションがある限り、同じ個人から外側のアドレスバインディングを保持することです。 ただし、NAPT構成では、同じ割り当てられたグローバルアドレス/ポートで複数の同時UDP接続を許可する必要があります。
The above approach has some problems. For example, a client could try contacting a private address, but that private address could be in use locally, when the private address at some other realm is meant. If the node that was contacted wrongfully has some other service or no service registered for the UDP port, the Activision connect messages are expected to be simply dropped. In the unlikely event, a registered application chooses to interpret the message, the results can be unpredictable.
上記のアプローチにはいくつかの問題があります。たとえば、クライアントはプライベートアドレスに連絡することを試みることができますが、他の領域のプライベートアドレスが意味する場合、そのプライベートアドレスはローカルで使用される可能性があります。誤って接触したノードに、UDPポートに登録されている他のサービスまたはサービスがない場合、Activision Connectメッセージは単純に削除されると予想されます。ありそうもないイベントでは、登録されたアプリケーションがメッセージを解釈することを選択しますが、結果は予測不可能です。
The readers may refer to Activision for the proprietary, detailed information on the function and design of this protocol.
読者は、このプロトコルの機能と設計に関する独自の詳細情報のActivisionを参照する場合があります。
The authors would like to express sincere thanks to Bernard Aboba, Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine, Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver and others that had provided valuable input in preparing this document. Special thanks to Dan Kegel for sharing the Activision games design methodology.
著者は、バーナード・アボバ、ビル・ソマーフィールド、デイブ・クライドランド、グレッグ・ハドソン、ヘニング・シュルツリン、ジェフリー・アルトマン、キース・ムーア、トーマス・ナルテン、ヴァーノン・シュリーバーなど、この文書の準備に貴重なインプットを提供してくれたことに感謝します。Activision Gamesのデザイン方法論を共有してくれたDan Kegelに感謝します。
The security considerations outlined in [NAT-TERM] are relevant to all NAT devices. This document does not warrant additional security considerations.
[NAT-Term]で概説されているセキュリティ上の考慮事項は、すべてのNATデバイスに関連しています。このドキュメントは、追加のセキュリティ上の考慮事項を保証しません。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-Term] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[Nat-Trad] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[H.323] ITU-T SG16 H.323, Intel white paper, "H.323 and Firewalls", Dave Chouinard, John Richardson, Milind Khare (with further assistance from Jamie Jason).
[H.323] ITU-T SG16 H.323、Intel White Paper、「H.323 and Firewalls」、Dave Chouinard、John Richardson、Milind Khare（Jamie Jasonのさらなる支援を受けて）。
[SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000.
[SNMP-Alg] Raz、D.、Schoenwaelder、J。and B. Sugla、「ペイロードアドレス翻訳のSNMPアプリケーションレベルゲートウェイ」、RFC 2962、2000年10月。
[SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[SNMP-APPL] Levi、D.、Meyer、P.およびB. Stewart、「SNMP Applications」、RFC 2573、1999年4月。
[NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993, November 2000.
[Nat-arch] Hain、T。「Natの建築的意味」、RFC 2993、2000年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10, RFC 821, August 1982.
[SMTP] Postel、J。、「Simple Mail Transfer Protocol」、Stdl 10、RFC 821、1982年8月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル（FTP）」、STD 9、RFC 959、1985年10月。
[SIP] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[SIP] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：Session Intiation Protocol」、RFC 2543、1999年3月。
[X Windows] Scheifler, B., "FYI on the X Window System", FYI 6, RFC 1198, January 1991.
[X Windows] Scheifler、B。、「FYI on the X Window System」、FYI 6、RFC 1198、1991年1月。
[RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang。L.、バーソン。S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[DNS-TERMS] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[DNS -TERMS] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[DNS-IMPL] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[DNS -IMPL] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[DNS-Alg] Srisuresh、P.、Tsirtsis、G.、Akkiraju、P。、およびA. Heffernan、「DNS拡張翻訳者（DNS_ALG）、RFC 2694、1999年9月。
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[Ipsec-esp] Kent、S。and R. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPSEC-AH] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[Ipsec-Docs] Thayer、R.、Doraswamy、N。and R. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[Nat-Sec] Srisuresh、P。、「NATドメイン用のトンネルモードIPSECを備えたセキュリティモデル」、RFC 2709、1999年10月。
[PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[Priv-Addr] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、G。DeGroot、およびE. Lear、「Private Internetsのアドレス配分」、BCP 5、RFC 1918、1996年2月。
[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[Addr-Beha] Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4 Address Behavior Today」、RFC 2101、1997年2月。
Authors' Addresses
著者のアドレス
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
MattRege Ipverse 223 Ximeno Ave. Long Beach、CA 90803
EMail: matt@ipverse.com
Pyda Srisuresh Jasmine Networks, Inc. 3061 Zanker Road, Suite B San Jose, CA 95134 U.S.A.
Pyda Srisuresh Jasmine Networks、Inc。3061 Zanker Road、Suite B San Jose、CA 95134 U.S.A.
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
電話：（408）895-5032メール：srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。