RFC2993 日本語訳
2993 Architectural Implications of NAT. T. Hain. November 2000. (Format: TXT=74136 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hain Request for Comments: 2993 Microsoft Category: Informational November 2000
コメントを求めるワーキンググループT.ハインの要求をネットワークでつないでください: 2993年のマイクロソフトカテゴリ: 情報の2000年11月
Architectural Implications of NAT
NATの建築含意
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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631.
中の増加している関心、およびネットワークアドレス変換(NAT)RFC-1631の展開の観点から、この論文は実装のための建築含意とガイドラインのいくつかについて議論するでしょう。 読者がRFC-1631に提示されるアドレス変換概念に詳しいと思われます。
Table of Contents
目次
1. Introduction................................................... 2
2. Terminology.................................................... 4
3. Scope.......................................................... 6
4. End-to-End Model............................................... 7
5. Advantages of NATs............................................. 8
6. Problems with NATs............................................ 10
7. Illustrations................................................. 13
7.1 Single point of failure...................................... 13
7.2. ALG complexity............................................. 14
7.3. TCP state violations........................................ 15
7.4. Symmetric state management................................. 16
7.5. Need for a globally unique FQDN when advertising public
services................................................... 18
7.6. L2TP tunnels increase frequency of address collisions...... 19
7.7. Centralized data collection system report correlation...... 20
8. IPv6.......................................................... 21
9. Security Considerations....................................... 22
10. Deployment Guidelines........................................ 23
11. Summary...................................................... 24
12. References................................................... 27
1. 序論… 2 2. 用語… 4 3. 範囲… 6 4. 終わりから終わりへのモデル… 7 5. NATsの利点… 8 6. NATsに関する問題… 10 7. イラスト… 13 7.1 失敗の単一のポイント… 13 7.2. ALGの複雑さ… 14 7.3. TCPは違反を述べます… 15 7.4. 左右対称の国家管理… 16 7.5. 社会奉仕の広告を出すとき、グローバルにユニークなFQDNに必要です。 18 7.6. L2TPトンネルはアドレス衝突の頻度を増強します… 19 7.7. 集結されたデータ収集システムは相関関係を報告します… 20 8. IPv6… 21 9. セキュリティ問題… 22 10. 展開ガイドライン… 23 11. 概要… 24 12. 参照… 27
Hain Informational [Page 1] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[1ページ]のRFC2993建築含意
13. Acknowledgments.............................................. 28 14. Author's Address............................................. 28 15. Full Copyright Statement..................................... 29
13. 承認… 28 14. 作者のアドレス… 28 15. 完全な著作権宣言文… 29
1. Introduction
1. 序論
Published in May 1994, written by K. Egevang and P. Francis, RFC-1631 [2] defined NAT as one means to ease the growth rate of IPv4 address use. But the authors were worried about the impact of this technology. Several places in the document they pointed out the need to experiment and see what applications may be adversely affected by NAT's header manipulations, even before there was any significant operational experience. This is further evidenced in a quote from the conclusions: 'NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution.'
K.EgevangとP.フランシスによって書かれた1994年5月に発行されています、RFC-1631[2]はIPv4アドレス使用の成長率を緩和する1つの手段とNATを定義しました。 しかし、作者はこの技術の影響が心配でした。 彼らがどんなアプリケーションがそうするかを実験して、確認するために必要性を指摘したドキュメントの処々方々がNATのヘッダー操作で悪影響を受けて、以前さえ、どんな重要な運用経験もありました。 これは引用文で結論からさらに証明されます: 'NATで、それを長期ソリューションとして不適当にするいくつかの否定的特性を持って、短期間ソリューションとしてさえ不適当になるかもしれません'。
Now, six years later and in spite of the prediction, the use of NATs is becoming widespread in the Internet. Some people are proclaiming NAT as both the short and long term solution to some of the Internet's address availability issues and questioning the need to continue the development of IPv6. The claim is sometimes made that NAT 'just works' with no serious effects except on a few legacy applications. At the same time others see a myriad of difficulties caused by the increasing use of NAT.
今、6年後と予測にもかかわらず、NATsの使用はインターネットで広範囲になっています。 人々の中には両方としてのNATが長・短期ソリューションであるとインターネットのアドレス有用性問題のいくつかと宣言して、IPv6の開発を続ける必要性に質問している人もいます。 時々いくつかのレガシーアプリケーションを除いて、NATが重大な効果なしで'ただ、働いている'というクレームをします。 同時に、他のものは、困難の無数がNATの増加する使用で引き起こされるのを見ます。
The arguments pro & con frequently take on religious tones, with each side passionate about its position.
議論プロとまやかしは頻繁に位置に関して情熱的なそれぞれの側で宗教トーンを呈します。
- Proponents bring enthusiasm and frequently cite the most popular
applications of Mail & Web services as shining examples of NAT
transparency. They will also point out that NAT is the feature
that finally breaks the semantic overload of the IP address as
both a locator and the global endpoint identifier (EID).
- An opposing view of NAT is that of a malicious technology, a weed
which is destined to choke out continued Internet development.
While recognizing there are perceived address shortages, the
opponents of NAT view it as operationally inadequate at best,
bordering on a sham as an Internet access solution. Reality lies
somewhere in between these extreme viewpoints.
- 提案者は、熱意をもたらして、NAT透明に関する模範として頻繁に最もポピュラーなメールの、そして、ウェブサービスの応用を引用します。 また、彼らは、NATがロケータとグローバルな終点識別子の両方(EID)としてIPアドレスの意味オーバーロードが最終的に壊れる特徴であると指摘するでしょう。 - NATの反対意見は悪意がある技術(窒息するように運命づけられて、インターネット開発が外で続いたということである雑草)のものです。 アドレス不足が知覚されると認めている間、NATの反対者は、それが操作上せいぜい不十分であるとみなします、インターネット・アクセス対策として紛い物に近似して。 現実がこれらの極端な観点の間のどこかにあります。
In any case it is clear NAT affects the transparency of end-to-end connectivity for transports relying on consistency of the IP header, and for protocols which carry that address information in places other than the IP header. Using a patchwork of consistently configured application specific gateways (ALG's), endpoints can work around some of the operational challenges of NAT. These operational challenges vary based on a number of factors including network and
どのような場合でも、IPヘッダーの粘性を当てにする輸送、およびプロトコルに、どれがIPヘッダー以外の場所でそのアドレス情報を運ぶかは、NATが終わりから終わりへの接続性の透明に影響するのが明確です。 一貫して構成されたアプリケーション特定のゲートウェイ(ALGのもの)のパッチワークを使用して、終点はNATの操作上の挑戦のいくつか周りで働くことができます。 そしてこれらの操作上の挑戦がネットワークを含む多くの要因に基づいて異なる。
Hain Informational [Page 2] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[2ページ]のRFC2993建築含意
application topologies and the specific applications in use. It can be relatively easy to deal with the simplest case, with traffic between two endpoints running over an intervening network with no parallel redundant NAT devices. But things can quickly get quite complicated when there are parallel redundant NAT devices, or where there are more distributed and multi-point applications like multi- party document sharing. The complexity of coordinating the updates necessary to work around NAT grows geometrically with the number of endpoints. In a large environment, this may require concerted effort to simultaneously update all endpoints of a given application or service.
使用中のアプリケーションtopologiesと特定のアプリケーション。 最も簡単なケースに対処するのは比較的簡単である場合があります、2つの終点の間のトラフィックが平行な余分なNATデバイスなしで介入しているネットワークをひいていて。 しかし、マルチパーティーが共有を記録するように平行な余分なNATデバイスがあるか、またはより多くの分配されてマルチポイントの利用があるところでいろいろなことはすばやくかなりこじれることができます。 終点の数に応じて、NATの周りで扱うのに必要なアップデートを調整する複雑さは幾何学上成長します。 大きい環境で、これは同時にすべての与えられたアプリケーションの、または、サービスの終点をアップデートするための協力を必要とするかもしれません。
The architectural intent of NAT is to divide the Internet into independent address administrations, (also see "address realms", RFC-2663 [3]) specifically facilitating casual use of private address assignments RFC-1918 [4]. As noted by Carpenter, et al RFC-2101 [5], once private use addresses were deployed in the network, addresses were guaranteed to be ambiguous. For example, when simple NATs are inserted into the network, the process of resolving names to or from addresses becomes dependent on where the question was asked. The result of this division is to enforce a client/server architecture (vs. peer/peer) where the servers need to exist in the public address realm.
NATの建築意図がインターネットを独立しているアドレス政権に分割することである、(また、「アドレス分野」(明確にプライベート・アドレス課題RFC-1918[4]のカジュアルな使用を容易にするRFC-2663[3]))を見てください。 Carpenter、他のRFC-2101[5]によって注意されるように、私用アドレスがネットワークでいったん配布されると、アドレスはあいまいになるように保証されました。 簡単なNATsがネットワークに挿入されるとき、例えば、アドレスかアドレスから名前を決議するプロセスは質問が行われたところの扶養家族になります。 この分割の結果はサーバが場内放送分野に存在する必要があるところでクライアント/サーバー・アーキテクチャを実施する(同輩/同輩に対して)ことです。
A significant factor in the success of the Internet is the flexibility derived from a few basic tenets. Foremost is the End- to-End principle (discussed further below), which notes that certain functions can only be performed in the endpoints, thus they are in control of the communication, and the network should be a simple datagram service that moves bits between these points. Restated, the endpoint applications are often the only place capable of correctly managing the data stream. Removing this concern from the lower layer packet-forwarding devices streamlines the forwarding process, contributing to system-wide efficiency.
インターネットの成功に関する特筆すべき要因はいくつかの基本的な主義から得られた柔軟性です。 終わりまでのEnd原則(さらに、以下では、議論する)が最前にあって、終点で機能を実行できるだけであって、その結果、それらがコミュニケーションのコントロール中であり、ネットワークが移行する簡単なデータグラムサービスであるべきであることをそんなに確信しているどの注意がこれらのポイントの間のビットであるか。 言い直されて、しばしば終点アプリケーションは正しくデータ・ストリームを管理できる唯一の場所です。 パケットを進める下層デバイスからこの関心を取り除くと、システム全体の効率に貢献して、推進プロセスは流線型にされます。
Another advantage is that the network does not maintain per connection state information. This allows fast rerouting around failures through alternate paths and to better scaling of the overall network. Lack of state also removes any requirement for the network nodes to notify each other as endpoint connections are formed or dropped. Furthermore, the endpoints are not, and need not be, aware of any network components other than the destination, first hop router(s), and an optional name resolution service. Packet integrity is preserved through the network, and transport checksums and any address-dependent security functions are valid end-to-end.
別の利点はネットワークが接続単位で州の情報を保守しないということです。 これは、失敗の周りで速く代替パスを通って総合的なネットワークの、より良いスケーリングにコースを変更するのを許容します。 また、状態の不足は終点接続が形成されるか、または下げられるときネットワーク・ノードが互いに通知するというどんな要件も取り除きます。 その上、終点は、なくて、ある必要はありません、最初に、目的地以外のどんなネットワーク要素、ホップルータ、および任意の名前解決サービスも意識しています。 輸送チェックサムとどんなアドレス依存するセキュリティ機能も、有効な終わりからパケット保全はネットワークを通して保持されて、終わりです。
Hain Informational [Page 3] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[3ページ]のRFC2993建築含意
NAT devices (particularly the NAPT variety) undermine most of these, basic advantages of the end-to-end model, reducing overall flexibility, while often increasing operational complexity and impeding diagnostic capabilities. NAT variants such as RSIP [6] have recently been proposed to address some of the end-to-end concerns. While these proposals may be effective at providing the private node with a public address (if ports are available), they do not eliminate several issues like network state management, upper layer constraints like TCP_TIME_WAIT state, or well-known-port sharing. Their port multiplexing variants also have the same DNS limitations as NAPT, and each host requires significant stack modifications to enable the technology (see below).
NATデバイス(特にNAPTのバラエティー)はこれらの大部分を弱体化させます、終わりから終わりへのモデルの基本的な利点、しばしば操作上の複雑さを増強している間、総合的な柔軟性を減少させて、診断能力を妨害して。 RSIP[6]などのNAT異形は、最近、終わりから終わりへの関心のいくつかを扱うために提案されました。 これらの提案が個人的なノードに場内放送を提供するところで有効であるかもしれない間(ポートが利用可能であるなら)、ネットワーク国家管理のようないくつかの問題を排除しません、TCP_タイム誌_WAIT州、またはよく知られるポートのような上側の層の規制が共有されて。 また、それらのポートマルチプレクシング異形には、NAPTと同じDNS制限があります、そして、各ホストは技術を可能にするために重要なスタック変更を必要とします(以下を見てください)。
It must be noted that firewalls also break the end-to-end model and raise several of the same issues that NAT devises do, while adding a few of their own. But one operational advantage with firewalls is that they are generally installed into networks with the explicit intent to interfere with traffic flow, so the issues are more likely to be understood or at least looked at if mysterious problems arise. The same issues with NAT devices can sometimes be overlooked since NAT devices are frequently presented as transparent to applications.
それら自身ののいくつかを加えている間、ファイアウォールがまた、終わりから終わりへのモデルを壊して、NAT捻出がするのと同じいくつかの問題を上げることに注意しなければなりません。 しかし、ファイアウォールがある1つのオペレーショナル・アドバンテージは一般に、それらが交通の流れを妨げる明白な意図を伴うネットワークにインストールされるということです、問題が、より理解されていそうであるか、または神秘的な問題が起こるなら少なくとも見られて。 アプリケーションに透明であるとして頻繁にNATデバイスを贈るので、時々NATデバイスの同じ問題を見落とすことができます。
One thing that should be clearly stated up front is, that attempts to use a variant of NAT as a simple router replacement may create several significant issues that should be addressed before deployment. The goal of this document is to discuss these with the intent to raise awareness.
明確に述べられているべきである1つのことが前払いであって、それは、簡単なルータ交換が展開の前に扱われるべきであるいくつかの重要な問題を作成するときNATの異形を使用するのを試みます。 このドキュメントの目標は関心を高める意図とこれらについて議論することです。
2. Terminology
2. 用語
Recognizing that many of these terms are defined in detail in RFC 2663 [3], the following are summaries as used in this document.
これらの用語の多くがRFC2663[3]で詳細に定義されると認めて、↓これは本書では使用されるように概要です。
NAT - Network Address Translation in simple form is a method by which IP addresses are mapped from one address administration to another. The NAT function is unaware of the applications traversing it, as it only looks at the IP headers.
NAT--単純形のネットワークAddress TranslationはIPアドレスが1つのアドレス管理から別のアドレス管理まで写像されるメソッドです。 IPヘッダーを見るだけであるのでアプリケーションがそれを横断するのにNAT機能は気づきません。
ALG - Application Layer Gateway: inserted between application peers to simulate a direct connection when some intervening protocol or device prevents direct access. It terminates the transport protocol, and may modify the data stream before forwarding.
ALG--応用層ゲートウェイ: ある介入しているプロトコルかデバイスが直接アクセスを防ぐとき、ダイレクト接続をシミュレートするためにアプリケーション同輩の間に挿入されます。 それは、トランスポート・プロトコルを終えて、推進の前にデータ・ストリームを変更するかもしれません。
NAT/ALG - combines ALG functions with simple NAT. Generally more useful than pure NAT, because it embeds components for specific applications that would not work through a pure NAT.
NAT/ALG--ALG機能を簡単なNATに結合します。 一般に、純粋なNATより役に立って、特定のアプリケーションのためにコンポーネントを埋め込むので、それは純粋なNATを終えないでしょう。
Hain Informational [Page 4] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[4ページ]のRFC2993建築含意
DNS/ALG - a special case of the NAT/ALG, where an ALG for the DNS service interacts with the NAT component to modify the contents of a DNS response.
DNS/ALG--NAT/ALGの特別なケース。そこでは、DNSサービスのためのALGが、DNS応答のコンテンツを変更するためにNATコンポーネントと対話します。
Firewall - access control point that may be a special case of an ALG, or packet filter.
ファイアウォール--ALG、またはパケットフィルタの特別なケースであるかもしれないコントロールポイントにアクセスしてください。
Proxy - A relay service designed into a protocol, rather than arbitrarily inserted. Unlike an ALG, the application on at least one end must be aware of the proxy.
プロキシ--任意に挿入されるよりむしろプロトコルに設計されたリレーサービス。 ALGと異なって、少なくとも片端におけるアプリケーションはプロキシを意識しているに違いありません。
Static NAT - provides stable one-to-one mapping between address spaces.
静的なNAT--安定した1〜1つのマッピングをアドレス空間の間に提供します。
Dynamic NAT - provides dynamic mapping between address spaces normally used with a relatively large number of addresses on one side (private space) to a few addresses on the other (public space).
ダイナミックなNAT--もう片方(パブリックスペース)に関するいくつかのアドレスへの半面(プライベート・スペース)に関する比較的多くのアドレスを通常、使用されるアドレス空間の間のダイナミックなマッピングに提供します。
NAPT - Network Address Port Translation accomplishes translation by multiplexing transport level identifiers of multiple addresses from one side, simultaneously into the transport identifiers of a single address on the other. See 4.1.2 of RFC-2663. This permits multiple endpoints to share and appear as a single IP address.
NAPT--ネットワークAddress Port Translationは同時に、倍数の平らな識別子が半面から扱うマルチプレクシング輸送でもう片方に関するただ一つのアドレスに関する輸送識別子に翻訳を実行します。 4.1に.2RFC-2663を見てください。 これは、複数の終点がただ一つのIPアドレスとして共有して、現れることを許可します。
RSIP - Realm Specific IP allows endpoints to acquire and use the public address and port number at the source. It includes mechanisms for the private node to request multiple resources at once. RSIP clients must be aware of the address administration boundaries, which specific administrative area its peer resides in for each application, and the topology for reaching the peer. To complete a connection, the private node client requests one or more addresses and/or ports from the appropriate RSIP server, then initiates a connection via that RSIP server using the acquired public resources. Hosts must be updated with specific RSIP software to support the tunneling functions.
RSIP--分野Specific IPは終点にソースにおける場内放送とポートナンバーを習得して、使用させます。 個人的なノードがすぐに複数のリソースを要求するように、それはメカニズムを含んでいます。 RSIPクライアントはアドレス管理境界を意識しているに違いありません。その特定の行政区域では、同輩が、同輩に届くように各アプリケーション、およびトポロジーと住んでいます。 個人的なノードクライアントは、接続を終了するために、適切なRSIPサーバから1つ以上のアドレス、そして/または、ポートを要求して、次に、後天的な共同資金を使用することでそのRSIPサーバで接続を開始します。 特定のRSIPソフトウェアでホストをアップデートして、トンネリングが機能であるとサポートしなければなりません。
VPN - For purposes of this document, Virtual Private Networks technically treat an IP infrastructure as a multiplexing substrate, allowing the endpoints to build virtual transit pathways, over which they run another instance of IP. Frequently the 2nd instance of IP uses a different set of IP addresses.
VPN--このドキュメントの目的のために、Virtual兵士のNetworksはマルチプレクシング基板としてIPインフラストラクチャを技術的に扱います、それらがIPの別のインスタンスを実行する仮想のトランジット小道を造るために終点を許容して。 頻繁に、IPの2番目のインスタンスは異なったIPアドレスを使用します。
AH - IP Authentication Header, RFC-2401 [7], which provides data integrity, data origin authentication, and an optional anti-replay service.
AH--IP Authentication Header、データ保全、データ発生源認証、および任意の反再生サービスを提供するRFC-2401[7]。
Hain Informational [Page 5] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[5ページ]のRFC2993建築含意
ESP - Encapsulating Security Payload protocol, RFC 2401, may provide data confidentiality (encryption), and limited traffic flow confidentiality. It also may provide data integrity, data origin authentication, and an anti-replay service.
超能力--Securityが有効搭載量であるとカプセル化して、プロトコル(RFC2401)はデータの機密性(暗号化)、および限られた交通の流れに秘密性を提供するかもしれません。 また、それはデータ保全、データ発生源認証、および反再生サービスを提供するかもしれません。
Address administration - coordinator of an address pool assigned to a collection of routers and end systems.
管理に演説してください--ルータとエンドシステムの収集に割り当てられたアドレスプールのコーディネータ。
Addressing realm - a collection of routers and end systems exchanging locally unique location knowledge. (Further defined in RFC-2663 NAT Terminology.) NAT is used a means to distribute address allocation authority and provide a mechanism to map addresses from one address administration into those of another administration.
分野に演説します--局所的にユニークな位置の知識を交換するルータとエンドシステムの収集。 (RFC-2663 NAT Terminologyでさらに定義されます。) NATは使用されて、アドレス配分権威を分配して、写像するメカニズムを提供する手段が、1からアドレスが管理であると別の管理のものに扱うということです。
3. Scope
3. 範囲
In discussing the architectural impact of NATs on the Internet, the first task is defining the scope of the Internet. The most basic definition is; a concatenation of networks built using IETF defined technologies. This simple description does not distinguish between the public network known as the Internet, and the private networks built using the same technologies (including those connected via NAT). Rekhter, et al in RFC-1918 defined hosts as public when they need network layer access outside the enterprise, using a globally unambiguous address. Those that need limited or no access are defined as private. Another way to view this is in terms of the transparency of the connection between any given node and the rest of the Internet.
インターネットのNATsの建築影響について議論する際に、最初のタスクはインターネットについて範囲を決めることです。 最も基本的な定義はそうです。 IETFを使用することで造られたネットワークの連結は技術を定義しました。 この簡単な描写はインターネットとして知られている公衆通信回線、および同じ技術を使用することで造られた私設のネットワークを見分けません(それらを含んでいるのはNATで接続しました)。 Rekhter、彼らが企業の外でネットワーク層アクセスを必要とするとき、RFC-1918の他は公共の同じくらいホストを定義しました、グローバルに明白なアドレスを使用して。 それが制限するか、またはアクセスする必要はないものは個人的であると定義されます。 どんな与えられたノードとインターネットの残りとの関係の透明に関してもこれを見る別の方法があります。
The ultimate resolution of public or private is found in the intent of the network in question. Generally, networks that do not intend to be part of the greater Internet will use some screening technology to insert a barrier. Historically barrier devices between the public and private networks were known as Firewalls or Application Gateways, and were managed to allow approved traffic while blocking everything else. Increasingly, part of the screening technology is a NAT, which manages the network locator between the public and private-use address spaces, and then, using ALGs adds support for protocols that are incompatible with NAT. (Use of NAT within a private network is possible, and is only addressed here in the context that some component of the private network is used as a common transit service between the NAT attached stubs.)
公共であるか個人的の究極の解決は問題のネットワークの意図で見つけられます。 一般に、より大きいインターネットの一部であることを意図しないネットワークがバリアを挿入する何らかのスクリーニング技術を使用するでしょう。 公共の、そして、私設のネットワークの間のバリアデバイスは、歴史的に、FirewallsかApplication Gatewaysとして知られていて、他の何もかもを妨げている間、承認されたトラフィックを許容するために管理されました。 ますます、スクリーニング技術の一部がNATです、そして、ALGsを使用すると、次に、NATと両立しないプロトコルのサポートは加えます。(それは、公衆と私用アドレス空間の間のネットワークロケータを管理します)。 (私設のネットワークの中のNATの使用は、可能であり、私設のネットワークの何らかの成分が文脈ですが、中でここで扱われるだけであって、間に一般的なトランジットサービスとして使用されて、NATがスタッブを付けたということです。)
RFC-1631 limited the scope of NAT discussions to stub appendages of a public Internet, that is, networks with a single connection to the rest of the Internet. The use of NAT in situations in which a network has multiple connections to the rest of the Internet is significantly more complex than when there is only a single
RFC-1631はNAT議論の範囲を公共のインターネットのスタッブ追加に制限しました、すなわち、インターネットの残りへの単独結合があるネットワーク。 ネットワークにはインターネットの残りには複数の接続がある状況におけるNATの使用はシングルしかない時よりかなり複雑です。
Hain Informational [Page 6] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[6ページ]のRFC2993建築含意
connection since the NATs have to be coordinated to ensure that they have a consistent understanding of address mapping for each individual device.
NATsが彼らにはそれぞれの個々のデバイスのためのアドレス・マッピングの一貫した理解があるのを保証するために調整されなければならなくて以来の接続。
4. End-to-End Model
4. 終わりから終わりへのモデル
The concept of the End-to-End model is reviewed by Carpenter in Internet Transparency [8]. One of the key points is "state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks"; this is termed "fate-sharing". The goal behind fate-sharing is to ensure robustness. As networks grow in size, likelihood of component failures affecting a connection becomes increasingly frequent. If failures lead to loss of communication, because key state is lost, then the network becomes increasingly brittle, and its utility degrades. However, if an endpoint itself fails, then there is no hope of subsequent communication anyway. Therefore the End-to-End model argues that as much as possible, only the endpoints should hold critical state.
Endから終わりへのモデルの概念はインターネットTransparency[8]でCarpenterによって再検討されます。 要所の1つは「状態が終点だけで維持されるべきです、終点自体が壊れると状態を破壊できるだけであるような方法で」です。 これは「運命共有」と呼ばれます。 運命共有の後ろの目標は丈夫さを確実にすることです。 ネットワークがサイズに生えているのに従って、コンポーネント故障が接続に影響するという見込みはますます頻繁になります。 主要な状態が無くなるので失敗がコミュニケーションの損失を出すなら、ネットワークはますますもろくなります、そして、ユーティリティは下がります。 しかしながら、終点自体が失敗するなら、その後のコミュニケーションの望みが全くとにかくありません。 したがって、Endから終わりへのモデルは、できるだけ、終点だけがきわどい状態を保持するべきであると主張します。
For NATs, this aspect of the End-to-End model translates into the NAT becoming a critical infrastructure element: if it fails, all communication through it fails, and, unless great care is taken to assure consistent, stable storage of its state, even when it recovers the communication that was passing through it will still fail (because the NAT no longer translates it using the same mappings). Note that this latter type of failure is more severe than the failure of a router; when a router recovers, any communication that it had been forwarding previous can continue to be successfully forwarded through it.
NATsに関しては、Endから終わりへのモデルのこの局面は重要インフラ要素になるNATに翻訳されます: 失敗するなら、それを通したすべてのコミュニケーションが失敗します、そして、高度の注意が状態の一貫して、安定したストレージを保証するために取られないと、通り抜けていたコミュニケーションを回復すると、それでも、それは失敗するでしょう(NATがもう同じマッピングを使用することでそれを翻訳しないので)。 この後者のタイプの失敗がルータの失敗より厳しいことに注意してください。 ルータが回復するとき、それが持っていた前であることの状態で進めることであるどんなコミュニケーションも、それを通して首尾よく進められ続けることができます。
There are other important facets to the End-to-End model:
Endから終わりへのモデルへの他の重要な一面があります:
- when state is held in the interior of the network, then traffic
dependent on that state cannot be routed around failures unless
somehow the state is replicated to the fail-over points, which can
be very difficult to do in a consistent yet efficient and timely
fashion.
- a key principle for scaling networks to large size is to push
state-holding out to the edges of the network. If state is held
by elements in the core of the network, then as the network grows
the amount of state the elements must holds likewise grows. The
capacities of the elements can become severe chokepoints and the
number of connections affected by a failure also grows.
- if security state must be held inside the network (see the
discussion below), then the possible trust models the network can
support become restricted.
- 状態がネットワークの内部に保持されて、状態がどうにかフェイルオーバーポイント(一貫しましたが、効率的でタイムリーなファッションでするのは非常に難しい場合がある)に模写されない場合、失敗の周りでその状態に依存するトラフィックを発送できません。 - 大判にネットワークについて合わせて調整するための主要な原則はネットワークの縁に州把持を押し出すことです。 状態がネットワークのコアの要素によって保持されるなら、ネットワークが要素が育てなければならない状態の量を育てるのに従って、船倉は同様に発展します。 要素の能力は厳しい難所になることができます、そして、また、失敗で影響を受けるポートの数は成長します。 - ネットワークの中にセキュリティ状態を保持しなければならないなら(以下での議論を見てください)、ネットワークがサポートできる可能な信頼モデルは制限されるようになります。
Hain Informational [Page 7] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[7ページ]のRFC2993建築含意
A network for which endpoints need not trust network service providers has a great deal more security flexibility than one which does. (Picture, for example, a business traveler connecting from their hotel room back to their home office: should they have to trust the hotel's networking staff with their security keys?, or the staff of the ISP that supplies the hotel with its networking service? How about when the traveler connects over a wireless connection at an airport?)
終点がネットワークサービスプロバイダーを信じる必要はないネットワークはそうする1より多くのセキュリティの柔軟性を大いに持っています。 (例えば、商用で旅行をする人がそれらのホテルの部屋からそれらのホームオフィスまで接続すると描写してください: 彼らは自分達のセキュリティキー(ネットワークサービスをホテルに供給するISPのスタッフ)をホテルのネットワークスタッフに委託しなければならないはずです。 旅行者がいつ空港での無線接続の上で接続するかは、どうですか?)
Related to this, RFC-2101 notes:
Since IP Security authentication headers assume that the addresses
in the network header are preserved end-to-end, it is not clear
how one could support IP Security-based authentication between a
pair of hosts communicating through either an ALG or a NAT.
RFC-2101は、これに関連されたことに注意します: IP Security認証ヘッダーが、ネットワークヘッダーのアドレスが保存された終わりから終わりであると仮定するので、1つがどうしたらALGかNATのどちらかを通って交信する1組のホストの間のIPのSecurityベースの認証をサポートすることができたかは、明確ではありません。
In addition, there are distributed applications that assume that IP addresses are globally scoped, globally routable, and all hosts and applications have the same view of those addresses. Indeed, a standard technique for such applications to manage their additional control and data connections is for one host to send to another the address and port that the second host should connect to. NATs break these applications. Similarly, there are other applications that assume that all upper layer ports from a given IP address map to the same endpoint, and port multiplexing technologies like NAPT and RSIP break these. For example, a web server may desire to associate a connection to port 80 with one to port 443, but due to the possible presence of a NATPT, the same IP address no longer ensures the same host.
さらに、IPアドレスがグローバルに見られると仮定する分配された利用があります、グローバルに発送可能で、すべてのホストとアプリケーションはそれらのアドレスの同じ視点を持っています。 本当に、そのようなアプリケーションが彼らの追加コントロールとデータ接続を管理する標準のテクニックは1人のホストが第2代ホストが接続するべきであるアドレスとポートを別のものに送ることです。 NATsはこれらのアプリケーションを破ります。 同様に、与えられたIPアドレスからのポートが同じ終点に写像するそのすべて上側の層を帯びる他の利用があります、そして、NAPTとRSIPのようなポートマルチプレクシング技術はこれらを壊します。 例えば、ウェブサーバーは、443を移植するために1で80を移植するために接続を関連づけることを望むかもしれませんが、NATPTの可能な存在のため、同じIPアドレスはもう同じホストを確実にしません。
Limiting such applications is not a minor issue: much of the success of the Internet today is due to the ease with which new applications can run on endpoints without first requiring upgrades to infrastructure elements. If new applications must have the NATs upgraded in order to achieve widespread deployment, then rapid deployment is hindered, and the pace of innovation slowed.
そのようなアプリケーションを制限するのは、小さな問題ではありません: 今日、インターネットの成功の多くが新しいアプリケーションが最初にインフラストラクチャ要素にアップグレードを必要としないで終点で動くことができる容易さのためです。 広範囲の展開を達成するために新しいアプリケーションでNATsをアップグレードさせなければならないなら、急速な展開は妨げられました、そして、革新のペースは遅くなりました。
5. Advantages of NATs
5. NATsの利点
A quick look at the popularity of NAT as a technology shows that it tackles several real world problems when used at the border of a stub domain.
技術としてのNATの人気におけるクイック・ルックは、スタッブドメインの境界で使用されるとそれがいくつかの本当の世界問題に取り組むのを示します。
- By masking the address changes that take place, from either dial-
access or provider changes, minimizes impact on the local network
by avoiding renumbering.
- Globally routable addresses can be reused for intermittent access
customers. This pushes the demand for addresses towards the
number of active nodes rather than the total number of nodes.
- 取るアドレス変化にマスクをかけることによって、ダイヤルアクセスかプロバイダー変化のどちらかから、番号を付け替えるのを避けることによって、場所は企業内情報通信網で影響を最小にします。 - グローバルに、間欠アクセス顧客のために発送可能アドレスを再利用できます。 これはノードの総数よりむしろ活動ノードの数に向かってアドレスの要求を押します。
Hain Informational [Page 8] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[8ページ]のRFC2993建築含意
- There is a potential that ISP provided and managed NATs would
lower support burden since there could be a consistent, simple
device with a known configuration at the customer end of an access
interface.
- Breaking the Internet into a collection of address authorities
limits the need for continual justification of allocations allows
network managers to avoid the use of more advanced routing
techniques such as variable length subnets.
- Changes in the hosts may not be necessary for applications that
don't rely on the integrity of the packet header, or carry IP
addresses in the payload.
- Like packet filtering Firewalls, NAPT, & RSIP block inbound
connections to all ports until they are administratively mapped.
- ISPが提供した可能性があります、そして、知られている構成がある一貫して、簡単なデバイスがアクセスインタフェースの顧客端にあるかもしれないので、管理されたNATsはサポート負担を下げるでしょう。 - インターネットをアドレスの当局限界の収集に細かく分けて、ネットワークマネージャは配分の絶え間ない正当化の必要性で可変長サブネットなどの、より高度なルーティングのテクニックの使用を避けることができます。 - ホストにおける変化はパケットのヘッダーの保全を当てにしないか、またはペイロードのIPアドレスを載せないアプリケーションに必要でないかもしれません。 - パケットフィルタリングFirewallsのように、それらが行政上写像されるまで、NAPT&RSIPはすべてのポートに本国行きの接続を妨げます。
Taken together these explain some of the strong motivations for moving quickly with NAT deployment. Traditional NAT [2] provides a relatively simple function that is easily understood.
一緒に取って、これらはNAT展開ですぐに移行することに関するいくつかの強い動機がわかります。 伝統的なNAT[2]は容易に理解されている比較的簡単な機能を提供します。
Removing hosts that are not currently active lowers address demands on the public Internet. In cases where providers would otherwise end up with address allocations that could not be aggregated, this improves the load on the routing system as well as lengthens the lifetime of the IPv4 address space. While reclaiming idle addresses is a natural byproduct of the existing dynamic allocation, dial- access devices, in the dedicated connection case this service could be provided through a NAT. In the case of a NAPT, the aggregation potential is even greater as multiple end systems share a single public address.
現在活発でないホストを免職すると、アドレス要求は公共のインターネットに下ろされます。 そうでなければプロバイダーが集めることができなかったアドレス配分で終わる場合では、これは、ルーティングシステムの上で負荷を改良して、IPv4アドレス空間の生涯を伸します。 無駄なアドレスを取り戻すのは、既存の動的割当ての自然な副産物ですが、NATを通してこのサービスを提供できた専用接続事件でアクセスデバイスにダイヤルしてください。 NAPTの場合では、複数のエンドシステムがただ一つの場内放送を共有するとき、集合の可能性はさらに大きいです。
By reducing the potential customer connection options and minimizing the support matrix, it is possible that ISP provided NATs would lower support costs.
見込み客接続オプションを抑えて、サポートマトリクスを最小にすることによって、ISPの提供されたNATsがサポートコストを下げるのは、可能です。
Part of the motivation for NAT is to avoid the high cost of renumbering inherent in the current IPv4 Internet. Guidelines for the assignment of IPv4 addresses RFC-2050 [9] mean that ISP customers are currently required to renumber their networks if they want to switch to a new ISP. Using a NAT (or a firewall with NAT functions) means that only the Internet facing IP addresses must be changed and internal network nodes do not need to be reconfigured. Localizing address administration to the NAT minimizes renumbering costs, and simultaneously provides for a much larger local pool of addresses than is available under current allocation guidelines. (The registry guidelines are intended to prolong the lifetime of the IPv4 address space and manage routing table growth, until IPv6 is ready or new routing technology reduces the pressure on the routing table. This is accomplished by managing allocations to match actual demand and to enforce hierarchical addressing. An unfortunate byproduct of the
NATに関する動機の一部は現在のIPv4インターネットで固有の番号を付け替えることの高い費用を避けることです。 IPv4の課題が、RFC-2050が[9]であると扱うので、ガイドラインは、新しいISPに切り替わりたいならISP顧客が現在彼らのネットワークに番号を付け替えさせなければならないことを意味します。 NAT(または、NAT機能があるファイアウォール)を使用するのは、インターネットの面しているIPアドレスだけを変えなければならなくて、内部のネットワーク・ノードが再構成する必要はないことを意味します。 アドレスが管理であるとNATにローカライズするのが、現在の配分ガイドラインの下で利用可能であるというよりも番号を付け替えるコストを最小にして、同時に、アドレスのはるかに大きい地方のプールに備えます。 (登録ガイドラインは、IPv4アドレス空間の生涯を長引かせて、実需を合わせて、階層的なアドレシング不幸な副産物を実施するために配分を管理するIPv6が準備ができているか、または新しいルーティング技術が. これが達成される経路指定テーブルで圧力を緩めるまでの経路指定テーブルの成長を管理することを意図します。
Hain Informational [Page 9] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[9ページ]のRFC2993建築含意
current guidelines is that they may end up hampering growth in areas where it is difficult to sort out real need from potential hoarding.) NAT is effective at masking provider switching or other requirements to change addresses, thus mitigates some of the growth issues.
現在のガイドラインは結局潜在的貯蔵から本当の必要性を整理するのが難しい領域での成長を妨げるかもしれないということです。) NATは、マスキングプロバイダーの切り換えかアドレスを変えるという他の要件で有効であり、その結果、成長問題のいくつかを緩和します。
NAT deployments have been raising the awareness of protocol designers who are interested in ensuring that their protocols work end-to-end. Breaking the semantic overload of the IP address will force applications to find a more appropriate mechanism for endpoint identification and discourage carrying the locator in the data stream. Since this will not work for legacy applications, RFC-1631 discusses how to look into the packet and make NAT transparent to the application (i.e.: create an application gateway). This may not be possible for all applications (such as IP based authentication in SNMP), and even with application gateways in the path it may be necessary to modify each end host to be aware when there are intermediaries modifying the data.
NAT展開は彼らのプロトコルが終わらせる終わりを扱うのを確実にしたがっているプロトコルデザイナーの認識を提起しています。 IPアドレスの意味オーバーロードを壊すのは、アプリケーションが終点識別に関して、より適切なメカニズムを見つけて、データのロケータが流す携帯をがっかりさせるのを強制するでしょう。 これがレガシーアプリケーションのために働かないのでRFC-1631がどのようにパケットを調べて、NATをアプリケーションに透明にするかを議論する、(すなわち:、作成、アプリケーションゲートウェイ) すべてのアプリケーション(SNMPでのIPのベースの認証などの)には、これは可能でないかもしれません、そして、アプリケーションゲートウェイさえ経路にある状態で、データを変更する仲介者がいるとき、意識しているようにそれぞれの終わりのホストを変更するのが必要であるかもしれません。
Another popular practice is hiding a collection of hosts that provide a combined service behind a single IP address (i.e.: web host load sharing). In many implementations this is architecturally a NAT, since the addresses are mapped to the real destination on the fly. When packet header integrity is not an issue, this type of virtual host requires no modifications to the remote applications since the end client is unaware of the mapping activity. While the virtual host has the CPU performance characteristics of the total set of machines, the processing and I/O capabilities of the NAT/ALG device bound the overall performance as it funnels the packets back and forth.
別のポピュラーな習慣はただ一つのIPアドレス(: すなわち、ウェブホスト負荷分割法)の後ろに結合したサービスを提供するホストの収集を隠しています。 多くの実装では、建築上、これはそうです。アドレスが急いで本当の目的地に写像されて以来のNAT。 パケットのヘッダー保全が問題でないときに、終わりのクライアントがマッピング活動に気づかないので、このタイプの事実上のホストはリモートアプリケーションへの変更を全く必要としません。 事実上のホストには、マシンの全体集合のCPU性能の特性がありますが、前後にパケットを注ぐので、NAT/ALGデバイスの処理と入出力能力は総合的な性能を縛りました。
6. Problems with NATs
6. NATsに関する問題
- NATs break the flexible end-to-end model of the Internet.
- NATs create a single point where fates are shared, in the device
maintaining connection state and dynamic mapping information.
- NATs complicate the use of multi-homing by a site in order to
increase the reliability of their Internet connectivity. (While
single routers are a point of fate sharing, the lack of state in a
router makes creating redundancy trivial. Indeed, this is on of
the reasons why the Internet protocol suite developed using a
connectionless datagram service as its network layer.)
- NATs inhibit implementation of security at the IP level.
- NATs enable casual use of private addresses. These uncoordinated
addresses are subject to collisions when companies using these
addresses merge or want to directly interconnect using VPNs.
- NATs facilitate concatenating existing private name spaces with
the public DNS.
- NATsは終わりから終わりへのインターネットのフレキシブルなモデルを壊します。 - NATsは運命が接続状態とダイナミックなマッピング情報を維持するデバイスで共有される1ポイントを作成します。 - NATsは、彼らのインターネットの接続性の信頼性を増強するためにサイトのそばでマルチホーミングの使用を複雑にします。 (ただ一つのルータは運命に共有されるというポイントですが、ルータにおける、状態の不足で、冗長を作成するのは些細になります。 本当に、これはインターネット・プロトコル群がネットワーク層としてコネクションレスなデータグラムサービスを使用することで展開した理由でオンです。) - NATsはIPレベルにおけるセキュリティの実装を禁止します。 - NATsはプライベート・アドレスのカジュアルな使用を可能にします。 これらのアドレスを使用する会社が合併したいか、またはVPNsを使用することで直接内部連絡したがっているとき、これらの非調整されたアドレスは衝突を受けることがあります。 - NATsは、公共のDNSと共に既存の個人的な名前空間を連結するのを容易にします。
Hain Informational [Page 10] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[10ページ]のRFC2993建築含意
- Port versions (NAPT and RSIP) increase operational complexity when
publicly published services reside on the private side.
- NATs complicated or may even invalidate the authentication
mechanism of SNMPv3.
- Products may embed a NAT function without identifying it as such.
- 公的に発行されたサービスが個人的側にあると、ポートバージョン(NAPTとRSIP)は操作上の複雑さを増強します。 - NATsはSNMPv3の認証機構を複雑にするか、または無効にさえするかもしれません。 - そういうものとしてそれを特定しないで、製品はNAT機能を埋め込むかもしれません。
By design, NATs impose limitations on flexibility. As such, extended thought about the introduced complications is called for. This is especially true for products where the NAT function is a hidden service, such as load balancing routers that re-write the IP address to other public addresses. Since the addresses may be all in publicly administered space these are rarely recognized as NATs, but they break the integrity of the end-to-end model just the same.
故意に、NATsは制限を柔軟性に課します。 そういうものとして、導入された複雑さに関する拡張考えは求められます。 NAT機能が隠されたサービスである製品に、これは特に本当です、IPアドレスを他の場内放送に書き直すロードバランシングルータなどのように。 アドレスがすべて公的に管理されたスペースにあるかもしれないので、これらはNATsとしてめったに認識されませんが、彼らはそれでも終わりから終わりへのモデルの保全を壊します。
NATs place constraints on the deployment of applications that carry IP addresses (or address derivatives) in the data stream, and they operate on the assumption that each session is independent. However, there are applications such as FTP and H.323 that use one or more control sessions to set the characteristics of the follow-on sessions in their control session payload. Other examples include SNMP MIBs for configuration, and COPS policy messages. Applications or protocols like these assume end-to-end integrity of addresses and will fail when traversing a NAT. (TCP was specifically designed to take advantage of, and reuse, the IP address in combination with its ports for use as a transport address.) To fix how NATs break such applications, an Application Level Gateway needs to exist within or alongside each NAT. An additional gateway service is necessary for each application that may imbed an address in the data stream. The NAT may also need to assemble fragmented datagrams to enable translation of the application stream, and then adjust TCP sequence numbers, prior to forwarding.
NATsはアプリケーションの展開のデータ・ストリームでIPアドレス(または、アドレス派生物)を運んでください。そうすれば、それぞれのセッションが独立しているという前提を作動させるという規制を置きます。 しかしながら、それらのコントロールセッションペイロードにおける、フォローオンセッションの特性を設定するのに1つ以上のコントロールセッションを使用するFTPやH.323などの利用があります。 他の例は構成のためのSNMP MIBs、およびCOPS方針メッセージを含んでいます。 これらのようなアプリケーションかプロトコルが、終わりから終わりへのアドレスの保全を仮定して、NATを横断するとき、失敗するでしょう。 (TCPはポートと組み合わせた使用のための輸送アドレスとしてのIPアドレスを利用して、再利用するように明確に設計されました。) NATsがどうそのようなアプリケーションを破るかを修理するために、Application Levelゲートウェイは、NAT以内か各NATと並んで存在する必要があります。 追加ゲートウェイサービスがデータ・ストリームでアドレスを埋め込むかもしれない各アプリケーションに必要です。 また、NATは、アプリケーションストリームに関する翻訳を可能にして、次に、TCP一連番号を調整するのに断片化しているデータグラムを組み立てる必要があるかもしれません、推進の前に。
As noted earlier, NATs break the basic tenet of the Internet that the endpoints are in control of the communication. The original design put state control in the endpoints so there would be no other inherent points of failure. Moving the state from the endpoints to specific nodes in the network reduces flexibility, while it increases the impact of a single point failure. See further discussion in Illustration 1 below.
より早く注意されるように、NATsは終点がコミュニケーションのコントロール中であるインターネットの基本的な主義を破ります。 当初の設計が州のコントロールを終点に置いたので、失敗の他のどんな固有のポイントもないでしょう。 ネットワークで状態を終点から特定のノードまで動かすと、柔軟性は減少します、ただ一つのポイント失敗の影響を増強しますが。 以下のIllustration1のさらなる議論を見てください。
In addition, NATs are not transparent to all applications, and managing simultaneous updates to a large array of ALGs may exceed the cost of acquiring additional globally routable addresses. See further discussion in Illustration 2 below.
さらに、NATsはすべてのアプリケーションに透明ではありません、そして、ALGsの大きい配列に同時のアップデートを管理すると、追加グローバルに発送可能なアドレスを習得する費用は超えられるかもしれません。 以下のIllustration2のさらなる議論を見てください。
While RSIP addresses the transparency and ALG issues, for the specific case of an individual private host needing public access, there is still a node with state required to maintain the connection.
RSIPは、透明とALGが問題であると扱いますが、パブリックアクセスを必要とする個々の個人的なホストの特定のケースのために、状態が接続を維持していなければならないノードがまだあります。
Hain Informational [Page 11] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[11ページ]のRFC2993建築含意
Dynamic NAT and RSIP will eventually violate higher layer assumptions about address/port number reuse as defined in RFC-793 [10] RFC-1323 [11]. The TCP state, TCP_TIME_WAIT, is specifically designed to prevent replay of packets between the 4-tuple of IP and port for a given IP address pair. Since the TCP state machine of a node is unaware of any previous use of RSIP, its attempt to connect to the same remote service that its neighbor just released (which is still in TCP_TIME_WAIT) may fail, or with a larger sequence number may open the prior connection directly from TCP_TIME_WAIT state, at the loss of the protection afforded by the TCP_TIME_WAIT state (further discussion in 2.6 of RFC-2663 [3]).
ダイナミックなNATとRSIPは結局、RFC-793[10]RFC-1323[11]で定義されるようにアドレス/ポートナンバー再利用に関する、より高い層の仮定に違反するでしょう。 TCP状態_(TCP_タイム誌WAIT)は、与えられたIPアドレス組のためにIPとポートの4-tupleの間のパケットの再生を防ぐように明確に設計されています。 TCPがノードのマシンを述べるので、RSIPのどんな前の使用、同じリモートサービスに接続する試みにもただ釈放された隣人(_まだTCP_タイム誌WAITにはある)が失敗するかもしれないのを気づかないか、または、より大きい一連番号で直接TCP_タイム誌_WAIT状態から先の接続を開くかもしれません、TCP_タイム誌_WAIT州によって提供された保護の損失のときに。(2.6RFC-2663[3])におけるさらなる議論。
For address translators (which do not translate ports) to comply with the TCP_TIME_WAIT requirements, they must refrain from assigning the same address to a different host until a period of 2*MSL has elapsed since the last use of the address, where MSL is the Maximum Segment Lifetime defined in RFC-793 as two minutes. For address-and-port translators to comply with this requirement, they similarly must refrain from assigning the same host/port pair until 2*MSL has elapsed since the end of its first use. While these requirements are simple to state, they can place a great deal of pressure on the NAT, because they temporarily reduce the pool of available addresses and ports. Consequently, it will be tempting or NAT implementers to ignore or shorten the TCP_TIME_WAIT requirements, at the cost of some of TCP's strong reliability. Note that in the case where the strong reliability is in fact compromised by the appearance of an old packet, the failure can manifest itself as the receiver accepting incorrect data. See further discussion in Illustration 3 below.
アドレス変換機構(ポートを翻訳しません)がTCP_タイム誌_WAIT要件に従うように、それらは、アドレスの最後の使用以来2*MSLの期間が経過するまで同じアドレスを異なったホストに割り当てるのを控えなければなりません。そこでは、MSLがRFC-793で2分と定義されたMaximum Segment Lifetimeです。 アドレスとポート翻訳者がこの要件に従うように、彼らは、最初の使用の終わり以来2*MSLが経過するまで同じホスト/ポート組を選任するのを同様に控えなければなりません。 これらの要件は述べるのが簡単である間、NATに対する多くの圧力を置くことができます、利用可能なアドレスとポートのプールを一時減少させるので。 その結果、TCP_タイム誌_WAIT要件を無視するか、または短くするために誘惑かNAT implementersになるでしょう、TCPの強い信頼性のいくつかの費用で。 古いパケットの外観で事実上、強い信頼性が感染される場合では、失敗が間違ったデータを受け入れる受信機として現れることができることに注意してください。 以下のIllustration3のさらなる議論を見てください。
It is sometimes argued that NATs simply function to facilitate "routing realms", where each domain is responsible for finding addresses within its boundaries. Such a viewpoint clouds the limitations created by NAT with the better-understood need for routing management. Compartmentalization of routing information is correctly a function of routing protocols and their scope of application. NAT is simply a means to distribute address allocation authority and provide a mechanism to map addresses from one address realm into those of another realm.
時々NATsがそれぞれのドメインが境界の中でアドレスを見つけるのに原因となる「ルーティング分野」を容易にするために単に機能すると主張されます。 そのような観点はNATによってルーティング管理の、よりよく理解されている必要性をもって作成された制限を曇らせます。 ルーティング情報の区画化は正確に言えば、aがルーティング・プロトコルとそれらの適用範囲を機能させるということです。 NATは単に1つのアドレス分野からのアドレスを別の分野のものに写像するためにアドレス配分権威を分配して、メカニズムを提供する手段です。
In particular, it is sometimes erroneously believed that NATs serve to provide routing isolation. In fact, if someone were to define an OSPF ALG it would actually be possible to route across a NAT boundary. Rather than NAT providing the boundary, it is the experienced operators who know how to limit network topology that serve to avoid leaking addresses across a NAT. This is an operational necessity given the potential for leaked addresses to introduce inconsistencies into the public infrastructure.
特に、時々NATsが、ルーティング分離を提供するのに役立つと誤って信じられています。 事実上、だれかがOSPF ALGを定義するなら、実際にNAT境界の向こう側に発送するのにおいて可能でしょうに。 境界を提供するNATよりむしろ、NATの向こう側にアドレスを漏らすのを避けるのに役立つのは、ネットワーク形態を制限する方法を知っている経験豊富なオペレータです。 漏らされたアドレスが公共のインフラストラクチャに矛盾を取り入れる可能性を考えて、これは操作上の必要性です。
Hain Informational [Page 12] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[12ページ]のRFC2993建築含意
One of the greatest concerns from the explosion of NATs is the impact on the fledgling efforts at deploying network layer end-to-end IP security. One fundamental issue for IPSec is that with both AH and ESP, the authentication check covers the TCP/UDP checksum (which in turn covers the IP address). When a NAT changes the IP address, the checksum calculation will fail, and therefore authentication is guaranteed to fail. Attempting to use the NAT as a security boundary fails when requirement is end-to-end network layer encryption, since only the endpoints have access to the keys. See further discussion in Illustration 4 below.
NATsの爆発からの最もすごい関心の1つはネットワーク層終わりから終わりへのIPセキュリティを配布するところの未熟な取り組みの影響です。 IPSecのための1つの基本的な問題はAHと超能力の両方で、認証チェックがTCP/UDPチェックサム(順番にIPアドレスをカバーする)をカバーしているということです。 NATがIPアドレスを変えると、チェックサム計算は失敗するでしょう、そして、したがって、認証は、失敗するように保証されます。 要件が終わりから終わりへのネットワーク層暗号化であるときに、セキュリティ境界としてNATを使用するのを試みるのに失敗します、終点だけがキーに近づく手段を持っているので。 以下のIllustration4のさらなる議論を見てください。
Finally, while the port multiplexing variants of NAT (popular because they allow Internet access through a single address) work modestly well for connecting private hosts to public services, they create management problems for applications connecting from public toward private. The concept of a well-known port is undermined because only one private side system can be mapped through the single public-side port number. This will affect home networks, when applications like multi-player Internet games can only be played on one system at a time. It will also affect small businesses when only one system at a time can be operated on the standard port to provide web services. These may sound like only medium-grade restrictions for the present, but as a basic property of the Internet, not to change years into the future, it is highly undesirable. The issue is that the public toward private usage requires administrative mapping for each target prior to connection. If the ISP chooses to provide a standardized version of these to lower configuration options, they may find the support costs of managing the ALGs will exceed the cost of additional address space. See further discussion in Illustration 6 below.
最終的に、NAT(ただ一つのアドレスにインターネット・アクセスの通ることを許すのでポピュラーな)のポートマルチプレクシング異形が社会奉仕の接続の個人的なホストに遠慮深くうまくいっている間、彼らは公衆から個人的に接続するアプリケーションのための管理問題を生じさせます。 ウェルノウンポートの概念は、ただ一つの公共のサイドポートナンバーを通して1台の個人的なサイドシステムしか写像できないので、弱体化させられます。 これはホームネットワークに影響するでしょう、一度に1台のシステムでマルチプレーヤーインターネットゲームのようなアプリケーションを使うことができるだけであるとき。 また、ウェブサービスを提供するために標準のポートの上で一度に1台のシステムしか操作できないとき、それは中小企業に影響するでしょう。 これらは当分並制限だけのように聞こえるかもしれませんが、インターネットの基礎特性として、それは未来の変化年前として望ましくないのではなく非常に望ましくありません。 問題は個人的な用法に向かった公衆が接続の前に各目標のために管理マッピングを必要とするということです。 ISPが、設定オプションを下ろすためにこれらの標準化されたバージョンを提供するのを選ぶなら、それらは、ALGsを管理するサポートコストが追加アドレス空間の費用を超えるのがわかるかもしれません。 以下のIllustration6のさらなる議論を見てください。
7. Illustrations
7. イラスト
7.1 Single point of failure
7.1 失敗の単一のポイント
A characteristic of stateful devices like NATs is the creation of a single point of failure. Attempts to avoid this by establishing redundant NATs, creates a new set of problems related to timely communication of the state, and routing related failures. This encompasses several issues such as update frequency, performance impact of frequent updates, reliability of the state update transaction, a-priori knowledge of all nodes needing this state information, and notification to end nodes of alternatives. (This notification could be accomplished with a routing protocol, which might require modifications to the hosts so they will listen.)
NATsのようなstatefulデバイスの特性は1ポイントの失敗の作成です。 状態のタイムリーなコミュニケーションに関連する新しいセットの問題を生じさせて、関連する失敗を発送して、余分なNATsを設立することによってこれを避ける試み。 これはアップデート頻度や、頻繁なアップデートの性能影響や、州のアップデートトランザクションの信頼性や、この州の情報を必要とするすべてのノードに関する先験的な知識や、代替手段のエンドノードへの通知などのいくつかの問題を包含します。 (ホストへの変更を必要とするかもしれないルーティング・プロトコルでこの通知を実行できたので、彼らは聴くでしょう。)
Hain Informational [Page 13] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[13ページ]のRFC2993建築含意
-------- --------
| Host A |-----| Host B |
-------- | --------
-----------------
| |
------ ------
| AD 1 | | AD 2 |
------ ------
\ /
--------
/Internet\
----------
-------- -------- | ホストA|-----| ホストB| -------- | -------- ----------------- | | ------ ------ | 西暦1年| | 西暦2年| ------ ------ \ / -------- /インターネット、\----------
--------
Illustration 1
-------- イラスト1
In the traditional case where Access Device (AD) 1 & 2 are routers, the single point of failure is the end Host, and the only effort needed to maintain the connections through a router or link failure is a simple routing update from the surviving router. In the case where the ADs are a NAT variant there will be connection state maintained in the active path that would need to be shared with alternative NATs. When the Hosts have open connections through either NAT, and it fails, the application connections will drop unless the state had been previously moved to the surviving NAT. The hosts will still need to acquire a routing redirect. In the case of RSIP, the public side address pool would also need to be shared between the ADs to allow movement. This sharing creates another real-time operational complexity to prevent conflicting assignments at connection setup. NAT as a technology creates a point fate sharing outside the endpoints, in direct contradiction to the original Internet design goals.
Access Device1と2(AD)がルータである伝統的な場合では、失敗の単一のポイントは終わりのHostです、そして、唯一の取り組みが、ルータを通して接続を維持する必要があったか、リンクの故障は生き残っているルータからの簡単なルーティングアップデートです。 ADsがNAT異形である場合には、代替のNATsと共有される必要があるアクティブな経路で維持された接続状態があるでしょう。 HostsにはNATを通したオープンな関係があって、失敗して、状態が以前に生き残っているNATに動かされていなかったなら、アプリケーション接続は低下するでしょう。 それでも、ホストは、再直接でルーティングを取得する必要があるでしょう。 また、RSIPの場合では、公共のサイドアドレスプールは、動きを許容するためにADsの間で共有される必要があるでしょう。 この共有は、接続設定で闘争課題を防ぐために別のリアルタイムの操作上の複雑さを作成します。 技術としてのNATは終点の外で共有されるポイント運命を作成します、元のインターネットデザイン目標への真っ向からの反対で。
7.2. ALG complexity
7.2. ALGの複雑さ
In the following example of a proposed corporate network, each NAT/ALG was to be one or more devices at each physical location, and there were to be multiple physical locations per diagramed connection. The logistics of simply updating software on this scale is cumbersome, even when all the devices are the same manufacturer and model. While this would also be true with routers, it would be unnecessary for all devices to run a consistent version for an application to work across an arbitrary path.
各NAT/ALGによるそれぞれの物理的な位置の提案された企業ネットワークに関する以下の例では、1台以上のデバイスであることになっていました、そして、複数の図解された接続あたりの物理的な位置があるつもりでした。 このスケールの単にアップデートソフトウェアのロジスティクスは厄介です、すべてのデバイスが同じメーカーであり、モデル化さえされるとき。 また、これもルータで本当であるだろうという間、すべてのデバイスがアプリケーションが任意の経路の向こう側に扱う一貫したバージョンを実行するのは、不要でしょう。
Hain Informational [Page 14] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[14ページ]のRFC2993建築含意
----------------------------------------
| Corporate Network |
| Asia |------| Americas |------| Europe |
------ ---------- --------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
--------------------------------------------
| Internet |
--------------------------------------------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
------------------ -------------- ----------------
Home Telecommuters Branch Offices Partner Networks
------------------ -------------- ----------------
---------------------------------------- | 企業ネットワーク| | アジア|------| アメリカ大陸|------| ヨーロッパ| ------ ---------- -------- | | | -------- -------- -------- |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| -------- -------- -------- | | | -------------------------------------------- | インターネット| -------------------------------------------- | | | -------- -------- -------- |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| -------- -------- -------- | | | ------------------ -------------- ---------------- ホーム在宅勤務者支店はネットワークを組ませます。------------------ -------------- ----------------
--------
Illustration 2
-------- イラスト2
7.3. TCP state violations
7.3. TCP州の違反
The full range of upper layer architectural assumptions that are broken by NAT technologies may not be well understood without a very large-scale deployment, because it sometimes requires the diversity that comes with large-scale use to uncover unusual failure modes. The following example illustrates an instance of the problem discussed above in section 6.
NAT技術で破られる建築仮定がそうする最大限の範囲の上側の層が非常に大規模な展開なしでよく理解されていなくて、時々多様性を必要とするので、それは大規模な使用と共に珍しい故障モードを発見するようになります。 以下の例は上でセクション6で議論した問題のインスタンスを例証します。
Hain Informational [Page 15] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[15ページ]のRFC2993建築含意
-------- --------
| Host A |-----| Host B |
-------- | --------
--------
|NAT/RSIP|
--------
|
--------
|Internet|
--------
|
---------
| Web |
| Server |
---------
-------- -------- | ホストA|-----| ホストB| -------- | -------- -------- |NAT/RSIP| -------- | -------- |インターネット| -------- | --------- | ウェブ| | サーバ| ---------
--------
Illustration 3
-------- イラスト3
Host A completes its transaction and closes the web service on TCP port 80, and the RSIP releases the public side address used for Host A. Host B attempts to open a connection to the same web service, and the NAT assigns then next free public side address which is the same one A just released. The source port selection rules on Host B happen to lead it to the same choice that A used. The connect request from Host B is rejected because the web server, conforming to the TCP specifications, has that 4-tuple in TIME WAIT for 4 minutes. By the time a call from Host B gets through to the helpdesk complaining about no access, the requested retry will work, so the issue is marked as resolved, when it in fact is an on-going, but intermittent, problem.
ホストAは、TCPポート80に取引を完了して、ウェブサービスを閉じます、そして、RSIPは同じウェブサービスに接続を開くHost A.Host B試みに使用される公共のサイドアドレスをリリースします、そして、NATはただリリースされた同じ1つAである次の当時の無料の公共のサイドアドレスを割り当てます。 Host Bの上のソースポート選択規則はたまたまそれをAが使用したのと同じ選択に導きます。 HostからのTCP仕様に従って、ウェブサーバーが4分間TIME WAITにその4-tupleを持っているのでBが拒絶されるという要求を接続してください。 Host Bからの呼び出しがアクセスがないのに関して不平を言うヘルプデスクに通じる時までには要求された再試行が働くので、問題は決議されているように著しいです、それが事実上継続していますが、間欠の問題であるときに。
7.4. Symmetric state management
7.4. 左右対称の国家管理
Operational management of networks incorporating stateful packet modifying device is considerably easier if inbound and outbound packets traverse the same path. (Otherwise it's a headache to keep state for the two directions synchronized.) While easy to say, even with careful planning it can be difficult to manage using a connectionless protocol like IP. The problem of creating redundant connections is ensuring that routes advertised to the private side reach the end nodes and map to the same device as the public side route advertisements. This state needs to persist throughout the lifetime of sessions traversing the NAT, in spite of frequent or simultaneous internal and external topology churn. Consider the following case where the -X- links are broken, or flapping.
本国行きの、そして、外国行きのパケットが同じ経路を横断するなら、デバイスを変更するstatefulパケットを取り入れるネットワークの運営管理はかなり簡単です。 (さもなければ、それは2つの方向への状態と同期し続ける頭痛です。) 綿密な計画があっても言うのが簡単である間、管理するのはIPのようなコネクションレスプロトコルを使用するのにおいて難しい場合があります。 余分な接続を創造するという問題は、個人的側に広告に掲載されたルートが公共のサイドルート広告と同じデバイスにエンドノードと地図に達するのを確実にしています。 この州は、NATを横断するセッションの生涯の間中固執する必要があります、頻繁であるか同時の内部の、そして、外部のトポロジー攪乳器にもかかわらず。 以下がどこをケースに入れるかと考えてください、-X-リンクは、壊れているか、またはばたついています。
Hain Informational [Page 16] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[16ページ]のRFC2993建築含意
-------- --------
| Host A | | Host B |
| Foo | | Bar |
-------- --------
| |
---- ----
|Rtr1|---X1---|Rtr2|
---- ----
| |
---- ----
|NAT1| |NAT2|
---- ----
| |
--------------
|Rtr Rtr|
| / Internet \ | ---
|Rtr----X2---Rtr|----|DNS|
-------------- ---
| |
| |
-------- --------
| Host C | | Host D |
-------- --------
-------- -------- | ホストA| | ホストB| | Foo| | バー| -------- -------- | | ---- ---- |Rtr1|---X1---|Rtr2| ---- ---- | | ---- ---- |NAT1| |NAT2| ---- ---- | | -------------- |Rtr Rtr| | /インターネット、\| --- |Rtr----X2---Rtr|----|DNS| -------------- --- | | | | -------- -------- | ホストC| | ホストD| -------- --------
--------
Illustration 4
-------- イラスト4
To preserve a consistent view of routing, the best path to the Internet for Routers 1 & 2 is via NAT1, while the Internet is told the path to the address pool managed by the NATs is best found through NAT1. When the path X1 breaks, Router 2 would attempt to switch to NAT2, but the external return path would still be through NAT1. This is because the NAT1 device is advertising availability of a pool of addresses. Directly connected routers in this same situation would advertise the specific routes that existed after the loss. In this case, redundancy was useless.
ルーティングの一貫した視点を保存するために、NAT1を通してRouters1と2のためのインターネットへの最も良い経路はあります、インターネットはNATsによって管理されたアドレスプールへの経路がNAT1を通して最も上手に見つけられると言われますが。 経路X1が壊れると、Router2は、NAT2に切り替わるのを試みるでしょうが、NAT1を通して外部のリターンパスがまだあるでしょう。 これはNAT1デバイスがアドレスのプールの広告の有用性であるからです。 この同じ状況における直接接続されたルータは損失の後に存在した特定のルートの広告を出すでしょう。 この場合、冗長は役に立ちませんでした。
Consider the case that the path between Router 1 & 2 is up, and some remote link in the network X2 is down. It is also assumed that DNS returns addresses for both NATs when queried for Hosts A or B. When Host D tries to contact Host B, the request goes through NAT2, but due to the internal routing, the reply is through NAT1. Since the state information for this connection is in NAT2, NAT1 will provide a new mapping. Even if the remote path is restored, the connection will not be made because the requests are to the public IP of NAT2, while the replies are from the public IP of NAT1.
Router1と2の間の経路が上がっていて、ネットワークX2における、あるリモートリンクが上がるケースがダウンすると考えてください。 また、Hosts Aのために質問されるとDNSが両方のNATsのためのアドレスを返すと思われようとするか、またはB.When Host DはHost Bに連絡しようとします、と要求では、NAT2を通して言われていますが、内部のルーティングのために、NAT1を通して回答があります。 この接続への州の情報がNAT2にあるので、NAT1は新しいマッピングを提供するでしょう。 遠く離れた経路が回復しても、NAT2の公立のIPには要求があるので、接続は作られないでしょう、回答がNAT1の公立のIPから来ていますが。
Hain Informational [Page 17] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[17ページ]のRFC2993建築含意
In a third case, both Host A & B want to contact Host D, when the remote link X2 in the Internet breaks. As long as the path X1 is down, Host B is able to connect, but Host A is cut off. Without a thorough understanding of the remote topology (unlikely since Internet providers tend to consider that sensitive proprietary information), the administrator of Hosts A & B would have no clue why one worked and the other didn't. As far as he can tell the redundant paths through the NATs are up but only one connection works. Again, this is due to lack of visibility to the topology that is inherent when a stateful device is advertising availability to a pool rather than the actual connected networks.
3番目の場合(インターネットのリモートリンクX2が壊れるとHost A&BがHost Dに連絡したがっている両方)で 経路X1が下がっている限り、Host Bは接続できますが、Host Aは断ち切られます。 遠く離れたトポロジーの徹底的な理解、(ありそうもなさ、プロバイダが、その機密の知的財産情報を考える傾向がある、)、Hosts A&Bの管理者は1つがなぜ働いていたかという手がかりを全く持っていなくて、またもう片方は持っていませんでした。 彼が判断できる限り、NATsを通した冗長パスは上がっていますが、1つの接続だけが働いています。 一方、これはstatefulデバイスが実際の接続ネットワークよりむしろプールへの広告の有用性であるときに固有のトポロジーへの目に見えることの不足のためです。
In any network topology, individual router or link failures may present problems with insufficient redundancy, but the state maintenance requirements of NAT present an additional burden that is not as easily understood or resolved.
どんなネットワーク形態にも、個々のルータかリンクの故障が不十分な冗長に関する問題を提示するかもしれませんが、NATの州のメインテナンス要件は同じくらい容易に理解されていないか、または決議されていない追加負担を寄贈します。
7.5. Need for a globally unique FQDN when advertising public services
7.5. 社会奉仕の広告を出すとき、グローバルにユニークなFQDNのためにそうしなければなりません。
The primary feature of NATs is the 'simple' ability to connect private networks to the public Internet. When the private network exists prior to installing the NAT, it is unlikely and unnecessary that its name resolver would use a registered domain. As noted in RFC 1123 [12] DNS queries may be resolved via local multicast. Connecting the NAT device, and reconfiguring it's resolver to proxy for all external requests allows access to the public network by hosts on the private network. Configuring the public DNS for the set of private hosts that need inbound connections would require a registered domain (either private, or from the connecting ISP) and a unique name. At this point the partitioned name space is concatenated and hosts would have different names based on inside vs. outside queries.
NATsのプライマリ特徴は私設のネットワークを公共のインターネットに接続する'簡単な'能力です。 NATをインストールする前に私設のネットワークが存在するとき、ネーム・リゾルバが登録されたドメインを使用するのは、ありそうもなくて、不要です。 [12] RFC1123に述べられるように、DNS質問は地方のマルチキャストで決議されるかもしれません。 NATデバイスを接続して、すべての外部要求のためのプロキシへのレゾルバが私設のネットワークのホストで公衆通信回線へのアクセスを許すということであることを再構成します。 または、本国行きの接続を必要とする個人的なホストのセットのために公共のDNSを構成するのが登録されたドメインを必要とするだろう、(個人的である、接続ISP) そして、ユニークな名前。 ここに、スペースという仕切られた名前は連結されます、そして、ホストは外の質問に対して異なった名前を内部に基づかせているでしょう。
Hain Informational [Page 18] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[18ページ]のRFC2993建築含意
-------- --------
| Host A | | Host B |
| Foo |-----| Bar |
-------- | -------- ---
|-------------|DNS|
--- ---
|NAT|
---
|
-------- ---
|Internet|----|DNS|
-------- ---
|
---
|NAT|
--- ---
|-------------|DNS|
-------- | -------- ---
| Host C |-----| Host D |
| Foo | | Bar |
-------- --------
-------- -------- | ホストA| | ホストB| | Foo|-----| バー| -------- | -------- --- |-------------|DNS| --- --- |NAT| --- | -------- --- |インターネット|----|DNS| -------- --- | --- |NAT| --- --- |-------------|DNS| -------- | -------- --- | ホストC|-----| ホストD| | Foo| | バー| -------- --------
--------
Illustration 5
-------- イラスト5
Everything in this simple example will work until an application embeds a name. For example, a Web service running on Host D might present embedded URL's of the form http://D/bar.html, which would work from Host C, but would thoroughly confuse Host A. If the embedded name resolved to the public address, Host A would be happy, but Host C would be looking for some remote machine. Using the public FQDN resolution to establishing a connection from Host C to D, the NAT would have to look at the destination rather than simply forwarding the packet out to the router. (Normal operating mode for a NAT is translate & forward out the other interface, while routers do not send packets back on the same interface they came from.) The NAT did not create the name space fragmentation, but it facilitates attempts to merge networks with independent name administrations.
アプリケーションが名前を埋め込むまで、この簡単な例のすべてが働くでしょう。 例えば、Host Dの上で作業するウェブサービスはフォーム http://D/bar.html の埋め込まれたURLを提示するかもしれません。(Host A.Ifをすっかり混乱させるだろうというのを除いて、 http://D/bar.html はHost Cから働いているでしょう)。場内放送に決議された、埋め込まれた名前、Host Aは満足でしょうが、Host Cはあるリモートマシンを探しているでしょう。 Host CからDまで取引関係を築くのに公共のFQDN解決を使用して、NATは単にルータへの外にパケットを送るよりむしろ目的地を見なければならないでしょう。 (NATのための正常なオペレーティング・モードはもう片方のインタフェースを外に翻訳して、送ることです、ルータはそれらが来た同じインタフェースでパケットを返送しませんが。) NATは名前宇宙断片化を作成しませんでしたが、それは独立している名前政権にネットワークを合併する試みを容易にします。
7.6. L2TP tunnels increase frequency of address collisions
7.6. L2TPトンネルはアドレス衝突の頻度を増強します。
The recent mass growth of the Internet has been driven by support of low cost publication via the web. The next big push appears to be support of Virtual Private Networks (VPNs) frequently accomplished using L2TP. Technically VPN tunnels treat an IP infrastructure as a multiplexing substrate allowing the endpoints to build what appear to be clear pathways from end-to-end. These tunnels redefine network visibility and increase the likelihood of address collision when
インターネットの最近の大規模成長は低価格公表のサポートでウェブで駆動でした。 次の大きいプッシュはL2TPを使用することで頻繁に達成されたVirtual兵士のNetworks(VPNs)のサポートであるように見えます。 技術的に、VPNトンネルは終わらせる終わりから明確な小道であるように見えることを築き上げるために終点を許容するマルチプレクシング基板としてIPインフラストラクチャを扱います。 再定義が目に見えることをネットワークでつないで、可能性を広げるこれらのトンネルは衝突にいつを扱うか。
Hain Informational [Page 19] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[19ページ]のRFC2993建築含意
traversing multiple NATs. Address management in the private space behind NATs will become a significant burden, as there is no central body capable of, or willing to do it. The lower burden for the ISP is actually a transfer of burden to the local level, because administration of addresses and names becomes both distributed and more complicated.
複数のNATsを横断します。 NATsの後ろのプライベート・スペースでのアドレス管理は重要な負担になるでしょう、できるか、またはそれをすることを望んでいた状態でどんな中央のボディーもないとき。 ISPのための下側の負担は実際に地方レベルへの負担の転送です、アドレスと名前の管理が分配されて、かつより複雑になるので。
As noted in RFC-1918, the merging of private address spaces can cause an overlap in address use, creating a problem. L2TP tunnels will increase the likelihood and frequency of that merging through the simplicity of their establishment. There are several configurations of address overlap which will cause failure, but in the simple example shown below the private use address of Host B matches the private use address of the VPN pool used by Host A for inbound connections. When Host B tries to establish the VPN interface, Host A will assign it an address from its pool for inbound connections, and identify the gateway for Host B to use. In the example, Host B will not be able to distinguish the remote VPN gateway address of Host A from its own private address on the physical interface, thus the connection will fail. Since private use addresses are by definition not publicly coordinated, as the complexity of the VPN mesh increases so does the likelihood that there will be a collision that cannot be resolved.
RFC-1918に述べられるように、問題を生じさせて、プライベート・アドレス空間の合併はアドレス使用でのオーバラップを引き起こす場合があります。 L2TPトンネルは、彼らの設立の簡単さを通して合併しながら、その見込みと頻度を増強するでしょう。 失敗を引き起こすアドレスオーバラップのいくつかの構成がありますが、私用の下の簡単な例では、Host Bのアドレスは本国行きの接続にHost Aによって使用されたVPNプールの私用アドレスに合っています。 Host BがVPNインタフェースを設置しようとするとき、Host Aは本国行きの接続のためにプールからのアドレスをそれに割り当てて、Host Bが使用するゲートウェイを特定するでしょう。 例では、Host Bが物理インターフェースに関するそれ自身のプライベート・アドレスとHost AのリモートVPNゲートウェイアドレスを区別できない、その結果、接続は失敗するでしょう。 以来、したがって、メッシュが増強するVPNの複雑さが決議できない衝突があるという見込みをするとき、私用アドレスは定義上公的に調整されません。
--------------- ----------------
| 10.10.10.10 |--------L2TP-------| Assigned by A |
| Host A | --- --- | Host B |
| 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 |
--------------- --- --- ----------------
--------------- ---------------- | 10.10.10.10 |--------L2TP-------| Aで、割り当てられます。| | ホストA| --- --- | ホストB| | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | --------------- --- --- ----------------
--------
Illustration 6
-------- イラスト6
7.7. Centralized data collection system report correlation
7.7. 集結されたデータ収集システムレポート相関関係
It has been reported that NAT introduces additional challenges when intrusion detection systems attempt to correlate reports between sensors inside and outside the NAT. While the details of individual systems are beyond the scope of this document, it is clear that a centralized system with monitoring agents on both sides of the NAT would also need access to the current NAT mappings to get this right. It would also be critical that the resulting data be indexed properly if there were agents behind multiple NATs using the same address range for the private side.
侵入検知システムが、センサの間のNATとNATの外におけるレポートを関連させるのを試みるとき、NATが追加挑戦を導入すると報告されました。 個人能率給制の細部はこのドキュメントの範囲を超えていますが、また、モニターしているエージェントがNATの両側にいる集権制がこの権利を得るために現在のNATマッピングへのアクセスを必要とするのは、明確です。 また、エージェントが複数のNATsの後ろにいたなら個人的側に同じアドレスの範囲を使用することで結果として起こるデータが適切に索引をつけられるのも、重要でしょう。
This also applies to management data collected via SNMP. Any time the data stream carries an IP address; the central collector or ALG will need to manipulate the data based on the current mappings in the
また、これはSNMPを通して集められた管理データに適用されます。 いつでも、データ・ストリームはIPアドレスを運びます。 中央のコレクタかALGが、中で現在のマッピングに基づいたデータを操る必要があるでしょう。
Hain Informational [Page 20] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[20ページ]のRFC2993建築含意
NAT.
NAT。
8. IPv6
8. IPv6
It has been argued that IPv6 is no longer necessary because NATs relieve the address space constraints and allow the Internet to continue growing. The reality is they point out the need for IPv6 more clearly than ever. People are trying to connect multiple machines through a single access line to their ISP and have been willing to give up some functionality to get that at minimum cost.
NATsが、アドレス空間規制を救って、インターネットが、成長し続けているのを許容するのでIPv6はもう必要でないと主張されました。 現実は彼らがこれまで以上明確にIPv6の必要性を指摘するということです。人々は、シングルアクセス系列を通して複数のマシンをそれらのISPに接続しようとしていて、最低費用でそれを得るために何らかの機能性をあきらめても構わないと思っています。
Frequently the reason for cost increases is the perceived scarcity (therefore increased value) of IPv4 addresses, which would be eliminated through deployment of IPv6. This crisis mentality is creating a market for a solution to a problem already solved with greater flexibility by IPv6.
頻繁に、コスト増の理由はIPv4アドレスへの知覚された不足(したがって、価値を増す)です。(アドレスはIPv6の展開で排除されるでしょう)。 この危機精神状態は、より大きい柔軟性でIPv6によって既に解決された問題の解決法の市場を創設しています。
If NAT had never been defined, the motivation to resolve the dwindling IPv4 address space would be a much greater. Given that NATs are enabling untold new hosts to attach to the Internet daily, it is difficult to ascertain the actual impact to the lifetime of IPv4, but NAT has certainly extended it. It is also difficult to determine the extent of delay NAT is causing for IPv6, both by relieving the pressure, and by redirecting the intellectual cycles away from the longer-term solution.
NATが一度も定義されたことがないなら、多くが、より大きいなら、やせ細っているIPv4アドレス空間を決議する動機は定義されたことがないでしょうに。 NATsが、無数の新しいホストが毎日インターネットに付くのを可能にしているなら、IPv4の生涯まで実際の影響を確かめるのが難しいのですが、確かに、NATはそれを広げました。 また、圧力を軽減して、より長い期間ソリューションから遠くで知的なサイクルを向け直すことによってNATがIPv6のために引き起こしている遅れの範囲を測定するのも難しいです。
But at the same time NAT functionality may be a critical facilitator in the deployment of IPv6. There are already 100 million or more computers running IPv4 on data networks. Some of these networks are connected to and thus part of the Internet and some are on private isolated networks. It is inconceivable that we could have a "flag day" and convert all of the existing IPv4 nodes to IPv6 at the same time. There will be a very long period of coexistence while both IPv4 and IPv6 are being used in the Internet and in private networks. The original IPv6 transition plan relied heavily on having new IPv6 nodes also be able to run IPv4 - a "dual stack" approach. When the dual stack node looks up another node in the DNS it will get back a IPv4 or an IPv6 address in response. If the response is an IPv4 address then the node uses IPv4 to contact the other node. And if the response is an IPv6 address then IPv6 can be used to make the contact. Turning the NAT into a 6to4 [13]router enables widespread deployment of IPv6 while providing an IPv4 path if IPv6 is unavailable. While this maintains the current set of issues for IPv4 connections, it reestablishes the end-to-end principle for IPv6 connections.
しかし、同時に、NATの機能性はIPv6の展開で重大なまとめ役であるかもしれません。 既に、IPv4をデータ網に実行する1億台以上のコンピュータがあります。 これらのいくつかのネットワークに関連づけられます、そして、その結果、インターネットといくつかの一部が私設の孤立しているネットワークにあります。 私たちが同時に「旗の日」を持って、既存のIPv4ノードのすべてをIPv6に変換できたのは、思いもよりません。 IPv4とIPv6の両方がインターネットと私設のネットワークに使用されている間、非常に長い期間の共存があるでしょう。 また、新しいIPv6ノードがIPv4を実行できるのをさせながら大いに当てにされたオリジナルのIPv6変遷プラン--「デュアルスタック」アプローチ。 デュアルスタックノードがDNSの別のノードを調べると、それは応答におけるIPv4かIPv6アドレスを取り戻すでしょう。 応答がIPv4アドレスであるなら、ノードは、もう片方のノードに連絡するのにIPv4を使用します。 そして、応答がIPv6アドレスであるなら、接触を作るのにIPv6を使用できます。 NATを6to4[13]ルータに変えると、IPv6の広範囲の展開はIPv6が入手できないならIPv4経路を提供している間、可能にされます。 これはIPv4接続のために現在のセットの問題を維持しますが、それはIPv6接続のために終わりから終わりへの原則を回復させます。
Hain Informational [Page 21] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[21ページ]のRFC2993建築含意
An alternative methodology would be to translate the packets between IPv6 and IPv4 at the boarders between IPv4 supporting networks and IPv6 supporting networks. The need for this functionality was recognized in [RFC 1752], the document that recommended to the IETF that IPv6 be developed and recommended that a set of working groups be established to work on a number of specific problems. Header translation (i.e, NAT) was one of those problems.
代替の方法論はネットワークをサポートしながらネットワークをサポートするIPv4とIPv6の間の寮生でIPv6とIPv4の間のパケットを翻訳するだろうことです。 この機能性の必要性は[RFC1752]で認識されました、IPv6が開発されることをIETFに勧めて、1セットのワーキンググループが多くの特定の問題に取り組むために設立されることを勧めたドキュメント。ヘッダー翻訳(i.e、NAT)はそれらの問題の1つでした。
Of course, NATs in an IPv6 to IPv4 translation environment encounter all of the same problems that NATs encounter in a pure IPv4 and the environment and cautions in this document apply to both situations.
もちろん、IPv4翻訳環境へのIPv6のNATsはNATsが純粋なIPv4で行きあたる同じ問題のすべてに遭遇します、そして、環境と警告は本書では両方の状況に適用されます。
9. Security Considerations
9. セキュリティ問題
NAT (particularly NAPT) actually has the potential to lower overall security because it creates the illusion of a security barrier, but does so without the managed intent of a firewall. Appropriate security mechanisms are implemented in the end host, without reliance on assumptions about routing hacks, firewall filters, or missing NAT translations, which may change over time to enable a service to a neighboring host. In general, defined security barriers assume that any threats are external, leading to practices that make internal breaches much easier.
NAT(特にNAPT)は、それがセキュリティバリアの幻想を引き起こすので実際に総合的なセキュリティを下げる可能性を持っていますが、ファイアウォールの管理された意図なしでそうします。 適切なセキュリティー対策は終わりのホストで実装されます、時間がたつにつれて隣接しているホストに対するサービスを可能にするために変化するかもしれないルーティングハッキング、ファイアウォールフィルタ、またはなくなったNAT翻訳に関する前提への信用なしで。 一般に、内部の不履行をはるかに簡単にする習慣に通じて、定義されたセキュリティバリアは、どんな脅威も外部であると仮定します。
IPsec RFC-2401 [7] defines a set of mechanisms to support packet- level authentication and encryption for use in IP networks. While this may be less efficient than application-level security but in the words of RFC-1752 [14] "support for basic packet-level authentication will provide for the adoption of a much needed, widespread, security infrastructure throughout the Internet."
IPsec RFC-2401[7]は、IPネットワークにおける使用のためのパケットレベル認証と暗号化をサポートするために1セットのメカニズムを定義します。 [14] これがアプリケーションレベルセキュリティほど効率的であるのではなく、RFC-1752の単語で効率的であるかもしれない間、「基本的なパケット・レベル認証のサポートはインターネット中の多くの必要で、広範囲のセキュリティインフラストラクチャの採用に備えるでしょう」。
NATs break IPsec's authentication and encryption technologies because these technologies depend on an end-to-end consistency of the IP addresses in the IP headers, and therefore may stall further deployment of enhanced security across the Internet. NATs raise a number of specific issues with IPsec. For example;
これらの技術がIPヘッダーで終わりから終わりへのIPアドレスの一貫性に依存して、したがって、インターネットの向こう側に警備の強化のさらなる展開を遅らせるかもしれないので、NATsはIPsecの認証と暗号技術を破ります。 NATsはIPsecの多くの特定の問題を提起します。 例えば。
- Use of AH is not possible via NAT as the hash protects the IP
address in the header.
- Authenticated certificates may contain the IP address as part of
the subject name for authentication purposes.
- Encrypted Quick Mode structures may contain IP addresses and ports
for policy verifications.
- The Revised Mode of public key encryption includes the peer
identity in the encrypted payload.
- ハッシュがヘッダーにIPアドレスを保護するとき、AHの使用はNATで可能ではありません。 - 認証された証明書は認証目的のための対象の名前の一部としてIPアドレスを含むかもしれません。 - 暗号化されたクィックMode構造は方針検証のためのIPアドレスとポートを含むかもしれません。 - 公開鍵暗号化のRevised Modeは暗号化されたペイロードに同輩のアイデンティティを含んでいます。
Hain Informational [Page 22] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[22ページ]のRFC2993建築含意
It may be possible to engineer and work around NATs for IPsec on a case-by-case basis, but at the cost of restricting the trust model, as discussed in section 4 above. With all of the restrictions placed on deployment flexibility, NATs present a significant obstacle to security integration being deployed in the Internet today.
IPsecのためにNATsの周りでケースバイケースで設計して、働いているのが可能であるかもしれませんが、信頼を制限する費用では、モデル化してください、上のセクション4で議論するように。 制限のすべてが展開の柔軟性に置かれている状態で、NATsは今日インターネットで配布されるセキュリティ統合に重要な障害を提示します。
As noted in the RFC-2694 [15], the DNS/ALG cannot support secure DNS name servers in the private domain. Zone transfers between DNSsec servers will be rejected when necessary modifications are attempted. It is also the case that DNS/ALG will break any modified, signed responses. This would be the case for all public side queries of private nodes, when the DNS server is on the private side. It would also be true for any private side queries for private nodes, when the DNS server is on the public side. Digitally signed records could be modified by the DNS/ALG if it had access to the source authentication key. DNSsec has been specifically designed to avoid distribution of this key, to maintain source authenticity. So NATs that use DNS/ALG to repair the namespace resolutions will either; break the security when modifying the record, or will require access to all source keys to requested resolutions.
RFC-2694[15]に述べられるように、DNS/ALGは、個人的なドメインで安全なDNSがネームサーバであるとサポートすることができません。 必要な変更が試みられるとき、DNSsecサーバの間のゾーン転送は拒絶されるでしょう。 また、DNS/ALGがどんな変更されて、署名している応答も壊すのは、事実です。 これは個人的なノードのすべての公共のサイド質問のためのそうでしょう、DNSサーバが少し個人的であるときに。 また、個人的なノードのためのどんな個人的なサイド質問にも、それも本当でしょう、DNSサーバが少し公共であるときに。 ソース認証キーに近づく手段を持っているなら、DNS/ALGはデジタルに署名している記録を変更できるでしょうに。 DNSsecは、このキーの分配を避けて、ソースの信憑性を維持するように明確に設計されています。 それで、名前空間解決を修理するのにDNS/ALGを使用するNATsはそうするでしょう。 記録を変更するときにはセキュリティを壊してください、または要求された解決のすべてのソースキーへのアクセスを必要とするでしょう。
Security mechanisms that do not protect or rely on IP addresses as identifiers, such as TLS [16], SSL [17], or SSH [18] may operate in environments containing NATs. For applications that can establish and make use of this type of transport connection, NATs do not create any additional complications. These technologies may not provide sufficient protection for all applications as the header is exposed, allowing subversive acts like TCP resets. RFC-2385 [19] discusses the issues in more detail.
TLS[16]、SSL[17]、またはSSH[18]などの識別子としてIPアドレスを保護しないか、または当てにしないセキュリティー対策はNATsを含む環境で動作するかもしれません。 このタイプの輸送接続を確立して、利用できるアプリケーションのために、NATsは少しの追加複雑さも作成しません。 ヘッダーがさらされているとき、これらの技術はすべてのアプリケーションのための十分な保護を提供しないかもしれません、TCPリセットのような破壊活動を許容して。 RFC-2385[19]はさらに詳細に問題に取り組みます。
Arguments that NATs may operate in a secure mode preclude true End- to-End security, as the NAT becomes the security endpoint. Operationally the NAT must be managed as part of the security domain, and in this mode the packets on the unsecured side of the NAT are fully exposed.
NATsが安全なモードで作動するかもしれないという主張は終わりまでの本当のEndセキュリティを排除します、NATがセキュリティ終点になるとき。 操作上、セキュリティー領域の一部としてNATを管理しなければなりません、そして、このモードで、NAT非機密保護する側の上のパケットは完全に暴露されます。
10. Deployment Guidelines
10. 展開ガイドライン
Given that NAT devices are being deployed at a fairly rapid pace, some guidelines are in order. Most of these cautionary in nature and are designed to make sure that the reader fully understands the implications of the use of NATs in their environment.
NATデバイスがかなり急速なペースで配布されているなら、いくつかのガイドラインが整然としています。 そして、だいたい、これら、警告的である、現実、読者が彼らの環境におけるNATsの使用の含意を完全に理解しているのを確実にするために、設計されています。
- Determine the mechanism for name resolution, and ensure the
appropriate answer is given for each address administration.
Embedding the DNS server, or a DNS ALG in the NAT device will
likely be more manageable than trying to synchronize independent
DNS systems across administrations.
- 名前解決のためにメカニズムを決定してください、そして、適切な答えが各アドレス管理のために与えられているのを確実にしてください。 サーバ、またはNATデバイスのDNS ALGが埋め込むDNSを埋め込んで、政権の向こう側に独立しているDNSシステムを同期させようとするよりおそらく処理しやすくいてください。
Hain Informational [Page 23] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[23ページ]のRFC2993建築含意
- Is the NAT configured for static one to one mappings, or will it
dynamically manage them? If dynamic, make sure the TTL of the DNS
responses is set to 0, and that the clients pay attention to the
don't cache notification.
- Will there be a single NAT device, or parallel with multiple paths?
If single, consider the impact of a device failure. If multiple,
consider how routing on both sides will insure the packets flow
through the same box over the connection lifetime of the
applications.
- Examine the applications that will need to traverse the NAT and
verify their immunity to address changes. If necessary provide an
appropriate ALG or establish a VPN to isolate the application from
the NAT.
- Determine need for public toward private connections, variability
of destinations on the private side, and potential for simultaneous
use of public side port numbers. NAPTs increase administration if
these apply.
- Determine if the applications traversing the NAPT or RSIP expect
all ports from the public IP address to be the same endpoint.
Administrative controls to prevent simultaneous access from
multiple private hosts will be required if this is the case.
- If there are encrypted payloads, the contents cannot be modified
unless the NAT is a security endpoint, acting as a gateway between
security realms. This precludes end-to-end confidentiality, as the
path between the NAT and endpoint is exposed.
- Determine the path for name resolutions. If hosts on the private
side of a NAPT or RSIP server need visibility to each other, a
private side DNS server may be required.
- If the environment uses secure DNS records, the DNS/ALG will
require access to the source authentication keys for all records to
be translated.
- When using VPNs over NATs, identify a clearinghouse for the private
side addresses to avoid collisions.
- Assure that applications used both internally and externally avoid
embedding names, or use globally unique ones.
- When using RSIP, recognize the scope is limited to individual
private network connecting to the public Internet. If other NATs
are in the path (including web-server load-balancing devices), the
advantage of RSIP (end-to-end address/port pair use) is lost.
- For RSIP, determine the probability of TCP_Time_Wait collisions
when subsequent private side hosts attempt to contact a recently
disconnected public side service.
- NATが静的な1〜1つのマッピングのために構成されますか、またはそれはダイナミックにそれらを管理するでしょうか? ダイナミックであるなら、DNS応答のTTLが0、およびそれへのクライアントが注意を向けるセットであることを確実にしてください、通知をキャッシュしないでください。 - 単一のNATデバイス、または類似が複数の経路と共にあるでしょうか? 単一であるなら、デバイスの故障の影響を考えてください。 複数なら、両側でのルーティングがどのようにアプリケーションのコネクション存続期間の間の同じ箱を通したパケット流動を保障するか考えてください。 - NATを横断して、変化を扱うためにそれらの免疫について確かめる必要があるアプリケーションを、調べてください。 必要なら、適切なALGを提供するか、またはVPNを設立して、NATからアプリケーションを隔離してください。 - 個人的な接続に向かった公衆の必要性、個人的側の上の目的地の可変性、および公共のサイドポートナンバーの同時の使用の可能性を測定してください。 これらが適用されるなら、NAPTsは管理を増強します。 - NAPTかRSIPを横断するアプリケーションが、公共のIPアドレスからのすべてのポートが同じ終点であると予想するかどうか決定してください。 複数の個人的なホストから同時アクセスを防ぐ運営管理コントロールがこれがそうであるなら必要でしょう。 - 暗号化されたペイロードがあって、NATがセキュリティ終点でないならコンテンツを変更できません、セキュリティ分野の間のゲートウェイとして機能して。これは終わりから終わりへの秘密性を排除します、NATと終点の間の経路が暴露されるとき。 - 名前解決のために経路を決定してください。 NAPTかRSIPサーバ個人的側の上のホストが互いに目に見えることを必要とするなら、個人的なサイドDNSサーバが必要であるかもしれません。 - 環境が安全なDNS記録を使用すると、DNS/ALGは、すべての記録が翻訳されるためにソース認証キーへのアクセスを必要とするでしょう。 - NATsの上でVPNsを使用するときには情報センターを特定して、個人的なサイドアドレスは衝突を避けてください。 - 内部的に外部的に使用されるアプリケーションが、名前を埋め込むのを避けると安心するか、またはグローバルにユニークなものを使用してください。 - RSIPを使用するときには、範囲が公共のインターネットとの個々の個人的なネットワーク接続に制限されると認めてください。 他のNATsが経路にあるなら(ウェブサーバー負荷分散デバイスを含んでいて)、RSIP(終わりから端へのアドレス/ポート組使用)の利点は無くなっています。 - RSIPに関しては、その後の個人的なサイドホストが、最近切断している公共のサイドサービスに連絡するのを試みるときにはTCP_Time_Wait衝突の確率を測定してください。
Hain Informational [Page 24] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[24ページ]のRFC2993建築含意
11. Summary
11. 概要
Over the 6-year period since RFC-1631, the experience base has grown, further exposing concerns raised by the original authors. NAT breaks a fundamental assumption of the Internet design; the endpoints are in control. Another design principle, 'keep-it-simple' is being overlooked as more features are added to the network to work around the complications created by NATs. In the end, overall flexibility and manageability are lowered, and support costs go up to deal with the problems introduced.
RFC-1631以来の6年の期間、さらに原作者によって高められた関心を暴露して、経験ベースは発展しています。 NATはインターネットデザインの基本的仮説を破ります。 終点はコントロール中です。 別の設計原理、より多くの特徴がNATsによって作成された複雑さの周りで扱うネットワークに追加されるとき、'それを簡単に保ってください'は見落とされています。 結局、総合的な柔軟性と管理可能性は下げられます、そして、サポートコストは紹介される問題との取引に上がります。
Evangelists, for and against the technology, present their cases as righteous while downplaying any rebuttals.
四福音書の著者はどんな反論も控え目に扱っている間、公正であるとして技術を支持して技術に対して彼らのケースを提示します。
- NATs are a 'fact of life', and will proliferate as an enhancement
that sustains the existing IPv4 infrastructure.
- NATs are a 'necessary evil' and create an administrative burden
that is not easily resolved. More significantly, they inhibit the
roll out of IPsec, which will in turn slow growth of applications
that require a secure infrastructure.
- NATsは'現実'であり、既存のIPv4インフラストラクチャを支える増進として増殖するでしょう。 - NATsは'必要悪'であり、容易に決議されていない管理負担を作成します。 よりかなり、彼らはIPsecからロールを禁止します。(IPsecは順番に安全なインフラストラクチャを必要とするアプリケーションの伸び悩みを望んでいます)。
In either case, NATs require strong applicability statements, clearly declaring what works and what does not.
どちらの場合ではも、NATsは強い適用性証明、明確に働いていることを宣言して、およびすることを必要とします。
An overview of the pluses and minuses:
プラスとマイナスの概要:
NAT advantages NAT disadvantages
-------------------------------- --------------------------------
Masks global address changes Breaks end-to-end model
Eases renumbering when providers Facilitates concatenation of
change multiple name spaces
Breaks IPsec
Stateful points of failure
Address administrations avoid Requires source specific DNS reply
justifications to registries or DNS/ALG
DNS/ALG breaks DNSsec replies
Lowers address utilization Enables end-to-end address
conflicts
Lowers ISP support burden Increases local support burden and
complexity
Transparent to end systems in some Unique development for each app
cases
Load sharing as virtual host Performance limitations with scale
Delays need for IPv4 replacement May complicate integration of IPv6
NAT利点NAT損失-------------------------------- -------------------------------- 仮面グローバルアドレス変化Breaks終わりから終わりへのモデル複数の名前空間Breaks IPsec Statefulが指す失敗Address政権の変化のプロバイダーFacilitates連結であるときに番号を付け替えるEasesがRequiresのソースの特定のDNS回答正当化を登録として避けるか、またはDNS/ALG DNS/ALGはLowersが扱うDNSsec回答を壊します; スケールDelaysとの仮想のホストパフォーマンス制限がIPv4交換に5月を必要としながら共有する各装置ケースLoadのための何らかのUnique開発にシステムを終わらせる終わりから終わりとの利用Enablesアドレス闘争のLowers ISPサポート負担のIncreasesの地方のサポート負担と複雑さTransparentはIPv6の統合を複雑にします。
Hain Informational [Page 25] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[25ページ]のRFC2993建築含意
There have been many discussions lately about the value of continuing with IPv6 development when the market place is widely deploying IPv4 NATs. A shortsighted view would miss the point that both have a role, because NATs address some real-world issues today, while IPv6 is targeted at solving fundamental problems, as well as moving forward. It should be recognized that there will be a long co- existence as applications and services develop for IPv6, while the lifetime of the existing IPv4 systems will likely be measured in decades. NATs are a diversion from forward motion, but they do enable wider participation at the present state. They also break a class of applications, which creates the need for complex work-around scenarios.
最近、市場が広くIPv4 NATsを配布しているときIPv6開発を続行する値に関して多くの議論がありました。 小乗的見地は両方には役割があるというポイントを逃すでしょう、NATsが、今日何らかの本当の世界が問題であると扱うので、IPv6は前方へ動くことと同様に基本的な問題を解決するのに狙いますが。 アプリケーションとサービスがIPv6のために展開するので長い共同存在があると認められるべきです、既存のIPv4システムの寿命は何10年間も後におそらく測定されるでしょうが。 NATsは前進運動からの転換ですが、彼らは現状で、より広い参加を可能にします。 また、彼らはアプリケーションのクラスを壊します。(それは、複雑な回避策シナリオの必要性を作成します)。
Efforts to enhance general security in the Internet include IPsec and DNSsec. These technologies provide a variety of services to both authenticate and protect information during transit. By breaking these technologies, NAT and the DNS/ALG work-around, hinder deployment of enhanced security throughout the Internet.
インターネットにおける総合証券を高める取り組みはIPsecとDNSsecを含んでいます。 これらの技術は、トランジットの間、ともに情報を認証して、保護するためにさまざまなサービスを提供します。 これらの技術、NAT、およびDNS/ALG回避策を破ることによって、インターネット中で警備の強化の展開を妨げてください。
There have also been many questions about the probability of VPNs being established that might raise some of the listed concerns. While it is hard to predict the future, one way to avoid ALGs for each application is to establish a L2TP over the NATs. This restricts the NAT visibility to the headers of the tunnel packets, and removes its effects from all applications. While this solves the ALG issues, it raises the likelihood that there will be address collisions as arbitrary connections are established between uncoordinated address spaces. It also creates a side concern about how an application establishes the necessary tunnel.
また、記載された関心のいくつかを高めるかもしれない設立されるVPNsの確率に関する多くの質問がありました。 各アプリケーションのためにALGsを避ける1つの方法は未来について予言しにくい間、NATsの上にL2TPを設立することです。 これは、NAT目に見えることをトンネルパケットのヘッダーに制限して、すべてのアプリケーションから効果を移します。 これはALG問題を解決しますが、それは任意の接続が非調整されたアドレス空間の間で確立されるのでアドレス衝突があるという見込みを上げます。 また、それはアプリケーションがどう必要なトンネルを確立するかに関するサイド心配を引き起こします。
The original IP architecture is powerful because it provides a general mechanism on which other things (yet unimagined) may be built. While it is possible to build a house of cards, time and experience have lead to building standards with more structural integrity. IPv6 is the long-term solution that retains end-to-end transparency as a principle. NAT is a technological diversion to sustain the lifetime of IPv4.
他のもの(しかし、非想像した)が造られるかもしれない一般的機構を提供するので、オリジナルのIPアーキテクチャは強力です。 砂上の楼閣を建てるのが可能である間、時間と経験は建築基準にリードをより構造的な保全と共に持っています。 IPv6は原則として終わりから終わりへの透明を保有する長期的な解決法です。 NATはIPv4の生涯を支える技術的な転換です。
Hain Informational [Page 26] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[26ページ]のRFC2993建築含意
12. References
12. 参照
1 Bradner, S., " The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
1 ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
2 Egevang, K. and P. Francis, "The IP Network Address Translator",
RFC 1631, May 1994.
2 EgevangとK.とP.フランシス、「IPネットワークアドレス変換機構」(RFC1631)は1994がそうするかもしれません。
3 Srisuresh, P. and M. Holdrege, "NAT Terminology and
Considerations", RFC 2663, August 1999.
3 Srisuresh、P.、M.Holdrege、および「NAT用語と問題」、RFC2663、8月1999日
4 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
4 Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
5 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behavior Today", RFC 2101, February 1997.
5大工とB.とクロウクロフトとJ.とY.Rekhter、「IPv4は今日振舞いを扱う」RFC2101、1997年2月。
6 M. Borella, D. Grabelsky, J., K. Tuniguchi, "Realm Specific IP:
Protocol Specification", Work in Progress, March 2000.
6M.Borella、D.Grabelsky、J.、K.Tuniguchi、「分野の特定のIP:」 「プロトコル仕様」、処理中の作業、2000年3月。
7 Kent, S. and R. Atkinson, "Security Architecture for IP", RFC
2401, November 1998.
7 ケントとS.とR.アトキンソン、「IPのためのセキュリティー体系」、RFC2401、1998年11月。
8 Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
8大工、B.、「インターネット透明」、RFC2775、2000年2月。
9 Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC
2050, November 1996.
9 ハバードとK.とKostersとM.とコンラッドとD.とKarrenbergとD.とJ.ポステル、「インターネット登録IP配分ガイドライン」、BCP12、RFC2050、1996年11月。
10 Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
10 ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
11 Jacobson, V., Braden, R. and L. Zhang, "TCP Extension for High-
Speed Paths", RFC 1185, October 1990.
11 ジェーコブソンとV.とブレーデンとR.とL.チャン、「高い速度経路のためのTCP拡張子」、RFC1185、1990年10月。
12 Braden, R., "Requirements for Internet Hosts", STD 3, RFC 1123,
October 1989.
12 ブレーデン、R.、「インターネットホストのための要件」、STD3、RFC1123、1989年10月。
13 Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels", Work in Progress.
13大工とB.とK.ムーア、「Explicit TunnelsのいないIPv4 Cloudsを通したIPv6 Domainsの接続」、ProgressのWork。
14 Bradner, S. and A. Mankin, "Recommendation for IPng", RFC 1752,
January 1995.
14 ブラドナーとS.とA.マンキン、「IPngのための推薦」、RFC1752、1995年1月。
15 Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS
extensions to NAT", RFC 2694, September 1999.
15 SrisureshとP.とTsirtsisとG.とAkkirajuとP.とA.ヘファーナン、「NATへのDNS拡張子」、RFC2694、1999年9月。
Hain Informational [Page 27] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[27ページ]のRFC2993建築含意
16 Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
1999.
16 DierksとT.とC.アレン、「TLSプロトコル」、RFC2246、1999年1月。
17 http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996.
17 1996年3月の http://home.netscape.com/eng/ssl3/ssl-toc.html 。
18 T. Ylonen, et al., "SSH Protocol Architecture", Work in Progress,
August 1998.
18 T.Ylonen、他、「セキュアシェル (SSH)プロトコルアーキテクチャ」、Progress、1998年8月のWork。
19 Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
19 ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
13. Acknowledgments
13. 承認
Valuable contributions to this document came from the IAB, Vern Paxson (lbl), Scott Bradner (harvard), Keith Moore (utk), Thomas Narten (ibm), Yakov Rekhter (cisco), Pyda Srisuresh, Matt Holdrege (lucent), and Eliot Lear (cisco).
このドキュメントへの有価約因はIAB、バーン・パクソン(lbl)、スコット・ブラドナー(harvard)、キース・ムーア(utk)、トーマスNarten(ibm)、ヤコフRekhter(コクチマス)、Pyda Srisuresh、マットHoldrege(透明な)、およびエリオットリア(コクチマス)から来ました。
14. Author's Address
14. 作者のアドレス
Tony Hain Microsoft One Microsoft Way Redmond, Wa. USA
トニーハインマイクロソフト1マイクロソフト道、レッドモンド、Wa。 米国
Phone: 1-425-703-6619 EMail: tonyhain@microsoft.com
以下に電話をしてください。 1-425-703-6619 メールしてください: tonyhain@microsoft.com
Hain Informational [Page 28] RFC 2993 Architectural Implications of NAT November 2000
NAT2000年11月のハインInformational[28ページ]のRFC2993建築含意
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Hain Informational [Page 29]
ハインInformationalです。[29ページ]
一覧
スポンサーリンク
