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
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.
著作権（C）インターネット協会（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途中で壊れプロトコルおよびアプリケーションを識別することです。文書はまた、任意の既知の回避策を識別しようとします。単一のドキュメントで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は、EN-経路（パケットのIPヘッダ内の）エンド・ノード・アドレスを変更し、セッションに関連するデータグラムが透過いずれかレルムの右端ノードにルーティングされるように、これらの更新の状態を維持します。可能な場合、アプリケーション固有のALGは、アプリケーションレベルの透明性を提供するために、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.
次のセクションでは、途中で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パケットは、ペイロードにおけるレルム固有のIPアドレスやポート情報が含まれている途中際にNATで失敗します。 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は、バンドルされたセッションの間の依存関係を知ることができず、各セッションは、互いに無関係であることを扱っていました。この場合、アプリケーションは、さまざまな理由で失敗する可能性があります。障害の二つの可能性が高い理由は、次のとおりです。コントロールペイロード内の（a）のアドレス情報は、（b）の制御セッションは、そのNATがかもしれない方向に由来するデータセッション（複数可）を可能にし、レルム固有で、パケットは元のレルムを横切った後、有効ではありません許可しません。
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.
レルム固有のアドレッシングがペイロードに指定され、ペイロードが暗号化されていない場合は、ALGは、いくつかのケースでのアプリケーションは、レルム間で透過的に実行するために必要なの周りに仕事を提供することができます。 ALGの複雑さは、ペイロードを処理し、状態を維持するために必要なアプリケーションレベルの知識に依存します。
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途中で中断する可能性があります。クライアント・サーバ・アプリケーションとは異なり、ピア・ツー・ピア・アプリケーションは、ピアのいずれかによって発信することができます。ピアは、プライベートとパブリックのレルムに分散されている場合、セッションが外部レルムが民間分野におけるホストからのセッションと同じように思われるから始まりました。彼らは事前に外部から割り当てられたIPアドレスまたはFQDNを知っている場合にのみ、外部ピアは、民間分野で仲間を見つけることができるようになります。割り当てられたアドレスへのマッピングFQDN名が途中で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.
プライベートホストをグローバルにルーティングされ、インターネットへの代表として動作するサーバーとのOutbound接続を維持するために、伝統的な-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
NAPTとIPフラグメンテーションは、途中の任意の単一のアプリケーションの問題ではなく、すべてのTCP / UDPアプリケーション間で浸透しています。問題は、[NAT-TRAD]に詳細に記載されています。次のように簡単に言えば、問題は行きます。 2つのプライベートホストが断片化された起源、と言います
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.
同じ宛先ホストへの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デバイスに通知することが可能になるアプリケーションに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サービスクライアントは、TCPポートIDとしてよく知られているのrloginポート512を使用します。いいえ、民間分野に複数のホストがサービスを開始することはできません。これは基本的に使用できる数より多くのパブリックアドレスを必要とするサービスを利用しようとする場合です。 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ヘッダ内の途中のアドレス情報を変更するので、ときにヘッダの内容が変更されたので、変更されたパケットを受信する宛先ホストがパケットを無効化します。 NATを横断するIPsecのAHの安全なパケットは、単に結果として、ターゲット・アプリケーションに到達しません。
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は、このチェックサム更新をすることができません。その結果、NATデバイスを横断するトランスポートモードESPで暗号化されたTCP / UDPパケットは、受信側の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アドレスを渡すことができます。正しくNATを通過するIKEネゴシエーションためには、これらのペイロードは変更する必要があります。しかし、これらのペイロードは、多くの場合、ハッシュにより保護や暗号化によって隠されています。でも、IPアドレスがIKEペイロードで使用されていない場合や、IKEネゴシエーション中に途切れない発生する可能性があり、IKEは、IPsecが上のキーを使用する時に交渉を完了した時点から、NATのプライベート・ツー・外部アドレスマッピングを保持して困難ですアプリケーション。前述したように、最終的に、エンド・ツー・エンドのIPsecの使用は厳しく、とにかく妨げられます。
For all practical purposes, end-to-end IPsec is impossible to accomplish with NAT enroute.
すべての実用的な目的のために、エンドツーエンドのIPsec NATは途中で達成することは不可能です。
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.
ケルベロス4チケットは暗号化されます。したがって、ALGを書き込むことができません。 KDCはチケット要求を受信すると、それが返されたチケットの送信元のIPアドレスが含まれています。すべてのケルベロス4サービスは、実際には送信元IPアドレスをチェックしません。 AFSはしていませんケルベロス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.
NATは、クライアントとアプリケーションサーバ間の接続用として、クライアントとKDCとの間の接続のためのプライベートホストに同じアドレスマッピングを使用する注意点もあります。この問題を回避するには、NATバインディングアドレスをドロップさせないように、チケットの有効期間全体の間に、リモートサーバへのオープンな任意の接続を維持することです。代わりに、ALGは、NATは、チケットの有効期間中に、チケットはプライベートホストとチケットがプライベートホストで使用されている時に発行されるまでの間にアドレスバインディングを変更しないことを確実にするために展開する必要があります。
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.
ただ、ケルベロス4と同様に、Kerberos 5のチケットは暗号化されます。したがって、ALGを書き込むことができません。
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.
ケルベロス5では、クライアントは、チケットの有効期限であるべきIPアドレスのリストを指定するか、それはすべてのIPアドレスのための有効なチケットを求めることができます。それは非常に透明ではないが、すべての-IP-アドレスチケットまたはNAPTデバイスアドレスを含むチケットを求めることで、あなたはkrb5のはNAPTデバイスで動作するように取得することができ、（それは彼らが他の場合とは異なる動作をするクライアントが必要です） 。 MITのkrb5 1.0実装では、IPは、クライアントが（それは常にそのインターフェイスアドレスの集合を求めた）を求めたとNATとよく相互作用しなかったアドレスを何のために任意の構成可能性を持っていませんでした。 MITのkrb5 1.1実装では、すべての-IP-アドレス-有効なチケットを要求するためのkrb5.confのどこかに「noaddresses」を配置することができます。
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（基本的な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.
チケットのセキュリティを減らすどちらもケルベロス5の2つの回避策があります。最初は、チケットのIPリストでNAPTのパブリックIPアドレスを指定しNAPT民間分野の顧客を持つことです。しかし、これは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.
第二の方法は、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サーバまたはオープンWindows Serverは、ディスプレイ/マウス/キーボードユニット（すなわち、実際の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サーバは、最初のオープンWindowsサーバがポート6000またはポート2000（より柔軟）であることができ、TCPポート6000です。私たちは、主に、ここで説明のために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-用語は、DISPLAY変数を設定する目的のためにクライアントからサーバにIPアドレスを送信します。設定した場合、DISPLAY変数は、ワークステーション上のXサーバにホスト上のXクライアントからの以降の接続に使用されます。 DISPLAY変数は、TELNETなどの交渉中にインラインで送られます
DISPLAY=<local-ip-addr>:<server>.<display>
DISPLAY = <ローカル-IP-addrに>：<サーバー> <表示>。
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.
<ローカル-IP-addrに>は、<サーバー>への接続に使用するソケットに関連付けられたローカルIPアドレスを調べることによって取得される場合。 <サーバ>はポート（6000 + <サーバ>）が接続を作るために使用されるべきかを決定します。 <表示>を使用すべき監視Xサーバへの接続を示すのに使用されるが、この議論には重要ではありません。
The <local-ip-addr> used is not a DNS name because:
<ローカル-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アドレスを使用するのは安全ではないかもしれません。 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のプライベート側のホスト上で実行されている、と言います。 DISPLAY変数はXクライアントが何らかの方法で実行されているホストにインラインで送信されます。 DISPLAY変数の内容を送信するプロセスは、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.
DISPLAY変数を送信するチャネルが暗号化されていない場合、NATデバイスは、IPアドレスを交換し、ゲートウェイとして機能するために有効な表示範囲（ポート6000以上）にポートを設定するには、ALGの助けを求めるかもしれません。交互に、NATは、ALGを必要とせず、Xサーバ（複数可）へのアクセスを提供するために、着信接続をリッスンするように構成することができます。しかし、このアプローチは、そうでなければ利用できないでしょうXサーバへのアクセスを提供することにより、セキュリティ上のリスクを増大させます。 IPは、アドレスとALGが改ざんとして、それはまた、使用する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のために別々のストリームをサポートするために、複数のセッションを使用しています。ランダムなポート番号は、標準エラー出力ポートとして使用するためにクライアントからサーバにインラインで送信されます。標準エラー出力ソケットは戻って、サーバからクライアントへの接続です。そして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のケルベロス保護されたバージョンが原因チケット問題や複数のセッションの使用に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は確実に2つのホスト間でファイルを転送するために使用されるTCPベースのアプリケーションです。 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符号化されたPORTと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 ALGは、FTPデータセッションのポート番号を特定し、外部から有効なアドレスとポート番号とプライベートアドレスとポート番号を変更すること（PORTとPASVモードの両方のための）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を拒否されると元のホストは、パス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.
制御コマンドチャネルが確保されている場合ALGは、コマンド交換にIPアドレスを更新するために、それは不可能だろう、しかし、注意してください。
When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same problems that occur with X-Term/Telnet occur with FTP.
AUTHはケルベロス4、ケルベロス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 portコマンド（EPSV ALL）をさらに排除、NATデバイスは、FTPプロトコルを高速に追跡できるようにするために使用することができます方法について説明（IPv6とNATのためのFTP拡張）RFC 2428のセクション4を注意することが重要ですALGによる処理は、リモート・サーバが「EPSV ALL」を受け入れ、場合。
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は、IP（IPv4またはIPv6のいずれか）の上で動作し、トランスポート層のプロトコルスタックに配置されます。しかしながら、他のトランスポートプロトコルとは異なり、RSVPは、アプリケーションデータを搬送しないが、代わりに他のインターネット制御プロトコル（例えば、ICMP、IGMP、ルーティングプロトコル）のように作用します。 RSVPメッセージは、生のIPデータグラムがエンドシステムと最初（または最後）のホップルータの間で使用されるべきであることが意図されているプロトコル番号46を使用して、生のIPデータグラムとしてホップバイホップRSVP対応ルータとの間に送られます。いないすべてのシステムがI / O生のネットワークを行うことができますしかし、これは常に可能ではないかもしれません。このため、エンドシステムの通信のためのUDPデータグラム内RSVPメッセージをカプセル化することが可能です。 UDPカプセル化
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メッセージは（RSVP対応ルータによって送信された場合）、ポート1698（エンドシステムによって送信された場合）またはポート1699のいずれかに送信されます。 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層以上の層で逆多重化のために使用される一般的な宛先ポート。
NAT devices are presented with unique problems when it comes to supporting RSVP. Two issues are:
それはRSVPをサポートすることになるとNATデバイスは、独自の問題を提示しています。 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 Pathメッセージを送信した場合たとえば、RSVPセッションは、外部送信者が内部受信者のIPアドレスであると考えているIPアドレスを指定します。しかし、RSVP Pathメッセージは、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のIntegrityオブジェクトを提供します。問題は、最初のポイントで、NATデバイスは、RSVPメッセージ内のIPアドレスを変更することができなければならないということです。これが行われたときにRSVPメッセージが変更されているようしかし、RSVPのIntegrityオブジェクトは、もはや有効ではありません。 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.
IPアドレスにDNS名を解決するためにDNSリゾルバを使用するアプリケーションは、アプリケーション固有のセッションで再利用のためのアドレス割り当ての利用可能性を想定しています。その結果、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.
プライベートドメイン内のネームサーバの必要性がない場合は別の方法として、プライベートドメインのホストは、単に外部名検索用の外部ネームサーバをポイントすることができます。ネームサーバが外部のドメインに位置しているとき、何ALGは必要ありません。
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は、メールサーバーがプライベートドメイン内または外に位置することができる25のよく知られたポートにTCPベースの電子メールメッセージを送信するためにsendmailなどのインターネット電子メールプログラムによって使用されるTCPベースのプロトコル（[SMTP]）、です。しかし、サーバは外部ホストからアクセスできる、グローバル名とアドレスを割り当てる必要があります。メールサーバーは、プライベートドメイン内に配置されている場合は、インバウンド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アドレスが含まれています。フィールド：一部のメールメッセージは「からのメール」で、デバッグの目的のためにまたは起因するDNSレコードの欠如へのFQDNの代わりにIPアドレスを使用します。
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.
一の以上のMTAがプライベートドメインにNATの後ろに位置するようにした、とメールメッセージが署名や暗号化キーによって保護されていない場合は、SMTP-ALGはのMTAによって登録されたIPアドレス情報を変換するために使用することができます。 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（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のために、あなたはALGを必要としません。双方向NATは、単純に2つの無関係なセッションとしてTCPとUDPの各セッションを処理し、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.
読者は、NATやファイアウォールデバイスを横断、そのアプリケーションが動作させることができる方法についての詳細なガイドラインについては、RealNetworks社に連絡することができます。
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接続用のポート番号は931、データストリーム内で確立されています。 （これは、これらのデータ・ストリーム内のアドレスを変更する必要がありますALG、ことは特に困難になります。）さらに悪いことに、それは、H.245接続がなければならないことを指定するには、例えば、Q.931で可能ですセキュア（暗号化）。セッションが暗号化されている場合、それは共有鍵へのアクセス権を持っていない限り、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
制御情報のほとんどは、Q.931プロトコルデータユニット、またはのPDU内でのみユーザーユーザー情報（ASN.1でエンコードされています
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 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のAのIPアドレスの間の典型的なH.323コールのためのプロトコル交換は88.88.88.88であるとBのIPアドレスは99.99.99.99です。 Q.931およびH.245メッセージは、RTPパケットのペイロードにASN.1で符号化されることに留意されたいです。だから、NATデバイスを介して接続を達成するために、H.323-ALGは、パケットを調べASN.1をデコードし、さまざまなH.323制御IPアドレスを変換する必要があります。
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は、ポート1092 99.99.99.99で、ユーザ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境界内に居住している場合、ALGは、様々なゲートウェイ発見スキームを認識することと同様にそれらの方式に適応しなければならないことに注意してください。ちょうど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 ALGは透過グローバルに一意なアドレスにレルム固有のアドレスを変換するために使用されてもよいです。このようなALGは、静的アドレスマッピングおよび双方向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は、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プロキシは、[SNMP-APPL]で定義されるように、外部のSNMPエンジン（及びその逆）へのSNMPメッセージを転送するNATと併せて使用することができます。 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デバイスを透過的に動作するためにALGを必要としないようにNATフレンドリーになるように設計されました。プライベートドメイン内のゲームのプレイヤーは、同じドメインまたは外部ドメイン内の他のプレイヤーと遊ぶことができます。アクティビジョンゲームプロトコルは、独自に開発したものであり、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アドレスとUDPポート番号など）を、プライベートIPアドレス情報を送信します。サーバーは、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ポートに登録されていないサービスがある場合は、アクティ接続メッセージを単純にドロップされることが期待されます。万一、登録されたアプリケーションは、メッセージを解釈することを選択し、結果は予測不可能であることができます。
The readers may refer to Activision for the proprietary, detailed information on the function and design of this protocol.
読者は、このプロトコルの機能及び設計上の独自の詳細については、アクティを参照することができます。
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.
著者は、この文書を作成するには、貴重な入力を提供していたバーナードAboba、ビルSommerfield、デイブCridland、グレッグ・ハドソン、ヘニングSchulzrine、ジェフリー・アルトマン、キースムーア、トーマスNarten氏、バーノンShryverと他の人に心からの感謝を表したいと思います。アクティビジョンゲームデザインの方法論を共有するためのダンケーゲルに感謝します。
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.ホールドレッジ、 "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、インテル白書、 "H.323とファイアウォール"（ジェイミージェイソンからのさらなる支援を受けて）デイブシュイナード、ジョン・リチャードソン、本部Milind Khare。
[SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000.
[SNMP-ALG]ラズ、D.、Schoenwaelder、J.とB. Sugla、RFC 2962、2000年10月 "ペイロード・アドレス変換のためのSNMPアプリケーションレベルゲートウェイ"。
[SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[SNMP-APPL]レヴィ、D.、マイヤー、P.とB.スチュワート、 "SNMPアプリケーション"、RFC 2573、1999年4月。
[NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993, November 2000.
[NAT-ARCH]ハイン、T. "NATの建築的意味"、RFC 2993、2000年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10, RFC 821, August 1982.
[SMTP]ポステル、J.、 "簡易メール転送プロトコル"、STDL 10、RFC 821、1982年8月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[FTP]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル（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]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、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 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]ブレーデン、R.、張。 L.、ベルソン。 S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（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のは、RFC 2694、1999年9月の "ネットワークへのDNS拡張は、翻訳者（DNS_ALG）をアドレス"。
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPsecの]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[IPsecの-ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406は、1998年11月。
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPsecの-AH]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[IPsecの-DOCS]セイヤー、R.、Doraswamy、N.とR.グレン、 "IPセキュリティドキュメントロードマップ"、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.、モスコウィッツ、B.、Karrenberg、D.、G.デ・グルート、およびE.リア、 "個人的なインターネットのための配分"、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]大工、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
Authors' Addresses
著者のアドレス
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マット・ホールドレッジipVerse 223 Ximenoアベニュー。ロングビーチ、CA 90803
EMail: matt@ipverse.com
メールアドレス：matt@ipverse.com
Pyda Srisuresh Jasmine Networks, Inc. 3061 Zanker Road, Suite B San Jose, CA 95134 U.S.A.
Pyda Srisureshジャスミンネットワークス株式会社3061 Zanker道路、スイートBサンノゼ、CA 95134 U.S.A.
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
電話：（408）895-5032 Eメール：srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。