[要約] RFC 2775は、インターネットの透明性に関するガイドラインであり、インターネットの運用と管理における透明性の重要性を強調しています。その目的は、ユーザーとインターネットのプロバイダー間の信頼関係を構築し、ネットワークの運用に関する情報の公開とアクセスを促進することです。
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.
Copyright（c）The Internet Society（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の使用における基本的な変化を認識しなければなりません。1つのシナリオでは、IPv6への完全な移行により、グローバルアドレスの透明性の回復が可能になりますが、写真からファイアウォールやプロキシを削除することはできません。もう1つの極端な場合、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」と略される「End to End」というフレーズは、インターネットの建築的議論で広く使用されています。この論文の目的のために、最初にエンドツーエンドの3つの異なる側面を提示します。
This is an argument first described in [Saltzer] and reviewed in [RFC 1958], from which an extended quotation follows:
これは[Saltzer]で最初に説明され、[RFC 1958]でレビューされた議論であり、そこから拡張された引用が続きます。
"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.
したがって、エンドツーエンドのこの最初の側面は、ネットワークが予想されることを制限し、最終システムが予想されることを明確にします。エンドツーエンドの引数は、このドキュメントの残りの部分の根底にあります。
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.
1974年のプージンによる以前の提案に続いて[ネットワークのネットワーク）が1978年にCERFによって最初に記述されたとき[Catenet]、明確な仮定は、単一の論理アドレス空間がCatenet全体をカバーする（または私たちが知っているようにインターネット）。これは、初期のTCP/IPインターネットだけでなく、Xerox PUPデザイン、OSI Connectionless Network Design、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.
この概念には2つの明確な結果がありました。パケットはネットワーク全体に本質的に変更されず、ソースと宛先のアドレスを最終システムの一意のラベルとして使用できます。
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番目の結果は、ある意味ではカテネットの概念の副作用でした。しかし、それは非常に重要になった副作用でした。アドレスの独自性と耐久性は、特にそれらを輸送識別子に組み込むことにより、多くの点で活用されています。したがって、それらは、輸送チェックサム、暗号化署名、Webドキュメント、および独自のソフトウェアライセンスサーバーに組み込まれています。[RFC 2101]このトピックを詳細に調査します。その主な結論は、IPv4アドレスがグローバルに一意または不変のいずれかであると想定できなくなり、これらのプロパティが予測不可能に失敗すると仮定するプロトコルまたはアプリケーションの設計はないということです。IABおよびNATワーキンググループ[NAT-ARCH]での作業は、非ユニーク性と非不変性、つまりネットワークアドレス翻訳者の1つの特定の原因の影響を分析しました。繰り返しになりますが、アドレスの透明性の仮定を回避するために特に適応されない限り、多くのアプリケーションが失敗するということです。適応の1つの形式は、何らかの形式のアプリケーションレベルゲートウェイを挿入することです。もう1つのフォームは、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を使用してSystem Restartで新しいアドレスを取得するため、ここでアドレスの実際の値は潜在的に一時的であり、セッション間に保存してはなりません。
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などの信頼できないアプリケーションがファイアウォールをパンチできるソックスメカニズム[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）またはプロキシと組み合わせる必要があります。さらに、新しいアドレス依存アプリケーションが登場するたびに、アルグまたはプロキシを更新する必要があります。実際には、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レコードに類似した一般的な迂回メカニズムが有益であるということです。SRVレコード[RFC 2052]はこの方向へのステップです。）
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」または「2つの対面DNS」です。ここでは、企業ネットワークがファイアウォールの内外で部分的または完全に異なる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は、Anycast [RFC 1546]をサポートするように設計されていないため、1つのサーバーがジョブをできない場合、ロードシェアリングへの自然なアプローチはありません。これを解決するためにさまざまなトリックが使用されています（マルチキャストフリーサーバーを見つけるために、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]は、エンドツーエンドアドレスの透明性が深刻な脅威にさらされているという認識の前に構築されました。代替提案が出現し始めていますが、[ヒップ]が現れ始めましたが、現在の現実は、IPSECを一般的なケースにエンドツーエンドを展開できないということです。トンネルモードIPSECは、コーポレートゲートウェイまたはファイアウォールの間に展開できます。トランスポートモードIPSECは、場合によってはコーポレートネットワーク内に展開できますが、イントラネットからインターネットに至ることはできません。
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、スリップ、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.
前のセクションで説明されている発明の多くは、少なくとも1人の他のホストによって直接的または間接的に媒介される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は、ミドルウェア、アプリケーション、および管理システムの適応を含む、すべてのホストとルーターに完全に実装されます。アドレス空間は考えられるすべてのニーズに合わせて十分に大きくなるため、アドレスの透明性を回復できます。適切なセキュリティポリシーツールと主要なインフラストラクチャが与えられると、Transport-Mode 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.) 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.
IPv6の基本的な仮定であることに注意してください。これは、それらの多くがあることを考えると、住所の供給に人為的な制約が置かれないことに注意してください。一部のISPがクライアントあたりのIPv4アドレスの数を強く制限する現在のプラクティスは、IPv6に存在する理由はありません。（ただし、階層的なルーティングを支持するように設計されたガイドラインに従って、アドレスは引き続き慎重に割り当てられます。）明らかに、これはいずれにせよ、非常に長期のシナリオです。なぜなら、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とNAPTの一般化された使用です（ポート番号の翻訳付きNAT）。これには、ホストがトラフィックに使用されているユニークなアドレスが気づいていないという不利な点があり、これが生成するすべての問題を伴うあいまいなプライベートアドレスのみを認識しています。[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 もう1つのサブサブシナリオは、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遷移技術の一部は、景観の永続的な特徴になります。アドレスが32ビット、時には128ビットである場合があります。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を使用せずにさまざまなシナリオはすべて乱雑であり、最終的には何らかの種類の行き止まりにつながるようです。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）では、特に[Bellovin]で提唱されている「分散ファイアウォール」モデルを使用して、エンドツーエンドのIPSECが可能になります。
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によって広範囲に議論されています。詳細なレビューとノエル・チアッパに感謝します。有用なコメントやアイデアは、ロブ・オーストイン、ジョン・バルタス、ジム・バウダス、スコット・ブラッドナー、ヴィント・ケルフ、スペンサー・ドーキンス、アヌープ・ガンワニ、エリック・グットマン、エリック・A・ホール、グラハム・クリーン、ダン・コーン、ガブリエル・モンテネグロ、トーマス・ナルテン、Nordmark、Vern Paxson、Michael Quinlan、Eric Rosen、Daniel Senie、Henning Schulzrinne、Bill Sommerfeld、George 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]分散ファイアウォール、S。Bellovin、http：//www.research.att.com/~smb/papers/distfw.pdfまたはhttp://www.research.att.com/~smb/papers/Distfw.ps（進行中の作業）。
[Berners-Lee] Weaving the Web, T. Berners-Lee, M. Fischetti, HarperCollins, 1999, p 208.
[Berners-Lee] Web、T。Berners-Lee、M。Fischetti、Harpercollins、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.
[Saltzer]システム設計におけるエンドツーエンドの引数、J.H。Saltzer、D.P.Reed、D.D.Clark、ACM TOCS、Vol 2、Number 4、1984年11月、pp 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] Cerf、V。、「インターネットワーキングのためのCatenetモデル」、情報処理手法、Defense Advanced Research Projects Agency、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] Pouzin、L。、「パケットスイッチングネットワークを相互接続する提案」、Eurocompの議事録、1974年5月、1023-36ページ。
[STD 7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[STD 7] Postel、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] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、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.、Moskowitz、B.、Karrenberg、D。and G. de Groot、「Private Internetsのアドレス割り当て」、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] Braden、R.、Clark、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.、Frederick、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.、Moskowitz、B.、Karrenberg、D.、de Groot、G。and E. Lear、「Private Internetsのアドレス配分」、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] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。and L. Jones、「Socks Protocolバージョン5」、RFC 1928、1996年3月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958] Carpenter、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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Auncoundective Options」、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] Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC 2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[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] 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、「インターネットでのキュー管理と混雑回避に関する推奨事項」、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.、Rao、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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC 2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC 2581] Allman、M.、Paxson、V。and W. Stevens、「TCP渋滞制御」、RFC 2581、1999年4月。
[NAT-ARCH] Hain, T., "Architectural Implications of NAT", Work in Progress.
[Nat-arch] Hain、T。、「Natの建築的意味」、進行中の作業。
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", Work in Progress.
[Nat-Prot] Holdrege、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] Lo、J.、Borella、M。、およびD. Grabelsky、「レルム固有のIP：フレームワーク」、進行中の作業。
[HIP] Moskowitz, R., "The Host Identity Payload", Work in Progress.
[HIP] Moskowitz、R。、「ホストIDペイロード」、進行中の作業。
Author's Address
著者の連絡先
Brian E. Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
ブライアンE.カーペンターIBM C/O ICAIR SUITE 150 1890 MAPLE AVENUE EVANSTON、IL 60201 USA
EMail: brian@icair.org
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エディター機能の資金は現在、インターネット協会によって提供されています。