RFC1287 日本語訳
1287 Towards the Future Internet Architecture. D. Clark, L. Chapin, V.Cerf, R. Braden, R. Hobby. December 1991. (Format: TXT=59812 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Clark
Request for Comments: 1287 MIT
L. Chapin
BBN
V. Cerf
CNRI
R. Braden
ISI
R. Hobby
UC Davis
December 1991
コメントを求めるワーキンググループD.クラークの要求をネットワークでつないでください: 1287 MIT L.チェーピンBBN V.サーフCNRI R.ブレーデンISI R.趣味UCデイヴィス1991年12月
Towards the Future Internet Architecture
将来のインターネットアーキテクチャに向かって
Status of this Memo
このMemoの状態
This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. It is offered to the Internet community for discussion and comment. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
この情報のRFCはインターネットアーキテクチャの可能な今後の発展のために重要な方向について議論して、望んでいる目標に向かってステップを勧めます。 議論とコメントのためにそれをインターネットコミュニティに提供します。 このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. INTRODUCTION ................................................. 2
1. 序論… 2
2. ROUTING AND ADDRESSING ....................................... 5
2. ルーティングとアドレシング… 5
3. MULTI-PROTOCOL ARCHITECTURES ................................. 9
3. マルチプロトコルアーキテクチャ… 9
4. SECURITY ARCHITECTURE ........................................ 13
4. セキュリティアーキテクチャ… 13
5 TRAFFIC CONTROL AND STATE .................................... 16
5 トラフィックコントロールAND状態… 16
6. ADVANCED APPLICATIONS ........................................ 18
6. アプリケーションを進めます… 18
7. REFERENCES ................................................... 21
7. 参照… 21
APPENDIX A. Setting the Stage .................................... 22
舞台装置をセットする付録A.… 22
APPENDIX B. Group Membership ..................................... 28
付録B.グループ会員資格… 28
Security Considerations .......................................... 29
セキュリティ問題… 29
Authors' Addresses ............................................... 29
作者のアドレス… 29
Clark, Chapin, Cerf, Braden, & Hobby [Page 1] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[1ページ]RFC未来
1. INTRODUCTION
1. 序論
1.1 The Internet Architecture
1.1 インターネットアーキテクチャ
The Internet architecture, the grand plan behind the TCP/IP
protocol suite, was developed and tested in the late 1970s by a
small group of network researchers [1-4]. Several important
features were added to the architecture during the early 1980's --
subnetting, autonomous systems, and the domain name system [5,6].
More recently, IP multicasting has been added [7].
インターネットアーキテクチャ(TCP/IPプロトコル群の後ろの大計画)は、ネットワーク研究者[1-4]の小さいグループによって開発されて、1970年代後半にテストされました。 いくつかの重要な特徴が1980年代前半の間、アーキテクチャに追加されました--サブネッティング、自律システム、およびドメイン名システム[5、6]。 より最近、IPマルチキャスティングは加えられます。[7]。
Within this architectural framework, the Internet Engineering Task
Force (IETF) has been working with great energy and effectiveness
to engineer, define, extend, test, and standardize protocols for
the Internet. Three areas of particular importance have been
routing protocols, TCP performance, and network management.
Meanwhile, the Internet infrastructure has continued to grow at an
astonishing rate. Since January 1983 when the ARPANET first
switched from NCP to TCP/IP, the vendors, managers, wizards, and
researchers of the Internet have all been laboring mightily to
survive their success.
この建築フレームワークの中では、インターネット・エンジニアリング・タスク・フォース(IETF)は、インターネットにプロトコルを設計して、定義して、広げて、テストして、標準化するためにかなりのエネルギーと有効性で働いています。 特別に重要な3つの領域が、ルーティング・プロトコルと、TCP性能と、ネットワークマネージメントです。 インターネット基盤は、その間、驚異的な速度で成長し続けていました。 アルパネットが最初にNCPからTCP/IPに切り替わった1983年1月以来、インターネットのベンダー、マネージャ、ウィザード、および研究者は皆、彼らの成功を乗り切るために勢いよく働いています。
A set of the researchers who had defined the Internet architecture
formed the original membership of the Internet Activities Board
(IAB). The IAB evolved from a technical advisory group set up in
1981 by DARPA to become the general technical and policy oversight
body for the Internet. IAB membership has changed over the years
to better represent the changing needs and issues in the Internet
community, and more recently, to reflect the internationalization
of the Internet, but it has retained an institutional concern for
the protocol architecture.
インターネットアーキテクチャを定義した研究者の1セットはインターネットActivities Board(IAB)のオリジナルの会員資格を形成しました。 技術的な顧問団から発展されたIABは、1981年にインターネットへの技術的、そして、方針の一般的な監視団体になるようにDARPAでセットアップします。 IAB会員資格はインターネットコミュニティと、より最近インターネットの国際化を反映するために変化の必要性と問題をよりよく表すために数年間変化していますが、それはプロトコルアーキテクチャに関する制度上の心配を保有しました。
The IAB created the Internet Engineering Task Force (IETF) to
carry out protocol development and engineering for the Internet.
To manage the burgeoning IETF activities, the IETF chair set up
the Internet Engineering Steering Group (IESG) within the IETF.
The IAB and IESG work closely together in ratifying protocol
standards developed within the IETF.
IABは、プロトコル開発と工学をインターネットに行うために、インターネット・エンジニアリング・タスク・フォース(IETF)を創設しました。 芽のIETF活動を管理するために、IETFいすはIETFの中のインターネットEngineering Steering Group(IESG)にセットしました。 IABとIESGはIETFの中で開発されたプロトコル標準を批准する際に緊密に一緒に働いています。
Over the past few years, there have been increasing signs of
strains on the fundamental architecture, mostly stemming from
continued Internet growth. Discussions of these problems
reverberate constantly on many of the major mailing lists.
過去数年間にわたって、緊張の高まる兆候が基本的なアーキテクチャにあります、継続的なインターネットの成長にほとんど由来して。 これらの問題の議論は主要なメーリングリストの多くで絶えず響きわたります。
1.2 Assumptions
1.2 仮定
The priority for solving the problems with the current Internet
architecture depends upon one's view of the future relevance of
アーキテクチャが人の将来の関連性の視点による現在のインターネットに関する問題を解決するための優先権
Clark, Chapin, Cerf, Braden, & Hobby [Page 2] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[2ページ]RFC未来
TCP/IP with respect to the OSI protocol suite. One view has been
that we should just let the TCP/IP suite strangle in its success,
and switch to OSI protocols. However, many of those who have
worked hard and successfully on Internet protocols, products, and
service are anxious to try to solve the new problems within the
existing framework. Furthermore, some believe that OSI protocols
will suffer from versions of many of the same problems.
OSIプロトコル群に関するTCP/IP。 1つの視点はTCP/IPスイートを成功で窒息して、私たちがただOSIプロトコルに切り換えるべきであるということです。 しかしながら、一生懸命、首尾よくインターネットプロトコル、製品、およびサービスに取り組んだ人の多くが既存のフレームワークの中で新しい問題を解決しようとすることを切望しています。 その上、或るものは、OSIプロトコルが同じ問題の多くのバージョンに苦しむと信じています。
To begin to attack these issues, the IAB and the IESG held a one-
day joint discussion of Internet architectural issues in January
1991. The framework for this meeting was set by Dave Clark (see
Appendix A for his slides). The discussion was spirited,
provocative, and at times controversial, with a lot of soul-
searching over questions of relevance and future direction. The
major result was to reach a consensus on the following four basic
assumptions regarding the networking world of the next 5-10 years.
これらの問題、IAB、およびIESGを攻撃し始めるのは1991年1月に1日間のインターネット構造的な問題の共同議論を開催しました。 このミーティングのためのフレームワークはデーブ・クラークによって設定されました(彼のスライドのためにAppendix Aを見てください)。 議論に生気を与えさせました、挑発的で、時には、論議を呼んで多くの精神が関連性の質問の上で探していて将来の方向。 主要な結果は次の5-10年のネットワーク世界に関する以下の4つの基本仮定に関するコンセンサスに達することでした。
(1) The TCP/IP and OSI suites will coexist for a long time.
(1) TCP/IPとOSIスイートは長い間、共存するでしょう。
There are powerful political and market forces as well as
some technical advantages behind the introduction of the OSI
suite. However, the entrenched market position of the TCP/IP
protocols means they are very likely to continue in service
for the foreseeable future.
強力な政治犯と市場の力がOSIスイートの導入の後ろのいくつかの技術的な利点と同様にあります。 しかしながら、TCP/IPプロトコルの強固な市場情勢は、それらが予見できる未来に使用中の状態で非常に継続的でありそうであることを意味します。
(2) The Internet will continue to include diverse networks and
services, and will never be comprised of a single network
technology.
(2) インターネットは、ずっとさまざまのネットワークとサービスを含んで、ただ一つのネットワーク技術から決して成らないでしょう。
Indeed, the range of network technologies and characteristics
that are connected into the Internet will increase over the
next decade.
本当に、インターネットに関連づけられるネットワーク技術と特性の範囲は次の10年間増加するでしょう。
(3) Commercial and private networks will be incorporated, but we
cannot expect the common carriers to provide the entire
service. There will be mix of public and private networks,
common carriers and private lines.
(3) 商業の、そして、私設のネットワークは法人組織になるでしょうが、私たちは、運輸業者が全体のサービスを提供することを期待できません。 公共の、そして、私設のネットワーク、運輸業者、および私設回線のミックスがあるでしょう。
(4) The Internet architecture needs to be able to scale to 10**9
networks.
(4) インターネットアーキテクチャは、10**に9つのネットワークをスケーリングできる必要があります。
The historic exponential growth in the size of the Internet
will presumably saturate some time in the future, but
forecasting when is about as easy as forecasting the future
economy. In any case, responsible engineering requires an
architecture that is CAPABLE of expanding to a worst-case
size. The exponent "9" is rather fuzzy; estimates have
varied from 7 to 10.
インターネットのサイズにおける歴史的な急激な増加が将来、おそらくいくらかの時間を飽和状態にしますが、予測して、いつが先物経済を予測するのとほぼ同じくらい簡単ですか? どのような場合でも、原因となる工学は最悪の場合サイズに拡大するCAPABLEであるアーキテクチャを必要とします。 解説者、「9インチはかなりあいまいです」。 見積りは7〜10に異なりました。
Clark, Chapin, Cerf, Braden, & Hobby [Page 3] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[3ページ]RFC未来
1.3 Beginning a Planning Process
1.3 計画過程を始めること。
Another result of the IAB and IESG meeting was the following list
of the five most important areas for architectural evolution:
IABとIESGミーティングの別の結果は建築発展のための5つの最も重要な領域の以下のリストでした:
(1) Routing and Addressing
(1) ルート設定とアドレシング
This is the most urgent architectural problem, as it is
directly involved in the ability of the Internet to continue
to grow successfully.
これは最も緊急の建築問題です、直接インターネットが首尾よく成長し続ける能力にかかわるとき。
(2) Multi-Protocol Architecture
(2) マルチプロトコルアーキテクチャ
The Internet is moving towards widespread support of both the
TCP/IP and the OSI protocol suites. Supporting both suites
raises difficult technical issues, and a plan -- i.e., an
architecture -- is required to increase the chances of
success. This area was facetiously dubbed "making the
problem harder for the good of mankind."
インターネットはTCP/IPとOSIプロトコル群の両方の広範囲のサポートに近づいています。 両方のスイートを支えると、難しい専門的な問題は提起されます、そして、プラン(すなわち、アーキテクチャ)が、勝算を増強するのに必要です。 この領域はひょうきんに「問題を人類の利益には、より困難にします」と呼ばれました。
Clark had observed that translation gateways (e.g., mail
gateways) are very much a fact of life in Internet operation
but are not part of the architecture or planning. The group
discussed the possibility of building the architecture around
the partial connectivity that such gateways imply.
クラークは、翻訳ゲートウェイ(例えば、メール・ゲートウェイ)がたいへんインターネット操作における現実ですが、アーキテクチャか計画の一部でないことを観測しました。 グループはそのようなゲートウェイが含意する部分的な接続性の周りでアーキテクチャを築き上げる可能性について議論しました。
(3) Security Architecture
(3) セキュリティー体系
Although military security was considered when the Internet
architecture was designed, the modern security issues are
much broader, encompassing commercial requirements as well.
Furthermore, experience has shown that it is difficult to add
security to a protocol suite unless it is built into the
architecture from the beginning.
軍事のセキュリティはインターネットアーキテクチャが設計されたなら考えられて、現代の安全保障問題がはるかに広いです、また、商業要件を取り囲んでことでしたが。 その上、アーキテクチャが始めからそれに組み込まれない場合、経験は、プロトコル群にセキュリティを加えるのが難しいのを示しました。
(4) Traffic Control and State
(4) トラフィックコントロールと状態
The Internet should be extended to support "real-time"
applications like voice and video. This will require new
packet queueing mechanisms in gateways -- "traffic control"
-- and additional gateway state.
インターネットは、声とビデオのような「リアルタイムで」のアプリケーションをサポートするために広げられるべきです。 これは「トラフィックコントロール」というゲートウェイと追加ゲートウェイ状態で新しいパケット待ち行列メカニズムを必要とするでしょう。
(5) Advanced Applications
(5) 高度なアプリケーション
As the underlying Internet communication mechanism matures,
there is an increasing need for innovation and
standardization in building new kinds of applications.
基本的なインターネット通信メカニズムが熟すとき、新しい種類のアプリケーションを組立てるのにおいて革新と標準化の増加する必要があります。
Clark, Chapin, Cerf, Braden, & Hobby [Page 4] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[4ページ]RFC未来
The IAB and IESG met again in June 1991 at SDSC and devoted three
full days to a discussion of these five topics. This meeting,
which was called somewhat perversely the "Architecture Retreat",
was convened with a strong resolve to take initial steps towards
planning evolution of the architecture. Besides the IAB and IESG,
the group of 32 people included the members of the Research
Steering Group (IRSG) and a few special guests. On the second
day, the Retreat broke into groups, one for each of the five
areas. The group membership is listed in Appendix B.
IABとIESGは1991年6月にSDSCで再会して、これらの5つの話題の議論に3丸一日をささげました。 このミーティング。(そのミーティングはいくらか片意地を張って呼ばれて、「アーキテクチャ後退」がアーキテクチャの計画発展に向かって初期段階を取る断固とした決心で召集されたということでした)。 IABとIESG以外に、32人の人のグループはResearch Steering Group(IRSG)と数人の特別ゲストのメンバーを含んでいました。 2日目に、Retreatはそれぞれの5つの領域にグループ、1に侵入しました。 グループ会員資格はAppendix Bに記載されています。
This document was assembled from the reports by the chairs of
these groups. This material was presented at the Atlanta IETF
meeting, and appears in the minutes of that meeting [8].
このドキュメントはこれらのグループの教授の職によるレポートから組み立てられました。 この材料は、アトランタIETFミーティングで寄贈されて、そのミーティング[8]の議事録の間、現れます。
2. ROUTING AND ADDRESSING
2. ルーティングとアドレシング
Changes are required in the addressing and routing structure of IP to deal with the anticipated growth and functional evolution of the Internet. We expect that:
変化はIPのアドレシングとルーティング構造でインターネットの予期された成長と機能進化に対処しなければなりません。 私たちは、以下のことと予想します。
o The Internet will run out of certain classes of IP network
addresses, e.g., B addresses.
o インターネットはIPネットワーク・アドレス、例えばあるクラスのBアドレスを使い果たすでしょう。
o The Internet will run out of the 32-bit IP address space
altogether, as the space is currently subdivided and managed.
o スペースが現在、分筆されて、管理されるとき、インターネットは全体で32ビットのIPアドレス空間を使い果たすでしょう。
o The total number of IP network numbers will grow to the point
where reasonable routing algorithms will not be able to perform
routing based upon network numbers.
o 合理的なルーティング・アルゴリズムがネットワーク・ナンバーに基づくルーティングを実行できないところでIPネットワーク・ナンバーの総数は肝心になるでしょう。
o There will be a need for more than one route from a source to a
destination, to permit variation in TOS and policy conformance.
This need will be driven both by new applications and by diverse
transit services. The source, or an agent acting for the
source, must control the selection of the route options.
o TOSの変化と方針順応を可能にするために、ソースから目的地まで1つ以上のルートの必要があるでしょう。 この必要性は新しいアプリケーションとさまざまのトランジットサービスで追い立てられるでしょう。 ソース、またはソースの代理をするエージェントがルートオプションの品揃えを制御しなければなりません。
2.1 Suggested Approach
2.1 提案されたアプローチ
There is general agreement on the approach needed to deal with
these facts.
これらの事実に対処するのに必要であるアプローチには一般協定があります。
(a) We must move to an addressing scheme in which network numbers
are aggregated into larger units as the basis for routing.
An example of an aggregate is the Autonomous System, or the
Administrative Domain (AD).
(a) 私たちはネットワーク・ナンバーがルーティングの基礎として、より大きい単位に集められるアドレシング体系に移行しなければなりません。 集合に関する例は、Autonomous System、またはAdministrative Domain(AD)です。
Aggregation will accomplish several goals: define regions
where policy is applied, control the number of routing
集合はいくつかの目標を達成するでしょう: 方針が適用されている領域を定義してください、そして、ルーティングの数を制御してください。
Clark, Chapin, Cerf, Braden, & Hobby [Page 5] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[5ページ]RFC未来
elements, and provide elements for network management. Some
believe that it must be possible to further combine
aggregates, as in a nesting of ADs.
要素、要素をネットワークマネージメントに提供してください。 或るものは、ADsの巣篭もりのようにさらに集合を結合するのが可能であるに違いないと信じています。
(b) We must provide some efficient means to compute common
routes, and some general means to compute "special" routes.
(b) 私たちは一般的なルートを計算するいくつかの効率的な手段、および「特別な」ルートを計算するいくつかの一般的な手段を提供しなければなりません。
The general approach to special routes will be some form of
route setup specified by a "source route".
特別なルートへの一般的方法は何らかの形式のルートセットアップに「送信元経路」で指定されたなるでしょう。
There is not full agreement on how ADs may be expected to be
aggregated, or how routing protocols should be organized to deal
with the aggregation boundaries. A very general scheme may be
used [ref. Chiappa], but some prefer a scheme that more restricts
and defines the expected network model.
集合境界に対処するADsが集められるとどのように予想されるかもしれないか、そして、またはルーティング・プロトコルがどのように組織化されているべきであるかに関する全面的な合意がありません。 非常に一般的な体系は使用されるかもしれません。[審判。 Chiappa], しかし、或るものは、以上が制限する体系を好んで、予想されたネットワークモデルを定義します。
To deal with the address space exhaustion, we must either expand
the address space or else reuse the 32 bit field ("32bf") in
different parts of the net. There are several possible address
formats that might make sense, as described in the next section.
アドレス空間疲労困憊に対処するために、私たちは、アドレス空間を広げなければならないか、またはネットの異なった部分の32ビットの分野("32bf")を再利用しなければなりません。 次のセクションで説明されるように理解できるかもしれないいくつかの可能なアドレス形式があります。
Perhaps more important is the question of how to migrate to the
new scheme. All migration plans will require that some routers
(or other components inside the Internet) be able to rewrite
headers to accommodate hosts that handle only the old or format or
only the new format. Unless the need for such format conversion
can be inferred algorithmically, migration by itself will require
some sort of setup of state in the conversion element.
恐らくより重要であるのは、どう新しい体系にわたるかに関する問題です。 すべての移行プランが、いくつかのルータ(または、インターネットの中の他のコンポーネント)が古い形式、形式または新しい形式だけを扱うホストを収容するためにヘッダーを書き直すことができるのを必要とするでしょう。 algorithmicallyにそのようなフォーマット変換の必要性を推論できないと、それ自体で移行は変換要素における、状態のある種のセットアップを必要とするでしょう。
We should not plan a series of "small" changes to the
architecture. We should embark now on a plan that will take us
past the exhaustion of the address space. This is a more long-
range act of planning than the Internet community has undertaken
recently, but the problems of migration will require a long lead
time, and it is hard to see an effective way of dealing with some
of the more immediate problems, such as class B exhaustion, in a
way that does not by itself take a long time. So, once we embark
on a plan of change, it should take us all the way to replacing
the current 32-bit global address space. (This conclusion is
subject to revision if, as is always possible, some very clever
idea surfaces that is quick to deploy and gives us some breathing
room. We do not mean to discourage creative thinking about
short-term actions. We just want to point out that even small
changes take a long time to deploy.)
私たちは構造への一連の「小さい」変化を計画するべきではありません。 私たちは今、アドレス空間の疲労困憊を超えて私たちを連れて行くプランを始めるべきです。 移動の問題は長い先行時間を必要とするでしょう、そして、これは計画するインターネットコミュニティが最近引き受けたより長い範囲条例ですが、より即座の問題のいくつかに対処する効果的な方法を見にくいです、クラスB疲労困憊などのように、それ自体で長くかからない方法で。 それで、私たちがいったん変化のプランを始めると、それは私たちを現在の32ビットのグローバルアドレススペースを取り替えるまでのいっぱいに連れて行くべきです。 (この結論はいつも可能であるように展開するのが迅速であり、いくらかの息づかい部屋を私たちに与えるいくつかの非常に賢明な考えの表面であるなら改正を受けることがあります。 私たちは、短期的な動作に関して創造的思考に水をさしているのを意図しません。 ばら銭さえ展開するには長い時かかるとただ指摘したいと思います。)
Conversion of the address space by itself is not enough. We must
at the same time provide a more scalable routing architecture, and
tools to better manage the Internet. The proposed approach is to
それ自体でアドレス空間の変換は十分ではありません。 私たちは同時に、よりスケーラブルなルーティング構造、およびインターネットをよりよく管理するツールを提供しなければなりません。 アプローチがある提案
Clark, Chapin, Cerf, Braden, & Hobby [Page 6] RFC 1287 Future of Internet Architecture December 1991
インターネット構造1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[6ページ]RFC未来
ADs as the unit of aggregation for routing. We already have
partial means to do this. IDPR does this. The OSI version of BGP
(IDRP) does this. BGP could evolve to do this. The additional
facility needed is a global table that maps network numbers to
ADs.
ルーティングのための集合の単位としてのADs。 私たちには、これをする部分的な手段が既にあります。 IDPRはこれをします。 BGP(IDRP)のOSIバージョンはこれをします。 BGPは、これをするために発展できました。 必要である追加の便宜供与はネットワーク・ナンバーをADsに写像するグローバルなテーブルです。
For several reasons (special routes and address conversion, as
well as accounting and resource allocation), we are moving from a
"stateless" gateway model, where only precomputed routes are
stored in the gateway, to a model where at least some of the
gateways have per-connection state.
いくつかの理由(特別なルート、アドレス変換、会計、および資源配分)で、私たちは「国がない」ゲートウェイモデルから移る予定です、少なくとも数門が1接続あたりの状態を持っているモデルに。(そこでは、前計算されたルートだけがゲートウェイに格納されます)。
2.2 Extended IP Address Formats
2.2 拡張IPアドレス形式
There are three reasonable choices for the extended IP address
format.
拡張IPアドレス形式のための3つの正当な選択があります。
A) Replace the 32 bit field (32bf) with a field of the same size
but with different meaning. Instead of being globally
unique, it would now be unique only within some smaller
region (an AD or an aggregate of ADs). Gateways on the
boundary would rewrite the address as the packet crossed the
boundary.
a) 32ビットの野原(32bf)を同じサイズの分野にもかかわらず、異なった意味に取り替えてください。 グローバルにユニークであることの代わりに、それは現在、何らかのより小さい領域(ADかADsの集合)だけの中でユニークでしょう。 パケットが境界を越えたので、境界のゲートウェイはアドレスを書き直すでしょう。
Issues: (1) addresses in the body of packets must be found
and rewritten; (2) the host software need not be changed; (3)
some method (perhaps a hack to the DNS) must set up the
address mappings.
問題: (1) パケットのボディーのアドレスを見つけられて、書き直さなければなりません。 (2) ホストソフトウェアを変える必要はありません。 (3) 何らかの方法(恐らくDNSへのハッキング)がアドレス・マッピングをセットアップしなければなりません。
This scheme is due to Van Jacobson. See also the work by
Paul Tsuchiya on NAT.
この計画はヴァン・ジェーコブソンのためです。 また、NATのポールTsuchiyaによる仕事を見てください。
B) Expand the 32bf to a 64 bit field (or some other new size),
and use the field to hold a global host address and an AD for
that host.
B) 64ビットの分野(ある他の新しいサイズ)に32bfを広げてください、そして、そのホストにグローバルなホスト・アドレスを保持する分野とADを使用してください。
This choice would provide a trivial mapping from the host to
the value (the AD) that is the basis of routing. Common
routes (those selected on the basis of destination address
without taking into account the source address as well) can
be selected directly from the packet address, as is done
today, without any prior setup.
この選択はホストからルーティングの基礎である値(AD)まで些細なマッピングを提供するでしょう。 直接パケットアドレスから一般的なルート(また、ソースアドレスを考慮に入れることのない送付先アドレスに基づいて選択されたもの)を選択できます、今日するように、少しも先のセットアップなしで。
3) Expand the 32bf to a 64 bit field (or some other new size),
and use the field as a "flat" host identifier. Use
connection setup to provide routers with the mapping from
host id to AD, as needed.
3) 64ビットの分野(ある他の新しいサイズ)に32bfを広げてください、そして、「平坦な」ホスト識別子として分野を使用してください。 必要であるように接続設定を使用して、ホストイドからADまでマッピングをルータに提供してください。
Clark, Chapin, Cerf, Braden, & Hobby [Page 7] RFC 1287 Future of Internet Architecture December 1991
インターネット構造1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[7ページ]RFC未来
The 64 bits can now be used to simplify the problem of
allocating host ids, as in Ethernet addresses.
現在、イーサネット・アドレスのようにイドをホストに割り当てるという問題を簡素化するのに64ビットを使用できます。
Each of these choices would require an address re-writing module
as a part of migration. The second and third require a change to
the IP header, so host software must change.
それぞれのこれらの選択は移動の一部としてモジュールを書き直すアドレスを必要とするでしょう。 2番目と3番目がIPヘッダーへの変化を必要とするので、ホストソフトウェアは変化しなければなりません。
2.3 Proposed Actions
2.3 提案された動作
The following actions are proposed:
以下の動作は提案されます:
A) Time Line
a) タイムライン
Construct a specific set of estimates for the time at which
the various problems above will arise, and construct a
corresponding time-line for development and deployment of a
new addressing/routing architecture. Use this time line as a
basis for evaluating specific proposals for changes. This is
a matter for the IETF.
上の様々な問題が起こる時の特定のセットの見積りを構成してください、そして、新しいアドレシング/ルーティング構造の開発と展開のために対応するタイムラインを構成してください。 変化に明確な提案を評価する基礎としてこのタイムラインを使用してください。 これはIETFのための問題です。
B) New Address Format
B) 新しいアドレス形式
Explore the options for a next generation address format and
develop a plan for migration. Specifically, construct a
prototype gateway that does address mapping. Understand the
complexity of this task, to guide our thinking about
migration options.
次世代アドレス形式のためのオプションを探ってください、そして、移動のために計画を作り上げてください。 明確に、アドレス・マッピングをする原型ゲートウェイを建築してください。 このタスクの複雑さを理解して、私たちが移動オプションについて考えるのを誘導してください。
C) Routing on ADs
C) 広告におけるルート設定
Take steps to make network aggregates (ADs) the basis of
routing. In particular, explore the several options for a
global table that maps network numbers to ADs. This is a
matter for the IETF.
手を打って、網目状の凝集体(ADs)をルーティングの基礎にしてください。 特に、ネットワーク・ナンバーをADsに写像するグローバルなテーブルのためのいくつかのオプションを探ってください。 これはIETFのための問題です。
D) Policy-Based Routing
D) 方針ベースのルート設定
Continue the current work on policy based routing. There are
several specific objectives.
方針に基づいているルーティングへの執筆中の作品を続けてください。 いくつかの明確な目標があります。
- Seek ways to control the complexity of setting policy
(this is a human interface issue, not an algorithm
complexity issue).
- 方針(これはアルゴリズム複雑さ問題ではなく、ヒューマンインターフェース問題である)を設定する複雑さを制御する方法を求めてください。
- Understand better the issues of maintaining connection
state in gateways.
- ゲートウェイで接続が状態であることを支持する問題をより理解してください。
- Understand better the issues of connection state setup.
- 接続州のセットアップの問題をより理解してください。
Clark, Chapin, Cerf, Braden, & Hobby [Page 8] RFC 1287 Future of Internet Architecture December 1991
インターネット構造1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[8ページ]RFC未来
E) Research on Further Aggregation
E) さらなる集合の研究
Explore, as a research activity, how ADs should be aggregated
into still larger routing elements.
研究活動として、ADsがどうそれでも、より大きいルーティング要素に集められるべきであるかを探検してください。
- Consider whether the architecture should define the
"role" of an AD or an aggregate.
- 構造がADか集合の「役割」を定義するべきであるかどうか考えてください。
- Consider whether one universal routing method or
distinct methods should be used inside and outside ADs
and aggregates.
- 1つの普遍的なルーティング方式か異なった方法が集合の中と、そして、ADsと集合の外に使用されるべきであるかどうか考えてください。
Existing projects planned for DARTnet will help resolve several of
these issues: state in gateways, state setup, address mapping,
accounting and so on. Other experiments in the R&D community also
bear on this area.
DARTnetのために計画されていた既存のプロジェクトは、これらのいくつかの問題を解決するのを助けるでしょう: ゲートウェイの状態、州のセットアップはマッピング、会計などを記述します。 また、研究開発共同体での他の実験はこの領域を圧迫します。
3. MULTI-PROTOCOL ARCHITECTURE
3. マルチプロトコル構造
Changing the Internet to support multiple protocol suites leads to three specific architectural questions:
複数のプロトコル群を支えるためにインターネットを変えるのは3つの特定の建築質問に通じます:
o How exactly will we define "the Internet"?
o 私たちはいったいどうやって「インターネット」を定義するつもりですか?
o How would we architect an Internet with n>1 protocol suites,
regardless of what the suites are?
o どのように、私たち、建築家、スイートが何であるかにかかわらずn>1プロトコル群があるインターネットであるだろう?
o Should we architect for partial or filtered connectivity?
o 私たち、部分的であるかフィルターにかけることの接続性のための建築家--であるべきです
o How to add explicit support for application gateways into the
architecture?
o アプリケーションゲートウェイの明白なサポートを構造に追加する方法?
3.1 What is the "Internet"?
3.1 「インターネット」は何ですか?
It is very difficult to deal constructively with the issue of "the
multi-protocol Internet" without first determining what we believe
"the Internet" is (or should be). We distinguish "the Internet",
a set of communicating systems, from "the Internet community", a
set of people and organizations. Most people would accept a loose
definition of the latter as "the set of people who believe
themselves to be part of the Internet community". However, no
such "sociological" definition of the Internet itself is likely to
be useful.
最初に私たちが、信じている「インターネット」が何(または、あるべきである)であるかを決定しない「マルチプロトコルインターネット」の問題に建設的に対処するのは非常に難しいです。 私たちは1セットの「インターネット」、「インターネットコミュニティ」、人々のセットからのシステムを伝えて、および組織を区別します。 ほとんどの人々が「自分たちがインターネットコミュニティの一部であると信じている人々のセット」として後者の厳密さに欠ける定義を認めるでしょう。 しかしながら、インターネット自体のどんなそのような「社会学」の定義も役に立つ傾向がありません。
Not too long ago, the Internet was defined by IP connectivity (IP
and ICMP were - and still are - the only "required" Internet
protocols). If I could PING you, and you could PING me, then we
were both on the Internet, and a satisfying working definition of
昔過ぎるというわけではないのに、インターネットはIPの接続性によって定義されました(スチール写真はそうです--IPとICMPはそうでした、そして、唯一はインターネットプロトコルを「必要でした」)。 私がそうすることができる、PING、あなた、およびあなたがそうすることができた、PING、私、インターネット、および満足のいった仮の定義には私たちがいたその時
Clark, Chapin, Cerf, Braden, & Hobby [Page 9] RFC 1287 Future of Internet Architecture December 1991
インターネット構造1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[9ページ]RFC未来
the Internet could be constructed as a roughly transitive closure
of IP-speaking systems. This model of the Internet was simple,
uniform, and - perhaps most important - testable. The IP-
connectivity model clearly distinguished systems that were "on the
Internet" from those that were not.
そして、IP-話しシステムインターネットのこのモデルのおよそ他動な閉鎖が簡単であったときに、インターネットを構成できました、一定である、--恐らく最も重要--、試験できます。 IP接続性モデルは明確に「インターネット」でそうしないそれらから来ていたシステムを区別しました。
As the Internet has grown and the technology on which it is based
has gained widespread commercial acceptance, the sense of what it
means for a system to be "on the Internet" has changed, to
include:
インターネットが発展して、それが基づいている技術が広範囲の商業承認を獲得するのに従って、システムが「インターネット」にあるそれが何を意味するかに関する感覚は、以下を含むように変化しました。
* Any system that has partial IP connectivity, restricted by
policy filters.
* 方針フィルタによって制限された部分的なIPの接続性を持っているどんなシステム。
* Any system that runs the TCP/IP protocol suite, whether or
not it is actually accessible from other parts of the
Internet.
* それが実際にインターネットの他の地域からアクセスしやすいか否かに関係なく、TCP/IPプロトコル群を動かすどんなシステム。
* Any system that can exchange RFC-822 mail, without the
intervention of mail gateways or the transformation of mail
objects.
* メール・ゲートウェイの介入もメール物の変化なしでRFC-822メールを交換できるどんなシステム。
* Any system with e-mail connectivity to the Internet, whether
or not a mail gateway or mail object transformation is
required.
* インターネットへのメールの接続性があるどんなシステムでありも、変化がメール・ゲートウェイかメール物であることにかかわらず必要です。
These definitions of "the Internet", are still based on the
original concept of connectivity, just "moving up the stack".
まさしく「スタックを上げ」て、「インターネット」のこれらの定義はまだ接続性のオリジナルの概念に基づいたそうです。
We propose instead a new definition of the Internet, based on a
different unifying concept:
私たちは異なった統一概念に基づいて代わりにインターネットの新しい定義を提案します:
* "Old" Internet concept: IP-based.
* 「古い」インターネット概念: IPベースです。
The organizing principle is the IP address, i.e., a common
network address space.
結団原則はIPアドレス、すなわち、一般的なネットワークアドレス空間です。
* "New" Internet concept: Application-based.
* 「新しい」インターネット概念: アプリケーションベースです。
The organizing principle is the domain name system and
directories, i.e., a common - albeit necessarily multiform -
application name space.
結団原則は、ドメイン名システムと必ず多様ですが、ディレクトリ、すなわち、コモンです--アプリケーション名スペース。
This suggests that the idea of "connected status", which has
traditionally been tied to the IP address(via network numbers,
should instead be coupled to the names and related identifying
information contained in the distributed Internet directory.
「関連状態」についてIPアドレスにどれを伝統的に結んであるか。これがそれを示す、考え、(ネットワーク・ナンバーで、代わりに分配されたインターネットディレクトリに含まれた情報を特定しながら、名前と結合されて、関係づけられるべきです。
Clark, Chapin, Cerf, Braden, & Hobby [Page 10] RFC 1287 Future of Internet Architecture December 1991
インターネット構造1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[10ページ]RFC未来
A naming-based definition of "the Internet" implies a much larger
Internet community, and a much more dynamic (and unpredictable)
operational Internet. This argues for an Internet architecture
based on adaptability (to a broad spectrum of possible future
developments) rather than anticipation.
「インターネット」の命名ベースの定義ははるかに大きいインターネットコミュニティ、およびはるかにダイナミックで(予測できない)の操作上のインターネットを含意します。 これは予期よりむしろ適応性(可能な未来の発展の広いスペクトルへの)に基づくインターネット構造について賛成の議論をします。
3.2 A Process-Based Model of the Multiprotocol Internet
3.2 Multiprotocolインターネットの過程ベースのモデル
Rather than specify a particular "multi-protocol Internet",
embracing a pre-determined number of specific protocol
architectures, we propose instead a process-oriented model of the
Internet, which accommodates different protocol architectures
according to the traditional "things that work" principle.
むしろ、私たちは代わりに予定された数の特定のプロトコル構造を受け入れて、特定の「マルチプロトコルインターネット」を指定するよりインターネットの過程指向のモデルを提案します、伝統的な「働いているもの」に従って異なったプロトコル構造に対応するもの。原則。
A process-oriented Internet model includes, as a basic postulate,
the assertion that there is no *steady-state* "multi-protocol
Internet". The most basic forces driving the evolution of the
Internet are pushing it not toward multi-protocol diversity, but
toward the original state of protocol-stack uniformity (although
it is unlikely that it will ever actually get there). We may
represent this tendency of the Internet to evolve towards
homogeneity as the most "thermodynamically stable" state by
describing four components of a new process-based Internet
architecture:
過程指向のインターネットモデルは基本的な公理として*定常状態*「マルチプロトコルインターネット」が全くないという主張を入れます。 インターネットの発展を運転する最も基本的な力がマルチプロトコルの多様性ではなく、プロトコル・スタックの一様性の原状に向かってそれを押しています(実際にそこに到着するのがありそうもないのですが)。 私たちはインターネットが新しい過程ベースのインターネット構造の4つの成分について説明することによって同じくらい最も多くの「熱学的に安定した」状態を同質に向かって発展するこの傾向を表すかもしれません:
Part 1: The core Internet architecture
第1部: コアインターネット構造
This is the traditional TCP/IP-based architecture. It is the
"magnetic center" of Internet evolution, recognizing that (a)
homogeneity is still the best way to deal with diversity in
an internetwork, and (b) IP connectivity is still the best
basic model of the Internet (whether or not the actual state
of IP ubiquity can be achieved in practice in a global
operational Internet).
これは伝統的なTCP/IPベースの建築です。 それがインターネット発展の「磁気センター」である、それでも、(a) それでも、同質がインターネットワーク、および(b)IPの接続性の多様性に対処する最も良い方法であると認めるのは、インターネットの最も良い基本型(グローバルな操作上のインターネットの習慣でIPの偏在の実際の状態を獲得できるか否かに関係なく)です。
"In the beginning", the Internet architecture consisted only of
this first part. The success of the Internet, however, has
carried it beyond its uniform origins; ubiquity and uniformity
have been sacrificed in order to greatly enrich the Internet "gene
pool".
インターネット構造は「初めに、」この最初の部分だけから成りました。 しかしながら、インターネットの成功はそれを一定の起源を超えたところまで運びました。 偏在と一様性は、インターネット「遺伝子プール」を大いに豊かにするために犠牲にされました。
Two additional parts of the new Internet architecture express the
ways in which the scope and extent of the Internet have been
expanded.
新しいインターネット構造の追加2箇所はインターネットの範囲と範囲を広げてある方法を言い表します。
Part 2: Link sharing
第2部: リンク共有
Here physical resources -- transmission media, network
ここ、物理資源--トランスミッションメディア、ネットワーク
Clark, Chapin, Cerf, Braden, & Hobby [Page 11] RFC 1287 Future of Internet Architecture December 1991
インターネット構造1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[11ページ]RFC未来
interfaces, perhaps some low-level (link) protocols -- are
shared by multiple, non-interacting protocol suites. This
part of the architecture recognizes the necessity and
convenience of coexistence, but is not concerned with
interoperability; it has been called "ships in the night" or
"S.I.N.".
インタフェース、恐らくいくつかの低レベルである(リンク)プロトコル--複数の、そして、非相互作用しているプロトコル群で、共有されます。 構造のこの部分は、共存の必要性と便利を認識しますが、相互運用性に関係がありません。 それは「夜の船」か「S.I.N.」と呼ばれました。
Coexisting protocol suites are not, of course, genuinely
isolated in practice; the ships passing in the night raise
issues of management, non-interference, coordination, and
fairness in real Internet systems.
共存プロトコル群はもちろん実際には本当に隔離されません。 夜追い越される船は実際のインターネット・システムの管理、不干渉、コーディネート、および公正の問題を提起します。
Part 3: Application interoperability
パート3: アプリケーション相互運用性
Absent ubiquity of interconnection (i.e., interoperability of
the "underlying stacks"), it is still possible to achieve
ubiquitous application functionality by arranging for the
essential semantics of applications to be conveyed among
disjoint communities of Internet systems. This can be
accomplished by application relays, or by user agents that
present a uniform virtual access method to different
application services by expressing only the shared semantics.
運ばれるアプリケーションの不可欠の意味論を準備することによって遍在しているアプリケーションの機能性を達成するには、インターネット・システムの共同体をばらばらにならせてください。インタコネクト(すなわち、「基本的なスタック」の相互運用性)の欠けている偏在、アプリケーションリレー、または共有された意味論だけを言い表すことによって一定の仮想のアクセス法を異なったアプリケーション・サービスに提示するユーザエージェントがこれを達成できるのは、まだ可能です。
This part of the architecture emphasizes the ultimate role of
the Internet as a basis for communication among applications,
rather than as an end in itself. To the extent that it
enables a population of applications and their users to move
from one underlying protocol suite to another without
unacceptable loss of functionality, it is also a "transition
enabler".
構造のこの部分はアプリケーションの中のコミュニケーションの基礎としてインターネットの究極の役割を強調します、むしろそれ自体への終わりより。 アプリケーションの人口と彼らのユーザが機能性の容認できない損失なしで1つの基本的なプロトコル群から別のプロトコル群まで移るのを可能にするという範囲に、また、それは「変遷イネーブラ」です。
Adding parts 2 and 3 to the original Internet architecture is at
best a mixed blessing. Although they greatly increase the scope
of the Internet and the size of the Internet community, they also
introduce significant problems of complexity, cost, and
management, and they usually represent a loss of functionality
(particularly with respect to part 3). Parts 2 and 3 represent
unavoidable, but essentially undesirable, departures from the
homogeneity represented by part 1. Some functionality is lost,
and additional system complexity and cost is endured, in order to
expand the scope of the Internet. In a perfect world, however,
the Internet would evolve and expand without these penalties.
パート2と3をオリジナルのインターネットアーキテクチャに追加するのは、せいぜいありがたいようなありがたくないようなことです。 インターネットの範囲とインターネットコミュニティのサイズを大いに増強しますが、また、彼らは複雑さ、費用、および管理の重大な問題を紹介します、そして、通常、機能性(特にパート3に関する)の損失を表します。 パート2と3は第1部によって表された同質から避けられない、しかし、本質的には望ましくない出発を表します。 何らかの機能性が無くなります、そして、追加システムの複雑さと費用は耐えられます、インターネットの範囲を広げるために。 理想の世界では、しかしながら、インターネットは、これらの刑罰なしで発展して、広がるでしょう。
There is a tendency, therefore, for the Internet to evolve in
favor of the homogeneous architecture represented by part 1, and
away from the compromised architectures of parts 2 and 3. Part 4
expresses this tendency.
したがって、インターネットがパート2と3の感染しているアーキテクチャから遠くに第1部によって表された同次のアーキテクチャを支持して発展するように、傾向があります。 パート4はこの傾向を言い表します。
Clark, Chapin, Cerf, Braden, & Hobby [Page 12] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[12ページ]RFC未来
Part 4: Hybridization/Integration.
パート4: 交配/統合。
Part 4 recognizes the desirability of integrating similar
elements from different Internet protocol architectures to
form hybrids that reduce the variability and complexity of
the Internet system. It also recognizes the desirability of
leveraging the existing Internet infrastructure to facilitate
the absorption of "new stuff" into the Internet, applying to
"new stuff" the established Internet practice of test,
evaluate, adopt.
パート4はインターネット・システムの可変性と複雑さを減少させるハイブリッドを形成するために異なったインターネットプロトコルアーキテクチャから同様の要素を統合する願わしさを認識します。 また、それは「新しいもの」の吸収をインターネットに容易にするために既存のインターネット基盤を利用する願わしさを認識します、テストの確立したインターネット習慣を「新しいもの」に適用して評価、採用します。
This part expresses the tendency of the Internet, as a
system, to attempt to return to the original "state of grace"
represented by the uniform architecture of part 1. It is a
force acting on the evolution of the Internet, although the
Internet will never actually return to a uniform state at any
point in the future.
この部分は、第1部の一定のアーキテクチャによって表されたオリジナルの「聖寵を受けている状態」に戻るのを試みるためにシステムとしてインターネットの傾向を言い表します。 それはインターネットの発展に作用する力です、インターネットが将来、実際に任意な点の一定の状態に決して戻らないでしょうが。
According to this dynamic process model, running X.400 mail over
RFC 1006 on a TCP/IP stack, integrated IS-IS routing, transport
gateways, and the development of a single common successor to the
IP and CLNP protocols are all examples of "good things". They
represent movement away from the non-uniformity of parts 2 and 3
towards greater homogeneity, under the influence of the "magnetic
field" asserted by part 1, following the hybridization dynamic of
part 4.
このダイナミックなプロセスに従って、モデル化してください、TCP/IPスタックでRFC1006の上にX.400メールを実行して、統合している、-、IPとCLNPプロトコルの独身の一般的な後継者のルーティング、輸送ゲートウェイ、および進化はすべて「良いもの」に関する例です。 彼らはパート2と3の非の一様性から遠くによりすばらしい同質に向かって動きを表します、第1部によって断言された「磁場」の影響を受けて、パート4の交配動力に続いて。
4. SECURITY ARCHITECTURE
4. セキュリティー体系
4.1 Philosophical Guidelines
4.1 哲学的なガイドライン
The principal themes for development of an Internet security
architecture are simplicity, testability, trust, technology and
security perimeter identification.
インターネットセキュリティー体系の開発のための主要なテーマは、簡単さと、試験のしやすさと、信頼と、技術とセキュリティ周辺識別です。
* There is more to security than protocols and cryptographic
methods.
* セキュリティにプロトコルと暗号のメソッド以上があります。
* The security architecture and policies should be simple
enough to be readily understood. Complexity breeds
misunderstanding and poor implementation.
* 理解されていて、セキュリティー体系と方針は容易にである簡単であるべきです。 複雑さは誤解と貧しい実装を飼育します。
* The implementations should be testable to determine if the
policies are met.
* 方針が満たされるかどうか決定するのにおいて実装は試験できるべきです。
* We are forced to trust hardware, software and people to make
any security architecture function. We assume that the
technical instruments of security policy enforcement are at
* 私たちは、ハードウェア、ソフトウェア、および人々がどんなセキュリティー体系機能も作るとやむを得ず信じます。 私たちは、それが実施がある安全保障政策の技術的な器具であると思います。
Clark, Chapin, Cerf, Braden, & Hobby [Page 13] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[13ページ]RFC未来
least as powerful as modern personal computers and work
stations; we do not require less capable components to be
self-protecting (but might apply external remedies such as
link level encryption devices).
現代のパーソナルコンピュータとワークステーションほど最も強力でない。 私たちは、自己に保護している(しかし、リンク・レベル暗号化デバイスなどの外部の療法を適用するかもしれない)ためにそれほどできないコンポーネントを必要としません。
* Finally, it is essential to identify security perimeters at
which protection is to be effective.
* 最終的に、有効である保護がことであるセキュリティ周辺を特定するのは不可欠です。
4.2 Security Perimeters
4.2 セキュリティ周辺
There were four possible security perimeters: link level,
net/subnet level, host level, and process/application level. Each
imposes different requirements, can admit different techniques,
and makes different assumptions about what components of the
system must be trusted to be effective.
4つの可能なセキュリティ周辺がありました: レベル、ネット/サブネットレベル、ホストレベル、およびプロセス/アプリケーションレベルをリンクしてください。 有効であるとシステムのどんな部品を信じなければならないかに関して、それぞれが、異なった要件を課して、異なったテクニックを認めることができて、異なった仮定をします。
Privacy Enhanced Mail is an example of a process level security
system; providing authentication and confidentiality for SNMP is
another example. Host level security typically means applying an
external security mechanism on the communication ports of a host
computer. Network or subnetwork security means applying the
external security capability at the gateway/router(s) leading from
the subnetwork to the "outside". Link-level security is the
traditional point-to-point or media-level (e.g., Ethernet)
encryption mechanism.
プライバシーEnhancedメールはプロセスレベルセキュリティシステムに関する例です。 認証と秘密性をSNMPに供給するのは、別の例です。 ホストレベルセキュリティは、対外安全保障メカニズムをホストコンピュータのCOMポートに適用することを通常意味します。 ネットワークかサブネットワークセキュリティが、サブネットワークから「外部」まで導きながらゲートウェイ/ルータで対外安全保障能力を適用することを意味します。 リンク・レベルセキュリティは伝統的なポイントツーポイントかメディアレベル(例えば、イーサネット)暗号化メカニズムです。
There are many open questions about network/subnetwork security
protection, not the least of which is a potential mismatch between
host level (end/end) security methods and methods at the
network/subnetwork level. Moreover, network level protection does
not deal with threats arising within the security perimeter.
ネットワーク/サブネットワーク機密保持に関する多くの未決問題があります。その最少でないのはネットワーク/サブネットワークレベルにおけるホストレベル(終わるか、または終わる)セキュリティメソッドとメソッドの間の潜在的ミスマッチです。 そのうえ、ネットワークレベル保護はセキュリティ周辺の中に起こる脅威に対処しません。
Applying protection at the process level assumes that the
underlying scheduling and operating system mechanisms can be
trusted not to prevent the application from applying security when
appropriate. As the security perimeter moves downward in the
system architecture towards the link level, one must make many
assumptions about the security threat to make an argument that
enforcement at a particular perimeter is effective. For example,
if only link-level encryption is used, one must assume that
attacks come only from the outside via communications lines, that
hosts, switches and gateways are physically protected, and the
people and software in all these components are to be trusted.
プロセスレベルで保護を適用するのは、基本的なスケジューリングとオペレーティングシステムメカニズムが、適切であるときに、アプリケーションがセキュリティを当てはまるのを防がないと信じることができると仮定します。 セキュリティ周辺がシステム構築でリンク・レベルに向かって下方に動くとき、特定の周辺での実施が有効であるという主張をする軍事的脅威に関する多くの仮定をしなければなりません。 攻撃が単に外部からコミュニケーション系列で起こって、ホスト、スイッチ、およびゲートウェイが物理的に保護されると仮定しなければなりません、そして、これらのすべてのコンポーネントにおける人々とソフトウェアは例えば、リンク・レベル暗号化が使用されてさえいる場合よいだろう、信じられることです。
4.3 Desired Security Services
4.3 必要なセキュリティー・サービス
We need authenticatable distinguished names if we are to implement
discretionary and non-discretionary access control at application
アプリケーションで任意の、そして、非任意のアクセスがコントロールであると実装するつもりであるなら、私たちは認証可能分類名を必要とします。
Clark, Chapin, Cerf, Braden, & Hobby [Page 14] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[14ページ]RFC未来
and lower levels in the system. In addition, we need enforcement
for integrity (anti-modification, anti-spoof and anti-replay
defenses), confidentiality, and prevention of denial-of-service.
For some situations, we may also need to prevent repudiation of
message transmission or to prevent covert channels.
そして、システムのレベルを下げてください。 さらに、私たちはサービスの否定の保全(反変更であって、反パロディーの、そして、反再生のディフェンス)、秘密性、および防止のための実施を必要とします。 また、いくつかの状況のために、私たちは、メッセージ送信の拒否を防ぐか、またはひそかなチャンネルを防ぐ必要があるかもしれません。
We have some building blocks with which to build the Internet
security system. Cryptographic algorithms are available (e.g.,
Data Encryption Standard, RSA, El Gamal, and possibly other public
key and symmetric key algorithms), as are hash functions such as
MD2 and MD5.
私たちには、インターネットセキュリティシステムを構築するいくつかのブロックがあります。 暗号アルゴリズムはMD2やMD5などのハッシュ関数のように利用可能です(例えば、Data Encryption Standard、RSA、El Gamal、ことによると他の公開鍵、および対称鍵アルゴリズム)。
We need Distinguished Names (in the OSI sense) and are very much
in need of an infrastructure for the assignment of such
identifiers, together with widespread directory services for
making them known. Certificate concepts binding distinguished
names to public keys and binding distinguished names to
capabilities and permissions may be applied to good advantage.
私たちは、そのような識別子の課題のためのインフラストラクチャを必要としてたいへんDistinguished Names(OSI意味における)を必要として、います、それらを明らかにするための広範囲のディレクトリサービスと共に。 公開鍵への分類名と能力と許容への拘束力がある分類名を縛る証明書概念は良い所をひき立てて適用されるかもしれません。
At the router/gateway level, we can apply address and protocol
filters and other configuration controls to help fashion a
security system. The proposed OSI Security Protocol 3 (SP3) and
Security Protocol 4 (SP4) should be given serious consideration as
possible elements of an Internet security architecture.
ルータ/ゲートウェイレベルでは、私たちは、セキュリティシステムを作成するのを助けるためにアドレス、プロトコルフィルタ、および他の構成管理を適用できます。 インターネットセキュリティー体系の可能な原理として提案されたOSI Securityプロトコル3(SP3)とSecurityプロトコル4(SP4)に真剣な考慮を与えるべきです。
Finally, it must be observed that we have no good solutions to
safely storing secret information (such as the secret component of
a public key pair) on systems like PCs or laptop computers that
are not designed to enforce secure storage.
最終的に、私たちが安全に、安全なストレージを実施するように設計されていないPCやラップトップコンピュータのようなシステムに関する秘密の情報(1公開鍵組の秘密のコンポーネントなどの)を保存するのにどんな良いソリューションも持っていないのを観測しなければなりません。
4.4 Proposed Actions
4.4 提案された動作
The following actions are proposed.
以下の動作は提案されます。
A) Security Reference Model
a) セキュリティ規範モデル
A Security Reference Model for the Internet is needed, and it
should be developed expeditiously. This model should
establish the target perimeters and document the objectives
of the security architecture.
インターネットへのSecurity Reference Modelが必要です、そして、それは迅速に開発されるべきです。 このモデルは、目標周辺を設置して、セキュリティー体系の目的を記録するべきです。
B) Privacy-Enhanced Mail (PEM)
B) プライバシーで高められたメール(PEM)
For Privacy Enhanced Mail, the most critical steps seem to be
the installation of (1) a certificate generation and
management infrastructure, and (2) X.500 directory services
to provide access to public keys via distinguished names.
Serious attention also needs to be placed on any limitations
Privacy Enhancedメールに関しては、最も重要なステップは(2) (1) 証明書世代と管理インフラストラクチャのインストールと、分類名で公開鍵へのアクセスを提供するX.500ディレクトリサービスであるように思えます。 また、重大な注意は、どんな制限にも置かれる必要があります。
Clark, Chapin, Cerf, Braden, & Hobby [Page 15] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[15ページ]RFC未来
imposed by patent and export restrictions on the deployment
of this system.
特許と輸出制限で、このシステムの展開に課されます。
C) Distributed System Security
C) 分散システムセキュリティ
We should examine security methods for distributed systems
applications, in both simple (client/server) and complex
(distributed computing environment) cases. For example, the
utility of certificates granting permissions/capabilities to
objects bound to distinguished names should be examined.
私たちは簡単な(クライアント/サーバ)ものと同様に複雑な(分散コンピューティング環境)場合における分散システムアプリケーションがないかどうかセキュリティメソッドを調べるべきです。 例えば、許容/能力を分類名に縛られたオブジェクトに与える証明書に関するユーティリティは調べられるべきです。
D) Host-Level Security
D) ホストレベルセキュリティ
SP4 should be evaluated for host-oriented security, but SP3
should also be considered for this purpose.
SP4はホスト指向のセキュリティのために評価されるべきですが、また、SP3はこのために考えられるべきです。
E) Application-Level Security
E) アプリケーションレベルセキュリティ
We should implement application-level security services, both
for their immediate utility (e.g., PEM, SNMP authentication)
and also to gain valuable practical experience that can
inform the refinement of the Internet security architecture.
私たちは、ともに、それらの即座のユーティリティ(例えば、PEM、SNMP認証)、また、インターネットセキュリティー体系の気品を知らせることができる貴重な実用的な経験をするためにアプリケーションレベルセキュリティがサービスであると実装するべきです。
5. TRAFFIC CONTROL AND STATE
5. トラフィックコントロールAND状態
In the present Internet, all IP datagrams are treated equally. Each datagram is forwarded independently, regardless of any relationship it has to other packets for the same connection, for the same application, for the same class of applications, or for the same user class. Although Type-of-Service and Precedence bits are defined in the IP header, these are not generally implemented, and in fact it is not clear how to implement them.
現在のインターネットでは、すべてのIPデータグラムが等しく扱われます。 独自に各データグラムを進めます、それが同じ接続のための他のパケットに持っているどんな関係にかかわらず、同じクラスのアプリケーション、または同じユーザ・クラスの同じアプリケーションのために。 サービスのTypeとPrecedenceビットはIPヘッダーで定義されますが、一般に、これらは実装されません、そして、事実上、どのようにそれらを実装するかは明確ではありません。
It is now widely accepted that the future Internet will need to support important applications for which best-effort is not sufficient -- e.g., packet video and voice for teleconferencing. This will require some "traffic control" mechanism in routers, controlled by additional state, to handle "real-time" traffic.
現在将来のインターネットが重要なアプリケーションをサポートする必要性を望んでいると広く受け入れる、どれ、ベストエフォート型、十分でないか、--例えば、パケットビデオと電子会議のための声。 これは、「リアルタイムで」のトラフィックを扱うために追加州によって制御されたルータで何らかの「トラフィックコントロール」メカニズムを必要とするでしょう。
5.1 Assumptions and Principles
5.1 仮定と原則
o ASSUMPTION: The Internet will need to support performance
guarantees for particular subsets of the traffic.
o 仮定: インターネットは、性能がトラフィックの特定の部分集合のための保証であるとサポートする必要があるでしょう。
Unfortunately, we are far from being able to give precise meanings
to the terms "performance", "guarantees", or "subsets" in this
statement. Research is still needed to answer these questions.
残念ながら、私たちはこの声明で用語「性能」、「保証」、または「部分集合」まで正確な意味を与えることができることから遠いです。 研究が、これらの質問に答えるのにまだ必要です。
Clark, Chapin, Cerf, Braden, & Hobby [Page 16] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[16ページ]RFC未来
o The default service will continue to be the current "best-
effort" datagram delivery, with no service guarantees.
o デフォルトサービスはずっとサービス保証がなければ現在の「最も良い取り組み」データグラム配信でしょう。
o The mechanism of a router can be separated into (1) the
forwarding path and (2) the control computations (e.g.,
routing) which take place in the background.
o (1) 推進経路と(2) バックグラウンドで行われるコントロール計算(例えば、ルーティング)にルータのメカニズムを切り離すことができます。
The forwarding path must be highly optimized, sometimes with
hardware-assist, and it is therefore relatively costly and
difficult to change. The traffic control mechanism operates
in the forwarding path, under the control of state created by
routing and resource control computations that take place in
background. We will have at most one shot at changing the
forwarding paths of routers, so we had better get it right
the first time.
変化するのは、時々ハードウェアアシストで推進経路を非常に最適化しなければならなくて、したがって、比較的高価であって、難しいです。 トラフィックコントロールメカニズムは推進経路で動作します、ルーティングとバックグラウンドで行われる資源管理計算で創設された状態のコントロールの下で。 ルータの推進経路を変えることへ1つのショットに最も攻撃するつもりであるので、私たちは1回目にそれを正しくするほうがよいです。
o The new extensions must operate in a highly heterogeneous
environment, in which some parts will never support
guarantees. For some hops of a path (e.g., a high-speed
LAN), "over-provisioning" (i.e., excess capacity) will allow
adequate service for real-time traffic, even when explicit
resource reservation is unavailable.
o 新しい拡大はaで非常に作動しなければなりません。異機種混在環境。(そこでは、いくつかの部品が保証を決して支えないでしょう)。 経路(例えば、高速LAN)のいくつかのホップに関しては、(すなわち、過剰生産能力)に「食糧を供給し過ぎる」と、リアルタイムのトラフィックのための適切なサービスは許されるでしょう、明白な資源予約が入手できないときにさえ。
o Multicast distribution is probably essential.
o マルチキャスト分配はたぶん不可欠です。
5.2 Technical Issues
5.2 技術的な問題
There are a number of technical issues to be resolved, including:
である:決議されるために、多くの専門的な問題があります。
o Resource Setup
o リソースセットアップ
To support real-time traffic, resources need to be reserved
in each router along the path from source to destination.
Should this new router state be "hard" (as in connections) or
"soft" (i.e., cached state)?
リアルタイムのトラフィックをサポートするために、リソースは、経路に沿った各ルータでソースから目的地まで予約される必要があります。 この新しいルータ状態は、「困難(接続のように)」か「柔らかくあるべきですか?」(すなわち、状態をキャッシュします)
o Resource binding vs. route binding
o リソース結合対ルート結合
Choosing a path from source to destination is traditionally
performed using a dynamic routing protocol. The resource
binding and the routing might be folded into a single complex
process, or they might be performed essentially
independently. There is a tradeoff between complexity and
efficiency.
ソースから目的地までの経路を選ぶのは、ダイナミックルーティングプロトコルを使用することで伝統的に実行されます。 リソース結合とルーティングが単一の複雑なプロセスに折り重ねられるかもしれませんか、またはそれらは本質的には独自に実行されるかもしれません。 複雑さと効率の間には、見返りがあります。
o Alternative multicast models
o 代替のマルチキャストモデル
IP multicasting uses a model of logical addressing in which
IPマルチキャスティングは中でどれを扱う論理的のモデルを使用します。
Clark, Chapin, Cerf, Braden, & Hobby [Page 17] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[17ページ]RFC未来
targets attach themselves to a group. In ST-2, each host in
a multicast session includes in its setup packet an explicit
list of target addresses. Each of these approaches has
advantages and drawbacks; it is not currently clear which
will prevail for n-way teleconferences.
目標はグループに愛着を持ちます。 ST-2では、マルチキャストセッションにおける各ホストはセットアップパケットであて先アドレスの明白なリストを入れます。 それぞれのこれらのアプローチには、利点と欠点があります。 どれがn-道の電子会議のために行き渡るかは、現在、明確ではありません。
o Resource Setup vs. Inter-AD routing
o リソースSetup対Inter-西暦のルーティング
Resource guarantees of whatever flavor must hold across an
arbitrary end-to-end path, including multiple ADs. Hence,
any resource setup mechanism needs to mesh smoothly with the
path setup mechanism incorporated into IDPR.
いかなる風味のリソース保証も終わりから端への複数のADsを含む任意の経路の向こう側に成立しなければなりません。 したがって、どんなリソースセットアップメカニズムも、経路セットアップメカニズムが法人組織でスムーズにIDPRとかみ合う必要があります。
o Accounting
o 会計
The resource guarantee subsets ("classes") may be natural
units for accounting.
リソース保証部分集合(「クラス」)は会計のための自然なユニットであるかもしれません。
5.3 Proposed Actions
5.3 提案された動作
The actions called for here are further research on the technical
issues listed above, followed by development and standardization
of appropriate protocols. DARTnet, the DARPA Research Testbed
network, will play an important role in this research.
ここに求められた動作は上に記載された専門的な問題のさらなる研究です、適切なプロトコルの開発と標準化があとに続いていて。 DARTnet(DARPA Research Testbedネットワーク)はこの研究で重要な役割を果たすでしょう。
6. ADVANCED APPLICATIONS
6. 高度なアプリケーション
One may ask: "What network-based applications do we want, and why don't we have them now?" It is easy to develop a large list of potential applications, many of which would be based on a client/server model. However, the more interesting part of the question is: "Why haven't people done them already?" We believe the answer to be that the tools to make application writing easy just do not exist.
尋ねるかもしれません: 「私たちは、どんなネットワークベースのアプリケーションが欲しいかと思います、そして、現在、それらを持ちましょう」 それの多くがクライアント/サーバモデルに基づくだろう潜在的アプリケーションの大きいリストを開発するのは簡単です。 しかしながら、質問の部分は、よりおもしろいです: 「人々はなぜ既に彼らをしていませんか?」 私たちは、答えがアプリケーション書くことを簡単にするツールがただ存在していないということであると信じています。
To begin, we need a set of common interchange formats for a number of data items that will be used across the network. Once these common data formats have been defined, we need to develop tools that the applications can use to move the data easily.
始まるように、私たちはネットワークの向こう側に使用される多くのデータ項目のための1セットの一般的な置き換え形式を必要とします。 これらの一般的なデータ書式がいったん定義されると、私たちは、アプリケーションが容易にデータを動かすのに使用できるツールを開発する必要があります。
6.1 Common Interchange Formats
6.1 一般的な置き換え形式
The applications have to know the format of information that they
are exchanging, for the information to have any meaning. The
following format types are to concern:
アプリケーションはそれらがどんな意味も持つために情報と交換している情報の書式を知らなければなりません。 関心には以下の形式タイプがあります:
(1) Text - Of the formats in this list, text is the most stable,
but today's international Internet has to address the needs
(1) このリストの形式のテキスト、テキストは最も安定していますが、今日の国際的なインターネットは必要性を扱わなければなりません。
Clark, Chapin, Cerf, Braden, & Hobby [Page 18] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[18ページ]RFC未来
of character sets other than USASCII.
USASCII以外の文字集合について。
(2) Image - As we enter the "Multimedia Age", images will become
increasingly important, but we need to agree on how to
represent them in packets.
(2)イメージ--私たちが「マルチメディア時代」に入るのに従って、イメージはますます重要になるでしょうが、私たちは、パケットにそれらを表す方法に同意する必要があります。
(3) Graphics - Like images, vector graphic information needs a
common definition. With such a format we could exchange
things like architectural blueprints.
(3)グラフィックス--イメージのように、ベクトルのグラフィック情報は一般的な定義を必要とします。 そのような形式で、私たちは建築青写真のようなものを交換できました。
(4) Video - Before we can have a video window running on our
workstation, we need to know the format of that video
information coming over the network.
(4)ビデオ--ビデオウィンドウに私たちのワークステーションで動かせることができる前に、私たちは、ネットワークを襲うそのビデオ情報の書式を知る必要があります。
(5) Audio/Analog - Of course, we also need the audio to go with
the video, but such a format would be used for representation
of all types of analog signals.
(5)オーディオ/アナログ--もちろん、また、私たちはビデオを伴うためにオーディオを必要としますが、そのような形式はすべてのタイプに関するアナログ信号の表現に使用されるでしょう。
(6) Display - Now that we are opening windows on our workstation,
we want to open a window on another person's workstation to
show her some data pertinent to the research project, so now
we need a common window display format.
ディスプレイ..開く..窓..ワークステーション..欲しい..窓を開ける..別の人..ワークステーション..示す..データ..適切..研究計画..そのように..現在..必要..通例..窓..システム出力表示形式
(7) Data Objects - For inter-process communications we need to
agree on the formats of things like integers, reals, strings,
etc.
(7)データObjects--相互プロセスコミュニケーションのために、私たちは、整数、本物、ストリングなどのようなものの書式に同意する必要があります。
Many of these formats are being defined by other, often several
other, standards organizations. We need to agree on one format
per category for the Internet.
これらの形式の多くは他によって定義されるしばしばいくつかの他の規格組織です。 私たちは、1カテゴリあたり1つの書式にインターネットに同意する必要があります。
6.2 Data Exchange Methods
6.2 データ交換メソッド
Applications will require the following methods of data exchange.
アプリケーションはデータ交換の以下のメソッドを必要とするでしょう。
(1) Store and Forward
(1) ストアとフォワード
Not everyone is on the network all the time. We need a
standard means of providing an information flow to
sometimes-connected hosts, i.e., we need a common store-and-
forward service. Multicasting should be included in such a
service.
皆は時間中にネットワークに関するそうであるというわけではありません。 そして、私たちが時々接続されたホストに情報流動を供給する標準の手段を必要として、すなわち、一般的な店を必要とする、-、-サービスを進めてください。 マルチキャスティングはそのようなサービスに含まれるべきです。
(2) Global File Systems
(2) グローバルなファイルシステム
Much of the data access over the network can be broken down
to simple file access. If you had a real global file system
where you access any file on the Internet (assuming you have
ネットワークの上のデータ・アクセスの多くを簡単なファイルアクセスまで壊すことができます。 あなたにインターネットのどんなファイルにもアクセスする全くグローバルなファイルシステムがあった、(あなたが持っていると仮定すること。
Clark, Chapin, Cerf, Braden, & Hobby [Page 19] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[19ページ]RFC未来
permission), would you ever need FTP?
許可)、あなたはFTP?必要とするでしょう。
(3) Inter-process Communications
(3) 相互プロセスコミュニケーション
For a true distributed computing environment, we need the
means to allow processes to exchange data in a standard
method over the network. This requirement encompasses RPC,
APIs, etc.
本当の分散コンピューティング環境のために、私たちはプロセスが標準方法によるデータをネットワークの上と交換するのを許容する手段を必要とします。 この要件はRPC、APIなどを取り囲みます。
(4) Data Broadcast
(4)データ放送
Many applications need to send the same information to many
other hosts. A standard and efficient method is needed to
accomplish this.
多くのアプリケーションが、多くの他のホストに同じ情報を送る必要があります。 標準の、そして、効率的なメソッドが、これを達成するのに必要です。
(5) Database Access
(5) データベースアクセス
For good information exchange, we need to have a standard
means for accessing databases. The Global File System can get
you to the data, but the database access methods will tell
you about its structure and content.
良い情報交換のために、私たちはデータベースにアクセスするための標準の手段を必要とします。 Global File Systemはあなたをデータに得ることができますが、データベースアクセス法はその構造と内容に関してあなたに示すでしょう。
Many of these items are being addressed by other organizations,
but for Internet interoperability, we need to agree on the methods
for the Internet.
これらの項目の多くが他の組織によって扱われていますが、インターネット相互運用性のために、私たちは、メソッドにインターネットに同意する必要があります。
Finally, advanced applications need solutions to the problems of
two earlier areas in this document. From the Traffic Control and
State area, applications need the ability to transmit real-time
data. This means some sort of expectation level for data delivery
within a certain time frame. Applications also require global
authentication and access control systems from the Security area.
Much of the usefulness of today's Internet applications is lost
due to the lack of trust and security. This needs to be solved
for tomorrow's applications.
最終的に、高度なアプリケーションは本書では2つの以前の領域の問題にソリューションを必要とします。 Traffic Controlと州領域から、アプリケーションはリアルタイムデータを伝える能力を必要とします。 これはある時間枠の中のデータ配送のためにある種の期待レベルを意味します。 また、アプリケーションはSecurity領域からグローバルな認証とアクセス制御システムを必要とします。 今日のインターネットアプリケーションの有用性の多くが信頼とセキュリティの不足のため失われています。 これは、明日のアプリケーションのために解決される必要があります。
Clark, Chapin, Cerf, Braden, & Hobby [Page 20] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[20ページ]RFC未来
7. REFERENCES
7. 参照
[1] Cerf, V. and R. Kahn, "A Protocol for Packet Network
Intercommunication," IEEE Transactions on Communication, May
1974.
[1] サーフ、V.、およびR.カーン(「パケット網相互通信のためのプロトコル」、コミュニケーションに関するIEEEトランザクション)は1974がそうするかもしれません。
[2] Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet
Protocol," Computer Networks, Vol. 5, No. 4, July 1981.
[2] ポステルとJ.と日光、C.とD.コーエン、「アルパインターネットプロトコル」コンピュータネットワーク、Vol.5、No.4、1981年7月。
[3] Leiner, B., Postel, J., Cole, R., and D. Mills, "The DARPA
Internet Protocol Suite," Proceedings INFOCOM 85, IEEE,
Washington DC, March 1985. Also in: IEEE Communications
Magazine, March 1985.
[3]LeinerとB.とポステルとJ.とコール、R.とD.工場、「DARPAインターネットプロトコル群」議事INFOCOM85、IEEE、ワシントンD.C.(1985年3月)。 以下でも 1985年3月のIEEEコミュニケーション雑誌。
[4] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Proceedings ACM SIGCOMM '88, Stanford, California,
August 1988.
[4] クラーク、D.、「DARPAインターネットプロトコルの設計理念」、議事ACM SIGCOMM88年、スタンフォード、カリフォルニア、1988年8月。
[5] Mogul, J., and J. Postel, "Internet Standard Subnetting
Procedure", RFC 950, USC/Information Sciences Institute, August
1985.
[5] ムガール人、J.とJ.ポステル、「インターネットの標準のサブネッティング手順」、RFC950、科学が1985年8月に設けるUSC/情報。
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, USC/Information Sciences Institute, November 1987.
[6]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC1034、科学が設けるUSC/情報、11月1987日
[7] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[7] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、RFC1112、スタンフォード大学、1989年8月。
[8] "Proceedings of the Twenty-First Internet Engineering Task
Force", Bell-South, Atlanta, July 29 - August 2, 1991.
[8] 7月29日--「第21インターネット・エンジニアリング・タスク・フォースの議事」、ベル・サウス、アトランタ、1991年8月2日。
Clark, Chapin, Cerf, Braden, & Hobby [Page 21] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[21ページ]RFC未来
APPENDIX A: Setting the Stage
付録A: 舞台装置をセットします。
Slide 1
WHITHER THE INTERNET?
スライド1インターネット?
OPTIONS FOR ARCHITECTURE
アーキテクチャのためのオプション
IAB/IESG -- Jan 1990
IAB/IESG--1990年1月
David D. Clark
デヴィッド・D.クラーク
__________________________________________________________________ Slide 2
__________________________________________________________________ スライド2
SETTING THE TOPIC OF DISCUSSION
議論の話題を設定します。
Goals:
目標:
o Establish a common frame of understanding for
IAB, IESG and the Internet community.
o IAB、IESG、およびインターネットコミュニティのために分かる共通フレームを設立してください。
o Understand the set of problems to be solved.
o 問題のセットが解決されるのを理解してください。
o Understand the range of solutions open to us.
o 私たちにとって、開いているソリューションの範囲を理解してください。
o Draw some conclusions, or else
"meta-conclusions".
o いくつかの結論、または「メタ結論」を引き起こしてください。
Clark, Chapin, Cerf, Braden, & Hobby [Page 22] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[22ページ]RFC未来
__________________________________________________________________ Slide 3
__________________________________________________________________ スライド3
SOME CLAIMS -- MY POSITION
いくつかのクレーム--私の地位
We have two different goals:
o Make it possible to build "The Internet"
o Define a protocol suite called Internet
私たちには、2つの異なった目標があります: o 「インターネット」o Defineにインターネットと呼ばれるプロトコル群を建設するのを可能にしてください。
Claim: These goals have very different implications.
The protocols are but a means, though a powerful one.
以下を要求してください。 これらの目標には、非常に異なった意味があります。 強力なものですが、プロトコルは手段にすぎません。
Claim: If "The Internet" is to succeed and grow, it will
require specific design efforts. This need will continue
for at least another 10 years.
以下を要求してください。 「インターネット」が成功して、成長するつもりであると、それは特定のデザイン取り組みを必要とするでしょう。 この必要性は少なくとも別のもののために10年間続くでしょう。
Claim: Uncontrolled growth could lead to chaos.
以下を要求してください。 無制約成長はカオスにつながるかもしれません。
Claim: A grass-roots solution seems to be the only
means to success. Top-down mandates are powerless.
以下を要求してください。 グラスルーツソリューションは成功への唯一の手段であるように思えます。 トップダウン命令は無力です。
__________________________________________________________________ Slide 4
__________________________________________________________________ スライド4
OUTLINE OF PRESENTATION
プレゼンテーションのアウトライン
1) The problem space and the solution space.
1) 問題スペースとソリューションスペース。
2) A set of specific questions -- discussion.
2) 1セットの具体的な質問--議論。
3) Return to top-level questions -- discussion.
3) トップレベル質問に戻ってください--議論。
4) Plan for action -- meta discussion.
4) 動作の計画を立ててください--メタ議論。
Try to separate functional requirements from technical approach.
技術的なアプローチと機能条件書を切り離すようにしてください。
Understand how we are bounded by our problem space and our
solution space.
私たちは私たちの問題スペースと私たちのソリューションスペースのそばでどのように境界があるか理解してください。
Is architecture anything but protocols?
アーキテクチャはプロトコル以外の何かですか?
Clark, Chapin, Cerf, Braden, & Hobby [Page 23] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[23ページ]RFC未来
__________________________________________________________________ Slide 5
__________________________________________________________________ スライド5
WHAT IS THE PROBLEM SPACE?
問題スペースは何ですか?
Routing and addressing:
How big, what topology, and what routing model?
ルート設定とアドレシング: どれくらい大きくて、どんなトポロジー、およびどんなルーティングがモデル化されますか?
Getting big:
User services, what technology for host and nets?
大きくなります: ユーザサービス、ホストとネットのためのどんな技術?
Divestiture of the Internet:
Accounting, controlling usage and fixing faults.
インターネットの剥奪: 説明して、用法を制御して、欠点を修正します。
New services:
Video? Transactions? Distributed computing?
新種業務: ビデオ? トランザクション? 分散コンピューティング?
Security:
End node or network? Routers or relays?
セキュリティ: エンドノードですかそれともネットワークですか? ルータですかそれともリレーですか?
__________________________________________________________________ Slide 6
__________________________________________________________________ スライド6
BOUNDING THE SOLUTION SPACE
制限はソリューションスペースです。
How far can we migrate from the current state?
o Can we change the IP header (except to OSI)?
o Can we change host requirements in mandatory ways?
o Can we manage a long-term migration objective?
- Consistent direction vs. diverse goals, funding.
どれくらい遠くに、私たちはIPヘッダー(OSIを除いた)を変える現状o Canからわたることができますか?私たちが変えるo Canは私たちが長期の移行目的を管理するという義務的な道?o Canの要件を接待します-- - 一貫した方向対さまざまの目標、基金
Can we assume network-level connectivity?
o Relays are the wave of the future (?)
o Security a key issue; along with conversion.
o Do we need a new "relay-based" architecture?
私たちはネットワークレベルの接続性を仮定できますか?o Relaysはキーが発行する将来の(?)o Securityの波です。 変換o Doと共に、私たちは新しい「リレーベース」のアーキテクチャを必要としますか?
How "managed" can/must "The Internet" be?
o Can we manage or constrain connectivity?
どのようにが缶/必須を「管理したか」。「インターネット」は、私たちが管理するo Canですかそれとも接続性を抑制しますか?
What protocols are we working with? One or many?
どんなプロトコルで、私たちは働いていますか? 1ですかそれとも多くですか?
Clark, Chapin, Cerf, Braden, & Hobby [Page 24] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[24ページ]RFC未来
__________________________________________________________________ Slide 7
__________________________________________________________________ スライド7
THE MULTI-PROTOCOL INTERNET
マルチプロトコルインターネット
"Making the problem harder for the good of mankind."
「問題を人類の利益には、より困難にします。」
Are we migrating, interoperating, or tolerating multiple protocols?
o Not all protocol suites will have same range of functionality
at the same time.
o "The Internet" will require specific functions.
共同利用して、私たちが移行しているか、または複数のプロトコル?o Notを許容して、同時に、すべてのプロトコル群には同じ範囲の機能性があるでしょう。○ 「インターネット」は具体的な機能を必要とするでしょう。
Claim: Fundamental conflict (not religion or spite):
o Meeting aggressive requirements for the Internet
o Dealing with OSI migration.
以下を要求してください。 基本的な紛争(信仰でない悪意でない): o OSI移行でインターネットo Dealingに、攻撃的な必要条件を満たします。
Conclusion: One protocol must "lead", and the others must follow.
When do we "switch" to OSI?
結論: 1つのプロトコルが「導かなければなりません」、そして、他のものは続かなければなりません。 私たちはいつOSIに「切り替わりますか?」
Consider every following slide in this context.
このような関係においてはあらゆる次のスライドを考えてください。
__________________________________________________________________ Slide 8
__________________________________________________________________ スライド8
ROUTING and ADDRESSING
ルーティングとアドレシング
What is the target size of "The Internet"?
o How do addresses and routes relate?
o What is the model of topology?
o What solutions are possible?
「インターネット」の目標サイズはどのくらいですか?ルートは関係します--o Whatはトポロジーのモデルです--o Howはアドレスをします、そして、o Whatソリューションは可能です--
What range of policy routing is required?
o BGP and IDRP are two answers. What is the question?
o Fixed classes, or variable paths?
o Source controlled routing is a minimum.
どんな範囲の方針ルーティングが必要ですか?o BGPとIDRPは2つの答えです。 何がo Sourceがルーティングを制御したという疑問(o Fixedのクラス、または可変経路)であるかは最小限です。
How seamless is the needed support for mobile hosts?
o New address class, rebind to local address, use DNS?
モバイルホストの必要なサポートはどれくらいシームレスですか?o Newはクラスに演説して、ローカルアドレス、使用にDNSを縛り直してください--
Shall we push for Internet multicast?
インターネットマルチキャストを要求しましょうか?
Clark, Chapin, Cerf, Braden, & Hobby [Page 25] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[25ページ]RFC未来
__________________________________________________________________ Slide 9
__________________________________________________________________ スライド9
GETTING BIG -- AN OLD TITLE
大きくなります--古いタイトル
(Addressing and routing was on previous slide...)
(前のスライドの上にアドレシングとルーティングがありました…)
What user services will be needed in the next 10 years?
o Can we construct a plan?
o Do we need architectural changes?
ユーザが修理することは10年?o次Canで必要であることで、私たちがプラン?o Doを組み立てるということでしょう。私たちは建築変化を必要としますか?
Is there a requirement for dealing better with ranges in
speed, packet sizes, etc.
o Policy to phase out fragmentation?
断片化を段階的に廃止するために、速度、パケットサイズ、などo Policyには取扱いのための範囲によって、より良い要件がありますか?
What range of hosts (things != Unix) will we support?
私たちはどんな範囲のホスト(もの!=unix)をサポートするつもりですか?
_________________________________________________________________ Slide 10
_________________________________________________________________ スライド10
DEALING WITH DIVESTITURE
剥奪に対処します。
The Internet is composed of parts separately managed and controlled.
インターネットは、別々に管理された部品で構成されて、制御されます。
What support is needed for network charging?
o No architecture implies bulk charges and re-billing, pay
for lost packets.
o Do we need controls to supply billing id or routing?
どんなサポートがネットワーク充電に必要ですか?○ どんなアーキテクチャも私たちが、コントロールが供給する必要がある大量の充電と再支払い(無くなっているパケットのための賃金)o Do支払いイドかルーティングを含意しません--
Requirement: we must support links with controlled sharing.
(Simple form is classes based on link id.)
o How general?
要件: 私たちは制御共有とのリンクを支えなければなりません。 (単純形はリンクイドに基づくクラスです。) o どれくらい一般的ですか?
Is there an increased need for fault isolation? (I vote yes!)
o How can we find managers to talk to?
o Do we need services in hosts?
欠点分離の増強された必要がありますか? (私は賛成票を投じます!) o 私たちは、o Doと話すためにどうしたらマネージャを見つけることができるか。ホストでサービスを必要としますか?
Clark, Chapin, Cerf, Braden, & Hobby [Page 26] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[26ページ]RFC未来
_________________________________________________________________ Slide 11
_________________________________________________________________ スライド11
NEW SERVICES
新種業務
Shall we support video and audio? Real time? What %?
o Need to plan for input from research. What quality?
o Target date for heads-up to vendors.
ビデオとオーディオを支えましょうか? リアルタイムでですか? 何という%--oは研究からの入力のためのプランにそうしなければならないか。 何という品質--o Targetは有利なスタートのためにベンダーとデートするか。
Shall we "better" support transactions?
o Will TCP do? VMTP? Presentation? Locking?
トランザクションを「よりよく」サポートしましょうか?--ウィルTCPがする○? VMTP? プレゼンテーション? ロック?
What application support veneers are coming?
o Distributed computing -- will it actually happen?
o Information networking?
アプリケーションサポートベニヤが来させること--o Distributedコンピューティング--実際に、起こるでしょうか?--o情報ネットワーク?
__________________________________________________________________ Slide 12
__________________________________________________________________ スライド12
SECURITY
セキュリティ
Can we persist in claiming the end-node is the only line of defense?
o What can we do inside the network?
o What can ask the host to do?
エンドノードがディフェンス?私たちがネットワークの中でするo What缶の唯一の系列であると主張するのに私たちは固執できますか?--Whatが、ホストがするように頼むことができる○?
Do we tolerate relays, or architect them? Can find a better way to construct security boundaries?
私たちがリレー、または建築家を許容する、それら-- セキュリティ境界を構成するより良い方法を見つけることができますか?
Do we need global authentication?
私たちはグローバルな認証を必要としますか?
Do we need new host requirements:
o Logging.
o Authentication.
o Management interfaces.
- Phone number or point of reference.
私たちは新しいホスト要件を必要とします: o 伐採o Authentication o Managementは連結します。 - 電話番号か参照のポイント。
__________________________________________________________________
__________________________________________________________________
Clark, Chapin, Cerf, Braden, & Hobby [Page 27] RFC 1287 Future of Internet Architecture December 1991
インターネットアーキテクチャ1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[27ページ]RFC未来
APPENDIX B: Group Membership
付録B: グループ会員資格
Group 1: ROUTING AND ADDRESSING
グループ1: ルーティングとアドレシング
Dave Clark, MIT [Chair]
Hans-Werner Braun, SDSC
Noel Chiappa, Consultant
Deborah Estrin, USC
Phill Gross, CNRI
Bob Hinden, BBN
Van Jacobson, LBL
Tony Lauck, DEC.
デーブ・クラーク、MIT[議長]ハンス-ヴェルナーBraun、SDSCクリスマスChiappa、コンサルタントデボラEstrin、USCフィルGross、CNRIボブHinden、BBNはジェーコブソンをバンに積みます、LBLトニーLauck、12月
Group 2: MULTI-PROTOCOL ARCHITECTURE
グループ2: マルチプロトコル構造
Lyman Chapin, BBN [Chair]
Ross Callon, DEC
Dave Crocker, DEC
Christian Huitema, INRIA
Barry Leiner,
Jon Postel, ISI
ライマン・チェーピン、BBN[議長]ロスCallon、12月のデーヴ・クロッカー、12月のクリスチャンのHuitema、INRIAバリトンサックスLeiner、ジョン・ポステル、ISI
Group 3: SECURITY ARCHITECTURE
グループ3: セキュリティー体系
Vint Cerf, CNRI [Chair]
Steve Crocker, TIS
Steve Kent, BBN
Paul Mockapetris, DARPA
Vintサーフ、CNRI[議長]スティーブ・クロッカー、TISスティーブ・ケント、BBNポールMockapetris、DARPA
Group 4: TRAFFIC CONTROL AND STATE
グループ4: トラフィックコントロールAND状態
Robert Braden, ISI [Chair]
Chuck Davin, MIT
Dave Mills, University of Delaware
Claudio Topolcic, CNRI
ロバート・ブレーデン、ISI[議長]チャック・デーヴィン、MITデーヴ工場、デラウエア大学クラウディオTopolcic、CNRI
Group 5: ADVANCED APPLICATIONS
グループ5: 高度なアプリケーション
Russ Hobby, UCDavis [Chair]
Dave Borman, Cray Research
Cliff Lynch, University of California
Joyce K. Reynolds, ISI
Bruce Schatz, University of Arizona
Mike Schwartz, University of Colorado
Greg Vaudreuil, CNRI.
ラスHobby、UCDavis[議長]デーヴ・ボーマン、クレイリサーチのクリフ・リンチ、カリフォルニア大学のジョイス・K.レイノルズ、ISIブルース・シャッツ、アリゾナ大学のマイク・シュワルツ、コロラドグレッグ・ボードルイ大学、CNRI。
Clark, Chapin, Cerf, Braden, & Hobby [Page 28] RFC 1287 Future of Internet Architecture December 1991
インターネット構造1991年12月のクラーク、チェーピン、サーフ、ブレーデン、および1287年の趣味[28ページ]RFC未来
Security Considerations
セキュリティ問題
Security issues are discussed in Section 4.
セクション4で安全保障問題について議論します。
Authors' Addresses
作者のアドレス
David D. Clark Massachusetts Institute of Technology Laboratory for Computer Science 545 Main Street Cambridge, MA 02139
Main Streetケンブリッジ、デヴィッドD.クラークマサチューセッツ工科大学コンピュータ科学研究所545MA 02139
Phone: (617) 253-6003 EMail: ddc@LCS.MIT.EDU
以下に電話をしてください。 (617) 253-6003 メールしてください: ddc@LCS.MIT.EDU
Vinton G. Cerf Corporation for National Research Initiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091
レストン、Suite100ヴァージニア 国家の研究イニシアチブ1895のプレストンの白いドライブ、22091へのビントンG.サーフ社
Phone: (703) 620-8990 EMail: vcerf@nri.reston.va.us
以下に電話をしてください。 (703) 620-8990 メールしてください: vcerf@nri.reston.va.us
Lyman A. Chapin Bolt, Beranek & Newman Mail Stop 20/5b 150 Cambridge Park Drive Cambridge, MA 02140
ライマンA.チェーピンボルト、Beranek、およびニューマンメール停止20/5b150ケンブリッジ公園Driveケンブリッジ、MA 02140
Phone: (617) 873-3133 EMail: lyman@BBN.COM
以下に電話をしてください。 (617) 873-3133 メールしてください: lyman@BBN.COM
Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ロバートブレーデンUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511 EMail: braden@isi.edu
以下に電話をしてください。 (310) 822-1511 メールしてください: braden@isi.edu
Russell Hobby University of California Computing Services Davis, CA 95616
デイヴィス、ラッセル趣味カリフォルニア大学Computing Servicesカリフォルニア 95616
Phone: (916) 752-0236 EMail: rdhobby@ucdavis.edu
以下に電話をしてください。 (916) 752-0236 メールしてください: rdhobby@ucdavis.edu
Clark, Chapin, Cerf, Braden, & Hobby [Page 29]
クラーク、チェーピン、サーフ、ブレーデン、および趣味[29ページ]
一覧
スポンサーリンク
