[要約] 要約：RFC 3724は、インターネットアーキテクチャの進化に関する考察であり、中間層の台頭とエンドツーエンドの未来に焦点を当てています。目的：このRFCの目的は、インターネットの進化に関する洞察を提供し、中間層の役割とエンドツーエンドの原則の重要性を強調することです。
Network Working Group J. Kempf, Ed.
Request for Comments: 3724 R. Austein, Ed.
Category: Informational IAB
March 2004
The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture
エンドツーエンドの中央と未来の台頭：インターネットアーキテクチャの進化に関する反省
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 (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends.
エンドツーエンドの原則は、インターネットのコアアーキテクチャガイドラインです。このドキュメントでは、長年にわたってインターネットアーキテクチャに適用されてきたエンドツーエンドの原則の開発を簡単に調べます。インターネットアーキテクチャの進化における現在の傾向について、エンドツーエンドの原則に関連して、エンドツーエンドの原則の進化について、したがってそれがサポートするインターネットアーキテクチャについて、いくつかの結論を導き出そうとします。これらの現在の傾向に照らして。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. A Brief History of the End-to-End Principle. . . . . . . . . . 2
3. Trends Opposed to the End-to-End Principle . . . . . . . . . . 5
4. Whither the End-to-End Principle?. . . . . . . . . . . . . . . 8
5. Internet Standards as an Arena for Conflict. . . . . . . . . . 10
6. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . . 12
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
One of the key architectural guidelines of the Internet is the end-to-end principle in the papers by Saltzer, Reed, and Clark [1][2]. The end-to-end principle was originally articulated as a question of where best not to put functions in a communication system. Yet, in the ensuing years, it has evolved to address concerns of maintaining openness, increasing reliability and robustness, and preserving the properties of user choice and ease of new service development as discussed by Blumenthal and Clark in [3]; concerns that were not part of the original articulation of the end-to-end principle.
インターネットの重要なアーキテクチャガイドラインの1つは、Saltzer、Reed、およびClark [1] [2]による論文のエンドツーエンドの原則です。エンドツーエンドの原則は、コミュニケーションシステムに関数を配置しないのが最善の問題の問題として、もともと明確に表現されていました。しかし、その後の数年間で、開放性を維持し、信頼性と堅牢性を高め、ユーザーの選択の特性と新しいサービス開発の容易さを維持するという懸念に対処するために進化しました[3]。エンドツーエンドの原則の元の明確化の一部ではなかった懸念。
In this document, we examine how the interpretation of the end-to-end principle has evolved over the years, and where it stands currently. We examine trends in the development of the Internet that have led to pressure to define services in the network, a topic that has already received some amount of attention from the IAB in RFC 3238 [5]. We describe some considerations about how the end-to-end principle might evolve in light of these trends.
このドキュメントでは、エンドツーエンドの原則の解釈が長年にわたってどのように進化してきたか、そして現在の場所を調べます。ネットワーク内のサービスを定義する圧力につながったインターネットの開発の傾向を調べます。これは、RFC 3238のIABからすでにある程度の注目を集めているトピックです[5]。これらの傾向に照らしてエンドツーエンドの原則がどのように進化するかについてのいくつかの考慮事項について説明します。
2.1. In the Beginning...
2.1. 最初は...
The end-to-end principle was originally articulated as a question of where best to put functions in a communication system:
エンドツーエンドの原則は、元々、コミュニケーションシステムの機能をどこに配置するのに最適なのかという問題として明確にされていました。
The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points 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.) [1].
問題の関数は、通信システムの最後のポイントに立つアプリケーションの知識と支援によってのみ、完全かつ正確に実装できます。したがって、その質問された機能を通信システム自体の特徴として提供することは不可能です。（通信システムによって提供される関数の不完全なバージョンが、パフォーマンスの向上として役立つ場合があります。）[1]。
A specific example of such a function is delivery guarantees [1]. The original ARPANET returned a message "Request for Next Message" whenever it delivered a packet. Although this message was found to be useful within the network as a form of congestion control, since the ARPANET refused to accept another message to the same destination until the previous acknowledgment was returned, it was never particularly useful as an indication of guaranteed delivery. The problem was that the host stack on the sending host typically doesn't want to know just that the network delivered a packet, but rather the stack layer on the sending host wants to know that the stack layer on the receiving host properly processed the packet. In terms of modern IP stack structure, a reliable transport layer requires an indication that transport processing has successfully completed, such as given by TCP's ACK message [4], and not simply an indication from the IP layer that the packet arrived. Similarly, an application layer protocol may require an application-specific acknowledgement that contains, among other things, a status code indicating the disposition of the request.
このような関数の具体的な例は、送達保証です[1]。元のArpanetは、パケットを配信するたびに「次のメッセージのリクエスト」というメッセージを返しました。このメッセージは、ネットワーク内で混雑制御の形として有用であることがわかりましたが、ARPANETは以前の承認が返されるまで同じ目的地への別のメッセージを受け入れることを拒否したため、保証された配達の兆候として特に有用ではありませんでした。問題は、送信ホストのホストスタックが通常、ネットワークがパケットを配信したことを知りたくないということでしたが、むしろ送信ホストのスタックレイヤーが受信ホストのスタックレイヤーがパケットを適切に処理したことを知りたいということでした。。最新のIPスタック構造の観点から、信頼性の高い輸送層は、TCPのACKメッセージ[4]で与えられるなど、輸送処理が正常に完了したことを示す必要があります。同様に、アプリケーションレイヤープロトコルには、リクエストの処分を示すステータスコードを含むアプリケーション固有の承認が必要になる場合があります。
The specific examples given in [1] and other references at the time [2] primarily involve transmission of data packets: data integrity, delivery guarantees, duplicate message suppression, per packet encryption, and transaction management. From the viewpoint of today's Internet architecture, we would view most of these as transport layer functions (data integrity, delivery guarantees, duplicate message suppression, and perhaps transaction management), others as network layer functions with support at other layers where necessary (for example, packet encryption), and not application layer functions.
[1]およびその他のリファレンスに記載されている特定の例[2]には、主にデータパケットの送信が含まれます：データの整合性、配信保証、複製メッセージ抑制、パケット暗号化ごとの複製、およびトランザクション管理。今日のインターネットアーキテクチャの観点から、これらのほとんどを輸送層関数（データの整合性、配信保証、複製メッセージ抑制、およびおそらくトランザクション管理）と見なします。、パケット暗号化）、アプリケーション層機能ではありません。
2.2. ...In the Middle...
2.2. ...真ん中に...
As the Internet developed, the end-to-end principle gradually widened to concerns about where best to put the state associated with applications in the Internet: in the network or at end nodes. The best example is the description in RFC 1958 [6]:
インターネットが発展するにつれて、エンドツーエンドの原則は、インターネットに関連する状態をネットワークまたはエンドノードのアプリケーションに関連する最善の場所に関する懸念に徐々に拡大しました。最良の例は、RFC 1958 [6]の説明です。
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.
この原則は、部分的なネットワークの障害に耐えるためにアプリケーションを要求する場合、重要な結果をもたらします。エンドツーエンドのプロトコル設計は、ネットワーク内の状態のメンテナンス（つまり、エンドツーエンド通信の状態に関する情報）に依存してはなりません。そのような状態は、エンドポイント自体が壊れたときにのみ状態を破壊できるように、エンドポイントでのみ維持されるべきです（運命共有として知られています）。これの直接的な結果は、データグラムが古典的な仮想回路よりも優れていることです。ネットワークの仕事は、データグラムを可能な限り効率的かつ柔軟に送信することです。他のすべてはフリンジで行う必要があります。
The original articulation of the end-to-end principle - that knowledge and assistance of the end point is essential and that omitting such knowledge and implementing a function in the network without such knowledge and assistance is not possible - took a while to percolate through the engineering community, and had evolved by this point to a broad architectural statement about what belongs in the network and what doesn't. RFC 1958 uses the term "application" to mean the entire network stack on the end node, including network, transport, and application layers, in contrast to the earlier articulation of the end-to-end principle as being about the communication system itself. "Fate-sharing" describes this quite clearly: the fate of a conversation between two applications is only shared between the two applications; the fate does not depend on anything in the network, except for the network's ability to get packets from one application to the other.
エンドツーエンドの原則の元の明確化 - エンドポイントの知識と支援が不可欠であり、そのような知識を省略し、そのような知識や支援なしでネットワークに機能を実装することは不可能です - エンジニアリングコミュニティ、そしてこの時点で、ネットワークに属するものとそうでないものについての幅広い建築声明に進化しました。RFC 1958は、「アプリケーション」という用語を使用して、通信システム自体に関するエンドツーエンドの原則の以前の明確化とは対照的に、ネットワーク、トランスポート、アプリケーション層を含むエンドノードのネットワークスタック全体を意味します。「Fate-Sharing」はこれを非常に明確に説明しています。2つのアプリケーション間の会話の運命は、2つのアプリケーション間でのみ共有されます。運命は、ネットワークがあるアプリケーションから別のアプリケーションにパケットを取得する能力を除いて、ネットワーク内のものに依存しません。
The end-to-end principle in this formulation is specifically about what kind of state is maintained where:
この定式化のエンドツーエンドの原則は、特にどのような状態が維持されるかについてです。
To perform its services, the network maintains some state information: routes, QoS guarantees that it makes, session information where that is used in header compression, compression histories for data compression, and the like. This state must be self-healing; adaptive procedures or protocols must exist to derive and maintain that state, and change it when the topology or activity of the network changes. The volume of this state must be minimized, and the loss of the state must not result in more than a temporary denial of service given that connectivity exists. Manually configured state must be kept to an absolute minimum.[6]
ネットワークは、サービスを実行するために、いくつかの状態情報を維持します。ルート、QoSは、ヘッダー圧縮で使用されるセッション情報、データ圧縮のための圧縮履歴などを保証します。この状態は自己癒しでなければなりません。適応手順またはプロトコルは、その状態を導き出し、維持し、ネットワークのトポロジまたはアクティビティが変更されたときにそれを変更するために存在する必要があります。この状態の量は最小限に抑える必要があり、州の損失は、接続性が存在することを考えると、一時的なサービスの拒否以上のものをもたらさないでください。手動で構成された状態は、絶対的な最小値まで保持する必要があります。[6]
In this formulation of the end-to-end principle, state involved in getting packets from one end of the network to the other is maintained in the network. The state is "soft state," in the sense that it can be quickly dropped and reconstructed (or even required to be periodically renewed) as the network topology changes due to routers and switches going on and off line. "Hard state", state upon which the proper functioning of the application depends, is only maintained in the end nodes. This formulation of the principle is a definite change from the original formulation of the principle, about end node participation being required for proper implementation of most functions.
エンドツーエンドの原則のこの定式化では、ネットワークの一方の端からもう一方の端にパケットを取得することに関与する状態がネットワークで維持されます。状態は「ソフト状態」であり、ルーターとスイッチがオンとオフラインのためにネットワークトポロジが変化するにつれて、すぐにドロップして再構築する（または定期的に更新する必要がある）という意味でです。アプリケーションの適切な機能が依存する状態「ハードステート」は、最終ノードでのみ維持されます。この原則の定式化は、ほとんどの機能の適切な実装に必要なエンドノード参加についての原則の元の定式化からの明確な変更です。
In summary, the general awareness both of the principle itself and of its implications for how unavoidable state should be handled grew over time to become a (if not the) foundation principle of the Internet architecture.
要約すると、原則自体の一般的な認識と、避けられない状態がどのように処理されるべきかに対するその意味の両方が、インターネットアーキテクチャの基礎原則になるために時間とともに成長しました。
2.3. ...And Now.
2.3. ...そしていま。
An interesting example of how the end-to-end principle continues to influence the technical debate in the Internet community is IP mobility. The existing Internet routing architecture severely constrains how closely IP mobility can match the end-to-end principle without making fundamental changes. Mobile IPv6, described in the Mobile IPv6 specification by Johnson, Perkins, and Arkko [7], requires a routing proxy in the mobile node's home network (the Home Agent) for maintaining the mapping between the mobile node's routing locator, the care of address, and the mobile node's node identifier, the home address. But the local subnet routing proxy (the Foreign Agent), which was a feature of the older Mobile IPv4 design [8] that compromised end-to-end routing, has been eliminated. The end node now handles its own care of address. In addition, Mobile IPv6 includes secure mechanisms for optimizing routing to allow end-to-end routing between the mobile end node and the correspondent node, removing the need to route through the global routing proxy at the home agent. These features are all based on end to end considerations. However, the need for the global routing proxy in the Home Agent in Mobile IPv6 is determined by the aliasing of the global node identifier with the routing identifier in the Internet routing architecture, a topic that was discussed in an IAB workshop and reported in RFC 2956 [9], and that hasn't changed in IPv6.
インターネットコミュニティの技術的な議論にどのようにエンドツーエンドの原則が影響を与え続けているかの興味深い例は、IPモビリティです。既存のインターネットルーティングアーキテクチャは、基本的な変更を加えることなく、IPモビリティがエンドツーエンドの原則にどの程度密接に一致するかを厳しく制約します。Johnson、Perkins、およびArkko [7]によるモバイルIPv6仕様で説明されているモバイルIPv6は、モバイルノードのルーティングロケーター間のマッピングを維持するために、モバイルノードのホームネットワーク（ホームエージェント）のルーティングプロキシを必要とします。、およびモバイルノードのノード識別子、ホームアドレス。しかし、エンドツーエンドのルーティングを損なう古いモバイルIPv4設計[8]の特徴であるローカルサブネットルーティングプロキシ（外国人エージェント）が排除されました。エンドノードは、独自のアドレスのケアを処理するようになりました。さらに、モバイルIPv6には、ルーティングを最適化してモバイルエンドノードと特派員ノード間のエンドツーエンドのルーティングを可能にするための安全なメカニズムが含まれており、ホームエージェントのグローバルルーティングプロキシを介してルーティングする必要性を削除します。これらの機能はすべて、エンドツーエンドの考慮事項に基づいています。ただし、モバイルIPv6のホームエージェントのグローバルルーティングプロキシの必要性は、インターネットルーティングアーキテクチャのルーティング識別子とグローバルノード識別子のエイリアシングによって決定されます。これは、IABワークショップで議論され、RFC 2956で報告されたトピックです。[9]、それはIPv6では変化していません。
Despite this constraint, the vision emerging out of the IETF working groups developing standards for mobile networking is of a largely autonomous mobile node with multiple wireless link options, among which the mobile node picks and chooses. The end node is therefore responsible for maintaining the integrity of the communication, as the end-to-end principle implies. This kind of innovative application of the end-to-end principle derives from the same basic considerations of reliability and robustness (wireless link integrity, changes in connectivity and service availability with movement, etc.) that motivated the original development of the end-to-end principle. While the basic reliability of wired links, routing, and switching equipment has improved considerably since the end-to-end principle was formalized 15 years ago, the reliability or unreliability of wireless links is governed more strongly by the basic physics of the medium and the instantaneous radio propagation conditions.
この制約にもかかわらず、モバイルネットワーキングの標準を開発するIETFワーキンググループから生まれるビジョンは、複数のワイヤレスリンクオプションを備えた自律的なモバイルノードであり、その中でモバイルノードが選択して選択します。したがって、エンドツーエンドの原則が示唆するように、エンドノードは通信の完全性を維持する責任があります。エンドツーエンドの原則のこの種の革新的なアプリケーションは、エンドツーの元の開発を動機づけた信頼性と堅牢性（ワイヤレスリンクの整合性、動きとのサービスの可用性の変化など）の同じ基本的な考慮事項に由来します。 - エンドの原則。有線リンク、ルーティング、およびスイッチング機器の基本的な信頼性は、15年前にエンドツーエンドの原則が正式になって以来かなり改善されましたが、ワイヤレスリンクの信頼性または信頼性は、媒体と媒体の基本物理学によってより強く支配されています。瞬間的な無線伝播条件。
While the end-to-end principle continues to provide a solid foundation for much IETF design work, the specific application of the end-to-end principle described in RFC 1958 has increasingly come into question from various directions. The IAB has been concerned about trends opposing the end-to-end principle for some time, for example RFC 2956 [9] and RFC 2775 [12]. The primary focus of concern in these documents is the reduction in transparency due to the introduction of NATs and other address translation mechanisms in the Internet, and the consequences to the end-to-end principle of various scenarios involving full, partial, or no deployment of IPv6. More recently, the topic of concern has shifted to the consequences of service deployment in the network. The IAB opinion on Open Pluggable Edge Services (OPES) in RFC 3238 [5] is intended to assess the architectural desirability of defining services in the network and to raise questions about how such services might result in compromises of privacy, security, and end-to-end data integrity. Clark, et al. in [10] and Carpenter in RFC 3234 [11] also take up the topic of service definition in the network.
エンドツーエンドの原則は、多くのIETF設計作業の強固な基盤を提供し続けていますが、RFC 1958で説明されているエンドツーエンドの原則の特定の適用は、さまざまな方向からますます疑問視されています。IABは、たとえばRFC 2956 [9]およびRFC 2775 [12]など、エンドツーエンドの原則に反対する傾向を懸念しています。これらのドキュメントの懸念の主な焦点は、NATやインターネットへのその他のアドレス翻訳メカニズムの導入による透明性の低下と、完全、部分的、または展開なしを含むさまざまなシナリオのエンドツーエンドの原則への結果です。IPv6の。最近では、懸念のトピックは、ネットワーク内のサービス展開の結果にシフトしています。RFC 3238 [5]のOpen Pluggable Edge Services（OPES）に関するIABの意見は、ネットワーク内のサービスを定義するアーキテクチャの望ましさを評価し、そのようなサービスがプライバシー、セキュリティ、および終了の妥協をどのようにもたらすかについての質問を提起することを目的としています。データの整合性。クラーク他[10]およびRFC 3234 [11]の大工[11]も、ネットワーク内のサービス定義のトピックを取り上げています。
Perhaps the best review of the forces militating against the end-to-end principle is by Blumenthal and Clark in [3]. The authors make the point that the Internet originally developed among a community of like-minded technical professionals who trusted each other, and was administered by academic and government institutions who enforced a policy of no commercial use. The major stakeholders in the Internet are quite different today. As a consequence, new requirements have evolved over the last decade. Examples of these requirements are discussed in the following subsections. Other discussions about pressures on the end-to-end principle in today's Internet can be found in the discussion by Reed [13] and Moors' paper in the 2002 IEEE International Communications Conference [14].
おそらく、エンドツーエンドの原則に反対する軍隊の最良のレビューは、[3]のブルーメンタールとクラークによるものです。著者は、インターネットがもともと互いに信頼している志を同じくする技術専門家のコミュニティの間で開発し、商業的使用の政策を施行した学術および政府機関によって管理されたと主張しています。インターネットの主要な利害関係者は今日かなり異なります。結果として、過去10年間で新しい要件が進化しました。これらの要件の例については、以下のサブセクションで説明します。今日のインターネットにおけるエンドツーエンドの原則に関するプレッシャーに関する他の議論は、2002年のIEEE International Communications Conference [14]のReed [13]とMoorsの論文による議論に記載されています。
Perhaps the single most important change from the Internet of 15 years ago is the lack of trust between users. Because the end users in the Internet of 15 years ago were few, and were largely dedicated to using the Internet as a tool for academic research and communicating research results (explicit commercial use of the Internet was forbidden when it was run by the US government), trust between end users (and thus authentication of end nodes that they use) and between network operators and their users was simply not an issue in general. Today, the motivations of some individuals using the Internet are not always entirely ethical, and, even if they are, the assumption that end nodes will always co-operate to achieve some mutually beneficial action, as implied by the end-to-end principle, is not always accurate. In addition, the growth in users who are either not technologically sophisticated enough or simply uninterested in maintaining their own security has required network operators to become more proactive in deploying measures to prevent naive or uninterested users from inadvertently or intentionally generating security problems.
おそらく、15年前のインターネットからの最も重要な変化は、ユーザー間の信頼の欠如です。15年前のインターネットのエンドユーザーは少数であり、学術研究と研究結果の伝達のツールとしてインターネットを使用することに主に専念していたため（インターネットの明示的な商業利用は、米国政府によって運営されたときに禁止されていました）、エンドユーザー間（したがって、使用するエンドノードの認証）とネットワークオペレーターとそのユーザー間の信頼は、一般的に単に問題ではありませんでした。今日、インターネットを使用している一部の個人の動機は常に完全に倫理的ではありません。たとえそうであっても、エンドツーエンドの原則によって暗示されるように、エンドノードが常に相互に有益なアクションを達成するために協力するという仮定は常に協力します、常に正確ではありません。さらに、技術的に十分に洗練されていないユーザーの成長または単に独自のセキュリティを維持することに興味がないため、ネットワークオペレーターは、素朴なまたは関心のないユーザーが不注意または意図的にセキュリティ問題を発生させることを防ぐための措置をより積極的にする必要がありました。
While the end-to-end principle does not require that users implicitly trust each other, the lack of trust in the Internet today requires that application and system designers make a choice about how to handle authentication, whereas that choice was rarely apparent 15 years ago. One of the most common examples of network elements interposing between end hosts are those dedicated to security: firewalls, VPN tunnel endpoints, certificate servers, etc. These intermediaries are designed to protect the network from unimpeded attack or to allow two end nodes whose users may have no inherent reason to trust each other to achieve some level of authentication.
エンドツーエンドの原則は、ユーザーが互いに暗黙的に信頼することを必要としませんが、今日のインターネットへの信頼の欠如は、アプリケーションとシステムの設計者が認証を処理する方法について選択することを要求しますが、その選択は15年前にはめったに明らかではありませんでした。エンドホスト間のネットワーク要素の最も一般的な例の1つは、セキュリティに専念している例です。ファイアウォール、VPNトンネルエンドポイント、証明書サーバーなど。これらの仲介者は、ネットワークを妨げられていない攻撃から保護するか、ユーザーがユーザーが可能な2つのエンドノードを許可するように設計されています。ある程度の認証を達成するためにお互いを信頼する固有の理由はありません。
At the same time, these measures act as impediments for end-to-end communications. Third party trust intermediaries are not a requirement for security, as end-to-end security mechanisms, such as S/MIME [15], can be used instead, and where third party measures such as PKI infrastructure or keys in DNS are utilized to exchange keying material, they don't necessarily impinge on end-to-end traffic after authentication has been achieved. Even if third parties are involved, ultimately it is up to the endpoints and their users in particular, to determine which third parties they trust.
同時に、これらの尺度は、エンドツーエンド通信の障害として機能します。S/MIME [15]などのエンドツーエンドのセキュリティメカニズムを使用することができ、DNSのPKIインフラストラクチャやキーなどのサードパーティの測定値を使用できるため、サードパーティの信託仲介業者はセキュリティの要件ではありません。キーイング素材を交換すると、認証が達成された後、必ずしもエンドツーエンドトラフィックに衝突するわけではありません。第三者が関与していても、最終的には、どの第三者が信頼するかを決定するのは、エンドポイント、特にユーザー次第です。
New service models inspired by new applications require achieving the proper performance level as a fundamental part of the delivered service. These service models are a significant change from the original best effort service model. Email, file transfer, and even Web access aren't perceived as failing if performance degrades, though the user may become frustrated at the time required to complete the transaction. However, for streaming audio and video, to say nothing of real time bidirectional voice and video, achieving the proper performance level, whatever that might mean for an acceptable user experience of the service, is part of delivering the service, and a customer contracting for the service has a right to expect the level of performance for which they have contracted. For example, content distributors sometimes release content via content distribution servers that are spread around the Internet at various locations to avoid delays in delivery if the server is topologically far away from the client. Retail broadband and multimedia services are a new service model for many service providers.
新しいアプリケーションに触発された新しいサービスモデルは、配信されたサービスの基本的な部分として適切なパフォーマンスレベルを達成する必要があります。これらのサービスモデルは、元のBest Effect Service Modelからの大幅な変更です。電子メール、ファイルの転送、さらには、パフォーマンスが低下した場合、ユーザーはトランザクションの完了に必要な時点でイライラする可能性がある場合は、パフォーマンスが低下した場合に失敗していると認識されません。ただし、オーディオとビデオのストリーミングでは、リアルタイムの双方向の音声とビデオは言うまでもなく、サービスの許容可能なユーザーエクスペリエンスにとって意味のあるものが何であれ、適切なパフォーマンスレベルを達成することは、サービスを提供することの一部であり、顧客は契約しています。このサービスには、契約したパフォーマンスのレベルを期待する権利があります。たとえば、コンテンツディストリビューターは、サーバーがクライアントからトポロジカルに遠く離れている場合、配信の遅延を回避するために、さまざまな場所のインターネット上に広がるコンテンツ配布サーバーを介してコンテンツをリリースする場合があります。小売ブロードバンドおよびマルチメディアサービスは、多くのサービスプロバイダーにとって新しいサービスモデルです。
Academic and government institutions ran the Internet of 15 years ago. These institutions did not expect to make a profit from their investment in networking technology. In contrast, the network operator with which most Internet users deal today is the commercial ISP. Commercial ISPs run their networks as a business, and their investors rightly expect the business to turn a profit. This change in business model has led to a certain amount of pressure on ISPs to increase business prospects by deploying new services.
学術および政府機関は、15年前のインターネットを運営していました。これらの機関は、ネットワーキングテクノロジーへの投資から利益を上げることを期待していませんでした。対照的に、今日のほとんどのインターネットユーザーが対処するネットワークオペレーターは、商用ISPです。商業ISPはビジネスとしてネットワークを運営しており、投資家はビジネスが利益を上げることを正しく期待しています。このビジネスモデルの変更により、ISPには新しいサービスを展開することでビジネスの見通しを増やすようにISPにある程度の圧力がかかりました。
In particular, the standard retail dialup bit pipe account with email and shell access has become a commodity service, resulting in low profit margins. While many ISPs are happy with this business model and are able to survive on it, others would like to deploy different service models that have a higher profit potential and provide the customer with more or different services. An example is retail broadband bit pipe access via cable or DSL coupled with streaming multimedia. Some ISPs that offer broadband access also deploy content distribution networks to increase the performance of streaming media. These services are typically deployed so that they are only accessible within the ISP's network, and as a result, they do not contribute to open, end-to-end service. From an ISP's standpoint, however, offering such service is an incentive for customers to buy the ISP's service.
特に、電子メールとシェルアクセスを備えた標準小売ダイヤルアップビットパイプアカウントが商品サービスになり、利益率が低くなります。多くのISPはこのビジネスモデルに満足しており、その上で生き残ることができますが、他の人はより高い利益の可能性を秘めたさまざまなサービスモデルを展開し、顧客により多くまたは異なるサービスを提供したいと考えています。例としては、ケーブルを介した小売ブロードバンドビットパイプアクセスまたはストリーミングマルチメディアと組み合わせたDSLです。ブロードバンドアクセスを提供する一部のISPは、コンテンツ配信ネットワークを展開して、ストリーミングメディアのパフォーマンスを向上させます。これらのサービスは通常、ISPのネットワーク内でのみアクセスできるように展開され、その結果、オープンのエンドツーエンドサービスに貢献しません。ただし、ISPの観点からは、そのようなサービスを提供することは、顧客がISPのサービスを購入するインセンティブです。
ISPs are not the only third party intermediary that has appeared within the last 10 years. Unlike the previous involvement of corporations and governments in running the Internet, corporate network administrators and governmental officials have become increasingly demanding of opportunities to interpose between two parties in an end-to-end conversation. A benign motivation for this involvement is to mitigate the lack of trust, so the third party acts as a trust anchor or enforcer of good behavior between the two ends. A less benign motivation is for the third parties to insert policy for their own reasons, perhaps taxation or even censorship. The requirements of third parties often have little or nothing to do with technical concerns, but rather derive from particular social and legal considerations.
ISPは、過去10年以内に登場したサードパーティの唯一の仲介者ではありません。インターネットの運営における企業や政府の以前の関与とは異なり、企業のネットワーク管理者と政府職員は、エンドツーエンドの会話で2つの当事者間を介入する機会をますます要求しています。この関与の良心的な動機は、信頼の欠如を軽減することです。そのため、サードパーティは、両端の間の良好な行動の信頼アンカーまたは執行者として機能します。あまり良くない動機は、第三者が独自の理由、おそらく課税や検閲さえもポリシーを挿入することです。第三者の要件は、多くの場合、技術的な懸念とはほとんどまたはまったく関係がありませんが、特定の社会的および法的考慮事項に由来しています。
Given the pressures on the end-to-end principle discussed in the previous section, a question arises about the future of the end-to-end principle. Does the end-to-end principle have a future in the Internet architecture or not? If it does have a future, how should it be applied? Clearly, an unproductive approach to answering this question is to insist upon the end-to-end principle as a fundamentalist principle that allows no compromise. The pressures described above are real and powerful, and if the current Internet technical community chooses to ignore these pressures, the likely result is that a market opportunity will be created for a new technical community that does not ignore these pressures but which may not understand the implications of their design choices. A more productive approach is to return to first principles and re-examine what the end-to-end principle is trying to accomplish, and then update our definition and exposition of the end-to-end principle given the complexities of the Internet today.
前のセクションで説明したエンドツーエンドの原則に対する圧力を考えると、エンドツーエンドの原則の将来について疑問が生じます。エンドツーエンドの原則には、インターネットアーキテクチャの未来がありますか？将来がある場合、どのように適用する必要がありますか？明らかに、この質問に答えるための非生産的なアプローチは、妥協を許さない原理主義の原則としてエンドツーエンドの原則を主張することです。上記のプレッシャーは現実的で強力であり、現在のインターネット技術コミュニティがこれらのプレッシャーを無視することを選択した場合、これらのプレッシャーを無視しないが、理解できない新しいテクニカルコミュニティの市場機会が作成される可能性があります。デザインの選択の意味。より生産的なアプローチは、第一原則に戻り、エンドツーエンドの原則が達成しようとしていることを再検討し、今日のインターネットの複雑さを考慮して、エンドツーエンドの原則の定義と説明を更新することです。
In this section, we consider the two primary desirable consequences of the end-to-end principle: protection of innovation and provision of reliability and robustness.
このセクションでは、エンドツーエンドの原則の2つの主要な望ましい結果を検討します。革新の保護と信頼性と堅牢性の提供です。
One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes. The counterargument - that many end nodes are now essentially closed boxes which are not updatable and that most users don't want to update them anyway - does not apply to all nodes and all users. Many end nodes are still user configurable and a sizable percentage of users are "early adopters," who are willing to put up with a certain amount of technological grief in order to try out a new idea. And, even for the closed boxes and uninvolved users, downloadable code that abides by the end-to-end principle can provide fast service innovation. Requiring someone with a new idea for a service to convince a bunch of ISPs or corporate network administrators to modify their networks is much more difficult than simply putting up a Web page with some downloadable software implementing the service.
エンドツーエンドの原則の望ましい結果の1つは、イノベーションの保護です。新しいサービスを展開するためにネットワークの変更を必要とすることは、通常、エンドノードを変更するよりも依然として困難です。反論 - 多くのエンドノードは、現在、更新できない本質的に閉じたボックスであり、ほとんどのユーザーがとにかく更新したくないということは、すべてのノードとすべてのユーザーには適用されません。多くのエンドノードはまだユーザーの構成可能であり、ユーザーのかなりの割合が「アーリーアダプター」であり、新しいアイデアを試すためにある程度の技術的な悲しみに喜んで我慢しています。また、閉じたボックスや関与していないユーザーであっても、エンドツーエンドの原則を順守するダウンロード可能なコードは、高速サービスの革新を提供できます。サービスの新しいアイデアを持っている人に、多数のISPSまたはコーポレートネットワーク管理者にネットワークを変更するよう説得することは、サービスを実装するいくつかのダウンロード可能なソフトウェアでWebページを作成するよりもはるかに困難です。
Of increasing concern today, however, is the decrease in reliability and robustness that results from deliberate, active attacks on the network infrastructure and end nodes. While the original developers of the Internet were concerned by large-scale system failures, attacks of the subtlety and variety that the Internet experiences today were not a problem during the original development of the Internet. By and large, the end-to-end principle was not addressed to the decrease in reliability resulting from attacks deliberately engineered to take advantage of subtle flaws in software. These attacks are part of the larger issue of the trust breakdown discussed in Section 3.1. Thus, the issue of the trust breakdown can be considered another forcing function on the Internet architecture.
しかし、今日の懸念が高まっているのは、ネットワークインフラストラクチャとエンドノードに対する意図的な積極的な攻撃から生じる信頼性と堅牢性の低下です。インターネットの元の開発者は大規模なシステムの障害に関係していましたが、インターネットの元の開発中に今日のインターネットが経験している繊細さと多様性の攻撃は問題ではありませんでした。概して、エンドツーエンドの原則は、ソフトウェアの微妙な欠陥を利用するように意図的に設計された攻撃に起因する信頼性の低下に対処されませんでした。これらの攻撃は、セクション3.1で議論されている信頼の内訳のより大きな問題の一部です。したがって、信頼の内訳の問題は、インターネットアーキテクチャでの別の強制機能と見なすことができます。
The immediate reaction to this trust breakdown has been to try to back fit security into existing protocols. While this effort is necessary, it is not sufficient. The issue of trust must become as firm an architectural principle in protocol design for the future as the end-to-end principle is today. Trust isn't simply a matter of adding some cryptographic protection to a protocol after it is designed. Rather, prior to designing the protocol, the trust relationships between the network elements involved in the protocol must be defined, and boundaries must be drawn between those network elements that share a trust relationship. The trust boundaries should be used to determine what type of communication occurs between the network elements involved in the protocol and which network elements signal each other. When communication occurs across a trust boundary, cryptographic or other security protection of some sort may be necessary. Additional measures may be necessary to secure the protocol when communicating network elements do not share a trust relationship. For example, a protocol might need to minimize state in the recipient prior to establishing the validity of the credentials from the sender in order to avoid a memory depletion DoS attack.
この信頼の内訳に対する即時の反応は、セキュリティを既存のプロトコルにバックバックしようとすることでした。この努力は必要ですが、十分ではありません。信頼の問題は、エンドツーエンドの原則が今日のように、将来のプロトコル設計における建築原則としてしっかりしている必要があります。信頼は、設計後にプロトコルに暗号化保護を追加するだけの問題ではありません。むしろ、プロトコルを設計する前に、プロトコルに関与するネットワーク要素間の信頼関係を定義する必要があり、信頼関係を共有するネットワーク要素の間に境界を描画する必要があります。信頼の境界を使用して、プロトコルに関係するネットワーク要素とどのネットワーク要素が互いに信号を送信するかを決定するために使用する必要があります。信頼の境界を越えて通信が発生する場合、ある種の暗号化またはその他のセキュリティ保護が必要になる場合があります。ネットワーク要素を通信しても信頼関係を共有しない場合、プロトコルを保護するためには、追加の手段が必要になる場合があります。たとえば、メモリの枯渇DOS攻撃を避けるために、送信者からの資格情報の有効性を確立する前に、プロトコルは受信者の状態を最小限に抑える必要がある場合があります。
The concern expressed by the end-to-end principle is applicable to applications design too. Two key points in designing application protocols are to ensure they don't have any dependencies that would break the end-to-end principle and to ensure that they can identify end points in a consistent fashion. An example of the former is layer violations - creating dependencies that would make it impossible for the transport layer, for example, to do its work appropriately. Another issue is the desire to insert more applications infrastructure into the network. Architectural considerations around this issue are discussed in RFC 3238 [5]. This desire need not result in a violation of the end-to-end principle if the partitioning of functioning is done so that services provided in the network operate with the explicit knowledge and involvement of endpoints, when such knowledge and involvement is necessary for the proper functioning of the service. The result becomes a distributed application, in which the end-to-end principle applies to each connection involved in implementing the application.
エンドツーエンドの原則によって表明される懸念は、アプリケーションの設計にも適用できます。アプリケーションプロトコルを設計する際の2つの重要なポイントは、エンドツーエンドの原則を破壊する依存関係を確保し、一貫した方法でエンドポイントを識別できるようにすることです。前者の例はレイヤー違反です - たとえば、輸送層が適切に作業を行うことを不可能にする依存関係を作成します。別の問題は、より多くのアプリケーションインフラストラクチャをネットワークに挿入したいという願望です。この問題に関する建築上の考慮事項は、RFC 3238で説明されています[5]。この欲求は、ネットワークで提供されるサービスが適切な知識と関与が適切に必要である場合、ネットワークで提供されるサービスが明示的な知識と関与とともに動作するように機能の分割が行われる場合、エンドツーエンドの原則に違反する必要はありません。サービスの機能。結果は分散アプリケーションになります。このアプリケーションでは、アプリケーションの実装に関連する各接続にエンドツーエンドの原則が適用されます。
Internet standards have increasingly become an arena for conflict [10]. ISPs have certain concerns, businesses and government have others, and vendors of networking hardware and software still others. Often, these concerns conflict, and sometimes they conflict with the concerns of the end users. For example, ISPs are reluctant to deploy interdomain QoS services because, among other reasons, every known instance creates a significant and easily exploited DoS/DDoS vulnerability. However, some end users would like to have end-to-end, Diffserv or Intserv-style QoS available to improve support for voice and video multimedia applications between end nodes in different domains, as discussed by Huston in RFC 2990 [16]. In this case, the security, robustness, and reliability concerns of the ISP conflict with the desire of users for a different type of service.
インターネットの基準は、紛争のための分野にますます増えています[10]。ISPには特定の懸念があり、企業や政府には他のものがあり、ネットワーキングハードウェアとソフトウェアのベンダーにはさらに他のものがあります。多くの場合、これらの懸念は対立し、時にはエンドユーザーの懸念と対立します。たとえば、ISPは、他の理由の中でも、すべての既知のインスタンスが重要かつ簡単に搾取されたDOS/DDOSの脆弱性を作成するため、ドメイン間QoSサービスの展開に消極的です。ただし、一部のエンドユーザーは、RFC 2990のHustonが議論したように、異なるドメインのエンドノード間の音声およびビデオマルチメディアアプリケーションのサポートを改善するために、エンドツーエンド、DiffServ、またはIntServスタイルのQOを利用できるようにしたいと考えています[16]。この場合、ISPのセキュリティ、堅牢性、および信頼性の懸念は、異なるタイプのサービスに対するユーザーの欲求と矛盾しています。
These conflicts will inevitably be reflected in the Internet architecture going forward. Some of these conflicts are impossible to resolve on a technical level, and would not even be desirable, because they involve social and legal choices that the IETF is not empowered to make (for a counter argument in the area of privacy, see Goldberg, et al. [17]). But for those conflicts that do involve technical choices, the important properties of user choice and empowerment, reliability and integrity of end-to-end service, supporting trust and "good network citizen behavior," and fostering innovation in services should be the basis upon which resolution is made. The conflict will then play out on the field of the resulting architecture.
これらの紛争は、今後のインターネットアーキテクチャに必然的に反映されます。これらの紛争のいくつかは、技術レベルで解決することは不可能であり、IETFが作成する権限を与えられていない社会的および法的選択を含むため、望ましくありません（プライバシーの分野での反論については、Goldberg、etを参照してくださいal。[17]）。しかし、技術的な選択、ユーザーの選択とエンパワーメントの重要な特性、エンドツーエンドサービスの信頼性と完全性、信頼と「優れたネットワーク市民行動」、およびサービスの革新の促進が含まれるこれらの競合のためには、どの解像度が行われますか。その後、紛争は結果として生じるアーキテクチャの分野で展開されます。
The end-to-end principle continues to guide technical development of Internet standards, and remains as important today for the Internet architecture as in the past. In many cases, unbundling of the end-to-end principle into its consequences leads to a distributed approach in which the end-to-end principle applies to interactions between the individual pieces of the application, while the unbundled consequences, protection of innovation, reliability, and robustness, apply to the entire application. While the end-to-end principle originated as a focused argument about the need for the knowledge and assistance of end nodes to properly implement functions in a communication system, particular second order properties developed by the Internet as a result of the end-to-end principle have come to be recognized as being as important, if not more so, than the principle itself. End user choice and empowerment, integrity of service, support for trust, and "good network citizen behavior" are all properties that have developed as a consequence of the end-to-end principle. Recognizing these properties in a particular proposal for modifications to the Internet has become more important than before as the pressures to incorporate services into the network have increased. Any proposal to incorporate services in the network should be weighed against these properties before proceeding.
エンドツーエンドの原則は、インターネット標準の技術開発を導き続けており、過去と同様にインターネットアーキテクチャにとって今日も重要です。多くの場合、その結果へのエンドツーエンドの原則のバンドリングは、エンドツーエンドの原則がアプリケーションの個々のピース間の相互作用に適用される分散アプローチにつながりますが、バンドルされていない結果、イノベーションの保護、信頼性と堅牢性は、アプリケーション全体に適用されます。エンドツーエンドの原則は、通信システムに機能を適切に実装するためのエンドノードの知識と支援の必要性に関する焦点を絞った議論として生まれましたが、エンドツーの結果としてインターネットが開発した特定の2次プロパティは最終原則は、原則自体よりも重要ではないにしても、重要であると認識されるようになりました。エンドユーザーの選択とエンパワーメント、サービスの整合性、信頼のサポート、および「優れたネットワーク市民行動」はすべて、エンドツーエンドの原則の結果として開発されたプロパティです。インターネットへの変更の特定の提案でこれらのプロパティを認識することは、ネットワークにサービスを組み込むというプレッシャーが増加したため、以前よりも重要になっています。ネットワークにサービスを組み込むという提案は、進行する前にこれらのプロパティに対して比較検討する必要があります。
Many of the ideas presented here originally appeared in the works of Dave Clark, John Wroclawski, Bob Braden, Karen Sollins, Marjory Blumenthal, and Dave Reed on forces currently influencing the evolution of the Internet. The authors would particularly like to single out the work of Dave Clark, who was the original articulator of the end-to-end principle and who continues to inspire and guide the evolution of the Internet architecture, and John Wroclawski, with whom conversations during the development of this paper helped to clarify issues involving tussle and the Internet.
ここで紹介したアイデアの多くは、もともとインターネットの進化に影響を与えている部隊に関するデイブ・クラーク、ジョン・ロクラウスキー、ボブ・ブレイデン、カレン・ソリンズ、マージョリー・ブルーメンタール、デイブ・リードの作品に登場しました。著者は、特に、エンドツーエンドの原則の元のアリチュレータであり、インターネットアーキテクチャの進化を刺激し、導き続けているデイブクラークの作品を選び出したいと思います。このペーパーの開発は、Tussleとインターネットに関連する問題を明らかにするのに役立ちました。
This document does not propose any new protocols, and therefore does not involve any security considerations in that sense. However, throughout this document, there are discussions of the privacy and integrity issues and the architectural requirements created by those issues.
このドキュメントは新しいプロトコルを提案していないため、その意味でのセキュリティ上の考慮事項は含まれません。ただし、この文書を通して、プライバシーと整合性の問題と、これらの問題によって作成されたアーキテクチャの要件についての議論があります。
[1] Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.
[1] Saltzer、J.H.、Reed、D.P。、およびClark、D.D。、「システム設計におけるエンドツーエンドの引数」、ACM TOCS、Vol 2、Number 4、1984年11月、pp 277-288。
[2] Clark, D., "The Design Philosophy of the DARPA Internet Protocols," Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pp. 106-114.
[2] クラーク、D。、「DARPAインターネットプロトコルの設計哲学」、Proc Sigcomm 88、ACM CCR Vol 18、Number 4、August 1988、pp。106-114。
[3] Blumenthal, M., Clark, D.D., "Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world", ACM Transactions on Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109.
[3] Blumenthal、M.、Clark、D.D。、「インターネットの設計を再考する：エンドツーエンドの議論vs. Brave New World」、ACM Transactions on Internet Technology、Vol。1、No。1、2001年8月、pp 70-109。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[5] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[5] Floyd、S。and L. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
[6] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[6] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Work in Progress.
[7] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、進行中の作業。
[8] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[8] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[9] Kaat, M., "Overview of 1999 IAB Network Layer Workshop," RFC 2956, October 2000.
[9] Kaat、M。、「1999年のIABネットワークレイヤーワークショップの概要」、RFC 2956、2000年10月。
[10] Clark, D.D., Wroclawski, J., Sollins, K., and Braden, B., "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of Sigcomm 2002.
[10] Clark、D.D.、Wroclawski、J.、Sollins、K。、およびBraden、B。、「Tussle in Cyberspace：明日のインターネットの定義」、Sigcomm 2002の議事録。
[11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February, 2002.
[11] Carpenter、B。and S. Brim、「Middleboxes：分類法と問題」、RFC 3234、2002年2月。
[12] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[12] カーペンター、B。、「インターネット透明性」、RFC 2775、2000年2月。
[13] Reed, D., "The End of the End-to-End Argument?", http://www.reed.com/dprframeweb/ dprframe.asp?section=paper&fn=endofendtoend.html, April 2000.
[13] リード、D。、「エンドツーエンドの議論の終わり？」、http：//www.reed.com/dprframeweb/ dprframe.asp？section = paper＆fn = endofendtoend.html、2000年4月。
[14] Moors, T., "A Critical Review of End-to-end Arguments in System Design," Proc. 2000 IEEE International Conference on Communications, pp. 1214-1219, April, 2002.
[14] Moors、T。、「システム設計におけるエンドツーエンドの議論の批判的レビュー」、Proc。2000 IEEE国際通信会議、pp。1214-1219、2002年4月。
[15] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[15] Ramsdell、B.、ed。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[16] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[16] Huston、G。、「IP QOSアーキテクチャの次のステップ」、RFC 2990、2000年11月。
[17] Goldberg, I., Wagner, D., and Brewer, E., "Privacy-enhancing technologies for the Internet," Proceedings of IEEE COMPCON 97, pp. 103-109, 1997.
[17] Goldberg、I.、Wagner、D。、およびBrewer、E。、「インターネット向けのプライバシー強化技術」、IEEE Compcon 97、pp。103-109、1997の議事録。
Internet Architecture Board EMail: iab@iab.org
インターネットアーキテクチャボードメールメール：iab@iab.org
IAB Membership at time this document was completed:
IABメンバーシップこのドキュメントが完了した時点：
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
バーナード・アボバ・ハラルド・アルベストランド・ロブ・オーストイン・レスリー・デイグル・パトリック・ファルトストロム・サリー・フロイド・ジュン・チーロ・イトジノ・マーク
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。