Network Working Group T. Hain
Request for Comments: 2993 Microsoft
Category: Informational November 2000
Architectural Implications of NAT
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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
13. Acknowledgments.............................................. 28
14. Author's Address............................................. 28
15. Full Copyright Statement..................................... 29
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アドレス利用の成長速度を容易にするための手段として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年後と予測にもかかわらず、NATのの使用はインターネットで普及しつつあります。一部の人々はインターネットのアドレス可用性の問題のいくつかの短期的および長期的な解決策の両方として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 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.
いずれの場合では、明確なNATは、IPヘッダの一貫性に依存するトランスポートのために、およびIPヘッダ以外の場所で、そのアドレス情報を搬送するプロトコルのためのエンドツーエンド接続の透明度に影響を与えています。一貫して構成されているアプリケーションの特定のゲートウェイ（ALGの）のパッチワークを使用して、エンドポイントがNATの運用上の課題のいくつかを回避することができます。これらの運用上の課題は、ネットワークとアプリケーションのトポロジ及び使用中の特定のアプリケーションを含む多くの要因に基づいて変化します。なし並列冗長NATデバイスとの介在するネットワーク上で実行されている2つのエンドポイント間のトラフィックで、最も単純なケースに対処するために、比較的簡単にすることができます。並列冗長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のカジュアルな使用を容易にする（RFC-2663 [3]、また、「アドレスレルム」を参照）、独立したアドレス投与にインターネットを分割することである[4]。カーペンターらのRFC-2101によって示されるように、プライベート使用アドレスがネットワーク内に配備された後、[5]、アドレスが曖昧であることが保証されました。シンプルなNATのがネットワークに挿入されている場合たとえば、またはアドレスから名前を解決するプロセスは、質問がされた場所に依存するようになります。この除算の結果は、サーバはパブリックアドレスレルム内に存在する必要がある場所（ピア/ピア対）は、クライアント/サーバアーキテクチャを強制することです。
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.
インターネットの成功の重要な要因は、いくつかの基本的な教義から派生柔軟性です。最前特定の機能のみ、彼らは通信の制御であり、したがって、エンドポイントで実行することができ、ネットワークの間のビットを移動する単純なデータグラムサービスであることを指摘し（さらに後述する）エンドツーエンド原理は、ありますこれらの点。言い直すと、エンドポイントのアプリケーションは、多くの場合、正しくデータ・ストリームを管理できる唯一の場所です。下位層のパケット転送装置からこの問題を削除すると、システム全体の効率化に貢献する、転送処理を効率化。
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.
もう一つの利点は、ネットワークが接続状態情報ごとに保持していないということです。これは、代替パスを通って、ネットワーク全体のより良いスケーリングに失敗周りに高速再ルーティングを可能にします。状態の欠如はまた、エンドポイント接続が形成されるか、または廃棄されたようにお互いに通知するためにネットワークノードのための任意の必要性を除去します。さらに、エンドポイントではありません、そして、先、最初のホップルータ（複数可）、および任意の名前解決サービス以外のネットワーク・コンポーネントを意識する必要はありません。パケットの整合性は、ネットワークを介して保持され、かつ輸送チェックサムと任意のアドレスに依存するセキュリティ機能は、エンドツーエンドの有効です。
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としてNATの変異体は、[6]最近のエンドツーエンドの懸念の一部に対処するために提案されてきました。これらの提案は、パブリックアドレス（ポートが使用可能な場合）とプライベート・ノードを提供するのに効果的であるかもしれないが、彼らは、TCP_TIME_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.
明確にフロントまで明記されなければならないことの一つは、単純なルータの交換が展開する前に対処すべきいくつかの重要な問題を作成することができますようNATのバリアントを使用しようとすること、です。このドキュメントの目標は、意識を高める目的でこれらを議論することです。
Recognizing that many of these terms are defined in detail in RFC 2663 [3], the following are summaries as used in this document.
本書で使用されるこれらの用語の多くは要約を[3]は、以下のRFC 2663に詳細に定義されていることを認識する。
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 - シンプルな形でのネットワークアドレス変換は、IPアドレスが別のアドレス管理からマッピングされる方法です。それが唯一の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 - シンプルなNATとALG機能を兼ね備えています。それは純粋なNATを介して動作しません、特定のアプリケーションのための部品を埋め込んでいるため、純粋なNATより一般的に、より便利。
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 - DNSサービスのALGは、DNS応答の内容を変更するNATコンポーネントと対話NAT / ALGの特殊なケース。
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は - ネットワークアドレスポート変換は、同時に他の上の単一のアドレスのトランスポート識別子に、片側から複数のアドレスの多重化トランスポート・レベルの識別子で翻訳を達成します。 RFC-2663の4.1.2を参照してください。これは、共有し、単一の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 - レルム固有の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 - このドキュメントの目的のために、仮想プライベートネットワークは技術的には、エンドポイントは、彼らが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認証ヘッダは、RFC-2401 [7]。
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.
ESP - カプセル化セキュリティペイロードプロトコル、RFC 2401は、データの機密性（暗号化）、および限定されたトラフィックフローの機密性を提供することができます。また、データの整合性、データ発信元認証、およびアンチリプレイサービスを提供することができます。
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用語で定義された。）NATは、アドレス割り当て権限を配布し、別の投与のものに一つのアドレス管理からアドレスをマッピングするメカニズムを提供するための手段を用いています。
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.
インターネット上のNATのアーキテクチャの影響を議論では、最初のタスクは、インターネットの範囲を定義しています。最も基本的な定義があります。ネットワークの連結は、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.)
パブリックまたはプライベートの最終的な解決は、問題のネットワークの意図に含まれています。一般的に、より大きなインターネットの一部であることを意図していないネットワークでは、バリアを挿入するために、いくつかのスクリーニング技術を使用します。パブリックおよびプライベートネットワーク間の歴史的障壁デバイスは、ファイアウォールやアプリケーションゲートウェイとして知られていた、と他のすべてを遮断しながら、承認されたトラフィックを許可するように管理されていました。ますます、スクリーニング技術の一部は、パブリックおよびプライベート使用アドレス空間の間のネットワークロケータを管理NAT、で、その後、のALGを使用すると、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 connection since the NATs have to be coordinated to ensure that they have a consistent understanding of address mapping for each individual device.
RFC-1631は、公衆インターネットの付属をスタブするNATの議論の範囲を制限され、それは、インターネットの残りの部分への単一の接続を持つネットワークです。ネットワークは、インターネットの残りの部分に複数の接続を持っている状況でのNATの使用は非常に複雑NATのは、彼らがためのアドレスマッピングの一貫した理解を持っていることを確実にするために調整する必要があるため、単一の接続があるときよりも個々のデバイス。
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.
エンドツーエンドモデルの概念は、インターネット透明でカーペンターによって見直される[8]。重要な点の一つは、「状態は、エンドポイント自体が壊れるときの状態のみ破壊することができるように、エンドポイントのみで維持されなければならない」です。これは、「運命の共有」と呼ばれています。運命の共有の背後にある目標は、堅牢性を確保することです。ネットワークのサイズが大きくなるように、接続に影響を与える部品の故障の可能性がますます頻繁になっています。障害が通信の損失につながる場合は、キーの状態が失われているため、ネットワークはますます脆くなり、その有用性が低下します。エンドポイント自体に障害が発生した場合は、その後、とにかくその後の通信の見込みはありません。したがって、エンドツーエンドモデルは、可能な限り、唯一のエンドポイントは臨界状態を保持すべきであると主張しています。
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.
NATのために、エンドツーエンドモデルのこの側面は、重要なインフラストラクチャ要素になってきてNATに変換：それが失敗した場合には、十分な注意が、その状態の一貫性、保存安定性を確保するために取られない限り、それを介してすべての通信は、失敗した、と、それが回復した場合にも（NATは、もはや同じマッピングを使用して、それを翻訳するため）、それを通過した通信は失敗しません。故障のこの後者のタイプは、ルータの故障よりも深刻であることに留意されたいです。ルータが回復したときに、それは以前転送されていたすべての通信が正常に介して転送し続けることができます。
There are other important facets to the End-to-End model:
エンドツーエンドのモデルに他の重要な面があります。
- 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.
- 状態はネットワークの内部に保持されているときに何とか状態がまだ効率的かつタイムリーな一貫で行うことは非常に困難になる可能性がフェイル・オーバーポイントに複製されていない限り、その状態に依存トラフィックは、障害を迂回することはできませんファッション。 - 大きなサイズにネットワークをスケーリングするための重要な原則は、ネットワークのエッジに出状態保持をプッシュすることです。状態は、ネットワークのコア内の要素によって保持されている場合、ネットワーク状態の量を成長するように、その後の要素は、同様に成長を保持しなければなりません。要素の容量は厳しい難所とも成長障害の影響を受けた接続の数になることができます。 - セキュリティ状態は、ネットワーク内部に保持しなければならないならば、ネットワークがサポートになる可能性のある信頼モデルが制限された、（下の説明を参照してください）。
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?)
エンドポイントがネットワーク・サービス・プロバイダーを信頼しない必要のあるネットワークがないものよりもはるかに多くのセキュリティ上の柔軟性を持っています。 （写真は、例えば、ビジネス旅行者は、彼らのホームオフィスに戻って自分のホテルの部屋から接続している：彼らはセキュリティキーで、ホテルのネットワークのスタッフを信頼する必要があります？、またはそのネットワーキングサービスでホテルを提供する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セキュリティ認証ヘッダは、ネットワークヘッダのアドレスは、エンドツーエンド保存されていることを前提としているので、一つを介して通信するホストのペア間でIPセキュリティベースの認証をサポートすることができるかは明らかではありませんALGまたはNATのいずれか。
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つのホストが第二のホストが接続する必要があります別のアドレスとポートに送信するために実際に、彼らの追加の制御とデータ接続を管理するために、このようなアプリケーションのための標準的な技術があります。 NATは、これらのアプリケーションを破ります。同様に、NAPTとRSIPのようなすべての上部同じエンドポイントに指定されたIPアドレスマップからレイヤポート、及びポート多重化技術は、これらを破ることを前提とし、他の用途があります。例えば、Webサーバは、ポート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.
今日は新しいアプリケーションが最初のインフラストラクチャ要素へのアップグレードを必要とせず、エンドポイント上で実行することができる容易さに起因して、インターネットの成功の多く：このようなアプリケーションを制限することはマイナーな問題ではありません。新しいアプリケーションが普及展開を実現するために、アップグレードのNATを持たなければならない場合には、迅速な展開が妨げられ、そして技術革新のペースは鈍化しています。
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.
- ダイヤルアクセスまたはプロバイダのいずれかの変化から、場所を取るアドレス変更をマスキングすることにより、リナンバリングを回避することにより、ローカルネットワークへの影響を最小限に抑えます。 - グローバルにルーティング可能なアドレスは、断続的なアクセスの顧客のために再利用することができます。これは、アクティブなノードの数ではなく、ノードの合計数に向かってアドレスの需要を押します。
- 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が提供してアクセスインターフェイスの顧客端で知られた構成と一致し、簡易な装置があるかもしれないので、NATのサポートの負担を低下さマネージド可能性があります。 - アドレス当局のコレクションにインターネットを破壊する割り当ての継続的な正当化の必要性は、ネットワーク管理者は、このような可変長サブネットなどのより高度なルーティング技術の使用を回避することを可能に制限します。 - ホストの変更は、パケットヘッダの整合性に依存している、またはペイロードにIPアドレスを携帯していないアプリケーションのために必要ではないかもしれません。 - すべてのポートにパケットフィルタリングファイアウォール、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がNATのは、サポートコストを下げるだろう提供することが可能です。
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 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の動機の一部は、現在のIPv4インターネットに固有のリナンバリングの高コストを回避することです。 IPv4の割り当てのためのガイドラインは、RFC-2050に取り組む[9] ISPの顧客は現在、彼らは新しいISPに切り替えたい場合は、自社のネットワークの番号を変更する必要があるということを意味します。 NAT（またはNAT機能を持つファイアウォール）を使用すると、IPアドレスが直面しているだけで、インターネットを変更する必要があり、内部ネットワーク・ノードを再構成する必要がないことを意味します。 NATにアドレス管理をローカライズすることはリナンバリングのコストを最小限に抑えると同時に、現在の割り当てガイドラインの下で利用可能であるよりも、アドレスのはるかに大きいローカルプールのために用意されています。 IPv6は準備ができたり、新たなになるまで（レジストリガイドラインはIPv4アドレス空間の寿命を延長し、ルーティングテーブルの成長を管理することが意図されている、ルーティング技術は、ルーティングテーブルの上に圧力を軽減します。これは、実際の需要に合わせて、割り当てを管理することにより達成され、強制します現在のガイドラインの階層取り組む。不幸な副産物は、彼らが潜在的な買いだめから本当の必要性を整理することが困難な地域での成長を妨げてしまうことがある。）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.
もう一つの人気の練習は（すなわち：Webホストの負荷分散）単一のIPアドレスの後ろに組み合わせたサービスを提供するホストの集合を隠しています。アドレスはその場で実際の宛先にマッピングされているので、多くの実装では、これは、アーキテクチャNATです。パケットヘッダの整合性が問題にならない場合は、エンドクライアントは、マッピング・アクティビティを認識していないことから、仮想ホストのこのタイプは、リモートアプリケーションへの変更を必要としません。仮想ホストは、マシンの全体集合のCPUの性能特性を有しているが、それは前後にパケットを漏斗として、処理およびI / NAT / ALGデバイスのO機能は、全体的なパフォーマンスを結合しました。
- 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.
- NATは、インターネットの柔軟なエンドツーエンドモデルを破ります。 - NATは接続状態と動的マッピング情報を維持する装置において、運命が共有される単一のポイントを作成します。 - NATは自分のインターネット接続の信頼性を高めるために、サイトによってマルチホーミングの使用を複雑にします。 （単一ルータは運命の共有のポイントですが、ルータの状態の欠如は些細な冗長性を作成します確かに、これは、インターネットプロトコルスイートは、そのネットワーク層として、コネクションレスのデータグラムサービスを使用して開発された理由のである。） - NATのIPレベルでのセキュリティの実装を阻害します。 - NATはプライベートアドレスのカジュアルな使用を可能にします。これらのまとまりのないアドレスは、これらのアドレスを使用して企業が合併または直接VPNを使用して相互接続したい衝突の対象となっています。 - NATは、パブリックDNSで既存のプライベート名前空間を連結促進します。
- 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）公に発表されたサービスは、プライベート側に存在したときに、操作の複雑さを増します。 - NATの複雑な、あるいは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.
設計により、NATは柔軟性に制限を課します。そのため、導入合併症について延長の思考が求められています。これは、NAT機能は、他のパブリックアドレスにIPアドレスを再書き込みなどの負荷分散ルータなどの隠されたサービスであり、製品には特にそうです。アドレスはすべて公に投与のスペースであってもよいので、これらはほとんどのNATとして認識されていないが、彼らは、エンドツーエンドモデルの整合性がちょうど同じ壊れています。
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.
NATは、データストリーム内のIPアドレス（またはアドレス誘導体）を運ぶアプリケーションの展開に制約を置き、彼らは各セッションが独立していることを前提に動作します。しかし、後続のそれらの制御セッションペイロードにおけるセッションの特性を設定するために1つの以上の制御セッションを使用してFTPやH.323などのアプリケーションがあります。他の例としては、コンフィギュレーションのためのSNMP MIBを含み、およびポリシーメッセージをCOPS。これらのようなアプリケーションやプロトコルは、アドレスのエンドツーエンドの整合性を想定し、NATを横断するときに失敗します。 （TCPは、具体的の利点、および再利用、トランスポートアドレスとして使用するためのポートと組み合わせて、IPアドレスを取るように設計されました。）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.
先に述べたように、NATは、エンドポイントは、通信の制御にあるインターネットの基本的な教義を破ります。故障の他に、固有の点はないであろうように、元のデザインは、エンドポイントの状態コントロールを配置しました。それは単一点の故障の影響を増加しながら、ネットワークの特定のノードへのエンドポイントから状態を移動すると、柔軟性を低下させます。下のイラスト1でさらに議論を参照してください。
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.
また、NATは、すべてのアプリケーションに対して透過的ではない、とのALGの大きな配列への同時更新を管理するには、追加のグローバルにルーティング可能なアドレスを取得するコストを上回ることがあります。下のイラスト2でさらに議論を参照してください。
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の問題に対処しながら、パブリックアクセスを必要とする個々のプライベートホストの特定の場合のために、接続を維持するために必要な状態を持つノードがまだあります。
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]).
[10] RFC-1323 [11] RFC-793で定義されるように動的NATとRSIPは、最終的にアドレス/ポート番号の再利用に関する上位層の仮定に違反するであろう。 TCP状態、TCP_TIME_WAITは、具体的には、所与のIPアドレスペアのIPの4タプルとポートとの間のパケットの再生を防止するように設計されています。ノードのTCPステートマシンがRSIPのいずれかの以前の使用を認識しないので、その試みが（TCP_TIME_WAITにまだある）その隣人がリリースされたばかりの同じリモートサービスへの接続に失敗する可能性があり、またはより大きなシーケンス番号で開くことTCP_TIME_WAIT状態によって与えられる保護の損失に直接TCP_TIME_WAIT状態から接続前、（RFC-2663の2.6でさらに議論[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_TIME_WAIT要件に準拠する（ポートを翻訳していない）アドレス変換のために、彼らはMSLがMSLがあるアドレスの最後の使用から経過した* 2の期間まで別のホストに同じアドレスを割り当てることを控える必要があります2分としてRFC-793で定義された最大セグメント寿命。アドレス・ポートトランスレータは、この要件に準拠するために、それらは同様にMSLがその最初の使用の終了から経過した2 *まで同じホスト/ポートのペアを割り当てる控えなければなりません。これらの要件は、状態にシンプルですが、彼らは一時的に利用可能なアドレスとポートのプールを減らすために、彼らは、NATに大きな圧力を置くことができます。したがって、TCPの強力な信頼性のいくつかのコストで、TCP_TIME_WAIT要件を無視するか短くする魅力的またはNAT実装されます。強い信頼性が、実際に古いパケットの出現により損なわれた場合に、障害が誤ったデータを受け付ける受信機として現れることができることに留意されたいです。下のイラスト3でさらに議論を参照してください。
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.
時々NATのは、単に各ドメインは、その境界内のアドレスを見つけるための責任がある「ルーティングレルムを」、促進するために機能することを主張しています。このような観点は、管理をルーティングするためのより良い理解を必要とNATによって作成された制限を雲。ルーティング情報の区画が正しくルーティングプロトコルの機能とその適用範囲です。 NATは、単にアドレス割り当ての権限を配布し、他の分野のそれらの中に一つのアドレス領域からアドレスをマッピングするためのメカニズムを提供するための手段です。
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.
特に、時々誤ってNATのルーティング分離を提供するのに役立つと考えられています。誰かがOSPF ALGを定義した場合実際には、それは実際にNAT境界を越えてルーティングすることも可能です。むしろNAT境界を設けるのではなく、それはNAT越えアドレスを漏洩しないようするのに役立つネットワークトポロジを制限する方法を知っている経験豊富なオペレーターです。これは、公共インフラへの不整合を導入するために漏洩したアドレスの可能性与えられた業務に必要です。
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.
NATの爆発からの最大の関心事の一つは、エンドツーエンドのIPセキュリティネットワーク層を配備するの駆け出しの努力への影響です。 IPSecのための1つの基本的な問題は、AHとESPの両方で、認証チェックが（順番にIPアドレスをカバー）TCP / UDPチェックサムをカバーすることです。 NATはIPアドレスを変更すると、チェックサムの計算は失敗しますので、認証が失敗することが保証されています。唯一のエンドポイントは、キーへのアクセス権を持っているので要件は、エンドツーエンドのネットワーク層の暗号化されたときに、セキュリティの境界としてNATを使用しようとすると失敗します。下のイラスト4でさらに議論を参照してください。
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つのシステムで再生することができるとき、これは、ホームネットワークに影響を与えます。一度に一つのシステムは、Webサービスを提供するために、標準のポート上で動作させることができたときにも中小企業に影響を与えます。これらが存在するための唯一のメディアグレードの制限のように聞こえるかもしれないが、インターネットの基本的な性質として、将来的に年を変更していない、それは非常に望ましくありません。問題は、民間の使用に向けた国民は、接続する前に、各ターゲットの管理のマッピングを必要とすることです。 ISPが低く設定オプションにこれらの標準化されたバージョンを提供することを選択した場合、彼らは追加のアドレススペースのコストを超過するのALGを管理するサポートコストを見つけることができます。下のイラスト6でさらに議論を参照してください。
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.)
NATのようなステートフル装置の特徴は、単一障害点の生成です。冗長のNATを確立することによって、これを回避する試みは、状態のタイムリーなコミュニケーション、およびルーティング関連の障害に関連する問題の新しいセットを作成します。これは、代替のノードを終了する更新頻度、頻繁な更新のパフォーマンスへの影響、状態更新トランザクションの信頼性は、この状態情報を必要とするすべてのノードの先験的知識、および通知などのいくつかの問題を包含する。 （この通知は、それらがリッスンするように、ホストへの変更が必要になる場合があり、ルーティングプロトコルを用いて達成することができます。）
-------- --------
| Host A |-----| Host B |
-------- | --------
-----------------
| |
------ ------
| AD 1 | | AD 2 |
------ ------
\ /
--------
/Internet\
----------
--------
Illustration 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.
アクセスデバイス（AD）1＆2は、ルータである伝統的な場合には、単一障害点がエンドホストであり、ルータまたはリンクの障害を介して接続を維持するのに必要なだけの努力が存続ルータからの単純なルーティングアップデートであります。広告がNAT変異体である場合には、代替のNATと共有する必要がアクティブパスに維持接続状態が存在することになります。ホストはNATのいずれかを通じてオープン接続を持っており、それが失敗したときの状態が以前存続NATに移動されていない限り、アプリケーション接続がドロップします。ホストは、依然としてルーティングリダイレクトを取得する必要があります。 RSIPの場合には、公共側アドレスプールも移動できるように広告の間で共有される必要があるであろう。この共有は、接続設定で、競合の割り当てを防ぐために、別のリアルタイム操作の複雑さを作成します。技術としてNATは、元のインターネットの設計目標への直接的な矛盾に、エンドポイント外ポイントの運命共有を作成します。
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つのまたは複数のデバイスであることだった、そして図解さ接続ごとに複数の物理的な場所であることがありました。単純にこの規模でソフトウェアを更新する物流は、すべてのデバイスが同じ製造元とモデルであっても、面倒です。これはまた、ルータとの真のであろうが、すべてのデバイスは、任意の経路を横切って動作するアプリケーションのための一貫性のあるバージョンを実行するために、それが不要になります。
----------------------------------------
| Corporate Network |
| Asia |------| Americas |------| Europe |
------ ---------- --------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
--------------------------------------------
| Internet |
--------------------------------------------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
------------------ -------------- ----------------
Home Telecommuters Branch Offices Partner Networks
------------------ -------------- ----------------
--------
Illustration 2
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で上述した問題のインスタンスを示します。
-------- --------
| Host A |-----| Host B |
-------- | --------
--------
|NAT/RSIP|
--------
|
--------
|Internet|
--------
|
---------
| Web |
| Server |
---------
--------
Illustration 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上のWebサービスを閉じ、RSIPは、ホストAホストBは、同じWebサービスへの接続を開こうとすると、NATは、次の無料の公共側、その後に割り当てるために使用されるパブリック側アドレスを解放同じ1 Aであるアドレスがリリースされたばかり。ホストB上のソースポートの選択規則が使用されるのと同じ選択肢にそれを導くために起こります。ウェブサーバは、TCPの仕様に準拠し、持っているので、ホストBからの接続要求は拒否された4分間のタイムWAITで4タプル。ホストBからの呼び出しがアクセスなしに不満ヘルプデスクへを通じて取得時までに、要求された再試行は問題が、問題を解決して、それが実際にオンに行くときに、マークされますが、断続的にされるように、動作します。
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.
インバウンドおよびアウトバウンドのパケットが同じ経路を横断する場合、ステートフルパケット改質装置を組み込んだネットワークの運用管理はかなり容易です。 （それ以外の場合は、同期2つの方向の状態を維持するために頭痛の種だ。）一方で言うのは簡単、でも慎重な計画と、IPのようなコネクションレスのプロトコルを使用して管理するのが困難な場合があります。冗長接続を作成する問題は、プライベート側にアドバタイズルートがエンドノードに到達するとパブリック側経路広告と同じデバイスにマッピングすることを保証されます。この状態が頻繁にまたは同時に、内部および外部のトポロジーチャーンにもかかわらず、NATを横断セッションの存続期間を通じて持続する必要があります。 -X-リンクが壊れ、またはフラッピングされている以下の場合を考えてみましょう。
-------- --------
| Host A | | Host B |
| Foo | | Bar |
-------- --------
| |
---- ----
|Rtr1|---X1---|Rtr2|
---- ----
| |
---- ----
|NAT1| |NAT2|
---- ----
| |
--------------
|Rtr Rtr|
| / Internet \ | ---
|Rtr----X2---Rtr|----|DNS|
-------------- ---
| |
| |
-------- --------
| Host C | | Host D |
-------- --------
--------
Illustration 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を通じて発見されたのNATによって管理アドレスプールへのパスを告げている間に、ルーティングの一貫したビュー、ルータ1＆2 NAT1を経由しているため、インターネットへの最適パスを保持するには。ときにパスX1改、ルータ2は、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.
ルータ1と2との間のパスが稼働している場合を考えると、ネットワークX2における一部のリモートリンクがダウンしています。また、ホストDはホストBに連絡しようとするホストAまたはBのために照会、要求はNAT2を通過するときDNSの両方のNATのアドレスを返すことが想定され、しかし、内部ルーティングのために、応答はNAT1を介してです。この接続の状態情報がNAT2であるので、NAT1は、新しいマッピングを提供します。リモートパスが復元された場合でも、要求はNAT2のパブリックIPにしているので、返信がNAT1のパブリックIPからであるが、接続は、行われません。
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.
三番目のケースでは、ホストA＆Bの両方がするとき、インターネットの区切りでリモートリンクX2、ホストDに連絡したいと思います。限りパスX1がダウンしているように、ホストBは接続可能であるが、ホストAが遮断されます。リモートトポロジ（そう、インターネットプロバイダがその機密専有情報を検討する傾向があるため）を十分に理解せずに、ホストA＆Bの管理者は1つが働いて他はしなかった理由を見当もつかないでしょう。限り、彼はNATを通過冗長パスを言うことができるようにアップされているが、一つだけの接続が動作します。繰り返しますが、これはステートフルデバイスは、広告の可用性がプールではなく、実際の接続のネットワークにあるときに固有のものであり、そのトポロジーへの可視性の欠如によるものです。
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の状態のメンテナンス要件はとして容易に理解または解決されていない追加の負担を提示します。
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.
NATのの主な特徴は、公衆インターネットにプライベートネットワークを接続するための「シンプル」の能力です。プライベートネットワークがNATをインストールする前に存在している場合は、その名前リゾルバが登録したドメインを使用するとは考えにくいと不要です。 RFC 1123に述べたように[12] DNSクエリがローカルマルチキャストを介して解決することができます。 NATデバイスを接続すると、すべての外部要求のプロキシには、リゾルバの再構成することは、プライベートネットワーク上のホストがパブリックネットワークへのアクセスを可能にします。着信接続を必要とするプライベートホストのセットの公開DNSを設定すると、登録済みのドメイン（プライベート、または接続ISPからのいずれか）と、一意の名前が必要になります。この時点で、パーティションの名前空間が連結され、ホストは対内外のクエリに基づいて別の名前を持っているでしょう。
-------- --------
| Host A | | Host B |
| Foo |-----| Bar |
-------- | -------- ---
|-------------|DNS|
--- ---
|NAT|
---
|
-------- ---
|Internet|----|DNS|
-------- ---
|
---
|NAT|
--- ---
|-------------|DNS|
-------- | -------- ---
| Host C |-----| Host D |
| Foo | | Bar |
-------- --------
--------
Illustration 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.
アプリケーションが名前を埋め込むまで、この単純な例ではすべてが動作します。例えば、ホストD上で実行されているWebサービスは、埋め込まれたURLの形式はhttpの存在かもしれません：//D/bar.html、ホストCから仕事だろうが、埋め込まれた名前は、パブリックアドレスに解決した場合は徹底的にホストAを混乱させる、ホストAは幸せになるだろうが、ホストCは、いくつかのリモートマシンを探していることになります。 DへのホストCからの接続を確立するには、パブリックFQDNの解像度を使用して、NATは単にルータの外にパケットを転送するのではなく、先を見なければならないでしょう。 NATは、名前空間の断片化を作成しませんでした（NATのための通常動作モードでは。ルータはどこから来た同じインターフェイス上でパケットを返送しませんが、他のインタフェースを翻訳＆アウト転送である）が、それはしてネットワークを統合しようとする試みを容易に独立した名前投与。
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 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.
近年のインターネットの質量の増加は、Web経由で低コストの出版の支援によって駆動されています。次の大きなプッシュが頻繁にL2TPを使用して達成する仮想プライベートネットワーク（VPN）のサポートであるように思われます。技術的にはVPNトンネルは、エンドツーエンドから明らかな経路のように見えるものを構築するために、エンドポイントを可能多重化基板としてIPインフラストラクチャを扱います。これらのトンネルは、ネットワークの可視性を再定義し、複数のNATを通過する際にアドレス衝突の可能性を高めます。できる、またはそれを行うには喜んで何の中心体が存在しないとNATの背後にあるプライベート空間のアドレス管理は、大きな負担となります。アドレスと名前の投与は両方が配布され、より複雑になるので、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トンネルは、その設立の簡素化を通じてその合併の可能性と頻度を増加します。そこ故障の原因となりますアドレス重複のいくつかの構成がありますが、簡単な例では、ホストBの私的使用のアドレスが着信接続用のホストAが使用するVPNプールの私的使用のアドレスと一致して、以下に示します。ホストBは、VPNインターフェイスを確立しようとすると、ホストAはそれを着信接続のためにそのプールからアドレスを割り当て、使用するために、ホストBのためのゲートウェイを特定します。一例では、ホストBは、物理インターフェイス上で、自身のプライベートアドレスからホスト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 |
--------------- --- --- ----------------
--------
Illustration 6
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の背後にある薬があった場合、結果のデータが適切にインデックスを作成することが重要になります。
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はの現在のマッピングに基づいてデータを操作する必要があります。
NAT.
NAT。
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.
NATのは、アドレス空間の制約を緩和し、インターネットが成長し続けることができるため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.
しばしばコストが増加する理由は、IPv6の導入を介して除去されるIPv4アドレスの知覚不足（従って増加した値）です。この危機の考え方は、すでに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アドレス空間を解決するための動機は、はるかに大きいだろう。 NATのが毎日インターネットに接続するために莫大新しいホストを有効にしていることを考えると、IPv4の寿命への実際の影響を把握することは困難であるが、NATは確かにそれを拡張しました。離れ長期溶液から知的サイクルをリダイレクトすることによって、圧力を緩和することによって、IPv6の両方を引き起こしているNAT遅延の程度を決定することも困難です。
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を実行億台以上のコンピュータがすでにあります。これらのネットワークの中には、インターネットのように一部に接続され、一部はプライベート隔離ネットワーク上にあります。私たちが「フラグの日」を持っていると同時に、IPv6への既存のIPv4ノードのすべてを変換することができるとは考えられません。 IPv4とIPv6の両方がインターネットにおよびプライベートネットワークで使用されている間に、共存の非常に長い期間があります。 「デュアルスタック」アプローチを - 元IPv6移行計画は、新しいIPv6ノードもIPv4のを実行できるようになるに大きく依存していました。デュアルスタックノードは、DNS内の別のノードを検索するとき、それはIPv4または応答におけるIPv6アドレスを取り戻すだろう。応答は、IPv4アドレスである場合、ノードは他のノードに接触するのIPv4を使用します。応答はその後、IPv6アドレスがある場合とIPv6が接触するために使用することができます。 IPv6が使用できない場合のIPv4経路を提供する一方で6to4にNATを回す[13]ルータは、IPv6の広範囲の展開を可能にします。これは、IPv4接続の問題の現在のセットを維持しながら、それはIPv6接続のためのエンド・ツー・エンドの原則を再確立します。
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の間でパケットを変換することです。この機能の必要性は、[RFC 1752]、開発及びワーキンググループのセットは、特定の問題の数に取り組むために設立することをお勧めするIPv6のIETFに推奨文書で認識されました。ヘッダ変換（すなわち、NAT）は、これらの問題の一つでした。
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.
もちろん、IPv6のIPv4のに翻訳環境でのNATはNATのは、両方の状況に適用されます。この文書で純粋なIPv4および環境や注意事項に遭遇する同じ問題のすべてが発生しました。
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ネットワークで使用するためのパケットレベルの認証と暗号化をサポートするためのメカニズムのセットを定義します。これは、アプリケーションレベルのセキュリティよりもなく、RFC-1752の言葉にはあまり効率的であるかもしれないが[14]、「基本的なパケットレベルの認証のサポートは、インターネットを通じて多くの必要な、広範な、セキュリティインフラの導入のために提供します。」
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;
NATは、これらの技術は、IPヘッダーのIPアドレスのエンド・ツー・エンドの一貫性に依存しているためにIPsecの認証および暗号化技術を壊すので、インターネットを介して強化されたセキュリティの更なる展開を停止します。 NATは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アドレスが含まれていてもよいです。 - 暗号化されたクイックモード構造は、ポリシー検証用IPアドレスとポートが含まれていてもよいです。 - 公開鍵暗号の改訂モードは、暗号化されたペイロード内のピアのIDを含んでいます。
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.
上記のセクション4で説明したように、エンジニア及びケースバイケースでIPsecのNATを回避することが可能であるが、信頼モデルを制限するコストにできます。導入の柔軟性に設定された制限のすべてと、NATは今日のインターネットで展開されているセキュリティ統合に大きな障害を提示します。
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を使用するNATは/ ALGは、解像度がいずれかの意志の名前空間を修復します。レコードを変更する際のセキュリティを破る、または要求決議へのすべてのソース・キーへのアクセスが必要になります。
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などの識別子としてIPアドレス、に依存しないセキュリティ・メカニズムは、[16]、SSL [17]、またはSSH [18]はNATをを含む環境で動作することができます。確立し、トランスポート接続のこのタイプを利用することができるアプリケーションでは、NATは、追加の合併症を作成しないでください。ヘッダが露出するように、これらの技術は、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.
NATは、セキュリティ上のエンドポイントになるとNATのがセキュアモードで動作することができる引数は、真のエンドツーエンドのセキュリティを妨げます。運用上NATは、セキュリティ・ドメインの一部として管理する必要があり、このモードでNATの無担保側のパケットが完全に露出しています。
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デバイスは、かなり急速なペースで展開されていることを考えると、いくつかのガイドラインが順序です。自然の中でこれらの注意の大部分とは、読者が完全に自分の環境でのNATの使用の意味を理解していることを確認するために設計されています。
- 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サーバー、またはDNS ALGを埋め込むことは可能性の高い行政間で独立したDNSシステムを同期しようとするよりも扱いになります。
- 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つのマッピングに静的なものに設定されている場合、またはそれが動的に管理するのでしょうか？動的な場合は、DNS応答のTTLが0に設定されていることを確認し、クライアントにはないキャッシュ通知に注意を払うこと。 - シングルNATデバイス、または複数のパスと並行はありますか？シングル場合は、機器の故障の影響を考慮してください。複数の場合は、両側にルーティングする方法を検討するパケットはアプリケーションの接続寿命にわたって同じボックスを流れる保証します。 - NATを横断し、変更に対処するための彼らの免疫力を確認する必要がありますアプリケーションを調べます。必要に応じて適切なALGを提供したり、NATからアプリケーションを隔離するためにVPNを確立します。 - プライベート接続に向けたパブリック、プライベート側の目的地の変動、および公共側のポート番号の同時使用のための潜在的な必要性を決定します。これらに該当する場合NAPTsは、管理を向上させます。 - NAPTまたはRSIPを横断するアプリケーションがパブリックIPアドレスからのすべてのポートが同じエンドポイントであることを期待かどうかを確認します。このような場合には、複数のプライベートホストからの同時アクセスを防止するための管理コントロールが必要となります。 - 暗号化されたペイロードがある場合NATは、セキュリティレルムとの間のゲートウェイとして動作し、セキュリティ上のエンドポイントである場合を除き、内容を変更することはできません。 NATとエンドポイントとの間の経路が露出するように、これは、エンドツーエンドの機密性を排除します。 - 名前解決のためのパスを決定します。 NAPTまたはRSIPサーバーのプライベート側のホストが相互に可視性を必要とする場合は、民間側のDNSサーバが必要な場合があります。 - 環境が安全なDNSレコードを使用している場合、すべてのレコードを変換するために、DNS / ALGはソース認証キーへのアクセスが必要になります。 - NATを超えるVPNを使用する場合は、衝突を避けるために、プライベート側のアドレスのためのクリアリングハウスを識別します。 - 内部と外部の両方で使用されるアプリケーションは、名前を埋め込まないことを確認、またはグローバルにユニークなものを使用します。 - RSIPを使用する場合は、スコープを認識は公共のインターネットへの接続、個々のプライベートネットワークに限定されています。他のNATは、（ウェブサーバロードバランシングデバイスを含む）のパスにある場合、RSIP（エンド・ツー・エンドのアドレス/ポートのペア使用）の利点が失われます。 - その後のプライベート側のホストが最近切断公共側のサービスに連絡しようとしたときRSIPのために、TCP_Time_Wait衝突の確率を決定します。
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は、インターネットの設計の基本的な前提を壊します。エンドポイントがコントロールしています。より多くの機能は、NATのによって作成された合併症を回避するためにネットワークに追加された別の設計原理、「キープそれを-シンプルな」を見落とされています。最後に、全体的な柔軟性と管理性が低下し、サポートコストが導入の問題に対処するために上がるいます。
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.
- NATは「人生の事実」であり、既存のIPv4インフラストラクチャを維持強化として増殖します。 - NATは「必要悪」であり、容易に解決されていない管理上の負担を作成します。もっと重要なのは、彼らがで安全なインフラストラクチャを必要とするアプリケーションの低成長を向けるだろうIPsecののロールアウトを阻害します。
In either case, NATs require strong applicability statements, clearly declaring what works and what does not.
いずれの場合も、NATは明確ではない何をするかで動作し、何を宣言し、強力な適用性ステートメントが必要です。
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
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のNATのを展開している時にIPv6の開発を続けるの価値について多くの議論がありました。 NATのは、今日、いくつかの現実世界の問題に対処するため、IPv6が根本的な問題を解決するだけでなく、前進を対象としながら、近視眼ビューは、両方の役割を持っているポイントを逃してしまいます。既存のIPv4システムの寿命は、おそらく数十年で測定されながら、アプリケーションやサービスは、IPv6の開発と長期共存があるであろうことを認識すべきです。 NATは前進運動からの流用ですが、彼らは現在の状態では、より広い参加を有効に行います。彼らはまた、複雑な回避策のシナリオの必要性を作成したアプリケーションのクラスを、破ります。
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.
また、記載された懸念の一部を起こすという確立されたVPNの確率について多くの質問がありました。それは未来を予測するのは難しいですが、それぞれのアプリケーションのためのALGを回避する1つの方法は、NATを介して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の寿命を維持するために技術的転換です。
1 Bradner, S., " The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
1ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
2 Egevang, K. and P. Francis, "The IP Network Address Translator", RFC 1631, May 1994.
2 Egevang、K.およびP.フランシス、 "IPネットワークアドレス変換"、RFC 1631、1994年5月。
3 Srisuresh, P. and M. Holdrege, "NAT Terminology and Considerations", RFC 2663, August 1999.
3 Srisuresh、P.とM.ホールドレッジ、 "NAT用語と考慮事項"、RFC 2663、1999年8月。
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.、グルート、G.およびE.リアデ、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
5 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
5大工、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
6 M. Borella, D. Grabelsky, J., K. Tuniguchi, "Realm Specific IP: Protocol Specification", Work in Progress, March 2000.
6 M.ボレッラ、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.、 "インターネットの透明性"、RFC 2775、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の割り当てガイドライン"、BCP 12、RFC 2050、1996年11月。
10 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
10ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、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拡張"、RFC 1185、1990年10月。
12 Braden, R., "Requirements for Internet Hosts", STD 3, RFC 1123, October 1989.
12ブレーデン、R.、 "インターネットホストのための要件"、STD 3、RFC 1123、1989年10月。
13 Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", Work in Progress.
13カーペンター、B.およびK.ムーア、「明示的なトンネルなしでのIPv4クラウドを介したIPv6ドメインの接続」、ProgressのWork。
14 Bradner, S. and A. Mankin, "Recommendation for IPng", RFC 1752, January 1995.
14ブラドナーの、S.およびA.マンキン、 "IPngのための勧告"、RFC 1752、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. Heffernanの、 "NATのDNSの拡張"、RFC 2694、1999年9月。
16 Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
16ダークス、T.とC.アレン、 "TLSプロトコル"、RFC 2246、1999年1月。
17 http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996.
17 http://home.netscape.com/eng/ssl3/ssl-toc.html、1996年3月。
18 T. Ylonen, et al., "SSH Protocol Architecture", Work in Progress, August 1998.
18 T. Ylonenと、ら、 "SSHプロトコルアーキテクチャ"、進歩、1998年8月に作業します。
19 Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
19 Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
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）、スコット・ブラッドナー（ハーバード大学）、キース・ムーア（UTK）、トーマスNarten氏（IBM）、ヤコフ・レックター（シスコ）、Pyda Srisuresh、マット・ホールドレッジ（ルーセント）、およびエリオット・リア（シスコ）。
Tony Hain Microsoft One Microsoft Way Redmond, Wa. USA
とｎｙ はいん みｃろそｆｔ おね みｃろそｆｔ わｙ れｄもんｄ、 わ。 うさ
Phone: 1-425-703-6619 EMail: tonyhain@microsoft.com
電話：1-425-703-6619 Eメール：tonyhain@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。