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）インターネット協会（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.
インターネットの主要な建築ガイドラインの一つは、[2] [1] Saltzer、リード、クラークの論文では、エンド・ツー・エンド原理です。エンド・ツー・エンド原理はもともと最良の通信システムにおける機能を入れない場所の問題として連接されました。しかし、その後の数年間で、それはブルーメンソールとクラークで説明したように、オープン性を維持し、信頼性と堅牢性を向上し、ユーザーの選択や新サービスの開発の容易性の性質を維持するの懸念に対処するために進化してきた[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]。私たちは、エンド・ツー・エンド原理は、これらの動向を踏まえて進化するかもしれない方法についていくつかの考慮事項について説明します。
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メッセージパケットが到着IP層から[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]は、主に、データパケットの送信を含みます。今日のインターネットアーキテクチャの観点から、我々は、例えば（必要な場合に他の層でのサポートでネットワーク層の機能として、トランスポート層の機能（データの整合性、配信保証、重複メッセージの抑制、そしておそらくトランザクション管理）、他人としてこれらのほとんどを表示します、パケットの暗号化）、およびないアプリケーション層の機能。
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]:
ネットワークまたはエンドノードでインターネットが開発したように、エンド・ツー・エンド原理は徐々に最高のインターネットでのアプリケーションに関連付けられている状態を置く場所についての懸念に拡大しました。最良の例は、[6] RFC 1958での説明です：
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は、通信システム自体に関するものとしてエンド・ツー・エンドの原則の以前の関節とは対照的に、ネットワーク、トランスポート、およびアプリケーション層を含むエンド・ノード上のネットワークスタック全体を意味する用語「アプリケーション」を使用します。 「運命の共有」は、この非常に明確に説明しています。2つのアプリケーション間の会話の運命は2つのだけのアプリケーション間で共有されています。運命は、他の1つのアプリケーションからのパケットを取得するためのネットワークの能力を除いて、ネットワークで何かに依存しません。
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.
要約すると、原則自体のとどのように処理すべきか避けられない状態のためにその意味の両方の一般的な認識は、インターネットアーキテクチャの（ない場合は）基礎原理になるために時間をかけて成長しました。
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
エンド・ツー・エンド原理は、インターネットコミュニティでの技術的な議論に影響を与え続け方法の興味深い例は、IPモビリティです。既存のインターネットルーティングアーキテクチャは厳しくIPモビリティは、根本的な変更を加えることなく、エンド・ツー・エンド原理を一致させることができますどのように密接に制約されます。ジョンソン、パーキンス、およびArkkoによってモバイルIPv6仕様に記載のモバイルIPv6は、[7]、移動ノードのルーティングロケータとの間のマッピングを維持するために、モバイルノードのホームネットワーク（ホームエージェント）におけるルーティングプロキシ、アドレスのケアを必要とします、およびモバイルノードのノード識別子、ホームアドレス。しかし、古いモバイルIPv4のデザインの特徴だったローカルサブネットルーティングプロキシ（外部エージェント）、[8]は
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.
エンドツーエンドルーティング損なわれ、排除されています。エンド・ノードは現在のアドレスの独自のケアを扱います。また、モバイルIPv6ホームエージェントのグローバルルーティングプロキシを介してルーティングする必要性を除去し、モバイルエンドノードとコレスポンデントノードとの間のエンドツーエンドルーティングを可能にするルーティングを最適化するための安全機構を含みます。これらの機能は、すべての考慮事項をエンド・ツー・エンドに基づいています。しかし、モバイルIPv6におけるホームエージェントのグローバルルーティングプロキシの必要性は、インターネットルーティングアーキテクチャにおけるルーティング識別子、RFC 2956でIABワークショップで議論され、報告されたトピックを持つグローバルノード識別子のエイリアシングによって決定されます[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のの。さらに最近では、懸念の話題は、ネットワークにおけるサービス展開の結果にシフトしています。 IAB [5]は、ネットワーク内のサービスを定義する建築望ましさを評価し、そのようなサービスは、プライバシーの妥協につながるかもしれない方法についての質問を提起することを意図しているRFC 3238で開くプラグイン可能なエッジサービス（OPES）に対する意見、セキュリティ、およびエンドエンドツーエンドのデータの整合性。クラークら。 RFC 3234 [11]で、[10]にし、カーペンター、ネットワークにサービス定義の話題を取り上げます。
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国際通信会議[14]でリード[13]とムーアズ紙での議論で見つけることができます。
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年前にはめったに見かけたのに対し、アプリケーションやシステム設計者は、認証を処理する方法についての選択をすることが必要です。これらの媒体は、妨げられずに攻撃からネットワークを保護するために、またはそのユーザ得る2つのエンドノードを可能にするように設計されているファイアウォール、VPNトンネルエンドポイント、証明書サーバ、等：セキュリティに専用のものであるエンドホストとの間に介在するネットワーク要素の最も一般的な例の一つ認証のいくつかのレベルを達成するためにお互いを信頼する固有の理由がありません。
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.
新しいアプリケーションに触発新しいサービスモデルは、提供されるサービスの基本的な部分として、適切な性能レベルを達成することが必要です。これらのサービスモデルは、オリジナルのベストエフォート型サービスモデルからの大きな変化です。メール、ファイル転送、さらにはウェブアクセスは、ユーザーがトランザクションを完了するのに必要な時間で欲求不満になるかもしれませんが、パフォーマンスが低下した場合に失敗として認識されていません。しかし、それはサービスの許容可能なユーザーエクスペリエンスのために意味するかもしれないものは何でも、適切な性能レベルを達成し、リアルタイムの双方向の音声とビデオの何も言わないし、オーディオやビデオをストリーミングするため、サービスの提供の一部であり、ために顧客との契約サービスは、彼らが契約しているため、パフォーマンスのレベルを期待する権利を持っています。例えば、コンテンツ配信業者は時々サーバがトポロジー的に遠く離れたクライアントからの場合は配達の遅れを避けるために、様々な場所でインターネットを中心に広がっているコンテンツ配信サーバを介してコンテンツをリリース。リテールのブロードバンドおよびマルチメディアサービスは、多くのサービスプロバイダーのための新しいサービスモデルです。
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への圧力の一定量につながっています。
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.
技術革新の保護と信頼性と堅牢性の提供：このセクションでは、エンド・ツー・エンド原理の二つの主要な望ましい結果を考慮します。
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.
エンド・ツー・エンド原理の一つの望ましい結果は、技術革新の保護です。新しいサービスを展開するために、ネットワークの変更を要求することは一般的に、まだエンド・ノードを変更するよりも困難です。反論 - 多くのエンド・ノードは、現在、本質的に更新可能ではなく、ほとんどのユーザーは、とにかくそれらを更新したくないというボックスを閉じていることは - すべてのノードとすべてのユーザーには適用されません。多くのエンド・ノードは、まだユーザーが設定され、ユーザーのかなりの割合は、新しいアイデアを試すために、技術悲しみの一定量を我慢して喜んでいる「アーリーアダプター」です。そして、さえクローズボックスと無関係のユーザーのために、エンド・ツー・エンド原理を遵守ダウンロードコードは、迅速なサービスのイノベーションを提供することができます。自社のネットワークを変更するには、ISPや企業のネットワーク管理者の束を説得するためのサービスのための新しいアイデアを持つ人を必要とすることははるかに困難単にサービスを実装するいくつかのダウンロード可能なソフトウェアを使用して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.
エンド・ツー・エンド原理で表現懸念があまりにもアプリケーションの設計に適用することができます。アプリケーションプロトコルを設計する上で二つのキーポイントは、彼らはエンド・ツー・エンドの原則を破ると、彼らは一貫した方法でエンドポイントを識別できることを保証するために、任意の依存関係を持っていないことを確認することです。適切にその仕事をするために、例えば、それが不可能なトランスポート層のためになるだろう依存関係を作成する - 前者の例は、レイヤ違反です。もう一つの問題は、ネットワークへのより多くのアプリケーションインフラストラクチャを挿入したいです。この問題の周りの建築の考察は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は、特定の懸念、企業や政府が他の人を持っていて、ネットワーク・ハードウェアおよびソフトウェアのベンダーは、まだ他の人。多くの場合、これらの懸念は、紛争、そして時には彼らは、エンドユーザーの懸念と競合します。他の理由の中で、すべての知られているインスタンスは重大かつ簡単に悪用のDoS / DDoS攻撃の脆弱性を作成し、ので、例えば、ISPはドメイン間のQoSサービスを展開するには消極的です。 RFC 2990 [16]でヒューストンによって論じたようしかし、いくつかのエンドユーザは、異なるドメイン内のエンドノードの間の音声およびビデオマルチメディアアプリケーションのためのサポートを改善するために利用可能なエンドツーエンド、DiffservのまたはのIntServスタイルQoSを持っていると思います。この場合には、サービスの異なるタイプのユーザーの願望を持つ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
これらの競合は、必然的に今後のインターネットアーキテクチャに反映されます。これらの競合の中には、技術的なレベルで解決することは不可能であり、それらは、IETFが見、プライバシーの領域でカウンタ引数に（作るために権限を与えていないことを社会的、法的な選択肢を伴うためにも、望ましいことではないでしょう
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.
ゴールドバーグら。 [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.
エンド・ツー・エンド原理は、インターネット標準の技術開発を導くために継続し、従来のように、インターネットアーキテクチャのために、今日のような重要なまま。多くの場合、その影響へのエンド・ツー・エンド原理のアンバンドリングはしばらくアンバンドルの結果、技術革新の保護エンド・ツー・エンド原理は、アプリケーションの個々の部分間の相互作用に適用される分散型のアプローチにつながり、信頼性、堅牢性、アプリケーション全体に適用されます。エンド・ツー・エンド原理は適切に通信システムにおける機能を実現するための知識とエンドノードの支援の必要性について集束引数として発信しつつ、特定の二次特性は、エンドツーの結果としてインターネットによって開発されましたエンド原則は原則そのものよりも、より多くのように重要であると認識されるようになり、もししていません。エンドユーザーの選択とエンパワーメント、サービスの完全性、信頼のサポート、および「良いネットワーク市民行動は、」エンド・ツー・エンド原理の結果として開発してきたすべてのプロパティです。ネットワークにサービスを組み込むための圧力が増加しているとして、インターネットへの修正のための特定の提案では、これらの特性を認識することが以前より重要になってきました。ネットワーク内のサービスを組み込むための任意の提案は、先に進む前に、これらの特性比較検討する必要があります。
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.
ここで紹介するアイデアの多くは、もともと現在のインターネットの進化に影響を与える力のデイブ・クラーク、ジョンWroclawski、ボブブレーデン、カレンSollins、マージョリー・ブルーメンソール、およびデイブ・リードの作品に登場しました。著者は、特に中との会話エンド・ツー・エンド原理の元咬合だったとインターネットアーキテクチャの進化を鼓舞し、導くために続けデイブ・クラーク、ジョンWroclawski、の作品を選び出すしたいと思いますこのホワイトペーパーの開発が取っ組み合いやインターネットに関する問題を明確にするために役立ちました。
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.、リード、D.P.、クラーク、D.D.、 "システム設計におけるエンドツーエンドの引数、" ACM TOCS、第2巻、ナンバー4、1984年11月、頁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.、PROCのSIGCOMM 88、ACM CCR第18巻、ナンバー4、1988年8月、頁106-114 "DARPAインターネットプロトコルのデザイン哲学"。
[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]ブルーメンソール、「インターネットのデザイン再考：エンドツーエンドの引数対勇敢な新しい世界」M.、クラーク、D.D.、インターネットテクノロジー、巻上、ACMトランザクション。 1、第1号、2001年8月、頁70から109まで。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4]ポステル、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]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[6] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[6]大工、B.、エド。、 "インターネットの建築原則"、RFC 1958、1996年6月。
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Work in Progress.
[7]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、ProgressのWork。
[8] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[8]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[9] Kaat, M., "Overview of 1999 IAB Network Layer Workshop," RFC 2956, October 2000.
[9] RFC 2956、2000年10月Kaat、M.、 "1999 IABネットワーク層ワークショップの概要"。
[10] Clark, D.D., Wroclawski, J., Sollins, K., and Braden, B., "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of Sigcomm 2002.
[10]クラーク、D.D.、Wroclawski、J.、Sollins、K.、およびブレーデン、B.、 "サイバースペースでの闘争：明日のインターネットの定義"、SIGCOMM 2002の議事。
[11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February, 2002.
[11]大工、B.とS.つば、 "の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？セクション=紙＆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]ムーア、T.、「システム設計におけるエンドツーエンドの引数の批判的検討、」PROC。 2000通信に関するIEEE国際会議、頁。1214年から1219年、2002年4月。
[15] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[15] Ramsdell、B.、エド。、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[16] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[16]ヒューストン、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]ゴールドバーグ、I.、ワグナー、D.、およびブリューワー、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
バーナードAbobaハラルドAlvestrandロブAusteinとレスリーDaigle氏パトリックFaltstromサリーフロイド6月-イチローいとぢゅん萩野マーク・ハンドリージェフ・ヒューストンチャーリー・カウフマンジェームス・ケンプ、エリックレスコラマイク・セントジョンズ
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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。