RFC3724 日本語訳

Network Working Group                                      J. Kempf, Ed.
Request for Comments: 3724                               R. Austein, Ed.
Category: Informational                                              IAB
                                                              March 2004

ワーキンググループのJ.ケンフ、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド3724R.Austein、カテゴリ: 2004年の情報のIAB行進

          The Rise of the Middle and the Future of End-to-End:
       Reflections on the Evolution of the Internet Architecture

中央の上昇と終わらせる終わりの未来: インターネット構造の発展のReflections

Status of this Memo

この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.

Copyright(C)インターネット協会(2004)。 All rights reserved。

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 終わりから終わりへの原則に関する小史。 . . . . . . . . . 2 3. 終わりから終わりへの原則. . . . . . . . . . 5 4に反対された傾向。 終わりから終わりへの原則. . . . . . . . . . . . . . . 8 5? アリーナとしての闘争のインターネット規格。 . . . . . . . . . 10 6. 結論。 . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. 承認. . . . . . . . . . . . . . . . . . . . . . . 11 8。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 9. 有益な参照. . . . . . . . . . . . . . . . . . . . 12 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 13 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 14

Kempf & Austein              Informational                      [Page 1]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[1ページ]情報のRFC3724未来

1.  Introduction

1. 序論

   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、リード、およびクラーク[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.

本書では、私たちは終わりから終わりへの原則の解釈が数年間どのように発展しているか、そして、それが現在どこに立つかを調べます。 私たちはインターネットの発展におけるネットワーク(RFC3238[5]のIABからいくらかの量の配慮を既に受けた話題)でサービスを定義する圧力につながった傾向を調べます。 私たちは終わりから終わりへの原則がこれらの傾向の観点からどう発展するかもしれないかに関するいくつかの問題について説明します。

2.  A Brief History of the End-to-End Principle

2. 終わりから終わりへの原則に関する小史

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

そのような機能の特定の例は配送保証[1]です。 パケットを届けたときはいつも、オリジナルのアルパネットは「次のメッセージに関する要求」をメッセージに返しました。 このメッセージは輻輳制御のフォームとしてネットワークの中で役に立つのがわかりましたが、アルパネットが、前の承認を返すまで別のメッセージを同じ目的地に受け入れるのを拒否したので、それは保証された配送のしるしとして特に決して役に立ちませんでした。 送付ホストの上のホストスタックがまさしくそれを通常知りたがっていないという問題がありました。ネットワークはパケットを届けましたが、むしろ送付ホストの上のスタック層は、受信ホストの上のスタック層が適切にパケットを処理したのを知りたがっています。 近代的なIPスタック構造に関して、信頼できるトランスポート層は輸送処理が首尾よく終了した指示を必要とします、与えるように

Kempf & Austein              Informational                      [Page 2]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[2ページ]情報のRFC3724未来

   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.

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]:

