[要約] RFC 2993は、NATのアーキテクチャの影響に関する情報を提供するために作成されました。このRFCの目的は、NATの導入によるネットワークアーキテクチャへの影響を理解し、適切な対策を講じることです。
Network Working Group T. Hain Request for Comments: 2993 Microsoft Category: Informational November 2000
Architectural Implications of NAT
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.
Copyright(c)The Internet Society(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. Francisによって書かれた1994年5月に公開されたRFC-1631 [2]は、NATをIPv4アドレスの使用の成長率を容易にする1つの手段として定義しました。しかし、著者はこの技術の影響を心配していました。ドキュメントのいくつかの場所は、実験し、どのアプリケーションが、重要な運用経験がある前であっても、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.
- 支持者は熱意をもたらし、郵便物サービスとWebサービスの最も人気のあるアプリケーションを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ヘッダー以外の場所でそのアドレス情報を伝えるプロトコルの輸送のエンドツーエンド接続の透明性に影響を与えることが明らかです。一貫して構成されたアプリケーション固有のゲートウェイ(アルグ)のパッチワークを使用して、エンドポイントはNATの運用上の課題のいくつかを回避できます。これらの運用上の課題は、ネットワークおよびアプリケーショントポロジ、および使用中の特定のアプリケーションなど、多くの要因に基づいて異なります。最も単純なケースに対処するのは比較的簡単に対処できます。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-2663 [3]も参照)。Carpenter、et al RFC-2101 [5]が指摘したように、私的使用アドレスがネットワークに展開されると、アドレスはあいまいであることが保証されました。たとえば、単純なNATがネットワークに挿入されると、アドレスとの間で名前を解決するプロセスは、質問がどこで尋ねられたかに依存します。この部門の結果は、サーバーがパブリックアドレスの領域に存在する必要がある場合、クライアント/サーバーアーキテクチャ(vs.ピア/ピア)を実施することです。
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.
もう1つの利点は、ネットワークが接続状態情報ごとに維持しないことです。これにより、代替パスを介した障害の周りを迅速に再ルーティングし、ネットワーク全体のスケーリングを改善できます。状態の欠如は、エンドポイント接続が形成またはドロップされると、ネットワークノードが互いに通知するための要件を削除します。さらに、エンドポイントは、宛先、ファーストホップルーター、およびオプションの名前解像度サービス以外のネットワークコンポーネントを認識していない、そしてそうである必要はありません。パケットの整合性はネットワークを介して保持され、輸送チェックサムとアドレス依存のセキュリティ関数は有効なエンドツーエンドです。
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_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 Divisesと同じ問題のいくつかを提起しながら、独自のいくつかを追加していることに注意する必要があります。しかし、ファイアウォールでの運用上の利点の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のバリアントを単純なルーター置換として使用しようとすると、展開前に対処すべきいくつかの重要な問題が発生する可能性があることです。このドキュメントの目標は、意識を高める意図でこれらを議論することです。
Recognizing that many of these terms are defined in detail in RFC 2663 [3], the following are summaries as used in this document.
これらの用語の多くはRFC 2663 [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-単純な形式のネットワークアドレス変換は、IPアドレスがあるアドレス管理から別のアドレス管理にマッピングされる方法です。NAT関数は、IPヘッダーのみを見るため、アプリケーションが通過することを認識していません。
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.
アルグ - アプリケーションレイヤーゲートウェイ:アプリケーションピア間に挿入されて、介在するプロトコルまたはデバイスが直接アクセスを防ぐと、直接接続をシミュレートします。トランスポートプロトコルを終了し、転送前にデータストリームを変更する場合があります。
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を組み合わせます。純粋な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がNATコンポーネントと相互作用してDNS応答の内容を変更するNAT/ALGの特殊なケース。
Firewall - access control point that may be a special case of an ALG, or packet filter.
ファイアウォール - アルグまたはパケットフィルターの特別なケースである可能性のあるアクセス制御ポイント。
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.
プロキシ - 任意に挿入されるのではなく、プロトコルに設計されたリレーサービス。アルグとは異なり、少なくとも一方の端のアプリケーションはプロキシを認識する必要があります。
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).
Dynamic 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 -Realm固有の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を介して接続されたものを含む)を使用して構築されたプライベートネットワークを区別するものではありません。RFC-1918のRekhter、et alは、グローバルに明確な住所を使用して、エンタープライズ外でネットワークレイヤーアクセスが必要な場合、ホストを一般に公開すると定義しました。アクセスが制限されていないか、アクセスが必要なものは、プライベートとして定義されています。これを表示する別の方法は、特定のノードと他のインターネットの間の接続の透明性の観点からです。
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であり、パブリックとプライベート使用アドレススペースの間のネットワークロケーターを管理し、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 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]。重要なポイントの1つは、「エンドポイント自体が破壊されたときにのみ状態を破壊できるように、エンドポイントでのみ状態を維持する必要がある」ことです。これは「運命共有」と呼ばれます。運命共有の背後にある目標は、堅牢性を確保することです。ネットワークがサイズが大きくなるにつれて、接続に影響を与えるコンポーネント障害の可能性がますます頻繁になります。障害がコミュニケーションの喪失につながる場合、キー状態が失われるため、ネットワークはますます脆くなり、その効用は劣化します。ただし、エンドポイント自体が失敗した場合、とにかくその後のコミュニケーションの希望はありません。したがって、エンドツーエンドモデルは、可能な限り、エンドポイントのみが臨界状態を保持する必要があると主張しています。
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セキュリティベースの認証をサポートする方法は明確ではありません。アルグまたは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つのホストが別のホストに送信することで、2番目のホストが接続するアドレスとポートが送信されます。Natsはこれらのアプリケーションを破ります。同様に、特定のIPアドレスマップから同じエンドポイントまでのすべての上層ポートが、NAPTやRSIPなどのポートマルチプレックステクノロジーがこれらを壊すと仮定する他のアプリケーションがあります。たとえば、Webサーバーは、ポート80への接続を1つとポート443に関連付けることを望む場合がありますが、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.
潜在的な顧客接続オプションを削減し、サポートマトリックスを最小限に抑えることにより、NATがサポートコストを削減するとISPが可能になる可能性があります。
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 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.
もう1つの一般的なプラクティスは、単一のIPアドレスの背後にある組み合わせサービスを提供するホストのコレクションを隠すことです(つまり、Webホストの負荷共有)。多くの実装では、アドレスが実際の目的地にマッピングされているため、これは建築的にNATです。パケットヘッダーの整合性が問題にならない場合、このタイプの仮想ホストは、エンドクライアントがマッピングアクティビティに気付いていないため、リモートアプリケーションの変更を必要としません。仮想ホストには、マシンの合計セットのCPUパフォーマンス特性がありますが、NAT/ALGデバイスの処理とI/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.
- Natsは、インターネットの柔軟なエンドツーエンドモデルを破ります。-NATは、接続状態と動的マッピング情報を維持するデバイスで、運命が共有される単一のポイントを作成します。-Natsは、インターネット接続の信頼性を高めるために、サイトによるマルチホミングの使用を複雑にします。(単一のルーターは運命共有のポイントですが、ルーターに状態がないため、冗長性の些細なことを作成します。これが、インターネットプロトコルスイートがネットワークレイヤーとしてConnectionless Datagramサービスを使用して開発された理由です。)IPレベルでのセキュリティの実装を阻害します。-ATSは、プライベートアドレスの偶然の使用を可能にします。これらの非調整されていないアドレスは、これらのアドレスを使用している企業がVPNを使用して直接相互接続したい場合に衝突の対象となります。-NATSは、既存の私立名とパブリック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)は、公開されているサービスがプライベート側にある場合、運用上の複雑さを高めます。-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.
設計上、NATは柔軟性に制限を課します。そのため、導入された合併症についての拡張された考えが求められています。これは、IPアドレスを他のパブリックアドレスに書き直す負荷分散ルーターなど、NAT機能が隠されたサービスである製品に特に当てはまります。アドレスはすべて公開されているスペースにある可能性があるため、これらはめったに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.
Natsは、データストリームにIPアドレス(またはアドレスデリバティブ)を運ぶアプリケーションの展開に制約を課し、各セッションが独立していると仮定して動作します。ただし、FTPやH.323などのアプリケーションがあり、1つ以上のコントロールセッションを使用して、コントロールセッションペイロードの後続セッションの特性を設定します。その他の例には、構成のためのSNMP MIBS、および警察のポリシーメッセージが含まれます。このようなアプリケーションまたはプロトコルは、アドレスのエンドツーエンドの完全性を想定しており、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.
前述のように、Natsはエンドポイントが通信を制御しているというインターネットの基本的な教義を破ります。元の設計により、状態制御がエンドポイントに状態を抑えているため、障害の他の固有のポイントはありません。ネットワーク内のエンドポイントから特定のノードに状態を移動すると、柔軟性が低下しますが、単一のポイント障害の影響が増加します。以下の図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は透明性とアルグの問題に対処しますが、個々のプライベートホストがパブリックアクセスを必要とする特定のケースについては、接続を維持するために必要な状態のノードがまだあります。
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_TIME_WAITは、特定のIPアドレスペアのIPとポートの4タプル間のパケットのリプレイを防ぐために特別に設計されています。ノードのTCP状態マシンは、以前のRSIPの使用を認識していないため、隣人がリリースしたばかり(まだTCP_TIME_WAITにある)と同じリモートサービスに接続しようとする試みが失敗する可能性があります。TCP_TIME_WAIT州が提供する保護が失われた場合、TCP_TIME_WAIT状態から直接事前の接続があります(RFC-2663 [3]の2.6のさらなる議論)。
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要件に準拠するために、2*MSLの最後の使用以来2*MSLの期間が経過するまで、同じアドレスを別のホストに割り当てることを控える必要があります。RFC-793で2分間定義された最大セグメント寿命。アドレスとポートの翻訳者がこの要件に準拠するためには、同様に、最初の使用の終了以来2*MSLが経過するまで、同じホスト/ポートペアの割り当てを控える必要があります。これらの要件は簡単に述べるのは簡単ですが、利用可能なアドレスとポートのプールを一時的に減らすため、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は、アドレス割り当て機関を配布し、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.
特に、NATがルーティングの分離を提供するのに役立つと誤って信じられていることがあります。実際、誰かがOSPFアルグを定義する場合、実際には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の爆発による最大の懸念の1つは、ネットワークレイヤーのエンドツーエンドのIPセキュリティを展開するための駆け出しの取り組みに影響を与えることです。IPSECの根本的な問題の1つは、AHとESPの両方で、認証チェックがTCP/UDPチェックサム(IPアドレスをカバーする)をカバーすることです。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つのプライベートサイドシステムのみが単一のパブリックサイドポート番号を介してマッピングできるため、損なわれています。これは、マルチプレイヤーインターネットゲームのようなアプリケーションが一度に1つのシステムでのみ再生できる場合、ホームネットワークに影響します。また、Webサービスを提供するために標準ポートで一度に1つのシステムのみを操作できる場合、中小企業にも影響します。これらは現在の中級制限のみのように聞こえるかもしれませんが、インターネットの基本的な特性として、将来に変わるのではなく、非常に望ましくありません。問題は、プライベート使用に向けたパブリックが、接続前に各ターゲットの管理マッピングを必要とすることです。ISPがこれらの標準化されたバージョンを提供して構成オプションを低くすることを選択した場合、ALGSの管理のサポートコストが追加のアドレススペースのコストを超えることがわかります。以下の図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.)
NATSのようなステートフルなデバイスの特徴は、単一の障害ポイントの作成です。冗長なNATを確立することでこれを回避しようとする試みは、国家のタイムリーなコミュニケーションとルーティング関連の障害に関連する新しい問題を作成します。これには、更新頻度、頻繁な更新のパフォーマンスへの影響、状態更新トランザクションの信頼性、この状態情報が必要なすべてのノードのA-PRIORI知識、代替のノードを終了するための通知など、いくつかの問題が含まれます。(この通知は、ルーティングプロトコルで達成できます。これには、ホストが聞くためにホストの変更が必要になる場合があります。)
-------- -------- | 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がルーターである従来のケースでは、単一の障害ポイントがエンドホストであり、ルーターまたはリンク障害を介して接続を維持するために必要な唯一の努力は、生き残ったルーターからの単純なルーティングアップデートです。。ADがNATバリアントである場合、Active Pathには、代替NATと共有する必要があるアクティブパスに接続状態が維持されます。ホストがいずれかのNATを介してオープンな接続を持ち、失敗すると、状態が以前に生存しているNATに移動されていない限り、アプリケーション接続が低下します。ホストは、ルーティングリダイレクトを取得する必要があります。RSIPの場合、パブリックサイドアドレスプールも、移動を許可するために広告間で共有する必要があります。この共有は、接続セットアップでの矛盾する割り当てを防ぐために、別のリアルタイムの運用複雑さを作成します。NATとしての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サービスへの接続を開く試みを試みます。リリースされたばかりのアドレス。ホストBのソースポート選択ルールは、Aが使用されているのと同じ選択に導かれます。TCP仕様に準拠したWebサーバーが4分間待機するWebサーバーが4分間待機しているため、ホストBからの接続要求は拒否されます。ホスト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.
Stateful Packet変更デバイスを組み込んだネットワークの運用管理は、インバウンドパケットとアウトバウンドパケットが同じパスを横断する場合、かなり簡単です。(そうでなければ、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.
ルーティングの一貫したビューを保持するために、ルーター1と2のインターネットへの最適なパスはNAT1を介して行われますが、インターネットはNATSによって管理されているアドレスプールへのパスは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のリモートリンクがダウンしている場合を考えてみましょう。また、DNSはホストAまたはBを照会したときに両方のNATのアドレスを返すと想定されています。ホストDがホストBに接触しようとすると、リクエストはNAT2を通過しますが、内部ルーティングのため、返信は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.
3番目のケースでは、両方のホストA&Bがインターネットのリモートリンクx2が壊れたときにホストDに連絡したいと考えています。パスX1がダウンしている限り、ホストBは接続できますが、ホストAは切断されます。リモートトポロジを完全に理解していないと(インターネットプロバイダーがその機密性のある情報を考慮する傾向があるため、ありそうもない)、ホストA&Bの管理者は、1つが機能し、もう1つが機能しなかった理由を示していません。彼が言うことができる限り、NATを通る冗長なパスはアップしていますが、1つの接続のみが機能します。繰り返しますが、これは、ステートフルなデバイスが実際の接続されたネットワークではなく、プールへの可用性を広告している場合に固有のトポロジーへの可視性の欠如によるものです。
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.
NATSの主な機能は、プライベートネットワークをパブリックインターネットに接続する「シンプルな」機能です。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サービスは、http://d/bar.htmlの形式の埋め込みURLを提示する場合があります。これはホストCから動作しますが、ホストAを完全に混乱させます。、ホストAは幸せですが、ホストCはリモートマシンを探しています。ホストCからDへの接続を確立するためにパブリック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を横断するときにネットワークの可視性を再定義し、住所衝突の可能性を高めます。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トンネルは、その施設のシンプルさを通じて、その融合の可能性と頻度を増加させます。障害を引き起こすアドレスオーバーラップのいくつかの構成がありますが、ホスト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 NAT.
これは、SNMPを介して収集された管理データにも適用されます。データストリームにIPアドレスが搭載されているときはいつでも。中央のコレクターまたはアルグは、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.
多くの場合、コストの増加の理由は、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アドレススペースを解決する動機ははるかに大きくなります。NATがUntoldの新しいホストが毎日インターネットに接続できるようにしていることを考えると、IPv4の寿命への実際の影響を確認することは困難ですが、NATは確かにそれを拡張しました。また、圧力を緩和することと、長期的なソリューションから知的サイクルをリダイレクトすることにより、DATが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トランジションプランは、新しいIPv6ノードを「デュアルスタック」アプローチであるIPv4を実行できることに大きく依存していました。デュアルスタックノードがDNSの別のノードを検索すると、それに応じてIPv4またはIPv6アドレスが戻ります。応答がIPv4アドレスの場合、ノードはIPv4を使用して他のノードに連絡します。また、応答がIPv6アドレスの場合、IPv6を使用して接触を行うことができます。NATを6to4 [13]ルーターに変えることで、IPv6が利用できない場合はIPv4パスを提供しながら、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とネットワークをサポートするIPv4の間にあるボーダーのIPv6とIPv4の間のパケットを翻訳することです。この機能の必要性は[RFC 1752]で認識されていました。これは、IPv6を開発し、多くの特定の問題に取り組むためにワーキンググループのセットを確立することを推奨するIETFに推奨された文書です。ヘッダー翻訳(つまり、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.
もちろん、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;
これらのテクノロジーはIPヘッダー内のIPアドレスのエンドツーエンドの一貫性に依存するため、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.
- Hashがヘッダー内のIPアドレスを保護するため、AHの使用はNATを介して不可能です。 - 認証された証明書には、認証目的でサブジェクト名の一部としてIPアドレスが含まれる場合があります。 - 暗号化されたクイックモード構造には、ポリシーの検証のためにIPアドレスとポートが含まれる場合があります。 - 公開キー暗号化の改訂モードには、暗号化されたペイロードのピアアイデンティティが含まれます。
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のためにNATSを設計して作業することが可能かもしれませんが、信頼モデルを制限するコストで使用することが可能かもしれません。すべての制限が展開の柔軟性に課されているため、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を使用して名前空間解像度を修復するNATはどちらかです。レコードを変更するときにセキュリティを破るか、要求された解像度にすべてのソースキーにアクセスする必要があります。
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アドレスを保護または依存していないセキュリティメカニズムは、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アルグを埋め込むことは、管理者全体で独立した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が構成されていますか、それとも動的に管理しますか?動的な場合は、DNS応答のTTLが0に設定されていることを確認し、クライアントがNot Cache通知に注意を払っていることを確認してください。 - 単一のNATデバイスがありますか、それとも複数のパスと平行していますか?単一の場合は、デバイスの障害の影響を考慮してください。複数の場合、両側のルーティングにより、アプリケーションの接続寿命にわたって同じボックスを通るパケットが流れるようにする方法を検討してください。 - 変化に対処するためにNATを通過する必要があるアプリケーションを調べ、それらの免疫を検証します。必要に応じて、適切なアルグを提供するか、VPNを確立して、NATからアプリケーションを分離します。 - プライベート接続に向けたパブリックの必要性、プライベート側の目的地の変動性、およびパブリックサイドポート番号の同時使用の可能性を判断します。これらが適用されれば、NAPTは投与を増やします。 - NAPTまたはRSIPを通過するアプリケーションが、パブリックIPアドレスからのすべてのポートが同じエンドポイントであると予想するかどうかを判断します。これが当てはまる場合、複数のプライベートホストからの同時アクセスを防ぐための管理管理が必要です。 - 暗号化されたペイロードがある場合、NATがセキュリティエンドポイントでない限り、セキュリティレルム間のゲートウェイとして機能しない限り、コンテンツを変更できません。これは、NATとエンドポイントの間のパスが公開されるため、エンドツーエンドの機密性を排除します。 - 名前解決のパスを決定します。NAPTまたはRSIPサーバーのプライベート側のホストが互いに視認性を必要とする場合、プライベート側DNSサーバーが必要になる場合があります。 - 環境がSecure DNSレコードを使用している場合、DNS/ALGは、すべてのレコードを翻訳するためにソース認証キーにアクセスする必要があります。-NATを介してVPNを使用する場合、衝突を避けるために、プライベートサイドアドレスのクリアリングハウスを特定します。 - アプリケーションが内部と外部の両方を使用して、名前を埋め込むことを避けたり、グローバルにユニークなものを使用したりすることを保証します。-RSIPを使用する場合、スコープがパブリックインターネットに接続する個々のプライベートネットワークに限定されていることを認識します。他のNATがパスにいる場合(Webサーバーロードバランシングデバイスを含む)、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は、インターネット設計の基本的な仮定を破ります。エンドポイントは制御されています。別の設計の原則「Keep-It-Simple」は、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インフラストラクチャを維持する強化として増殖します。 - ナットは「必要な悪」であり、簡単に解決されない行政上の負担を作成します。さらに重要なことは、それらが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.
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が確立される可能性についても多くの質問がありました。将来を予測することは困難ですが、各アプリケーションのアルグを回避する1つの方法は、NATにL2TPを確立することです。これにより、トンネルパケットのヘッダーへのNATの可視性が制限され、すべてのアプリケーションからその効果が削除されます。これはアルグの問題を解決しますが、協調的なアドレススペース間に任意の接続が確立されるため、住所衝突がある可能性が高くなります。また、アプリケーションが必要なトンネルをどのように確立するかについての副関心を生み出します。
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 Bradner、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. Francis、「The IP Network Address Translator」、RFC 1631、1994年5月。
3 Srisuresh, P. and M. Holdrege, "NAT Terminology and Considerations", RFC 2663, August 1999.
3 Srisuresh、P。およびM. Holdrege、「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.、Moskowitz、B.、Karrenberg、D.、de Groot、G。and E. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
5 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
5 Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
6 M. Borella, D. Grabelsky, J., K. Tuniguchi, "Realm Specific IP: Protocol Specification", Work in Progress, March 2000.
6 M. Borella、D。Grabelsky、J.、K。Tuniguchi、「Realm固有のIP:プロトコル仕様」、2000年3月の作業。
7 Kent, S. and R. Atkinson, "Security Architecture for IP", RFC 2401, November 1998.
7 Kent、S。およびR. Atkinson、「IPのセキュリティアーキテクチャ」、RFC 2401、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 Hubbard、K.、Kosters、M.、Conrad、D.、Karrenberg、D。、およびJ. Postel、「インターネットレジストリIP割り当てガイドライン」、BCP 12、RFC 2050、1996年11月。
10 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
10 Postel、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 Jacobson、V.、Braden、R。およびL. Zhang、「高速パスのTCP拡張」、RFC 1185、1990年10月。
12 Braden, R., "Requirements for Internet Hosts", STD 3, RFC 1123, October 1989.
12 Braden、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 Carpenter、B。およびK. Moore、「明示的なトンネルなしのIPv4クラウドを介したIPv6ドメインの接続」、進行中の作業。
14 Bradner, S. and A. Mankin, "Recommendation for IPng", RFC 1752, January 1995.
14 Bradner、S。およびA. Mankin、「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。and A. Heffernan、「DNS Extensions to Nat」、RFC 2694、1999年9月。
16 Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
16 Dierks、T。およびC. Allen、「TLSプロトコル」、RFC 2246、1999年1月。
17 http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996.
17 http://home.netscape.com/eng/ssl3/ssltoc.html、1996年3月。
18 T. Ylonen, et al., "SSH Protocol Architecture", Work in Progress, August 1998.
18 T. Ylonen、et al。、「SSH Protocol Architecture」、Work in Progress、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、Vern Paxson(LBL)、Scott Bradner(Harvard)、Keith Moore(UTK)、Thomas Narten(IBM)、Yakov Rekhter(Cisco)、Pyda Srusuresh、Matt Holdrege(Lucent)、およびMatt Holdrege(Lucent)から来ました。エリオット・リア(シスコ)。
Tony Hain Microsoft One Microsoft Way Redmond, Wa. USA
トニー・ハイン・マイクロソフト・ワン・マイクロソフト・ウェイ・レドモンド、ワシントン州。アメリカ合衆国
Phone: 1-425-703-6619 EMail: tonyhain@microsoft.com
電話:1-425-703-6619メール:tonyhain@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。