RFC3027 日本語訳
3027 Protocol Complications with the IP Network Address Translator. M.Holdrege, P. Srisuresh. January 2001. (Format: TXT=48662 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Holdrege
Request for Comments: 3027 ipVerse
Category: Informational P. Srisuresh
Jasmine Networks
January 2001
Holdregeがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3027年のipVerseカテゴリ: 情報のP.Srisureshジャスミンは2001年1月をネットワークでつなぎます。
Protocol Complications with the IP Network Address Translator
IPネットワークアドレス変換機構とのプロトコル複雑さ
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
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 Network Address Translator(NAT)の支援を求めると、多くのインターネットアプリケーションが悪影響を受けることができます。NATデバイスだけが、必要なアプリケーション/プロトコル透明をすべてのケースに供給できないで、透明を提供するために可能であるところでApplication Level Gateways(ALGs)の支援を求めます。 このドキュメントの目的は途中で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
1.0序論… 2 2.0 NATによって破られたプロトコルの一般的なCharacteristics… 2 途中でNATで働くことができない3.0のプロトコル… 4 ALGの援助で働くことができる4.0のプロトコル… 8 途中でNATで働くように明らかに設計された5.0のプロトコル… 16 6.0の承認… 17 7.0 セキュリティ問題… 17 8.0の参照箇所… 17 9.0人の作者のアドレス… 19 10.0 完全な著作権宣言文… 20
Holdrege & Srisuresh Informational [Page 1] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[1ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
1.0 Introduction
1.0 序論
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ヘッダーの中に)、これらのアップデートのために状態を支持するので、セッションに関するデータグラムはどちらの分野でも透過的に正しい終わりのノードに発送されます。 可能であるところでは、アプリケーションの特定のALGsが、アプリケーションレベル透明を提供するのに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を支持することを意図するのではなく、このドキュメントがむしろプロトコルとアプリケーションで複雑さを指摘するために意図することに注意するのも重要です。
2.0 Common Characteristics of Protocols broken by NAT
2.0 NATによって破られたプロトコルの一般的なCharacteristics
[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によって破られるプロトコルの特性をまとめるためにこのセクションで言い直されています。
2.1 Realm-specific IP address information in payload
2.1 ペイロードの分野特有のIPアドレス情報
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であるなら、アプリケーションは必ず失敗するでしょう。
2.2 Bundled session applications
2.2 添付されたセッションアプリケーション
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
また、通常、FTPや、H.323や、SIPやRTSPなどの添付されたセッションアプリケーションは途中で、NATデバイスによって破られます。(RTSPは、データフローを証明するのにコントロール接続を使用します)。 これはこれらのアプリケーションがコントロールセッション中にデータセッションとセッションオリエンテーションを証明するためにアドレスを交換して、パラメタを移植するからです。 NATは、添付されたセッションの相互依存性を知ることができないで、それぞれを扱うでしょう。
Holdrege & Srisuresh Informational [Page 2] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[2ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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.
お互いにとって関係ないセッション。 この場合、アプリケーションはさまざまな理由で失敗できます。 失敗の2つの最もありそうな理由は以下の通りです。 (a) パケットがいったん、起因する分野(NATが可能にしないかもしれない方向に溯源するコントロールセッションがデータセッションを許可する(b))を越えると、コントロールペイロードのアドレス指定情報は、分野特有であり、有効ではありません。
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の複雑さはペイロードを処理して、状態を維持するのに必要であるアプリケーションレベル知識に依存します。
2.3 Peer-to-peer applications
2.3 ピアツーピアアプリケーション
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と分かれそうです。 Client-サーバ・アプリケーションと異なって、同輩のいずれもPeerから同輩へのアプリケーションを溯源できます。 同輩が分配されているとき、個人的で公立の分野、発せられるセッションの向こう側に、外部の分野は私設の分野においてホストからのセッションとちょうど同じくらい傾向があります。 彼らが早めに外部的に割り当てられたIPアドレスかFQDNを知っているときだけ、外部の同輩は私設の分野で彼らの同輩の居場所を見つけることができるでしょう。 割り当てられたアドレス・マッピングへのFQDN名がそれほど長い間だけ起こることができる、途中で、NATデバイスはDNS-ALGをサポートします。 Peerから同輩へのアプリケーションに関する例はインタラクティブゲーム、インターネット電話、およびイベントベースのプロトコル(Instant-メッセージングなどの)を含んでいます。
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があるこのタイプの問題のための可能な回避策は個人的なホストが彼らの代表としてグローバルに発送されたインターネットに務めるサーバとの外国行きの関係を維持することです。
2.4 IP fragmentation with NAPT enroute
2.4 途中NAPTとのIP断片化
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が断片化したと言ってください。
Holdrege & Srisuresh Informational [Page 3] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[3ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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パケット。 そして、彼らはたまたま同じ断片化識別子を使用しました。 同じ断片化イドを運んで、目標ホストが2個の関係ないデータグラムを受け取って、目標ホストが、ホスト・アドレスが割り当てられた同じくらいからデータグラムが2つのセッションのどれに属すかを決定できないとき。 その結果、両方のセッションは崩壊するでしょう。
2.5 Applications requiring retention of address mapping
2.5 アドレス・マッピングの保有を必要とするアプリケーション
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と対話するのに必要であるかもしれません。
2.6 Applications requiring more public addresses than available
2.6 利用可能であるより公共のアドレスを必要とするアプリケーション
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サービスを取ってください。 彼らのTCPがIDを移植するとき、Rloginサービスクライアントはよく知られるrloginポート512を使用します。 私設の分野の1人未満のホストがサービスを開始できます。 これは基本的に利用可能であるより公共のアドレスを必要とするサービスを利用しようとするそうです。 NATデバイスはアドレスを保存できますが、それらは、より多くのアドレスを作成できません。
3.0 Protocols that cannot work with NAT enroute
3.0 途中でNATで働くことができないプロトコル
3.1 IPsec and IKE
3.1 IPsecとIKE
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の安全なパケットはその結果目標アプリケーションに絶対に達しないでしょう。
Holdrege & Srisuresh Informational [Page 4] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[4ページ]のRFC3027は2001年1月に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、超能力([IPsec-超能力])の暗号化されたパケットは途中で、NATデバイスによって限られた数の場合だけで変更されるかもしれません。 TCP/UDPパケットのケースでは、NATは、TCP/UDPヘッダーでチェックサムをアップデートする必要があるでしょう、IPヘッダーのアドレスを変えるとき。 しかしながら、TCP/UDPヘッダーが超能力によって暗号化されるとき、NATはこのチェックサムアップデートをすることができないでしょう。 その結果、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はMain、Aggressive、およびクィックModesの間、ノード識別子として潜在的にIPアドレスを通過できます。 IKE交渉が正しくNATを通り抜けるように、これらのペイロードは、変更される必要があるでしょう。 しかしながら、これらのペイロードは、しばしばハッシュによって保護されるか、または暗号化で見えなくされます。 とぎれなくて、IPアドレスがIKEペイロードで使用されないで、IKE交渉が起こることができた場合ではさえ、困難があります。時間IKEからのNATに関する外部アドレスに個人的なマッピングを保有するのに、完了している時間IPsecまでの交渉はアプリケーションのときにキーを使用します。 結局、終わりから終わりへのIPsecの使用は、より早く説明されるように厳しくとにかく妨げられます。
For all practical purposes, end-to-end IPsec is impossible to accomplish with NAT enroute.
実際上は、終わりから終わりへのIPsecは途中でNATで達成するのが不可能です。
3.2 Kerberos 4
3.2 ケルベロス4
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デバイスに関して気むずかしくはありません。 ケルベロスチケットはチケットを要求した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ゲートウェイのむこうにあって、ケルベロスサービスのすべてが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
NATはクライアントとKDCとの接続のための個人的なホストにクライアントとアプリケーション・サーバーとの関係のように同じアドレス・マッピングを使用します。また、チケット生涯の間中リモートサーバに開かれているように任意の接続を保つこの問題の周りの仕事がそうである警告があります、そう
Holdrege & Srisuresh Informational [Page 5] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[5ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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をさせないように、アドレス結合を下げてください。 交互に、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の個人的なドメインがもちろん当然ながら信じられたネットワークでないと仮定します、多くの攻撃が組織の中から起こるので。
3.3 Kerberos 5
3.3 ケルベロス5
Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be written.
ちょうどケルベロス4のように、ケルベロス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デバイスアドレスを含むチケットを求めることによって、あなたはNAPTデバイスでkrb5を働かせることができます、それがそれほど透明ではありませんが(振る舞うのがクライアントが必要である、そうでなければ、彼らがそうするだろう、) MIT krb5 1.0実装は、クライアントが求めた(それはいつもインターフェース・アドレスのセットを求めました)すべてのIPアドレスのために少しのconfigurabilityも持たないで、またNATとよく対話しませんでした。 あなたがkrb5.confのどこかでMIT krb5 1.1実装で"noaddresses"を要求につけることができる、オール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アドレスを含みます。(チケットはそれから有効であると考えられることになっています)。 ケルベロス認証でアクセスされるサービスがNAT公共側にあると、NAT(基本的なNATかNAPT)によって使用されるIPアドレスが許容できるアドレスのリストにないので、ケルベロス認証は失敗するでしょう。
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つの回避策があります。 1番目はNAPTの私設の分野のクライアントにチケットのIPリストでNAPTの公共のIPアドレスを指定させることです。 しかし、これはK4のために詳しく述べられた同じ警備上の問題に通じます。 そのうえ、個人的なドメインのクライアントがNAPTの公共のIP Addressを見つけるのは、明白ではありません。 それは終わりホストの上のアプリケーションの振舞いの変化でしょう。
Holdrege & Srisuresh Informational [Page 6] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[6ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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アドレスを取り除くことですが、これで、チケットの窃盗は、どこからでもチケットを使用できるので、今、さらに悪くなります。 私設でないネットワークだけから。
3.4 The X Windowing System and X-term/Telnet
3.4 XウインドーシステムとX-用語/telnet
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 Windowingシステムは基づくTCPです。 しかしながら、他のほとんどのアプリケーションと比べて、これらのアプリケーションとのクライアント/サーバー関係は逆です。 Xサーバかオープンウィンドウサーバがディスプレイ/マウス/キーボードユニット(すなわち、実際の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にあります。 最初のオープンウィンドウズサーバは、ポート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-用語Transmits IPは設定の目的のためにクライアントからサーバまでDISPLAY変数を扱います。 設定されると、DISPLAY変数はその後のホストの上のXクライアントからXサーバまでの接続にワークステーションの上で使用されます。 TELNET交渉の間のインラインが変数に送られるDISPLAY
DISPLAY=<local-ip-addr>:<server>.<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
地方のマシンが知るどんな能力も逆のDNSルックアップを地方のip-addrに実行することのないそのDNS名ではありません。
. There is no guarantee that the name returned by a reverse
DNS lookup actually maps back to the local IP address.
. 名前が実際に地図がローカルアイピーアドレスに支持する逆のDNSルックアップで戻ったという保証が全くありません。
. 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
このアプリケーションの一般の使用はホームの自分達のXターミナルから企業のオフィスに直通電話にかける人々です。 言ってください、とXクライアントはホストの上にNAT公共側で述べています、そして、Xサーバはaで走っています。
Holdrege & Srisuresh Informational [Page 7] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[7ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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.
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はX Server(s)へのアクセスを提供するために接続要求の聞こうとするために構成されるかもしれません、ALGを必要としないで。 しかし、このアプローチは、そうでなければ利用可能でないXサーバへのアクセスを提供することによって、セキュリティリスクを増強します。 また、ALGがIPアドレスをいじるとき、使用されるのはMITのマジックCOOKIE-1以外のX Authorizationメソッドに可能にならないでしょう。 すべての記録されたX AuthorizationメソッドでMITのマジックCOOKIE-1は最も安全ではありません。
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によって引き起こされたクライアント証明書検証問題があるかもしれません。
3.5 RSH/RLOGIN
3.5 RSH/RLOGIN
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はNAT環境で働かないでしょう。
4.0 Protocols that can work with the aid of an ALG
4.0 ALGの援助で働くことができるプロトコル
This document predominantly addresses problems associated with Traditional NAT, especially NAPT.
このドキュメントはTraditional NAT、特にNAPTに関連しているその問題を支配的に訴えます。
4.1 FTP
4.1 FTP
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,
FTPはFTPサーバのウェルノウン・ポート番号21にアクセスするクライアントによって開始されます。これはFTPコントロールセッションと呼ばれます。 しばしば、追加データセッションはコントロールセッションに伴います。 デフォルトで
Holdrege & Srisuresh Informational [Page 8] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[8ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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.
サーバのTCPポート20からコントロールセッションを開始するのに使用されるTCPポートクライアントまでデータセッションがあるでしょう。 しかしながら、データセッションポートは、FTPコントロールセッション以内にASCIIのコード化されたPORT、PASVコマンド、および応答を使用することで変更されるかもしれません。
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.
私設のネットワークであるとサポートされたNATにはFTPクライアントがいると言ってください。 FTP ALGが、外部的に有効なアドレスとポートナンバーでFTPデータセッションポートナンバーを特定して、プライベート・アドレスとポートナンバーを変更するために、FTPコントロールセッション(PORTとPASVモードの両方のための)をモニターするのに必要でしょう。 さらに、系列、承認番号、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.
しかしながら、制御コマンドチャンネルが固定されていると、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".
最後にa新しいFTPポートがどう命令するかを説明するRFC2428(IPv6とNATsのためのFTP拡大)のセクション4に注意するのは興味がある、(EPSV、すべて) ファストトラックへのFTPプロトコルをNATデバイスに許容するのに使用できて、リモートサーバが受け入れるならALGを通したさらなる処理を排除する、「EPSV、すべて」
4.2 RSVP
4.2 RSVP
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
IP(IPv4かIPv6のどちらか)の上で作動して、RSVPはトランスポート層のプロトコル・スタックに置かれます。 しかしながら、RSVPは他のトランスポート・プロトコルと異なって、アプリケーションデータを輸送しませんが、代わりに他のインターネット制御プロトコル(例えば、ICMP、IGMP、ルーティング・プロトコル)のように行動します。 プロトコル番号46を使用することでRSVPできるルータの間の生としてのホップごとのIPデータグラムをRSVPメッセージに送ります。 生のIPデータグラムがエンドシステムと最初(最後)のホップルータの間で使用されるべきであることを意図します。 しかしながら、すべてのシステムが生のネットワーク入出力ができるというわけではないので、これはいつも可能であるかもしれないというわけではありません。 これのために、終わりシステム・コミュニケーションのためにUDPデータグラムの中にRSVPにメッセージをカプセル化するのは可能です。 UDPによってカプセル化されます。
Holdrege & Srisuresh Informational [Page 9] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[9ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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.
1698(エンドシステムで送るなら)を移植するか、または1699を移植するためにRSVPメッセージを送ります(RSVPによって可能にされたルータで送るなら)。 RSVPメッセージのUDPカプセル化に関する詳しい情報のために。 RFC2205のAppendix 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.
目的地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.
目的地Port--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デバイスに達するとき、受信機に内部的に使用されるIPアドレスを反映するためにRSVPセッションを変えなければなりません。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 Objectが使用されているとき、RSVP-ALGは働かないでしょう。
4.3 DNS
4.3 DNS
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
DNSはTCP/UDPのベースのプロトコルです。 ドメインNamesはホストのための問題です(NATの私設の分野でローカルのDNSサーバを使用します)。 個人的なドメインのホストへのアドレス・マッピングへのDNS名は個人的なドメインの中の正式のネームサーバで構成されるべきです。 このサーバは名前解決のために外部の、そして、内部のホストによって同じくアクセスされるでしょう。 DNS-ALGが、DNSにおける変換を質問と応答と命名するためにアドレスを実行するのに必要でしょう。 [DNS-ALG]はDNS- ALGについて説明します。
Holdrege & Srisuresh Informational [Page 10] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[10ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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パケットが暗号化されるか、または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名にIPアドレスに変えるのに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は全く必要ではありません。
4.4 SMTP
4.4 SMTP
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ベースのメールメッセージをよく知られているポート25に送るのに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@company.com などの)を指定します、個々のホスト( fooboo@hostA.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アドレスか満足しているデータへのリンクの参照を含んでいません。 しかしながら、いくつかのメール・メッセージが「受け取ったところ」でメッセージをリレーするMTAsのIPアドレスを含んでいます。 「さばきます」。 いくつかのメール・メッセージがデバッグの目的のためのFQDNに代わったDNS記録の不足のためIPアドレスを使用します、「メール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.
1MTAsが個人的なドメインにNATの後ろに位置することになっていて、メール・メッセージが署名か暗号化キーによって保証されないなら、SMTP-ALGは、MTAsによって登録されたIPアドレス情報を翻訳するのに使用されるかもしれません。 MTAsに静的なアドレス・マッピングがあるなら、翻訳は長期間の間、分野の向こう側に有効でしょう。
Holdrege & Srisuresh Informational [Page 11] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[11ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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.
航空郵便路をたどる能力は、NATによってALGなしで単独で妨げられるか、または防がれるかもしれません。 メール問題をデバッグするか、またはメールの虐待的なユーザを捜し出すとき、これは問題を起こすことができます。
4.5 SIP
4.5 一口
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の種類によって定義されます)。 マルチメディアセッションのために、通常、これはSession記述プロトコル(SDP RFC2327)です。 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はシグナリングアドレスを指定するContact、To、およびFrom分野で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ポートの上で機能できたプロキシサーバをサポートします。 そのようなプロキシには、局所的に特定の構成があるでしょう。
4.6 RealAudio
4.6 リアルオーディオ
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を移植する、(たとえば、外部のドメインの場所を見つける、)、再生中に(例えば、オーディオストリームをポーズするか、または止める)交換にメッセージを制御してください。 オーディオセッションパラメタはTCPコントロールセッションのときにバイト・ストリームとして埋め込まれます。
Holdrege & Srisuresh Informational [Page 12] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[12ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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コントロールセッションのときに同意されたポートのための本国行きのUDPセッションを可能にするためにTCPトラフィックを調べるだろうことです。 交互に、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.
2方向の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とファイアウォールを通してデバイスを横断して。
4.7 H.323
4.7時間.323
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です。 オーディオだけ会議を支持して、最大異なったUDP'接続'が作った4があるかもしれません。
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データ・ストリームの中で確立されます。 (これで、これらのデータ・ストリームの中でアドレスを変更するのは必要である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
制御情報の大部分がASNでコード化される、.1 (Q.931プロトコルのData Units、またはPDUsの中のUserユーザ情報だけ
Holdrege & Srisuresh Informational [Page 13] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[13ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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.
以下であることは、プロトコル交換がUser AとUser B.AのIPアドレスの間の典型的なH.323呼び出しが88.88の.88の.88とビーズ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 User B Aはよく知られているQ.931ポートの上で接続をBに確立します。(1720)
----------------------------------------------->
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
-----------------------------------------------88.88.88.88訪問者ポート=1120訪問される人>Q.931セットアップ訪問者アドレス=アドレスは99.99.99.99訪問される人ポート=1720<と等しいです。----------------------------------------------- <を警告するQ.931----------------------------------------------- Q.931は99.99.99.99H.245ポート=H.245アドレス=1092を接続します。
User A establishes connection to User B at
99.99.99.99, port 1092
ユーザAが99.99でUser Bに接続を確立する、.99、.99、ポート1092
<---------------------------------------------->
Several H.245 messages are exchanged (Terminal
Capability Set, Master Slave Determination and
their respective ACKs)
<。---------------------------------------------->いくつかのH.245メッセージを交換します。(端末のCapability Set、Master Slave Determination、およびそれらのそれぞれの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)
<。----------------------------------------------- H.245の開いているLogical Channel、チャンネル=257RTCPアドレス=99.99.99.99RTCPポート=1093----------------------------------------------->のH.245の開いているLogical Channel Ack、チャンネル=257RTPアドレス=88.88.88.88RTPポート=2002(これはUser AがRTPデータを送って欲しいところです)
Holdrege & Srisuresh Informational [Page 14] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[14ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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
88.88.88.88RTCPポート=RTCPアドレス=2003----------------------------------------------->のH.245の開いているLogical Channel、チャンネル=257RTCPアドレス=88.88.88.88RTCPポート=2003<。----------------------------------------------- H.245の開いているLogical Channel Ack、チャンネル=257RTPアドレス=99.99.99.99RTPポート=1092(これはUser BがRTPデータを送って欲しいところである)RTCPアドレス=99.99.99.99RTPポート=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が様々なゲートウェイ発見体系において認識力があって、また、それらの体系に順応しなければならないことに注意してください。 または、まさしくH.323ホスト/端末がNAT境界の中にあって、Gatekeeperとともに記名しようとするなら、登録メッセージのIP情報はNATによって翻訳されなければならないでしょうに。
4.8 SNMP
4.8 SNMP
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 ALGsをすべての管理アプリケーションに完全に透明にするのは、達成可能なタスクではありません。 ALGsはSNMPv3セキュリティ機能に関する問題を出くわすでしょう、認証であるときに(任意に、プライバシー) ALGがセキュリティキーに近づく手段を持っていない場合、可能にされます。 また、[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
交互に、[SNMP-APPL]で定義されるSNMPプロキシは、外部のSNMPエンジン(逆もまた同様である)へのメッセージをSNMPに転送するのにNATに関連して使用されるかもしれません。 SNMPプロキシは個人的に仕立てられます。
Holdrege & Srisuresh Informational [Page 15] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[15ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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トラフィック(通知と要求)をプロキシ混載業者に向けるために構成される必要があるでしょう。
5.0 Protocols designed explicitly to work with NAT enroute
5.0 途中でNATで働くように明らかに設計されたプロトコル
5.1 Activision Games
5.1 Activisionゲーム
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 Gamesは、ゲームが透過的に伝統的なNATデバイスを終えるようにALGを必要としないようにNATに優しくなるように設計されました。 個人的なドメインの中のゲームをする人は同じドメインか外部のドメインで他のプレーヤーで演奏できます。 Activisionゲーミングプロトコルは、独占であり、UDPに基づいています。 アドレスサーバは、UDPポートNo.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と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.
今、クライアントは直接他のクライアント(or)があるので、彼らがゲーミングサーバで他のクライアントとのセッションを持つことができるセッションを持つことができます。キーはtupleが初期の接続にすべてのその後の接続のためのゲームサーバに使用した同じくらい(グローバルアドレス、割り当てられたUDPポート)の再利用をクライアントに許すことになっています。 ゲームをする人は1によって他のすべての同輩プレーヤーによる(プライベート・アドレス、UDPポート)か(グローバルアドレス、割り当てられたUDPポート)について見分けられます。 それで、tuplesの間の結合はNATで変わりがあるべきではありません、ゲーミングプレーヤーが1とのセッションか複数の他のプレーヤーにいる限り。
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に接続を許さなければなりません。
Holdrege & Srisuresh Informational [Page 16] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[16ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
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が接続するなら、メッセージによって単に下げられると予想されます。 ありそうもないイベントでは、結果は登録されたアプリケーションが、メッセージを解釈するのを選ぶのを予測できるはずがありません。
The readers may refer to Activision for the proprietary, detailed information on the function and design of this protocol.
読者はこのプロトコルの機能とデザインの独占で、詳細な情報についてActivisionを参照するかもしれません。
6.0 Acknowledgements
6.0 承認
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、ビル・ソマーフィールド、デーヴCridland、グレッグ・ハドソン、ヘニングSchulzrine、ジェフリー・アルトマン、キース・ムーア、トーマスNarten、ヴァーノンShryver、および他のものに心からの感謝を申し上げたがっています。 Activisionゲームを共有するためのダン・ケーゲルへの特別な感謝は方法論を設計します。
7.0 Security Considerations
7.0 セキュリティ問題
The security considerations outlined in [NAT-TERM] are relevant to all NAT devices. This document does not warrant additional security considerations.
[NAT-TERM]に概説されたセキュリティ問題はすべてのNATデバイスに関連しています。 このドキュメントは追加担保問題を保証しません。
8.0 References
8.0の参照箇所
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
Srisuresh、P.、M.Holdrege、および「IPネットワークアドレス変換機構(NAT)用語と問題」という[ナット-用語]、RFC2663、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)」、RFC3022、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] RazとD.とSchoenwaelderとJ.とB.Sugla、「有効搭載量アドレス変換のためのSNMPアプリケーションレベルゲートウェイ」、RFC2962、2000年10月。
[SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
RFC 2573, April 1999.
[SNMP-APPL] レビとD.とマイヤーとP.とB.スチュワート、「SNMPアプリケーション」、RFC2573、1999年4月。
Holdrege & Srisuresh Informational [Page 17] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[17ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
[NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993,
November 2000.
[ナット-アーチ] ハイン、T. 「NATの建築含意」、RFC2993、2000年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10,
RFC 821, August 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STDl10、RFC821、1982年8月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol
(FTP)", STD 9, RFC 959, October 1985.
[FTP] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、1985年10月。
[SIP] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[一口] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[X Windows] Scheifler, B., "FYI on the X Window System", FYI 6, RFC
1198, January 1991.
[X-windows]Scheifler、B.、「Xウィンドウシステムの上のFYI、」、FYI6、RFC1198、1月1991日
[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.、Berson。 S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、9月1997日
[DNS-TERMS] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[DNS-用語]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[DNS-IMPL] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[DNS-IMPL]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[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.ヘファーナン、「Network Address Translators(DNS_ALG)へのDNS拡張子」RFC2694(1999年9月)。
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPsec] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[IPsec-超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[IPsec、-、ああ、]、ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、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セキュリティドキュメント道路地図」、1998年11月のRFC2411。
[NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode IPsec
for NAT Domains", RFC 2709, October 1999.
[NAT SEC]Srisuresh、P.、「NATドメインへのトンネルモードIPsecの機密保護モデル」、RFC2709、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.deグルートとE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
Holdrege & Srisuresh Informational [Page 18] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[18ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[ADDR-BEHA] 大工とB.とクロウクロフトとJ.とY.Rekhter、「IPv4は今日ふるまいを扱う」RFC2101、1997年2月。
Authors' Addresses
作者のアドレス
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マットHoldrege ipVerse223Ximeno Ave。 ロングビーチ、カリフォルニア 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ジャスミンはInc.3061Zanker道路、Bサンノゼ、スイートカリフォルニア95134米国をネットワークでつなぎます。
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
以下に電話をしてください。 (408) 895-5032 メールしてください: srisuresh@yahoo.com
Holdrege & Srisuresh Informational [Page 19] RFC 3027 Protocol Complications with NAT January 2001
Holdrege&Srisureshの情報[19ページ]のRFC3027は2001年1月にNATとの複雑さについて議定書の中で述べます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Holdrege & Srisuresh Informational [Page 20]
Holdrege&Srisuresh情報です。[20ページ]
一覧
スポンサーリンク
