Network Working Group B. Carpenter
Request for Comments: 2775 IBM
Category: Informational February 2000
Internet Transparency
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
抽象
This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.
この文書では、エンドツーエンドの接続性と透明性の問題に集中し、建築の視点から、インターネットの現在の状態を説明しています。これは、インターネットのネットワーク層が直面しているいくつかの主要な建築の選択肢の概要で締めくくり。
This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.
この文書では、このような理由から1999年7月に開催されたネットワーク層の将来に関するIABワークショップへの入力として使用し、それは完全で決定的であることを主張しない、それは勧告を行うことを控えます。
Table of Contents
目次
1. Introduction.................................................2
2. Aspects of end-to-end connectivity...........................3
2.1 The end-to-end argument.....................................3
2.2 End-to-end performance......................................4
2.3 End-to-end address transparency.............................4
3. Multiple causes of loss of transparency......................5
3.1 The Intranet model..........................................6
3.2 Dynamic address allocation..................................6
3.2.1 SLIP and PPP..............................................6
3.2.2 DHCP......................................................6
3.3 Firewalls...................................................6
3.3.1 Basic firewalls...........................................6
3.3.2 SOCKS.....................................................7
3.4 Private addresses...........................................7
3.5 Network address translators.................................7
3.6 Application level gateways, relays, proxies, and caches.....8
3.7 Voluntary isolation and peer networks.......................8
3.8 Split DNS...................................................9
3.9 Various load-sharing tricks.................................9
4. Summary of current status and impact.........................9
5. Possible future directions..................................11
5.1 Successful migration to IPv6...............................11
5.2 Complete failure of IPv6...................................12
5.2.1 Re-allocating the IPv4 address space.....................12
5.2.2 Exhaustion...............................................13
5.3 Partial deployment of IPv6.................................13
6. Conclusion..................................................13
7. Security Considerations.....................................13
Acknowledgements...............................................14
References.....................................................14
Author's Address...............................................17
Full Copyright Statement.......................................18
"There's a freedom about the Internet: As long as we accept the
rules of sending packets around, we can send packets containing
anything to anywhere." [Berners-Lee]
The Internet is experiencing growing pains which are often referred to as "the end-to-end problem". This document attempts to analyse those growing pains by reviewing the current state of the network layer, especially its progressive loss of transparency. For the purposes of this document, "transparency" refers to the original Internet concept of a single universal logical addressing scheme, and the mechanisms by which packets may flow from source to destination essentially unaltered.
インターネットは、多くの場合、「エンド・ツー・エンドの問題」と呼ばれる成長の痛みを経験しています。この文書では、ネットワーク層、透明性の特にその進歩的な損失の現在の状態を確認して、それらの成長の痛みを分析しようとします。この文書の目的では、「透明」とは、単一の汎用論理アドレッシング方式の元のインターネットの概念、およびパケットが本質的に変化していないソースから宛先に流れることができるメカニズムを指します。
The causes of this loss of transparency are partly artefacts of parsimonious allocation of the limited address space available to IPv4, and partly the result of broader issues resulting from the widespread use of TCP/IP technology by businesses and consumers. For example, network address translation is an artefact, but Intranets are not.
透明性の損失の原因は、一部のIPv4に利用できる限られたアドレス空間の倹約割り当ての工芸品、および企業と消費者によるTCP / IP技術の普及に起因する幅広い問題の一部結果です。たとえば、ネットワークアドレス変換はアーティファクトですが、イントラネットではありません。
Thus the way forward must recognise the fundamental changes in the usage of TCP/IP that are driving current Internet growth. In one scenario, a complete migration to IPv6 potentially allows the restoration of global address transparency, but without removing firewalls and proxies from the picture. At the other extreme, a total failure of IPv6 leads to complete fragmentation of the network layer, with global connectivity depending on endless patchwork.
このような方法は、現在のインターネットの成長を牽引しているTCP / IPの使用方法に根本的な変化を認識しなければなりません。あるシナリオでは、IPv6への完全移行は、潜在的に、しかしピクチャからファイアウォールやプロキシを除去することなく、グローバルアドレス透明性の回復を可能にします。他の極端では、IPv6の総失敗はグローバルな接続が無限のパッチワークに依存して、ネットワーク層の断片化を完了させるためにつながります。
This document does not discuss the routing implications of address space, nor the implications of quality of service management on router state, although both these matters interact with transparency to some extent. It also does not substantively discuss namespace issues.
これらの問題の両方がある程度の透明性と対話が、この文書では、アドレス空間のルーティングへの影響、またルータの状態にサービス管理の品質の影響を議論していません。また、実質的に、名前空間の問題について議論しません。
The phrase "end to end", often abbreviated as "e2e", is widely used in architectural discussions of the Internet. For the purposes of this paper, we first present three distinct aspects of end-to-endness.
句「端へ」、しばしば「E2E」と略記は、広くインターネットの建築議論に使用されています。本稿の目的のために、私たちはまず、エンドツーendness 3つの異なる側面を提示します。
This is an argument first described in [Saltzer] and reviewed in [RFC 1958], from which an extended quotation follows:
これは、第1の拡張引用は以下そこから[RFC 1958]の[Saltzer]で説明、レビューの引数です。
"The basic argument is that, as a first principle, certain required end-to-end functions can only be performed correctly by the end-systems themselves. A specific case is that any network, however carefully designed, will be subject to failures of transmission at some statistically determined rate. The best way to cope with this is to accept it, and give responsibility for the integrity of communication to the end systems. Another specific case is end-to-end security.
「基本的な引数は、第一原理として、特定の必要なエンドツーエンド機能のみエンドシステム自体によって正確に行うことができる、ということである。特定の場合には、任意のネットワークが、しかし注意深く設計の障害を受けることになるということですいくつかの統計学的に決定される速度で伝送。これに対応するための最良の方法はそれを受け入れ、およびエンドシステムへの通信の整合性のための責任を与えることである。別の具体的なケースは、エンドツーエンドのセキュリティです。
"To quote from [Saltzer], 'The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)'
「[Saltzer]から引用すると、「問題の機能は完全に正しく通信システムの特徴として、その疑問視機能を提供する、唯一のため、通信システムのエンドポイントに立ったアプリケーションの知識と助けを借りて実装することができそれ自体は可能ではない。（時々通信システムによって提供される機能の不完全なバージョンは、性能向上として有用であり得ます。）」
"This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes."
我々は、部分的なネットワーク障害を生き残るためのアプリケーションが必要な場合は、「この原則は、重要な結果を持っています。エンドツーエンドプロトコル設計がネットワーク内の状態の維持（エンド・ツー・エンドの通信の状態に関するすなわち情報）に頼るべきではありませんこのような状態は、（運命共有としても知られる）、エンドポイント自体が壊れるときの状態のみ破壊することができるように、エンドポイントにのみ維持されるべきである。この直接の結果は、データグラムが古典的な仮想回路よりも優れているということです。ネットワークの仕事を効率的かつ柔軟に可能な限りのデータグラムを送信することである。他のすべての縞で行われるべきです。」
Thus this first aspect of end-to-endness limits what the network is expected to do, and clarifies what the end-system is expected to do. The end-to-end argument underlies the rest of this document.
したがって、エンドツーendnessのこの第1の態様は、ネットワークが実行すると予想されるものを制限し、及びエンドシステムを実行することが期待されるものを明確にしています。エンド・ツー・エンドの引数は、このドキュメントの残りの部分の下にあります。
Another aspect, in which the behaviour of the network and that of the end-systems interact in a complex way, is performance, in a generalised sense. This is not a primary focus of the present document, but it is mentioned briefly since it is often referred to when discussing end-to-end issues.
ネットワークの動作とエンドシステムのそれは複雑な方法で相互作用する別の態様は、一般的な意味では、パフォーマンスです。これは、本文書の主な焦点ではありませんが、それは多くの場合、エンド・ツー・エンドの問題を議論する際に参照されているので、それを簡単に言及されています。
Much work has been done over many years to improve and optimise the performance of TCP. Interestingly, this has led to comparatively minor changes to TCP itself; [STD 7] is still valid apart from minor additions [RFC 1323, RFC 2581, RFC 2018]. However a great deal of knowledge about good practice in TCP implementations has built up, and the queuing and discard mechanisms in routers have been fine-tuned to improve system performance in congested conditions.
多くの研究は、TCPのパフォーマンスを向上させ、最適化するために、長年にわたり行われてきました。興味深いことに、これは自分自身を、TCPの比較的軽微な変化をもたらしています。 [STD 7]はマイナー追加[RFC 1323、RFC 2581、RFC 2018]から離れてまだ有効です。しかし、TCPの実装では良いプラクティスに関する知識を大量に構築、およびキューイングおよびルータでのメカニズムが輻輳状態でシステム性能を向上させるために微調整されている廃棄しました。
Unfortunately all this experience in TCP performance does not help with transport protocols that do not exhibit TCP-like response to congestion [RFC 2309]. Also, the requirement for specified quality of service for different applications and/or customers has led to much new development, especially the Integrated Services [RFC 1633, RFC 2210] and Differentiated Services [RFC 2475] models. At the same time new transport-related protocols have appeared [RFC 1889, RFC 2326] or are in discussion in the IETF. It should also be noted that since the speed of light is not set by an IETF standard, our current notions of end-to-end performance will be largely irrelevant to interplanetary networking.
残念ながら、TCPのパフォーマンスのすべてのこの経験は混雑へのTCPのような応答を示さないトランスポートプロトコル[RFC 2309]には役立ちません。また、異なるアプリケーションおよび/または顧客に対するサービスの指定された品質のための要件は、多くの新しい発展に特に統合サービス[RFC 1633、RFC 2210]と差別化サービス[RFC 2475]のモデルをリードしてきました。同時に、新しいトランスポート関連のプロトコルは、[RFC 1889、RFC 2326]登場しているか、IETFでの議論です。また、光の速度はIETF標準で設定されていないので、エンド・ツー・エンドのパフォーマンスの我々の現在の概念は惑星間ネットワークへの大部分は無関係になることに留意すべきです。
Thus, despite the fact that performance and congestion issues for TCP are now quite well understood, the arrival of QOS mechanisms and of new transport protocols raise new questions about end-to-end performance, but these are not further discussed here.
このように、TCPのパフォーマンスと輻輳の問題は、現在非常によく理解されているという事実にもかかわらず、QOSメカニズムの、新たなトランスポートプロトコルの到着は、エンド・ツー・エンドのパフォーマンスについて、新たな問題を提起したが、これらは、ここで議論されていません。
When the catenet concept (a network of networks) was first described by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin in 1974 [CATENET], a clear assumption was that a single logical address space would cover the whole catenet (or Internet as we now know it). This applied not only to the early TCP/IP Internet, but also to the Xerox PUP design, the OSI connectionless network design, XNS, and numerous other proprietary network architectures.
CATENET概念（ネットワークのネットワーク）は、最初1978年にサーフによって記載されたとき[IEN 48] [CATENET] 1974年プザンにより以前提案以下、明確な仮定は、単一の論理アドレス空間全体CATENETをカバーすることであった（あるいは我々は今それを知っているように、インターネット）。これは、初期のTCP / IPインターネットにするだけでなく、ゼロックスPUPデザイン、OSIコネクションレスネットワークの設計、XNS、および多数の他の独自のネットワーク・アーキテクチャにも適用しました。
This concept had two clear consequences - packets could flow essentially unaltered throughout the network, and their source and destination addresses could be used as unique labels for the end systems.
この概念は、二つの明確な結果をもたらした - パケットがネットワーク全体で、本質的に変化していない流れができ、そしてその送信元と送信先のアドレスは、エンド・システムのためのユニークなラベルとして使用することができます。
The first of these consequences is not absolute. In practice changes can be made to packets in transit. Some of these are reversible at the destination (such as fragmentation and compression). Others may be irreversible (such as changing type of service bits or decrementing a hop limit), but do not seriously obstruct the end-to-end principle of Section 2.1. However, any change made to a packet in transit that requires per-flow state information to be kept at an intermediate point would violate the fate-sharing aspect of the end-to-end principle.
これらの結果の最初は絶対ではありません。実際には変更は、輸送中のパケットにすることができます。これらのいくつかは、（断片化および圧縮など）先に可逆的です。他のものは、（例えば、サービスビットのタイプを変更したり、ホップリミットをデクリメントなど）不可逆的であってもよいが、真剣にセクション2.1のエンド・ツー・エンド原理を妨げません。しかしながら、中間点に保持するフローごとの状態情報を必要と輸送中のパケットに対して行われた変更は、エンド・ツー・エンドの原則の運命共有局面に違反します。
The second consequence, using addresses as unique labels, was in a sense a side-effect of the catenet concept. However, it was a side-effect that came to be highly significant. The uniqueness and durability of addresses have been exploited in many ways, in particular by incorporating them in transport identifiers. Thus they have been built into transport checksums, cryptographic signatures, Web documents, and proprietary software licence servers. [RFC 2101] explores this topic in some detail. Its main conclusion is that IPv4 addresses can no longer be assumed to be either globally unique or invariant, and any protocol or applications design that assumes these properties will fail unpredictably. Work in the IAB and the NAT working group [NAT-ARCH] has analysed the impact of one specific cause of non-uniqueness and non-invariance, i.e., network address translators. Again the conclusion is that many applications will fail, unless they are specifically adapted to avoid the assumption of address transparency. One form of adaptation is the insertion of some form of application level gateway, and another form is for the NAT to modify payloads on the fly, but in either case the adaptation is application-specific.
ユニークなラベルとしてのアドレスを使用して、第2の結果は、ある意味でCATENET概念の副作用でした。しかし、それは非常に重要であることになりました副作用でした。アドレスの一意性と耐久性はトランスポート識別子でそれらを組み込むことにより、特に、多くの方法で利用されています。したがって、彼らは輸送チェックサム、暗号署名、Webドキュメント、および独自のソフトウェア・ライセンス・サーバに組み込まれています。 [RFC 2101]は、いくつかの詳細にこのトピックを探ります。その主な結論は、IPv4アドレスは、もはやグローバルに一意または不変のどちらかであると想定することはできないということであり、これらの特性は、予期しない失敗すると仮定し、任意のプロトコルやアプリケーションの設計。 IABとNATワーキンググループ[NAT-ARCH]で作業は、非一意性と非不変性、すなわち、ネットワークアドレス変換の一つの特定の原因の影響を分析しました。彼らは、特にアドレス透明性の仮定を避けるように適応されない限り、ここでも結論は、多くのアプリケーションが失敗するということです。適応の一の形態は、アプリケーション・レベルのゲートウェイの何らかの形の挿入であり、そして他の形態は、オンザフライでペイロードを変更するためのNATのためのものであるが、いずれの場合にも適応は、アプリケーション固有です。
Non-transparency of addresses is part of a more general phenomenon. We have to recognise that the Internet has lost end-to-end transparency, and this requires further analysis.
アドレスの非透明性は、より一般的な現象の一部です。私たちは、インターネットは、エンドツーエンドの透明性を失ったことを認識する必要があり、これはさらなる分析が必要です。
This section describes various recent inventions that have led to the loss of end-to-end transparency in the Internet.
このセクションでは、インターネットにおけるエンド・ツー・エンドの透明性の喪失につながっている様々な最近の発明を説明しています。
Underlying a number of the specific developments mentioned below is the concept of an "Intranet", loosely defined as a private corporate network using TCP/IP technology, and connected to the Internet at large in a carefully controlled manner. The Intranet is presumed to be used by corporate employees for business purposes, and to interconnect hosts that carry sensitive or confidential information. It is also held to a higher standard of operational availability than the Internet at large. Its usage can be monitored and controlled, and its resources can be better planned and tuned than those of the public network. These arguments of security and resource management have ensured the dominance of the Intranet model in most corporations and campuses.
下記の具体的な進展の数の基礎となる「イントラネット」の概念であり、緩くTCP / IP技術を利用して企業のプライベートネットワークとして定義され、慎重に制御された方法で大でインターネットに接続されています。イントラネットは、ビジネス上の目的のために、企業の従業員が使用していると推定されており、機密情報や機密情報を運ぶホストを相互接続します。また、大規模でインターネットより運用可用性の高い水準に保持されています。その使用は、監視、制御、およびそのリソースは、より良い計画とパブリックネットワークのものより調整することができますすることができます。セキュリティとリソース管理のこれらの引数は、ほとんどの企業やキャンパス内のイントラネットモデルの優位性を確保しています。
The emergence of the Intranet model has had a profound effect on the notion of application transparency. Many corporate network managers feel it is for them alone to determine which applications can traverse the Internet/Intranet boundary. In this world view, address transparency may seem to be an unimportant consideration.
イントラネットモデルの登場は、アプリケーションの透明性の概念に大きな影響を与えています。多くの企業のネットワーク管理者は、彼らだけでは、アプリケーションがインターネット/イントラネットの境界を通過できるかを決定することがある気がします。この世界観では、アドレスの透明性が重要でない考慮ように見えることがあります。
It is to be noted that with the advent of vast numbers of dial-up Internet users, whose addresses are allocated at dial-up time, and whose traffic may be tunneled back to their home ISP, the actual IP addresses of such users are purely transient. During their period of validity they can be relied on end-to-end, but they must be forgotten at the end of every session. In particular they can have no permanent association with the domain name of the host borrowing them.
これは、アドレスを持つトラフィック自宅のISPに戻ってトンネル化することができるダイヤルアップ時に割り当てられ、ダイヤルアップインターネットユーザーの膨大な数の出現で、こうしたユーザーの実際のIPアドレスは、純粋であることに留意されたいです過渡。有効性の彼らの期間中、彼らは、エンドツーエンドに頼っていたことができますが、それらはすべてのセッションの最後に忘れなければなりません。特に、彼らはそれらを借りホストのドメイン名とは永久的な関連性を持つことはできません。
Similarly, LAN-based users of the Internet today frequently use DHCP to acquire a new address at system restart, so here again the actual value of the address is potentially transient and must not be stored between sessions.
同様に、インターネットのLANベースのユーザーは、今日は、頻繁にシステムの再起動時に新しいアドレスを取得するためにDHCPを使用するので、ここで再度、アドレスの実際の値は、潜在的に一時的であるとセッション間で保存されてはいけません。
Intranet managers have a major concern about security: unauthorised traffic must be kept out of the Intranet at all costs. This concern led directly to the firewall concept (a system that intercepts all traffic between the Internet and the Intranet, and only lets through selected traffic, usually belonging to a very limited set of applications). Firewalls, by their nature, fundamentally limit transparency.
不正なトラフィックがすべてのコストでのイントラネットの外に置かれている必要がありますイントラネットの管理者は、セキュリティについて大きな懸念を持っています。この懸念は、ファイアウォールの概念（インターネットとイントラネット間のすべてのトラフィックを傍受し、そして唯一の選択されたトラフィックを通す、通常のアプリケーションの非常に限られたセットに属するシステム）に直接つながりました。ファイアウォールは、その性質上、基本的に透明性を制限します。
A footnote to the effect of firewalls is the SOCKS mechanism [RFC 1928] by which untrusted applications such as telnet and ftp can punch through a firewall. SOCKS requires a shim library in the Intranet client, and a server in the firewall which is essentially an application level relay. As a result, the remote server does not see the real client; it believes that the firewall is the client.
ファイアウォールの効果に脚注はTelnetやFTPなど、信頼できないアプリケーションがファイアウォールを介してパンチことが可能なSOCKSメカニズム[RFC 1928]です。 SOCKSイントラネットクライアントでシムライブラリ、および基本的にアプリケーションレベルのリレーでファイアウォール内のサーバーが必要です。その結果、リモートサーバは、実際のクライアントは表示されません。それは、ファイアウォールがクライアントであると考えています。
When the threat of IPv4 address exhaustion first arose, and in some cases user sites were known to be "pirating" addresses for private use, a set of official private addresses were hurriedly allocated [RFC 1597] and later more carefully defined [BCP 5]. The legitimate existence of such an address allocation proved to very appealing, so Intranets with large numbers of non-global addresses came into existence. Unfortunately, such addresses by their nature cannot be used for communication across the public Internet; without special measures, hosts using private addresses are cut off from the world.
IPv4アドレス枯渇の脅威が最初に生じた、とユーザサイトは私的使用のための「著作権侵害」のアドレスであることが知られたいくつかのケースでは、公式のプライベートアドレスのセットは急い[RFC 1597]を割り当てられ、後に、より慎重に定義された場合は[BCP 5] 。非グローバルアドレスの数が多いイントラネットが存在に入って来たので、このようなアドレス割り当ての合法的な存在は、非常に魅力的に証明しました。残念ながら、その性質上、このようなアドレスは、公共のインターネット経由の通信に使用することはできません。特別な措置なしで、プライベートアドレスを使用しているホストが世界から切り離されます。
Note that private address space is sometimes asserted to be a security feature, based on the notion that outside knowledge of internal addresses might help intruders. This is a false argument, since it is trivial to hide addresses by suitable access control lists, even if they are globally unique - indeed that is a basic feature of a filtering router, the simplest form of firewall. A system with a hidden address is just as private as a system with a private address. There is of course no possible point in hiding the addresses of servers to which outside access is required.
プライベートアドレス空間は時々内部アドレスの外側の知識は侵入者を助けるかもしれないという考えに基づいて、セキュリティ機能であることが表明されていることに注意してください。適切なアクセス制御リストでアドレスを隠すために簡単ですので、これは、彼らがグローバルに一意であっても、偽の引数である - 確かにそれは、フィルタリングルータ、ファイアウォールの最も単純な形式の基本的な機能です。隠されたアドレスを持つシステムでは、プライベートアドレスを持つシステムと同じようにプライベートです。外部からのアクセスが必要とされているサーバーのアドレスを隠すには可能性の点ではもちろんありません。
It is also worth noting that the IPv6 equivalent of private addresses, i.e. site-local addresses, have similar characteristics to BCP 5 addresses, but their use will not be forced by a lack of globally unique IPv6 addresses.
プライベートアドレスのIPv6の同等、すなわち、サイトローカルアドレスは、BCP 5アドレスに似た特性を持っていることも注目に値するが、その使用は、グローバルにユニークなIPv6アドレスの不足によって強制されることはありません。
Network address translators (NATs) are an almost inevitable consequence of the existence of Intranets using private addresses yet needing to communicate with the Internet at large. Their architectural implications are discussed at length in [NAT-ARCH], the fundamental point being that address translation on the fly destroys end-to-end address transparency and breaks any middleware or applications that depend on it. Numerous protocols, for example H.323, carry IP addresses at application level and fail to traverse a simple NAT box correctly. If the full range of Internet applications is to be used, NATs have to be coupled with application level gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be updated whenever a new address-dependent application comes along. In practice, NAT functionality is built into many firewall products, and all useful NATs have associated ALGs, so it is difficult to disentangle their various impacts.
ネットワークアドレス変換器（NAT）はまだ広くインターネットと通信する必要がプライベートアドレスを使用してイントラネットの存在のほぼ必然的な結果です。彼らの建築の影響が[NAT-ARCH]の長さで議論され、その場でそのアドレス変換されて基本的なポイントは、エンドツーエンドのアドレスの透明性を破壊し、それに依存するミドルウェアやアプリケーションを壊します。多数のプロトコルは、例えば、H.323のために、アプリケーションレベルでIPアドレスを運び、正しくシンプルなNATボックスを通過しません。インターネットアプリケーションの全範囲を使用する場合、NATはアプリケーションレベルゲートウェイ（のALG）またはプロキシと結合しなければなりません。新しいアドレスに依存するアプリケーションがやって来るたびさらに、ALGまたはプロキシを更新する必要があります。実際には、NAT機能は、多くのファイアウォール製品に組み込まれ、そしてすべての有用なNATはのALGが関連付けられているので、彼らの様々な影響を解きほぐすことは困難です。
It is reasonable to position application level gateways, relays, proxies, and caches at certain critical topological points, especially the Intranet/Internet boundary. For example, if an Intranet does not use SMTP as its mail protocol, an SMTP gateway is needed. Even in the normal case, an SMTP relay is common, and can perform useful mail routing functions, spam filtering, etc. (It may be observed that spam filtering is in some ways a firewall function, but the store-and-forward nature of electronic mail and the availability of MX records allow it to be a distinct and separate function.)
特定の重要なトポロジカルポイント、特にイントラネット/インターネット境界でアプリケーションレベルゲートウェイ、リレー、プロキシ、およびキャッシュを配置するのが合理的です。イントラネットは、そのメールプロトコルとしてSMTPを使用しない場合、例えば、SMTPゲートウェイが必要です。通常の場合、SMTPリレーは一般的であり、等の有用なメールルーティング機能、スパムフィルタリングを行うことができる（スパムフィルタリング、ファイアウォール機能は、いくつかの方法であることが観察されたが、ストアアンドフォワード性質のものであってもよいです電子メールおよびMXレコードの利用可能性は、それがはっきりと別の関数であることを可能にします。）
Similarly, for a protocol such as HTTP with a well-defined voluntary proxy mechanism, application proxies also serving as caches are very useful. Although these devices interfere with transparency, they do so in a precise way, correctly terminating network, transport and application protocols on both sides. They can however exhibit some shortfalls in ease of configuration and failover.
同様に、明確に定義された自発的なプロキシ機構とHTTPなどのプロトコルのために、また、キャッシュとしてのアプリケーションプロキシは非常に有用です。これらのデバイスは、透明性を妨げるが、それらは正しく両側のネットワーク、輸送とアプリケーションプロトコルを終端し、正確な方法で行います。彼らは、しかし、構成やフェイルオーバーの容易さで、いくつかの不足を示すことができます。
However, there appear to be cases of "involuntary" applications level devices such as proxies that grab and modify HTTP traffic without using the appropriate mechanisms, sometimes known as "transparent caches", or mail relays that purport to remove undesirable words. These devices are by definition not transparent, and may have totally unforeseeable side effects. (A possible conclusion is that even for non-store-and-forward protocols, a generic diversion mechanism analogous to the MX record would be of benefit. The SRV record [RFC 2052] is a step in this direction.)
しかし、このような望ましくない単語を削除する趣旨適切時々「透明キャッシュ」として知られているメカニズム、またはメールリレーを使用せずに取得し、HTTPトラフィックを変更するプロキシとして「不随意」アプリケーション・レベルのデバイスの例があるように思われます。これらのデバイスは、定義により透明でない、と完全に予測できない副作用を有することができます。 （可能な結論はさらに、非ストアアンドフォワードプロトコルについて、MXレコードに類似した一般的な迂回機構は有益であろうということである。[RFC 2052]は、この方向への一歩であるSRVレコード）。
There are communities that think of themselves as being so different that they require isolation via an explicit proxy, and even by using proprietary protocols and addressing schemes within their network. An example is the WAP Forum which targets very small phone-like devices with some capabilities for Internet connectivity. However, it's not the Internet they're connecting directly to. They have to go through a proxy. This could potentially mean that millions of devices will never know the benefits of end-to-end connectivity to the Internet.
彼らは、明示的なプロキシを経由して、さらには独自のプロトコルを使用して、そのネットワーク内のアドレッシング方式による単離を必要とするので、異なるものとして自分自身を考えるコミュニティがあります。例では、インターネット接続のためのいくつかの機能を備えた非常に小さな携帯電話のようなデバイスを対象とWAPフォーラムです。しかし、それは彼らがに直接接続しているインターネットではありません。彼らは、プロキシを通過する必要があります。これは、潜在的に何百万ものデバイスがインターネットにエンドツーエンド接続のメリットを知っていることはありませんことを意味します。
A similar effect arises when applications such as telephony span both an IP network and a peer network layer using a different technology. Although the application may work end-to-end, there is no possibility of end-to-end packet transmission.
そのような電話スパンなどのアプリケーションIPネットワークとピアネットワーク層の両方は、異なる技術を使用する場合も同様の効果が生じます。アプリケーションは、エンドツーエンドの仕事かもしれないが、エンドツーエンドのパケット送信の可能性はありません。
Another consequence of the Intranet/Internet split is "split DNS" or "two faced DNS", where a corporate network serves up partly or completely different DNS inside and outside its firewall. There are many possible variants on this; the basic point is that the correspondence between a given FQDN (fully qualified domain name) and a given IPv4 address is no longer universal and stable over long periods.
イントラネット/インターネットスプリットの他の結果は、企業ネットワークがファイアウォールの内側と外側の部分的または完全に異なるDNSをセットアップ機能「スプリットDNS」または「2つの直面しているDNS」、です。この上の多くの可能なバリエーションがあります。基本的なポイントは、与えられたFQDN（完全修飾ドメイン名）と指定したIPv4アドレスの対応関係は、もはや長期間にわたり普遍的かつ安定しているということではありません。
IPv4 was not designed to support anycast [RFC 1546], so there is no natural approach to load-sharing when one server cannot do the job. Various tricks have been used to resolve this (multicast to find a free server, the DNS returns different addresses for the same FQDN in a round-robin, a router actually routes packets sent to the same address automatically to different servers, etc.). While these tricks are not particularly harmful in the overall picture, they can be implemented in such a way as to interfere with name or address transparency.
IPv4のは、エニーキャスト[RFC 1546]をサポートするように設計されたので、一つのサーバが仕事をすることができない場合、ロードシェアリングへの自然なアプローチではありませんされませんでした。様々なトリックが、この解決するために使用されています（無料のサーバーを見つけるために、マルチキャストを、DNSが実際にルータ別のサーバーに自動的に同じアドレスに送信されたパケットをルーティングするなど、ラウンドロビンで同じFQDNのための異なるアドレスを返します）。これらのトリックは全体像では特に有害ではありませんが、名前や住所、透明性に干渉するような方法で実施することができます。
It is impossible to estimate with any numerical reliability how widely the above inventions have been deployed. Since many of them preserve the illusion of transparency while actually interfering with it, they are extremely difficult to measure.
上記の発明が展開されているか、広く任意の数値の信頼性を推定することは不可能です。実際にそれに干渉しながら、それらの多くは、透明性の錯覚を維持するので、測定することが極めて困難です。
However it is certain that all the mechanisms just described are in very widespread use; they are not a marginal phenomenon. In corporate networks, many of them are the norm. Some of them (firewalls, relays, proxies and caches) clearly have intrinsic value given the Intranet concept. The others are largely artefacts and pragmatic responses to various pressures in the operational Internet, and they must be costing the industry very dearly in constant administration and complex fault diagnosis.
しかし、それだけで説明したすべてのメカニズムは非常に普及していることは確かです。彼らはマージナルな現象ではありません。企業ネットワークでは、それらの多くは当たり前です。それらのいくつかは（ファイアウォール、リレー、プロキシやキャッシュ）明確にイントラネット概念与えられた本質的な価値を持っています。他の人は、主に工芸品や運用インターネットで様々な圧力に実用的な反応であり、彼らは一定の管理と複雑な故障診断に非常に心から産業の原価計算する必要があります。
In particular, the decline of transparency is having a severe effect on deployment of end-to-end IP security. The Internet security model [SECMECH] calls for security at several levels (roughly, network, applications, and object levels). The current network level security model [RFC 2401] was constructed prior to the recognition that end-to-end address transparency was under severe threat. Although alternative proposals have begun to emerge [HIP] the current reality is that IPSEC cannot be deployed end-to-end in the general case. Tunnel-mode IPSEC can be deployed between corporate gateways or firewalls. Transport-mode IPSEC can be deployed within a corporate network in some cases, but it cannot span from Intranet to Internet and back to another Intranet if there is any chance of a NAT along the way.
特に、透明性の低下は、エンドツーエンドのIPセキュリティの展開に重大な影響を持っています。いくつかのレベルのセキュリティのためのインターネット・セキュリティ・モデルは、[SECMECH]コール（おおよそ、ネットワーク、アプリケーション、およびオブジェクトレベル）。現在のネットワークレベルのセキュリティモデル[RFC 2401】従来、エンドツーエンドのアドレス透明性が深刻な脅威にさらされたという認識に構築しました。代替案は、[HIP]を出始めているが、現在の現実は、IPSECは、一般的な場合には、エンドツーエンドを展開することができないということです。トンネルモードIPSECは、企業のゲートウェイまたはファイアウォールの間に配置することができます。トランスポートモードIPSECは、いくつかのケースでは、企業ネットワーク内に配置することができますが、道に沿ってNATのいずれかの可能性がある場合には、イントラネットからインターネットへと戻って別のイントラネットにまたがることはできません。
Indeed, NAT breaks other security mechanisms as well, such as DNSSEC and Kerberos, since they rely on address values.
彼らはアドレス値に依存しているため、実際に、NATは、DNSSECやKerberosなどの他のセキュリティメカニズムを破ります。
The loss of transparency brought about by private addresses and NATs affects many applications protocols to a greater or lesser extent. This is explored in detail in [NAT-PROT]. A more subtle effect is that the prevalence of dynamic addresses (from DHCP, SLIP and PPP) has fed upon the trend towards client/server computing. Today it is largely true that servers have fixed addresses, clients have dynamic addresses, and servers can in no way assume that a client's IP address identifies the client. On the other hand, clients rely on servers having stable addresses since a DNS lookup is the only generally deployed mechanism by which a client can find a server and solicit service. In this environment, there is little scope for true peer-to-peer applications protocols, and no easy solution for mobile servers. Indeed, the very limited demand for Mobile IP might be partly attributed to the market dominance of client/server applications in which the client's address is of transient significance. We also see a trend towards single points of failure such as media gateways, again resulting from the difficulty of implementing peer-to-peer solutions directly between clients with no fixed address.
プライベートアドレスとNATのによってもたらさ透明性の喪失は、多かれ少なかれ多くのアプリケーションプロトコルに影響を与えます。これは、[NAT-PROT]で詳細に調査しています。より微妙な効果は（DHCP、SLIPおよびPPPから）動的アドレスの有病率は、クライアント/サーバ・コンピューティング傾向の際に供給されたことです。今日では、サーバは、クライアントが動的アドレスを持つ、アドレスを固定しており、サーバは決してクライアントのIPアドレスは、クライアントを識別することを想定することができることを、主に真実です。 DNSルックアップは、クライアントがサーバーを見つけて、サービスを求めることが可能なだけで、一般的に展開メカニズムであるため、一方で、クライアントが安定したアドレスを持つサーバに依存しています。この環境では、真のピア・ツー・ピア・アプリケーション・プロトコルのために少し範囲、およびモバイル・サーバー用の簡単な解決策があります。確かに、モバイルIPのための非常に限られた需要の一部は、クライアントのアドレスが一時的意義のある、クライアント/サーバアプリケーションの市場支配力に起因している可能性があります。我々はまた、再び固定されていないアドレスとクライアント間で直接ピア・ツー・ピア・ソリューションを実現することの難しさに起因する、そのようなメディアゲートウェイとして単一障害点に向かう傾向を見ます。
The notion that servers can use precious globally unique addresses from a small pool, because there will always be fewer servers than clients, may become anachronistic when most electrical devices become network-manageable and thus become servers for a management protocol. Similarly, if every PC becomes a telephone (or the converse), capable of receiving unsolicited incoming calls, the lack of stable IP addresses for PCs will be an issue. Another impending paradigm shift is when domestic and small-office subscribers move from dial-up to always-on Internet connectivity, at which point transient address assignment from a pool becomes much less appropriate.
ほとんどの電気機器がネットワーク管理可能となり、したがって、管理プロトコル用のサーバになったときに、常にクライアントより少数のサーバーが存在しますので、サーバは、小さなプールからの貴重なグローバルに一意のアドレスを使用することができる概念は、時代錯誤になることがあります。同様に、すべてのPCは、電話（またはその逆）になった場合、迷惑着信コールを受けることができる、PC用安定したIPアドレスの不足が問題になります。別の差し迫ったパラダイムシフトは、国内および小規模オフィスの加入者がダイヤルアップからに移動するときは常にオンのプールからの過渡アドレス割り当てはあまり適切となった時点で、インターネット接続、。
Many of the inventions described in the previous section lead to the datagram traffic between two hosts being directly or indirectly mediated by at least one other host. For example a client may depend on a DHCP server, a server may depend on a NAT, and any host may depend on a firewall. This violates the fate-sharing principle of [Saltzer] and introduces single points of failure. Worse, most of these points of failure require configuration data, yet another source of operational risk. The original notion that datagrams would find their way around failures, especially around failed routers, has been lost; indeed the overloading of border routers with additional functions has turned them into critical rather than redundant components, even for multihomed sites.
2つのホスト間でデータグラムトラフィックに前節リードに記載の発明の多くは、直接的または間接的に少なくとも一つの他のホストによって媒介されます。たとえば、クライアントがDHCPサーバーに依存してもよい、サーバがNATに依存してもよいし、任意のホストは、ファイアウォールに依存してもよいです。これは、[Saltzer]の運命共有の原則に違反し、単一障害点を紹介します。さらに悪いことに、失敗のこれらの点のほとんどは、構成データ、オペレーショナル・リスクのさらに別のソースを必要としています。データグラムが失敗の周りに自分の道を見つけるだろう、元の概念、特に周りに失敗したルータは、失われています。確かに、追加の機能を持つ境界ルータのオーバーロードでもマルチホームのサイトのために、重要ではなく、冗長コンポーネントにそれらを回しました。
The loss of address transparency has other negative effects. For example, large scale servers may use heuristics or even formal policies that assign different priorities to service for different clients, based on their addresses. As addresses lose their global meaning, this mechanism will fail. Similarly, any anti-spam or anti-spoofing techniques that rely on reverse DNS lookup of address values can be confused by translated addresses. (Uncoordinated renumbering can have similar disadvantages.)
アドレス透明性の損失は、他の負の効果を持っています。たとえば、大規模なサーバーでは、ヒューリスティックまたはそのアドレスに基づいて異なるクライアントのためにサービスを提供するために異なる優先順位を割り当てることも、正式なポリシーを使用することができます。アドレスは、グローバルな意味を失うように、このメカニズムは失敗します。同様に、アドレス値のDNSの逆引きに依存しているすべてのアンチスパムやアンチスプーフィング技術は、変換されたアドレスで混乱することができます。 （非協調リナンバリングは、同様の欠点を持つことができます。）
The above issues are not academic. They add up to complexity in applications design, complexity in network configuration, complexity in security mechanisms, and complexity in network management. Specifically, they make fault diagnosis much harder, and by introducing more single points of failure, they make faults more likely to occur.
上記の問題は学術的ではありません。彼らは、アプリケーションの設計、ネットワーク構成の複雑さ、セキュリティメカニズムにおける複雑さ、およびネットワーク管理における複雑さの複雑まで追加します。具体的には、彼らははるかに困難故障診断を行い、故障のより多くの単一のポイントを導入することで、彼らが発生する障害が可能性が高くなります。
In this scenario, IPv6 becomes fully implemented on all hosts and routers, including the adaptation of middleware, applications, and management systems. Since the address space then becomes big enough for all conceivable needs, address transparency can be restored. Transport-mode IPSEC can in principle deploy, given adequate security policy tools and a key infrastructure. However, it is widely believed that the Intranet/firewall model will certainly persist.
このシナリオでは、IPv6は完全ミドルウェア、アプリケーション、および管理システムの適応を含め、すべてのホストおよびルータに実装さになります。アドレス空間は、その後、考えられるすべてのニーズに十分な大きさになりますので、アドレス透明性を復元することができます。トランスポートモードでIPSECは、原則として展開して、適切なセキュリティポリシーツールや鍵インフラストラクチャを与えることができます。しかし、広くイントラネット/ファイアウォールモデルは確かに持続すると考えられます。
Note that it is a basic assumption of IPv6 that no artificial constraints will be placed on the supply of addresses, given that there are so many of them. Current practices by which some ISPs strongly limit the number of IPv4 addresses per client will have no reason to exist for IPv6. (However, addresses will still be assigned prudently, according to guidelines designed to favour hierarchical routing.)
人為的な制約は、それらの多くがあることを考えると、アドレスの供給に置かれないことのIPv6の基本的な前提であることに注意してください。一部のISPは強くクライアントあたりのIPv4アドレスの数を制限することにより、現在の慣行は、IPv6のために存在する理由がないだろう。 （ただし、アドレスはまだ階層型ルーティングを優先するように設計されたガイドラインに従って、慎重に割り当てられます。）
Clearly this is in any case a very long term scenario, since it assumes that IPv4 has declined to the point where IPv6 is required for universal connectivity. Thus, a viable version of Scenario 5.3 is a prerequisite for Scenario 5.1.
それは、IPv4がIPv6がユニバーサルな接続のために必要とされる点まで減少していることを前提としているのでこれは明らかに、どのような場合に非常に長期的なシナリオです。このように、シナリオ5.3の実行可能なバージョンは、シナリオ5.1のための前提条件です。
In this scenario, IPv6 fails to reach any significant level of operational deployment, IPv4 addressing is the only available mechanism, and address transparency cannot be restored. IPSEC cannot be deployed globally in its current form. In the very long term, the pool of globally unique IPv4 addresses will be nearly totally allocated, and new addresses will generally not be available for any purpose.
このシナリオでは、IPv6はIPv4アドレス、業務展開の任意の有意水準に到達するために失敗しただけで利用できる機構であり、アドレスの透明性を復元することはできません。 IPSECは、現在の形でグローバルに展開することができません。非常に長期的には、グローバルに一意のIPv4アドレスのプールはほぼ完全に割り当てられます、そして新しいアドレスは、一般的に、任意の目的のために使用することはできません。
It is unclear exactly what is likely to happen if the Internet continues to rely exclusively on IPv4, because in that eventuality a variety of schemes are likely to promulgated, with a view toward providing an acceptable evolutionary path for the network. However, we can examine two of the more simplistic sub-scenarios which are possible, while realising that the future would be unlikely to match either one exactly:
インターネットは、IPv4のみに頼ることを続ければその事態に様々なスキームは、公布の可能性があるので、ネットワークのための許容可能な進化の経路を提供することも視野に、起こりそうであるまさに不明です。将来は正確にどちらか一方に一致する可能性は低いだろうことを認識しながら、しかし、我々は、可能であり、より単純なサブシナリオのうち2つを調べることができます。
Suppose that a mechanism is created to continuously recover and re-allocate IPv4 addresses. A single global address space is maintained, with all sites progressively moving to an Intranet private address model, with global addresses being assigned temporarily from a pool of several billion.
メカニズムが連続的にIPv4アドレスを回復し、再割り当てするために作成されたとします。単一のグローバルアドレス空間は、すべてのサイトが徐々にグローバルアドレスは、数十億のプールから一時的に割り当てられていると、イントラネットプライベートアドレスモデルに移行して、維持されています。
5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT (NAT with port number translation). This has the disadvantage that the host is unaware of the unique address being used for its traffic, being aware only of its ambiguous private address, with all the problems that this generates. See [NAT-ARCH].
5.2.1.1本のサブサブシナリオが（ポート番号変換とNAT）NATとNAPTの使用が一般化されます。これは、ホストは、これが生成するすべての問題で、唯一その曖昧なプライベートアドレスを意識すること、そのトラフィックのために使用されている一意のアドレスを知らないという欠点があります。 [NAT-ARCH]を参照してください。
5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP addressing implemented at the host rather than by a NAT box. See [RSIP]. In this case the host is aware of its unique address, allowing for substantial restoration of the end-to-end usefulness of addresses, e.g. for TCP or cryptographic checksums.
5.2.1.2別のサブサブシナリオは、ホストではなく、NATボックスによって実現アドレッシングレルム固有のIPの使用です。 [RSIP]を参照してください。この場合、ホストは、例えば、アドレスのエンドツーエンドの有用性の実質的な回復を可能にする、独自のアドレスを知っていますTCPまたは暗号チェックサムのために。
5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model in which address translation is replaced by systematic encapsulation of all packets for wide-area transport. This model has never been fully developed, although it is completely compatible with end-to-end addressing.
5.2.1.3最終サブサブシナリオは、アドレス変換が広域輸送のためのすべてのパケットの系統的なカプセル化により置換された「マップおよびカプセル化」モデルです。それはエンドツーエンドのアドレス指定と完全に互換性がありますが、このモデルは、完全に、開発されていませんでした。
Suppose that no mechanism is created to recover addresses (except perhaps black or open market trading). Sites with large address blocks keep them. All the scenarios of 5.2.1 appear but are insufficient. Eventually the global address space is no longer adequate. This is a nightmare scenario - NATs appear within the "global" address space, for example at ISP-ISP boundaries. It is unclear how a global routing system and a global DNS system can be maintained; the Internet is permanently fragmented.
メカニズムが（おそらく黒または公開市場取引を除く）のアドレスを回復するために作成されていないこととします。大規模なアドレスブロックを持つサイトでは、それらを保ちます。 5.2.1のすべてのシナリオが表示されますが、不十分です。最終的にはグローバルアドレス空間は、もはや十分ではありません。これは悪夢のシナリオです - NATはISP-ISPの境界で、たとえば、「グローバル」アドレス空間内に表示されます。グローバルルーティングシステムとグローバルDNSシステムを維持することができるかは不明です。インターネットは永久に断片化されています。
In this scenario, IPv6 is completely implemented but only deploys in certain segments of the network (e.g. in certain countries, or in certain areas of application such as mobile hand-held devices). Instead of being transitional in nature, some of the IPv6 transition techniques become permanent features of the landscape. Sometimes addresses are 32 bits, sometimes they are 128 bits. DNS lookups may return either or both. In the 32 bit world, the scenarios 5.2.1 and 5.2.2 may occur. IPSEC can only deploy partially.
このシナリオでは、IPv6が完全に実装されているのみ（例えば、特定の国、またはそのようなモバイルハンドヘルドデバイスなどのアプリケーションの特定の領域における）ネットワークの特定のセグメントに展開します。代わりに自然の中で過渡的であることの、IPv6移行技術のいくつかは、景観の恒久的な機能になります。時にはアドレスは時々、彼らは128ビットであり、32ビットです。 DNSルックアップは、いずれかまたは両方を返すことがあります。 32ビットの世界では、シナリオ5.2.1および5.2.2が発生することがあります。 IPSECは部分的にしか展開できます。
None of the above scenarios is clean, simple and straightforward. Although the pure IPv6 scenario is the cleanest and simplest, it is not straightforward to reach it. The various scenarios without use of IPv6 are all messy and ultimately seem to lead to dead ends of one kind or another. Partial deployment of IPv6, which is a required step on the road to full deployment, is also messy but avoids the dead ends.
上記のシナリオのいずれも、きれいな単純明快ではありません。純粋なIPv6のシナリオが最もクリーンかつ最も簡単ですが、それに到達することは簡単ではありません。 IPv6のを使用することなく、様々なシナリオは、すべての乱雑され、最終的に1種類または別の行き止まりにつながるように見えます。完全な展開への道に必要なステップであるIPv6の、の部分的な展開は、また厄介であるが、行き止まりを回避することができます。
The loss of transparency is both a bug and a feature from the security viewpoint. To the extent that it prevents the end-to-end deployment of IPSEC, it damages security and creates vulnerabilities. For example, if a standard NAT box is in the path, then the best that can be done is to decrypt and re-encrypt IP traffic in the NAT. The traffic will therefore be momentarily in clear text and potentially vulnerable. Furthermore, the NAT will possess many keys and will be a prime target of attack. In environments where this is unacceptable, encryption must be applied above the network layer instead, of course with no usage whatever of IP addresses in data that is cryptographically protected. See section 4 for further discussion.
透明性の損失は、バグやセキュリティの観点からの特徴でもあります。それは、IPSECのエンドツーエンドの展開を防止して損害賠償のセキュリティと脆弱性を作成する程度に。標準NATボックスはパスにある場合は、その後に行うことができる最善のは、NATでIPトラフィックを復号化し、再暗号化することです。トラフィックは、したがって、一時的にクリアテキストで、潜在的に脆弱になります。さらに、NATは、多くのキーを所有し、攻撃の主なターゲットとなります。これは許容されない環境では、暗号化が暗号で保護されたデータにIPアドレスのどのない用途に当然のことながら、代わりに、ネットワーク層の上に適用されなければなりません。さらなる議論のためのセクション4を参照してください。
In certain scenarios, i.e. 5.1 (full IPv6) and 5.2.1.2 (RSIP), end-to-end IPSEC would become possible, especially using the "distributed firewalls" model advocated in [Bellovin].
特定のシナリオ、すなわち、5.1（完全なIPv6）と5.2.1.2（RSIP）において、エンドツーエンドのIPSECは特に[Bellovin氏]で提唱「分散型ファイアウォール」モデルを使用して、可能になります。
The loss of transparency at the Intranet/Internet boundary may be considered a security feature, since it provides a well defined point at which to apply restrictions. This form of security is subject to the "crunchy outside, soft inside" risk, whereby any successful penetration of the boundary exposes the entire Intranet to trivial attack. The lack of end-to-end security applied within the Intranet also ignores insider threats.
それは制限を適用するために明確に定義されたポイントを提供するため、イントラネット/インターネット境界における透明性の損失は、セキュリティ機能を考慮することができます。セキュリティのこの形式は、境界のいずれかの成功浸透は些細な攻撃に全体のイントラネットを公開することにより、「カリカリの外側、内側のソフトな」リスクにさらさです。イントラネット内で適用エンドツーエンドのセキュリティの欠如はまた、インサイダーの脅威を無視します。
It should be noted that security applied above the transport level, such as SSL, SSH, PGP or S/MIME, is not affected by network layer transparency issues.
SSL、SSH、PGPやS / MIMEなどのトランスポートレベルの上方に適用されるセキュリティは、ネットワーク層の透明性の問題に影響されないことに留意すべきです。
Acknowledgements
謝辞
This document and the related issues have been discussed extensively by the IAB. Special thanks to Steve Deering for a detailed review and to Noel Chiappa. Useful comments or ideas were also received from Rob Austein, John Bartas, Jim Bound, Scott Bradner, Vint Cerf, Spencer Dawkins, Anoop Ghanwani, Erik Guttmann, Eric A. Hall, Graham Klyne, Dan Kohn, Gabriel Montenegro, Thomas Narten, Erik Nordmark, Vern Paxson, Michael Quinlan, Eric Rosen, Daniel Senie, Henning Schulzrinne, Bill Sommerfeld, and George Tsirtsis.
このドキュメントおよび関連する問題は、IABによって広く議論されてきました。詳細なレビューのためにとクリスマスChiappaにスティーブデアリングに感謝します。有益なコメントやアイデアもロブAusteinと、ジョンBartas、ジム・バウンド、スコット・ブラッドナー、ヴィントン・サーフ、スペンサードーキンスアヌープGhanwani、エリック・グットマン、エリックA.ホール、グラハムKlyne、ダンコーン、ガブリエルモンテネグロ、トーマスNarten氏、エリックから受け取りましたNordmarkと、バーン・パクソン、マイケル・クインラン、エリック・ローゼン、ダニエルSenie、ヘニングSchulzrinneと、ビルゾンマーフェルト、ジョージTsirtsis。
References
リファレンス
[Bellovin] Distributed Firewalls, S. Bellovin, available at http://www.research.att.com/~smb/papers/distfw.pdf or http://www.research.att.com/~smb/papers/distfw.ps (work in progress).
[Bellovin氏】分散型ファイアウォール、http://www.research.att.com/~smb/papers/distfw.pdf又はhttp://www.research.att.com/~smb/papers/で入手可能S. Bellovin氏、 distfw.ps（作業中）。
[Berners-Lee] Weaving the Web, T. Berners-Lee, M. Fischetti, HarperCollins, 1999, p 208.
ウェブを編む[バーナーズ - リー]、T.バーナーズ - リー、M. Fischetti、ハーパーコリンズ、1999、P 208。
[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.
システム設計、J.H.で[Saltzer]エンドツーエンドの引数Saltzer、D.P.Reed、D.D.Clark、ACM TOCS、第2巻、ナンバー4、1984年11月、頁277-288。
[IEN 48] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
[IEN 48]サーフ、V.、 "インターネットワーキングのためのCATENETモデル、" 情報処理テクニックオフィス、米国防総省の国防高等研究計画庁、IEN 48、1978年7月。
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks," Proceedings of EUROCOMP, Brunel University, May 1974, pp. 1023-36.
[CATENET]プザン、L.、EUROCOMP、ブルネル大学、1974年5月、頁。1023年から1036年の議事録「を、パケット交換網を相互接続するための提案」。
[STD 7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[STD 7]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC 1546] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC 1546]ウズラ、C.、メンデス、T.およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[RFC 1597] Rekhter, Y., Moskowitz, B., Karrenberg, D. and G. de Groot, "Address Allocation for Private Internets", RFC 1597, March 1994.
[RFC 1597] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.とG.デ・グルート、 "個人的なインターネットのための配分"、RFC 1597、1994年3月。
[RFC 1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC 1633]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC 1889] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[BCP 5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[BCP 5] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、デ・グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC 1928]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC 2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC 2018]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC 2052] Gulbrandsenの、A.及びP.いるVixie、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2052、1996年10月。
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC 2101]大工、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC 2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC 2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC 2309]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RFC 2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC 2326] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC 2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC 2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC 2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC 2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[NAT-ARCH] Hain, T., "Architectural Implications of NAT", Work in Progress.
[NAT-ARCH]ハイン、T.、 "NATの建築含意" が進行中で働いています。
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", Work in Progress.
[NAT-PROT]ホールドレッジ、M.とP. Srisuresh、進行中、作業 "IPネットワークアドレス変換（NAT）とプロトコル合併症"。
[SECMECH] Bellovin, S., "Security Mechanisms for the Internet", Work in Progress.
[SECMECH] Bellovin氏、S.、 "インターネットのセキュリティメカニズム" が進行中で働いています。
[RSIP] Lo, J., Borella, M. and D. Grabelsky, "Realm Specific IP: A Framework", Work in Progress.
[RSIP]ロー、J.、ボレッラ、M.とD. Grabelsky、 "レルム特定IP：フレームワーク"、ProgressのWork。
[HIP] Moskowitz, R., "The Host Identity Payload", Work in Progress.
[HIP]モスコウィッツ、R.、「ホストアイデンティティペイロード」、進行中の作業。
Author's Address
著者のアドレス
Brian E. Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
ブライアンE.カーペンターIBM C / iCAIRスイート150 1890メープルアベニューエバンストン、IL 60201 USA O
EMail: brian@icair.org
メールアドレス：brian@icair.org
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機能のための基金は現在、インターネット協会によって提供されます。