インターネットが展開したとき、終わりから終わりへの原則は徐々にアプリケーションに関連している状態をインターネットに置くために最も良いところに関する心配に広くなりました: ネットワークかエンドノードにおいて。 最も良い例はRFC1958[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

エンドポイントの知識と支援が不可欠であり、そのような知識と支援なしでそのような知識を省略して、ネットワークで機能を実行するのが可能でないという終わりから終わりへの原則のオリジナルの歯切れ--工学共同体を浸み通らせるにはしばらくかかって、この時点で、ネットワークには何があるか、そして、何がないかに関して広い建築声明に発展しました。 RFC1958はエンドノードで全体のネットワークスタックを意味するのに「アプリケーション」という用語を使用します、ネットワーク、輸送、および応用層を含んでいて、通信系自体に関してあるとしての終わりから終わりへの原則の以前の歯切れと対照して。 「運命共有」は全く明確にこれについて説明します: 2つのアプリケーションでの会話の運命がそうである、唯一

Kempf & Austein              Informational                      [Page 3]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[3ページ]情報のRFC3724未来

   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.

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保証、それがどこでヘッダー圧縮に使用されるかというセッション情報、データ圧縮のための圧縮歴史、および同様のもの。 この状態は自己を治療であるに違いありません。 ネットワークのトポロジーか活動が変化するとき、適応型の手順かプロトコルが、その状態を引き出して、維持するために存在していて、それを変えなければなりません。 この状態のボリュームを最小にしなければなりません、そして、接続性が存在しているなら、状態の損失はサービスの1以上一時的な否定をもたらしてはいけません。 手動で構成された状態を絶対最小値まで維持しなければなりません。[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.

概要では、避けられない状態がどう扱われるべきであるか原則自体とその含意の一般的な認識が時間がたつにつれてaになるようになった、(そうでなければ、)、インターネット構造の基礎原理。

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

終わりから終わりへの原則が、インターネットコミュニティでどう技術的な討論に影響を及ぼすか続けるのに関するおもしろい例はIPの移動性です。 既存のインターネット・ルーティング構造は厳しくIPの移動性がどう密接に、根本的変化を作らないで終わりから終わりへの原則に合うことができるかを抑制します。 モバイルモバイルIPv6仕様でジョンソン、パーキンス、およびArkko[7]によって説明されたIPv6は、可動のノードのルーティングロケータと、アドレスの注意と、可動のノードのノード識別子(ホームアドレス)の間のマッピングを維持するために可動のノードのホームネットワーク(ホームのエージェント)でルーティングプロキシを必要とします。 しかし、地方のサブネットがプロキシ(Foreignエージェント)を発送して、どれが、より古いモバイルIPv4の特徴であったかは[8] それを設計します。

Kempf & Austein              Informational                      [Page 4]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[4ページ]情報のRFC3724未来

   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は可動端のノードと通信員ノードの間で終わりから終わりへのルーティングを許すためにルーティングを最適化するための安全なメカニズムを含んでいます、家のエージェントのグローバルなルーティングプロキシを通して発送する必要性を取り除いて。 これらの特徴は、問題を終わらせるために続けてすべて基づいています。 しかしながら、インターネットの最適路線識別子が構造、IABワークショップで議論して、RFC2956[9]で報告された話題、およびそれを発送していてホームのエージェントというモバイルIPv6のグローバルなルーティングプロキシがグローバルなノード識別子のエイリアシングで断固としているので、必要性は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年前に正式にされて以来、ワイヤードなリンク、ルーティング、およびスイッチ装置の基本的な信頼性はかなり向上していますが、無線のリンクの信頼性か非信頼性が媒体の基本的な物理学と瞬時に起こっているラジオ伝播状態によって、より強く管理されます。

3.  Trends Opposed to the End-to-End Principle

3. 終わりから終わりへの原則に反対された傾向

   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

終わりから終わりへの原則は、多くのIETFデザインワークに堅実な基礎を提供し続けていますが、終わりから終わりへのRFC1958で説明された原則の特定のアプリケーションはますます様々な指示から問題になりました。 IABは傾向しばらく終わりから終わりへの原則に反対する例えば、RFC2956[9]とRFC2775[12]に関して心配していました。 これらのドキュメントで重要な焦点はインターネットのNATsと他のアドレス変換メカニズムの導入にもかかわらず、いっぱいにかかわる様々な部分的なシナリオの終わりから終わりへの原則への結果にもかかわらず、IPv6の展開がないのによる透明の減少です。 より最近、関心の話題はネットワークにおける、サービス展開の結果に移行しました。 ネットワークでサービスを定義する建築願わしさを評価して、RFC3238[5]のオープンPluggable Edge Services(作品)に関するIAB意見がそのようなサービスがどう妥協をもたらすかもしれないかに関する疑問を挙げることを意図します。

Kempf & Austein              Informational                      [Page 5]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[5ページ]情報のRFC3724未来

   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.

プライバシー、セキュリティ、および終わりから終わりへのデータ保全について。 クラーク、また、[10]の他とRFC3234[11]のCarpenterはネットワークとのサービス定義の話題を始めます。

   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年間発展しています。 以下の小区分でこれらの要件に関する例について議論します。 リード[13]とムーアズの論文は2002年のIEEE国際交流コンファレンス[14]で今日のインターネットの終わりから終わりへの原則に対する圧力についての他の議論を議論で見つけることができます。

3.1.  Need for Authentication

3.1. 認証の必要性

   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つのエンドノードを許容するように設計されています。

Kempf & Austein              Informational                      [Page 6]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[6ページ]情報のRFC3724未来

   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インフラストラクチャかキーなどの第三者測定が材料を合わせる交換に利用されるところに終わらせる終わりにおける交通を打つというわけではないとき。 第三者がかかわっても、結局、それは、彼らがどの第三者を信じるかを決定するためには終点と特に彼らのユーザ次第です。

3.2.  New Service Models

3.2. 新しいサービスモデル

   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.

新しいアプリケーションで奮い立たせられた新しいサービスモデルは、渡されたサービスの基本的な部分として相当の行為レベルを達成するのを必要とします。 これらのサービスモデルはオリジナルのベストエフォート型サービスモデルからの著しい変化です。 メール、ファイル転送、およびウェブアクセスさえ性能が下がるなら失敗するとして知覚されません、取引を完了するのが必要であるときに、ユーザはだめにされるようになるかもしれませんが。 サービスには彼らが契約した技量を予想する権利があるので、しかしながら、それが許容できるサービスのユーザー・エクスペリエンスのために何を意味してもリアルタイムの双方向の声とビデオは言うまでもなくストリーミングのオーディオとビデオのために相当の行為レベルを達成するのは、サービス、および顧客契約を提供する一部です。 例えば、満足しているディストリビュータはクライアントから遠くにサーバが位相的に普及であるなら配送の遅れを避ける様々な位置のインターネットの周りの普及である満足している分配サーバで内容を時々発表します。 小売のブロードバンドとマルチメディアサービスは多くのサービスプロバイダーの新しいサービスモデルです。

3.3.  Rise of the Third Party

3.3. 第三者の上昇

   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

特に、メールとシェルアクセスとの標準の小売のダイアルアップ噛み付いているパイプアカウントは商品サービスになりました、小さな利鞘をもたらして。 多くのISPがこのビジネスモデルに満足であり、それで生き残ることができる間、他のものは、より高い利益を潜在的にして、より多いか異なったサービスを顧客に提供する異なったサービスモデルを配備したがっています。 例はストリーミングに結びつけられたケーブルかDSLを通した小売の広帯域の噛み付いているパイプアクセスです。

Kempf & Austein              Informational                      [Page 7]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[7ページ]情報のRFC3724未来

   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が、ストリーミング・メディアの性能を向上させるように満足している流通機構を配備します。 これらのサービスが通常配備されるので、それらは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回のパーティーの間で挿入する機会で過酷になりました。 このかかわり合いに関する優しい動機が信用の不足を緩和することであるので、2つの間の良い振舞いの信用アンカーかエンフォーサが終わっている間、第三者は行動します。 それほど優しくない動機は第三者がそれら自身の理由、恐らく課税または検閲のためのさえ方針を挿入することです。 第三者の要件には、何か技術的な関心をもってしますが、特定の社会的で法的な問題からむしろ派生する少しかものがしばしばあるというわけではありません。

4.  Whither the End-to-End Principle?

4. 終わりから終わりへの原則--

   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.

終わりから終わりへの前項で議論した原則に対する圧力を考えて、質問は終わりから終わりへの原則の未来に関して起こります。 終わりから終わりへの原則はインターネット構造において将来性がありますか? 将来性があるなら、それはどのように適用されるべきですか? 明確に、この質問に答えることへの非生産的なアプローチは妥協を全く許さない根本主義者の原則として終わりから終わりへの原則を言い張ることです。 上で説明された圧力は、本当であって、強力です、そして、現在のインターネット技術団体が、これらの圧力を無視するのを選ぶなら、起こりそうな結果は市場機会がこれらの圧力を無視しませんが、彼らのデザイン選択の含意を理解しないかもしれない新しい技術的な共同体に作成されるということです。 より生産的なアプローチは、今日のインターネットの複雑さを考えて、原則に戻って、終わりから終わりへの原則のどんな終わらせる終わりの原則が私たちの定義を達成して、次に、アップデートしようとしているか、そして、博覧会を再検討することです。

4.1.  Consequences of the End-to-End Principle

4.1. 終わりから終わりへの原則の結果

   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つの第一の望ましい結果を考えます: 革新の保護と信頼性と丈夫さの支給。

Kempf & Austein              Informational                      [Page 8]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[8ページ]情報のRFC3724未来

4.1.1.  Protection of Innovation

4.1.1. 革新の保護

   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つの望ましい結果は革新の保護です。 それでも、新種業務を配備するためにネットワークで変更を必要とするのは、終わりを変更するより通常難しいノードです。 そんなに多くのエンドノードがアップデート可能でなく、ほとんどのユーザがとにかく彼らをアップデートしたがっていない現在本質的には閉じている箱であるという反論はすべてのノードとすべてのユーザに適用されません。 多くのエンドノードはそれでも、構成可能なユーザとユーザのかなり大きい百分率が「初期採用者」であるということです。(」は新しいアイデアを十分に試すためにある量の技術的な深い悲しみを我慢しても構わないと思っています)。 そして、閉じている箱と無関心なユーザのためにさえ、終わりから終わりへの原則を守るダウンローダブルなコードは速いサービス革新を供給できます。 サービスが、彼らのネットワークを変更するように多くのISPか企業ネットワークの管理者を説得するように新しいアイデアでだれかを必要とするのは単に何らかのダウンローダブルなソフトウェアがサービスを実行しているウェブページを提供するよりはるかに難しいです。

4.1.2.  Reliability and Trust

4.1.2. 信頼性と信用

   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

この信用故障への即座の反応は既存のプロトコルへのセキュリティが合い返そうとしたことです。 この努力が必要ですが、それは十分ではありません。 終わりから終わりへの原則が今日ときに、信用の問題は未来のプロトコルデザインにおける同じくらい堅い建築原則にならなければなりません。 信用は単にそれが設計された後に何らかの暗号の保護をプロトコルに追加する問題ではありません。 むしろ、プロトコルを設計する前にプロトコルに伴われるネットワーク要素の間の信用関係を定義しなければなりません、そして、信用関係を共有するそれらのネットワーク要素の間に境界を描かなければなりません。 信用境界は、どんなタイプに関するコミュニケーションがプロトコルに伴われるネットワーク要素の間に現れるか、そして、どのネットワーク要素が互いを示すかを決定するのに使用されるべきです。 コミュニケーションが信用境界の向こう側に現れると、ある種の暗号の、または、他の機密保持は現れます。

Kempf & Austein              Informational                      [Page 9]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[9ページ]情報のRFC3724未来

   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攻撃を避けるために受取人で送付者から状態を最小にする必要があるかもしれません。

4.2.  The End-to-End Principle in Applications Design

4.2. アプリケーションデザインにおける終わりから終わりへの原則

   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つの要所は、それらには終わりから終わりへの原則を破る少しの依存もないのを保証して、一貫したファッションでエンドポイントを特定できるのを保証することです。 例えばトランスポート層が適切に仕事するのを不可能にする依存を引き起こして、前者に関する例は層の違反です。 別の問題は、より多くのアプリケーションインフラストラクチャをネットワークに挿入する願望です。 RFC3238[5]でこの問題の周りの建築問題について議論します。 ネットワークに提供されたサービスが終点の形式知とかかわり合いで作動するように機能する仕切りをするなら、この願望は終わりから終わりへの原則の違反をもたらす必要はありません、そのような知識とかかわり合いがサービスの適切な機能に必要であるときに。 結果は分配されたアプリケーションになります。そこでは、終わりから終わりへの原則がアプリケーションを実行するのにかかわる各接続に適用されます。

5.  Internet Standards as an Arena for Conflict

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はinterdomain QoSサービスを配備するのに気が重いです。 しかしながら、何人かのエンドユーザが異なったドメインの声のサポートとエンドノードの間のビデオマルチメディア応用を改良するために利用可能な終わりから終わり、DiffservまたはIntserv-スタイルQoSが欲しいです、ヒューストンがRFC2990[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

これらの闘争は必然的に進んでいるインターネット構造に反映されるでしょう。 これらの闘争のいくつかが、技術水準を決心するのが不可能であり、望ましくしさえしないでしょう、IETFが作るのは権限を与えられない社会的で法的な選択にかかわるので(プライバシーの領域でのカウンタ議論に関して、見てください。

Kempf & Austein              Informational                     [Page 10]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[10ページ]情報のRFC3724未来

   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]). しかし、ユーザ選択と権限委譲の重要な特性と、終わりから終わりに対するサービス、信用を支持して、および「良いネットワーク市民の振舞い」の信頼性と保全と、サービスで革新を伸ばすのは、解決がされる技術選択にかかわるそれらの闘争の基礎であるべきです。 そして、闘争は結果として起こる構造のフィールドで展開するでしょう。

6.  Conclusions

6. 結論

   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番目の特定のオーダーの特性は同じくらい重要であるか、または、よりそうであるとして認識されるようになっています、原則自体より。 エンドユーザ選択、権限委譲、サービスの保全、信用のサポート、および「良いネットワーク市民の振舞い」はすべて終わりから終わりへの原則の結果として展開した特性です。 サービスをネットワークに組み入れる圧力が増えるのに従って、インターネットへの変更のための特定の提案でこれらの特性を認識するのは以前より重要になりました。 サービスをネットワークに取り入れるというどんな提案も進行の前にこれらの特性に比較考量されるべきです。

7.  Acknowledgements

7. 承認

   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の仕事を選び抜きたがっています。デーブ・クラークは、終わりから終わりへの原則のオリジナルの咬合器であり、インターネット構造の発展を奮い立たせて、誘導し続けています。(乱闘とインターネットにかかわる問題をはっきりさせるのをこの紙の開発の間の会話とWroclawskiを助けました)。

Kempf & Austein              Informational                     [Page 11]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[11ページ]情報のRFC3724未来

8.  Security Considerations

8. セキュリティ問題

   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.

このドキュメントは、どんな新しいプロトコルも提案しないで、またしたがって、その意味で、どんなセキュリティ問題にもかかわりません。 しかしながら、このドキュメント中にそれらの問題によって作成されたプライバシー、保全問題、および建築要件の議論があります。

9.  Informative References

9. 有益な参照

   [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、Vol2、Number4、1984年11月(pp277-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 SIGCOMM88、ACM CCR Vol18、Number4、1988年8月、ページ 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] ブルーメンソル、M.、クラーク、D.D.、「インターネットのデザインを再考します:」 「終わりから終わりへの議論対素晴らしい新世界」、インターネットTechnologyの上のACM Transactions、Vol.1、No.1、2001年8月(pp70-109)。

   [4]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

[4] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。

   [6]  Carpenter, B., Ed., "Architectural Principles of the Internet",
        RFC 1958, June 1996.

[6] 大工、B.、エド、「インターネットの建築プリンシプルズ」、RFC1958、6月1996日

   [7]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", Work in Progress.

[7] ジョンソンとD.とパーキンスとC.とJ.Arkko、「IPv6"での移動性サポート、進行中の仕事。」

   [8]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
        August 2002.

[8] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」

   [9]  Kaat, M., "Overview of 1999 IAB Network Layer Workshop," RFC
        2956, October 2000.

[9]Kaat、M.、「1999IABネットワーク層ワークショップの概観」、RFC2956、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] クラークとD.D.とWroclawskiとJ.とSollins、K.とブレーデン、B.、「サイバースペースでは、乱闘してください」 「明日のインターネットを定義します」、Sigcomm2002の議事。

   [11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
        RFC 3234, February, 2002.

[11] 大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月、2002

Kempf & Austein              Informational                     [Page 12]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[12ページ]情報のRFC3724未来

   [12] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.

[12] 大工、B.、「インターネット透明」、RFC2775、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?セクションは2000年4月に紙とfn=endofendtoend.htmlと等しいです。

   [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。 Communications、ページの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メッセージ仕様」、RFC2633、6月1999日

   [16] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990,
        November 2000.

[16] ヒューストン、G.、「IP QoS構造のための次のステップ」、RFC2990、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.

IEEE COMPCON97の[17] ゴールドバーグとI.とワグナー、D.とBrewer、E.、「インターネットへのプライバシーを高める技術」Proceedings、ページ 103-109, 1997.

10. Author Information

10. 作者情報

   Internet Architecture Board
   EMail:  iab@iab.org

インターネット・アーキテクチャ委員会メール: iab@iab.org

   IAB Membership at time this document was completed:

このドキュメントが完成した時のIAB Membership:

      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 Sallyフロイド6月-ichiro Itojun Haginoマークハンドレージェフヒューストンチャーリー・カウフマンジェームスケンフエリックレスコラマイク通りジョーンズ

Kempf & Austein              Informational                     [Page 13]

RFC 3724                  Future of End-to-End                March 2004

終わりから終わりへの行進2004年のケンフとAustein[13ページ]情報のRFC3724未来

11.  Full Copyright Statement

11. 完全な著作権宣言文

   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.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Kempf & Austein              Informational                     [Page 14]

ケンフとAustein情報です。[14ページ]