RFC1726 日本語訳
1726 Technical Criteria for Choosing IP The Next Generation (IPng). C.Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Partridge
Request for Comments: 1726 BBN Systems and Technologies
Category: Informational F. Kastenholz
FTP Software
December 1994
コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 1726台のBBNシステムと技術カテゴリ: 情報のF.Kastenholz FTPソフトウェア1994年12月
Technical Criteria for Choosing
IP The Next Generation (IPng)
IP次世代を選ぶ技術的な評価基準(IPng)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IPng Area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.
RFC1550に対応してこのドキュメントをIPng Areaに提出しました。 このドキュメントの公表は中で言い表された状態でどんな考えのIPng Areaによる承認も含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。 このRFCはIPのNext Generationのデザインと選択における考慮に移動性に関連する評価基準を指定します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Note on Terminology . . . . . . . . . . . . . . . . . . . 4
4. General Principles. . . . . . . . . . . . . . . . . . . . 4
4.1 Architectural Simplicity. . . . . . . . . . . . . . . . . 4
4.2 One Protocol to Bind Them All . . . . . . . . . . . . . . 4
4.3 Live Long . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4 Live Long AND Prosper . . . . . . . . . . . . . . . . . . 5
4.5 Co-operative Anarchy. . . . . . . . . . . . . . . . . . . 5
5. Criteria. . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Topological Flexibility . . . . . . . . . . . . . . . . . 8
5.3 Performance . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Robust Service. . . . . . . . . . . . . . . . . . . . . . 10
5.5 Transition. . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Media Independence. . . . . . . . . . . . . . . . . . . . 13
5.7 Unreliable Datagram Service . . . . . . . . . . . . . . . 15
5.8 Configuration, Administration, and Operation. . . . . . . 16
5.9 Secure Operation. . . . . . . . . . . . . . . . . . . . . 17
5.10 Unique Naming . . . . . . . . . . . . . . . . . . . . . . 18
5.11 Access. . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.12 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . 2 2. 目標. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 用語. . . . . . . . . . . . . . . . . . . 4 4では、注意します。 綱領。 . . . . . . . . . . . . . . . . . . . 4 4.1 建築簡単さ。 . . . . . . . . . . . . . . . . すべての.44.3の生体のロング. . . . . . . . . . . . . . . . . . . . . . . . 5 4.4にそれらを縛る1つのプロトコルは、長い間生きていて、.54.5に繁栄しています。4 4.2 協力的なアナーキー。 . . . . . . . . . . . . . . . . . . 5 5. 評価基準。 . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 スケール. . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2位相的な柔軟性. . . . . . . . . . . . . . . . . 8 5.3パフォーマンス. . . . . . . . . . . . . . . . . . . . . . . 9 5.4の体力を要しているサービス。 . . . . . . . . . . . . . . . . . . . . . 10 5.5 変遷。 . . . . . . . . . . . . . . . . . . . . . . . 12 5.6 メディア独立。 . . . . . . . . . . . . . . . . . . . 13 5.7 頼り無いデータグラムサービス. . . . . . . . . . . . . . . 15 5.8構成、政権、および操作。 . . . . . . 16 5.9は操作を保証します。 . . . . . . . . . . . . . . . . . . . . 17 5.10 ユニークな命名. . . . . . . . . . . . . . . . . . . . . . 18 5.11アクセサリー . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.12 マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . . 20
Partridge and Kastenholz [Page 1] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[1ページ]RFC1726IPng
5.13 Extensibility . . . . . . . . . . . . . . . . . . . . . . 21
5.13.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.3 Data Structures . . . . . . . . . . . . . . . . . . . . . 22
5.13.4 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.14 Network Service . . . . . . . . . . . . . . . . . . . . . 22
5.15 Support for Mobility. . . . . . . . . . . . . . . . . . . 24
5.16 Control Protocol. . . . . . . . . . . . . . . . . . . . . 25
5.17 Private Networks. . . . . . . . . . . . . . . . . . . . . 25
6. Things We Chose Not to Require. . . . . . . . . . . . . . 26
6.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26
6.2 IP Header Checksum. . . . . . . . . . . . . . . . . . . . 26
6.3 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4 Network Management. . . . . . . . . . . . . . . . . . . . 27
6.5 Accounting. . . . . . . . . . . . . . . . . . . . . . . . 27
6.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.6.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.2 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.3 QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.4 Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.5 Stability . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.6 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . 30
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 30
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . 31
5.13 伸展性. . . . . . . . . . . . . . . . . . . . . . 21 5.13.1のアルゴリズム22 5.13…………………….2個のヘッダー. . . . . . . . . . . . . . . . . . . . . . . . . 22 5.13.3のデータ構造. . . . . . . . . . . . . . . . . . . . . 22 5.13.4のパケット. . . . . . . . . . . . . . . . . . . . . . . . . 22 5.14が移動性のサービス. . . . . . . . . . . . . . . . . . . . . 22 5.15サポートをネットワークでつなぎます。 . . . . . . . . . . . . . . . . . . 24 5.16はプロトコルを制御します。 . . . . . . . . . . . . . . . . . . . . 25 5.17 私設のネットワーク。 . . . . . . . . . . . . . . . . . . . . 25 6. 私たちが必要でないことを選んだもの。 . . . . . . . . . . . . . 26 6.1 断片化. . . . . . . . . . . . . . . . . . . . . . 26 6.2IPヘッダーチェックサム。 . . . . . . . . . . . . . . . . . . . 26 6.3個のファイアウォール. . . . . . . . . . . . . . . . . . . . . . . . 27 6.4のネットワークマネージメント。 . . . . . . . . . . . . . . . . . . . 27 6.5 会計。 . . . . . . . . . . . . . . . . . . . . . . . 27 6.6 ルート設定. . . . . . . . . . . . . . . . . . . . . . . . . 27 6.6.1スケール. . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.6.2方針。 . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.6 .3QOS. . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.6.4フィードバック。 . . . . . . . . . . . . . . . . . . . . . . . . 28 6.6 .5 安定性. . . . . . . . . . . . . . . . . . . . . . . . 28 6.6.6マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . . 29 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . 29 8。 セキュリティ問題. . . . . . . . . . . . . . . . . 30 9。 承認。 . . . . . . . . . . . . . . . . . . . . 30 10. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . 31
1. Introduction
1. 序論
This version of this memo was commissioned by the IPng area of the IETF in order to define a set of criteria to be used in evaluating the protocols being proposed for adoption as the next generation of IP.
このメモのこのバージョンは、採用のためにIPの次世代として提案されるプロトコルを評価する際に使用されるために1セットの評価基準を定義するためにIETFのIPng領域によって任命されました。
The criteria presented here were culled from several sources, including "IP Version 7" [1], "IESG Deliberations on Routing and Addressing" [2], "Towards the Future Internet Architecture" [3], the IPng Requirements BOF held at the Washington D.C. IETF Meeting in December of 1992, the IPng Working Group meeting at the Seattle IETF meeting in March 1994, the discussions held on the Big-Internet mailing list (big-internet@munnari.oz.au, send requests to join to big-internet-request@munnari.oz.au), discussions with the IPng Area Directors and Directorate, and the mailing lists devoted to the individual IPng efforts.
ここに提示された評価基準はいくつかのソースから選別されて、含んでいる「IPバージョン7インチ1、「ルート設定とアドレシングにおけるIESG熟考」2、「今後のインターネット建築」3、IPng Requirements BOFはワシントンDCで成立しました」でした; 1992年12月のIETF Meeting、1994年3月のシアトルのIETFミーティングにおけるIPng作業部会のミーティング、議論はBig-インターネットメーリングリスト( big-internet@munnari.oz.au 、 big-internet-request@munnari.oz.au につなぐという要求を送る)、IPng AreaディレクターとDirectorateとの議論、および個々のIPngの努力にささげられたメーリングリストで成立しました。
This document presumes that a new IP-layer protocol is actually desired. There is some discussion in the community as to whether we can extend the life of IPv4 for a significant amount of time by
このドキュメントは、新しいIP-層のプロトコルが実際に望まれていると推定します。 私たちが重要な時間IPv4の人生を伸ばすことができるかどうかに関して何らかの議論が共同体にあります。
Partridge and Kastenholz [Page 2] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[2ページ]RFC1726IPng
better engineering of, e.g., routing protocols, or we should develop IPng now. This question is not addressed in this document.
例えば、ルーティング・プロトコル、または私たちは開発するべきです。設計するほうがよい、今、IPngを開発してください。 この質問は本書では記述されません。
We would like to gratefully acknowledge the assistance of literally hundreds of people who shared their views and insights with us. However, this memo is solely the personal opinion of the authors and in no way represents, nor should it be construed as representing, the opinion of the ISOC, the IAB, the IRTF, the IESG, the IETF, the Internet community as a whole, nor the authors' respective employers.
感謝して文字通り彼らの視点と洞察を私たちと共有した何百人もの人々の支援を承諾したいと思います。 しかしながら、このメモが唯一決して作者の個人的な見解でない、表す、また、表すISOC、IAB、IRTF、IESG、IETF、全体でインターネットコミュニティ、および作者のそれぞれの雇い主の意見にそれを理解するべきではありません。
2. Goals
2. 目標
We believe that by developing a list of criteria for evaluating proposals for IP The Next Generation (IPng), the IETF will make it easier for developers of proposals to prioritize their work and efforts and make reasoned choices as to where they should spend relatively more and less time. Furthermore, a list of criteria may help the IETF community determine which proposals are serious contenders for a next generation IP, and which proposals are insufficient to the task. Note that these criteria are probably not sufficient to make final decisions about which proposal is best. Questions such as whether to trade a little performance (e.g., packets per second routed) for slightly more functionality (e.g., more flexible routing) cannot be easily addressed by a simple list of criteria. However, at minimum, we believe that protocols that meet these criteria are capable of serving as the future IPng.
私たちは、IETFがIP Next Generation(IPng)のために提案を評価する評価基準のリストを開発することによって、提案がそれらが比較的多く、より少ない時間を過ごすべきであるところに関して彼らの仕事と努力を最優先させて、推論された選択をするのを開発者には、より簡単にすると信じています。 その上、評価基準のリストは、IETF共同体が、IP、およびそれの提案がタスクに不十分である次世代のためにどの提案が真剣な競争者であるかを決定するのを助けるかもしれません。 これらの評価基準が提案が最も良い最終決定をするようにたぶん十分でないことに注意してください。 評価基準に関する単純並びは容易にわずかに多くの機能性(例えば、よりフレキシブルなルーティング)のために、少しの性能(例えば1秒あたりのパケットは掘られた)を交えなどかどうかなどの質問を記述できません。 しかしながら、最小限で、私たちは、これらの評価基準を満たすプロトコルが将来のIPngとして機能できると信じています。
This set of criteria originally began as an ordered list, with the goal of ranking the importance of various criteria. Eventually, the layout evolved into the current form, where each criterion was presented without weighting, but a time frame, indicating approximately when a specific criterion, or feature of a criterion, should be available was added to the specification.
このセットの評価基準は元々、様々な評価基準の重要性を格付けするという目標のために規則正しいリストとして始まりました。 結局、各評価基準が重さなしで提示されたところで現在のフォームに発展されたレイアウトにもかかわらず、時間枠、特定の評価基準、または評価基準の特徴がいつ頃に利用可能であるべきであるかを示すのが仕様に追加されました。
We have attempted to state the criteria in the form of goals or requirements and not demand specific engineering solutions. For example, there has been talk in the community of making route aggregation a requirement. We believe that route aggregation is not, in and of itself, a requirement but rather one part of a solution to the real problem of scaling to some very large, complex topology. Therefore, route aggregation is NOT listed as a requirement; instead, the more general functional goal of having the routing scale is listed instead of the particular mechanism of route aggregation.
私たちは、目標か要件の形に評価基準を述べて、特定のエンジニアリング解を要求しないのを試みました。 例えば、話がルート集合を要件にする共同体にありました。 私たちは、ルート集合がそういうものとして要件にもかかわらず、むしろいくらかの非常に大きくて、複雑なトポロジーに比例する実際の問題の解決の一部でないと信じています。 したがって、ルート集合は要件として記載されていません。 代わりに、ルーティングスケールを持っているというより一般的な機能的な目標はルート集合の特定のメカニズムの代わりに記載されています。
In determining the relative timing of the various criteria, we have had two guiding principles. First, IPng must offer an internetwork service akin to that of IPv4, but improved to handle the well-known and widely-understood problems of scaling the Internet architecture
様々な評価基準の相対的なタイミングを決定する際に、私たちは2つの指導原理を持っていました。 まず最初に、IPngは、インターネット構造をスケーリングするという周知の、そして、広く理解されている問題を扱うためにIPv4のものと同系で、しかし、改良されていた状態で相互ネットワーク・サービスを提供しなければなりません。
Partridge and Kastenholz [Page 3] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[3ページ]RFC1726IPng
to more end-points and an ever increasing range of bandwidths. Second, it must be desirable for users and network managers to upgrade their equipment to support IPng. At a minimum, this second point implies that there must be a straightforward way to transition systems from IPv4 to IPng. But it also strongly suggests that IPng should offer features that IPv4 does not; new features provide a motivation to deploy IPng more quickly.
より多くのエンドポイントと増加し続けている範囲の帯域幅に。 2番目に、ユーザとネットワークマネージャがIPngを支持するためにそれらの設備をアップグレードさせるのは、望ましくなければなりません。 最小限では、この2番目のポイントは、IPv4からIPngまで変遷システムへの簡単な道があるに違いないのを含意します。 しかし、また、強く、IPngがIPv4が提供しない特徴を提供するはずであると示唆します。 新機能は、よりはやくIPngを配備する動機を提供します。
3. Note on Terminology
3. 用語に関する注
The existing proposals tend distinguish between end-point identification of, e.g., individual hosts, and topological addresses of network attachment points. In this memo we do not make that distinction. We use the term "address" as it is currently used in IPv4; i.e., for both the identification of a particular endpoint or host AND as the topological address of a point on the network. We presume that if the endpoint/ address split remains, the proposals will make the proper distinctions with respect to the criteria enumerated below.
既存の提案は傾向がある、エンドポイント識別の間で区別する、例えば、個々のホスト、およびネットワーク付着点の位相的なアドレス。 このメモでは、私たちはそれを区別にしません。 それが現在IPv4で使用されるとき、私たちは「アドレス」という用語を使用します。 すなわち、特定の終点かホストの両方の識別と、そして、ネットワークのポイントの位相的なアドレスとして。 私たちは、提案が終点/アドレス分裂が残っていると、以下に列挙された評価基準に関して適切な区別をすると推定します。
4. General Principles
4. 綱領
4.1 Architectural Simplicity
4.1 建築簡単さ
In anything at all, perfection is finally attained not
when there is no longer anything to add, but when there
is no longer anything to take away.
とにかく何においてでも、何も持ち去るものがもうないとき、完全性に加えることがもうあるとき、達するのではなく、最終的に達します。
Antoine de Saint-Exupery
アントワーヌ・ド・サン=テグジュペリ
We believe that many communications functions are more appropriately performed at protocol layers other than the IP layer. We see protocol stacks as hourglass-shaped, with IPng in the middle, or waist, of the hourglass. As such, essentially all higher-layer protocols make use of and rely upon IPng. Similarly IPng, by virtue of its position in the "protocol hourglass" encompasses a wide variety of lower-layer protocols. When IPng does not perform a particular function or provide a certain service, it should not get in the way of the other elements of the protocol stack which may well wish to perform the function.
私たちは、多くのコミュニケーション機能がIP層以外のプロトコル層で、より適切に実行されると信じています。 私たちは、プロトコル・スタックがIPngと共に砂時計の中央、またはウエストに砂時計の形をしているとみなします。 そういうものと、本質的にはすべての上位層プロトコルが、IPngを利用して、当てにされます。 IPng、同様に、中の位置による、「プロトコル砂時計」はさまざまな下位層プロトコルを包含します。 IPngが特定の機能を実行もしませんし、あるサービスを提供もしないと、それはたぶん機能を実行したがっているだろうプロトコル・スタックの他の要素の邪魔をするべきではありません。
4.2 One Protocol to Bind Them All
4.2 それらを皆、縛る1つのプロトコル
One of the most important aspects of The Internet is that it provides global IP-layer connectivity. The IP layer provides the point of commonality among all of the nodes on the Internet. In effect, the main goal of the Internet is to provide an IP Connectivity Service to all who wish it.
インターネットの最も重要な局面の1つはグローバルなIP-層の接続性を提供するということです。 IP層はインターネットのノードのすべてに共通点のポイントを提供します。 事実上、インターネットの第一目的はそれを願っているすべてにIP Connectivity Serviceを提供することになっています。
Partridge and Kastenholz [Page 4] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[4ページ]RFC1726IPng
This does NOT say that the Internet is a One-Protocol Internet. The Internet is today, and shall remain in the future, a Multi-Protocol Internet. Multi-Protocol operations are required to allow for continued testing, experimentation, and development and because service providers' customers clearly want to be able to run protocols such as CLNP, DECNET, and Novell over their Internet connections.
これは、インターネットがOne-プロトコルインターネットであると言いません。 インターネットは、今日であり、未来、Multi-プロトコルインターネットに残っているものとします。 マルチプロトコル操作は継続的なテスト、実験、および開発を考慮するのが必要であり、サービスプロバイダーの顧客が明確に彼らのインターネット接続の上でCLNPや、DECNETや、ノベルなどのプロトコルを走らせることができるようになりたがっているからです。
4.3 Live Long
4.3は長い間、生きています。
It is very difficult to change a protocol as central to the workings of the Internet as IP. Even more problematic is changing such a protocol frequently. This simply can not be done. We believe that it is impossible to expect the community to make significant, non- backward compatible changes to the IP layer more often than once every 10-15 years. In order to be conservative, we strongly urge protocol developers to consider what the Internet will look like in 20 years and design their protocols to fit that vision.
IPとしてインターネットの作業に主要であるとしてのプロトコルを変えるのは非常に難しいです。 さらに問題が多いのは、頻繁にそのようなプロトコルを変えることです。 これが絶対にできません。 私たちは、それはIPへの重要で、非後方のコンパチブル変更を行う共同体が一度あらゆる10-15よりしばしば層にされると予想するのが年間不可能であると信じています。 保守的になるように、私たちはインターネットが20年間で何に似るかを考えて、そのビジョンに合うように彼らのプロトコルを設計するよう強くプロトコル開発者に促します。
As a data point, the SNMP community has had great difficulty moving from SNMPv1 to SNMPv2. Frequent changes in software are hard.
データポイントとして、SNMP共同体はSNMPv1からSNMPv2まで動くことにおける重大な苦労をしました。 ソフトウェアにおける頻繁な変化は固いです。
4.4 Live Long AND Prosper
4.4は、長い間生きていて、繁栄しています。
We believe that simply allowing for bigger addresses and more efficient routing is not enough of a benefit to encourage vendors, service providers, and users to switch to IPng, with its attendant disruptions of service, etc. These problems can be solved much more simply with faster routers, balkanization of the Internet address space, and other hacks.
私たちは、単により大きいアドレスと、より効率的なルーティングを考慮するのが業者、サービスプロバイダー、およびユーザがIPngに切り換えるよう奨励する利益に十分でないと信じています、サービスなどの付き添いの分裂で インターネットアドレス空間、および他のハッキングについてはるかに単により速いルータ、小国分割でこれらの問題を解決できます。
We believe that there must be positive functional or operational benefits to switching to IPng.
私たちは、IPngに切り替わることへの上向きの機能的であるか操作上の利益があるに違いないと信じています。
In other words, IPng must be able to live for a long time AND it must allow the Internet to prosper and to grow to serve new applications and user needs.
インターネットは、それによって、言い換えれば、IPngが長い間、生きることができなければならなくて、繁栄して、新しいアプリケーションとユーザの必要性に役立つようにならなければなりません。
4.5 Co-operative Anarchy
4.5 協力的なアナーキー
A major contributor to the Internet's success is the fact that there is no single, centralized, point of control or promulgator of policy for the entire network. This allows individual constituents of the network to tailor their own networks, environments, and policies to suit their own needs. The individual constituents must cooperate only to the degree necessary to ensure that they interoperate.
インターネットの成功への一流の貢献者は全体のネットワークのための方針のコントロールか公布者の単一の、そして、集結されたポイントが全くないという事実です。 これで、ネットワークの個々の構成要素は、それら自身の必要性に合うようにそれら自身のネットワーク、環境、および方針を合わせることができます。 個々の成分は彼らが共同利用するのを保証するのに必要な程度だけに協力しなければなりません。
Partridge and Kastenholz [Page 5] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[5ページ]RFC1726IPng
We believe that this decentralized and decoupled nature of the Internet must be preserved. Only a minimum amount of centralization or forced cooperation will be tolerated by the community as a whole.
私たちは、これが分散したと信じています、そして、衝撃を吸収されたインターネットの性質を保持しなければなりません。 最小の量の中央集権化か無理矢理の協力だけが全体で共同体によって許容されるでしょう。
We also believe that there are some tangible benefits to this decoupled nature. For example,
また、私たちは、この衝撃を吸収された自然へのいくつかの明白な利点があると信じています。 例えば
* It is easier to experiment with new protocols and services and then
roll out intermediate and final results in a controlled fashion.
* By eliminating a single point of control, a single point of failure
is also eliminated, making it much less likely that the entire
network will fail.
* It allows the administrative tasks for the network to be more
widely distributed.
* 新しいプロトコルとサービスを実験して、次に、管理された方法で中間的で最終的な結果を発表するのは、より簡単です。 * また、1ポイントのコントロールを排除することによって、1ポイントの失敗は排除されます、全体のネットワークが行き詰まるのをはるかにありそうでなくして。 * それは、ネットワークが、より広く分配されるために管理業務を許容します。
An example of the benefits of this "Cooperative Anarchy" can be seen in the benefits derived from using the Domain Naming System over the original HOSTS.TXT system.
オリジナルのHOSTS.TXTシステムの上でDomain Naming Systemを使用するのから得られた利益でこの「協力的なアナーキー」の利益に関する例を見ることができます。
5. Criteria
5. 評価基準
This section enumerates the criteria against which we suggest the IP The Next Generation proposals be evaluated.
このセクションが私たちがIP Next Generationを勧める評価基準を列挙する、提案、評価されてください。
Each criterion is presented in its own section. The first paragraph of each section is a short, one or two sentence statement of the criterion. Additional paragraphs then explain the criterion in more detail, clarify what it does and does not say and provide some indication of its relative importance.
各評価基準はそれ自身のセクションに示されます。 それぞれのセクションの第一節は評価基準の短い1か2文の声明です。 追加パラグラフは、次に、さらに詳細に評価基準について説明して、それが何をして、示さないかをはっきりさせて、いくつかの相対的に重要なしるしを供給します。
Also, each criterion includes a subsection called "Time Frame". This is intended to give a rough indication of when the authors believe that the particular criterion will become "important". We believe that if an element of technology is significant enough to include in this document then we probably understand the technology enough to predict how important that technology will be. In general, these time frames indicate that, within the desired time frame, we should be able to get an understanding of how the feature will be added to a protocol, perhaps after discussions with the engineers doing the development. Time Frame is not a deployment schedule since deployment schedules depend on non-technical issues, such as vendors determining whether a market exists, users fitting new releases into their systems, and so on.
また、各評価基準は「時間枠」と呼ばれる小区分を含んでいます。 これが作者が特定の評価基準が「重要に」なると信じている時の荒いしるしを与えることを意図します。 私たちは、技術の要素が本書では含むことができるくらいかなりならその技術がどれくらい重要になるかを予測できるくらいたぶん技術を理解していると信じています。 一般に、これらの時間枠は、私たちが必要な時間枠の中で特徴がどうプロトコルに追加されるかに関する理解を得ることができるはずであるのを示します、恐らく開発する技術者との議論の後に。 展開スケジュールが非技術系の問題によるので、時間Frameは展開スケジュールではありません、市場が存在するかどうかと決心している業者、それらのシステムに新版に合うユーザなどなどのように。
Partridge and Kastenholz [Page 6] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[6ページ]RFC1726IPng
5.1 Scale
5.1 スケール
CRITERION
The IPng Protocol must scale to allow the identification and
addressing of at least 10**12 end systems (and preferably much
more). The IPng Protocol, and its associated routing protocols
and architecture must allow for at least 10**9 individual networks
(and preferably more). The routing schemes must scale at a rate
that is less than the square root of the number of constituent
networks [10].
CRITERION IPngプロトコルは、少なくとも10**12エンドシステム(望ましくははるかに)の識別とアドレシングを許容するために比例しなければなりません。 プロトコルと構造が少なくとも10**9個々のネットワーク(望ましくはさらに)のために許さなければならないIPngプロトコル、およびその関連ルーティング。 ルーティング計画は構成しているネットワーク[10]の数の平方根より少ない速度で比例しなければなりません。
DISCUSSION
The initial, motivating, purpose of the IPng effort is to allow
the Internet to grow beyond the size constraints imposed by the
current IPv4 addressing and routing technologies.
インターネットがIPngの努力の初期の、そして、動機づけている目的でサイズ規制を超えて育てることになっていることができるDISCUSSIONは現在のIPv4アドレシングとルーティング技術ででしゃばりました。
Both aspects of scaling are important. If we can't route then
connecting all these hosts is worthless, but without connected
hosts, there's no point in routing, so we must scale in both
directions.
スケーリングの両方の局面は重要です。 私たちがその時を発送できないなら、これらのすべてのホストに接するのは価値がないのですが、接続ホスト、ルーティングにはポイントが全くないので、私たちは両方の指示を計量しなければなりません。
In any proposal, particular attention must be paid to describing
the routing hierarchy, how the routing and addressing will be
organized, how different layers of the routing interact, and the
relationship between addressing and routing.
どんな提案でも、アドレシングとルーティングとのルーティング階層構造、ルーティングとアドレシングがどう組織化されるだろうか、そして、ルーティングの異なった層がどう相互作用するか、そして、および関係について説明するのに特別の注意を向けなければなりません。
Particular attention must be paid to describing what happens when
the size of the network approaches these limits. How are network,
forwarding, and routing performance affected? Does performance
fall off or does the network simply stop as the limit is neared.
ネットワークのサイズがこれらの限界にアプローチすると何が起こるかを説明するのに特別の注意を向けなければなりません。 ネットワーク、推進、およびルーティング性能はどのように影響を受けますか? 性能は落ちますか、限界が近づかれるとき、ネットワークが単に止まりますか?
This criterion is the essential problem motivating the transition
to IPng. If the proposed protocol does not satisfy this criteria,
there is no point in considering it.
この評価基準はIPngへの変遷を動機づけることにおいて主要問題です。 提案されたプロトコルがこれを満たさないなら、評価基準であり、それを考えるには意味が全くありません。
We note that one of the white papers solicited for the IPng
process [5] indicates that 10**12 end nodes is a reasonable
estimate based on the expected number of homes in the world and
adding two orders of magnitude for "safety". However, this white
paper treats each home in the world as an end-node of a world-wide
Internet. We believe that each home in the world will in fact be
a network of the world-wide Internet. Therefore, if we take [5]'s
derivation of 10**12 as accurate, and change their assumption that
a home will be an end-node to a home being a network, we may
expect that there will be the need to support at least 10**12
networks, with the possibility of supporting up to 10**15 end-
nodes.
私たちは、IPngの過程[5]が、10**12がノードを終わらせるのを示すので請求された白書の1つが世界の家の予想された数に基づいていて、「安全」のために2桁を加える合理的な見積りであることに注意します。 しかしながら、この白書は世界的なインターネットのエンドノードとして世界の各家を扱います。 私たちは、事実上、世界の各家が世界的なインターネットのネットワークになると信じています。 [5] したがって、私たちが取るなら、10**12の派生は同じくらい正確です、そして、家がエンドノードになるという彼らの仮定をネットワーク、私たちは少なくとも10**12ネットワークをサポートする必要があると予想するかもしれません、15の終わりのノードを10**までサポートする可能性でことである家に変えてください。
Partridge and Kastenholz [Page 7] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[7ページ]RFC1726IPng
Time Frame
Any IPng proposal should be able to show immediately that it has
an architecture for the needed routing protocols, addressing
schemes, abstraction techniques, algorithms, data structures, and
so on that can support growth to the required scales.
時間Frame Any IPng提案は、すぐにそれには必要なルーティング・プロトコルのための構造があるのを示すことができるべきです、必要なスケールへの成長を支持できる計画、抽象化のテクニック、アルゴリズム、データ構造などを記述して。
Actual development, specification, and deployment of the needed
protocols can be deferred until IPng deployment has extended far
enough to require such protocols. A proposed IPng should be able
to demonstrate ahead of time that it can scale as needed.
IPng展開がそのようなプロトコルを必要とすることができるくらい遠くに広がるまで、必要なプロトコルの実際の開発、仕様、および展開を延期できます。 提案されたIPngは、早めに、それが必要に応じて比例できるのを示すはずであることができます。
5.2 Topological Flexibility
5.2 位相的な柔軟性
CRITERION
The routing architecture and protocols of IPng must allow for many
different network topologies. The routing architecture and
protocols must not assume that the network's physical structure is
a tree.
IPngのルーティング構造とプロトコルが多くの異なったネットワークtopologiesのために許容しなければならないCRITERION。 ルーティング構造とプロトコルは、ネットワークの物理構造が木であると仮定してはいけません。
DISCUSSION
As the Internet becomes ever more global and ubiquitous, it will
develop new and different topologies. We already see cases where
the network hierarchy is very "broad" with many subnetworks, each
with only a few hosts and where it is very "narrow", with few
subnetworks each with many hosts. We can expect these and other
topological forms in the future. Furthermore, since we expect
that IPng will allow for many more levels of hierarchy than are
allowed under IPv4, we can expect very "tall" and very "short"
topologies as well.
DISCUSSION Asインターネットはかつて、よりグローバルで遍在するようになって、それは新しくて異なったtopologiesを開発するでしょう。 私たちは既に、ネットワーク階層構造が多くのサブネットワークと、それぞれほんの数人のホストと共に非常に「広く」、それが非常に「狭い」ケースを見ます、それぞれ多くのホストがいるわずかなサブネットワークで。 私たちは将来、これらと他のトポロジー型を予想できます。 その上、IPngがIPv4の下に許容されているよりずっと多くのレベルの階層構造を考慮すると予想して、私たちはまた、非常に「高く」て非常に「短い」topologiesを予想できます。
Constituent organizations of the Internet should be allowed to
structure their internal topologies in any manner they see fit.
Within reasonable implementation limits, organizations should be
allowed to structure their addressing in any manner. We
specifically wish to point out that if the network's topology or
addressing is hierarchical, constituent organizations should be
able to allocate to themselves as many levels of hierarchy as they
wish.
インターネットの構成している組織はどんな方法でも彼らが適していると決める自分達の内部のtopologiesを構造化できるべきです。 妥当な実現限界の中では、組織はどんな方法でもそれらのアドレシングを構造化できるべきです。 それがネットワークのトポロジーかアドレシングが階層的で、構成している組織であるなら願っているように同じくらい多くのレベルの階層構造を自分たちに割り当てることができるべきであると明確に指摘したいと思います。
It is very possible that the diameter of the Internet will grow to
be extremely large; perhaps larger than 256 hops.
インターネットの直径が成長して、非常に大きくなるのは非常に可能です。 恐らく256のホップより大きいです。
Neither the current, nor the future, Internet will be physically
structured as a tree, nor can we assume that connectivity can
occur only between certain points in the graph. The routing and
addressing architectures must allow for multiply connected
networks and be able to utilize multiple paths for any reason,
including redundancy, load sharing, type- and quality-of-service
どちらも電流か未来、インターネットは木として物理的に構造化されるでしょう、そして、私たちは接続性がグラフに、ある一定のポイントだけの間に現れることができると思うことができません。 ルーティングとアドレッシング体系は、多重連結のネットワークを考慮して、どんな理由にも複数の経路を利用できなければなりません、冗長、負荷分割法、タイプ、およびサービスの質を含んでいて
Partridge and Kastenholz [Page 8] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[8ページ]RFC1726IPng
differentiation.
分化。
Time Frame
We believe that Topological Flexibility is an inherent element of
a protocol and therefore should be immediately demonstrable in an
IPng proposal.
時間Frame WeはTopological Flexibilityがプロトコルの固有の原理であり、したがって、すぐにIPng提案で明白であるべきであると信じています。
5.3 Performance
5.3 パフォーマンス
CRITERION
A state of the art, commercial grade router must be able to
process and forward IPng traffic at speeds capable of fully
utilizing common, commercially available, high-speed media at the
time. Furthermore, at a minimum, a host must be able to achieve
data transfer rates with IPng comparable to the rates achieved
with IPv4, using similar levels of host resources.
CRITERIONのA最先端の、そして、商業のグレードルータは当時一般的で、商業的に利用可能で、高速なメディアを完全に利用できる速度での過程と前進のIPng交通にできるに違いありません。 その上、最小限では、ホストはIPv4と共に達成されたレートに匹敵するIPngと共にデータ転送速度を達成できなければなりません、同じ水準に関するホストリソースを使用して。
DISCUSSION
Network media speeds are constantly increasing. It is essential
that the Internet's switching elements (routers) be able to keep
up with the media speeds.
DISCUSSION Networkメディア速度は絶えず上がっています。 インターネットのスイッチング素子(ルータ)がメディア速度について行くことができるのは、不可欠です。
We limit this requirement to commercially available routers and
media. If some network site can obtain a particular media
technology "off the shelf", then it should also be able to obtain
the needed routing technology "off the shelf." One can always go
into some laboratory or research center and find newer, faster,
technologies for network media and for routing. We do believe,
however, that IPng should be routable at a speed sufficient to
fully utilize the fastest available media, though that might
require specially built, custom, devices.
私たちはこの要件を商業的に利用可能なルータとメディアに制限します。 また、何らかのネットワークサイトが特定のメディア技術「すぐ入手できること」を得ることができるなら、必要なルーティング技術「すぐ入手できること」を得ることができるべきです。 人は、いつもある実験室かリサーチセンターに入って、ネットワークメディアとルーティングに関して、より新しくて、より速い技術を見つけることができます。 しかしながら、私たちは、IPngが最も速い利用可能なメディアを完全に利用できるくらいの速度で発送可能であるはずであると信じています、それが特に組立の、そして、カスタムの装置を必要とするかもしれませんが。
We expect that more and more services will be available over the
Internet. It is not unreasonable, therefore, to expect that the
ratio of "local" traffic (i.e., the traffic that stays on one's
local network) to "export" traffic (i.e., traffic destined to or
sourced from a network other than one's own local network) will
change, and the percent of export traffic will increase.
私たちは、ますます多くのサービスがインターネットの上で利用可能になると予想します。 したがって、「地方」の交通(すなわち、人の企業内情報通信網に残っている交通)対「輸出」交通(すなわち、企業内情報通信網が運命づけられているか、または自分自身のを除いたネットワークから出典を明示された交通)の比率が変化して、輸出交通のパーセントが増加すると予想するのは無理ではありません。
We note that the host performance requirement should not be taken
to imply that IPng need only be as good as IPv4. If an IPng
candidate can achieve better performance with equivalent resources
(or equivalent transfer rates with fewer resources) vis-a-vis IPv4
then so much the better. We also observe that many researchers
believe that a proper IPng router should be capable of routing
IPng traffic over links at speeds that are capable of fully
utilizing an ATM switch on the link.
私たちは、ホスト性能要件がIPngがIPv4と同じくらい良いだけでよいのを含意するために取られるべきでないことに注意します。 次に、IPv4と向かいあった同等なリソース(または、より少ないリソースがある同等な転送レート)が尚更良い状態でIPng候補が、より良い性能を実現できるなら。 また、私たちは、多くの研究者が、適切なIPngルータがリンクの上のATMスイッチを完全に利用できる速度がリンクの上のルーティングIPng交通ができるべきであると信じているのを観測します。
Partridge and Kastenholz [Page 9] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[9ページ]RFC1726IPng
Some developments indicate that the use of very high speed point-
to-point connections may become commonplace. In particular, [5]
indicates that OC-3 speeds may be widely used in the Cable TV
Industry and there may be many OC-3 speed lines connecting to
central switching elements.
いくつかの開発が、非常に高い速度ポイントポイントとの接続の使用が平凡になるかもしれないのを示します。 特に、[5]は、OC-3速度がケーブルTV Industryで広く使用されるかもしれないのを示します、そして、主要なスイッチング素子に接続する多くのOC-3速度回線があるかもしれません。
Processing of the IPng header, and subsequent headers (such as the
transport header), can be made more efficient by aligning fields
on their natural boundaries and making header lengths integral
multiples of typical word lengths (32, 64, and 128 bits have been
suggested) in order to preserve alignment in following headers.
IPngヘッダー、およびヘッダーに続く際に整列を保存するためにそれらの固有の境界で分野を並べることによって、より効率的に作ることができて、ヘッダ長を典型的な語長(32、64、および128ビットは示された)の整数倍にするその後のヘッダー(輸送ヘッダーなどの)の処理。
We point out that optimizing the header's fields and lengths only
to today's processors may not be sufficient for the long term.
Processor word and cache-line lengths, and memory widths are
constantly increasing. In doing header optimizations, the
designer should predict word-widths one or two CPU generations
into the future and optimize accordingly. If IPv4 and TCP had been
optimized for processors common when they were designed, they
would be very efficient for 6502s and Z-80s.
私たちは、ヘッダーの分野と長さを今日のプロセッサだけに最適化するのが長期の間十分でないかもしれないと指摘します。 プロセッサ単語、キャッシュ行長、および幅が絶えず増加させているメモリ。 ヘッダーに最適化をする際に、デザイナーは、単語幅をCPU1世代か2世代未来まで予測して、それに従って、最適化するべきです。 それらが設計されたとき、IPv4とTCPがプロセッサのために一般的に最適化されたなら、6502年代とZ80-年代に、それらは非常に効率的でしょう。
Time Frame
An IPng proposal must provide a plausible argument of how it will
scale up in performance. (Obviously no one can completely predict
the future, but the idea is to illustrate that if technology
trends in processor performance and memory performance continue,
and perhaps using techniques like parallelism, there is reason to
believe the proposed IPng will scale as technology scales).
時間Frame An IPng提案は性能でどう拡大するかに関するもっともらしい議論を提供しなければなりません。 (明らかに、だれでも完全に未来について予言できるというわけではありませんが、考えがプロセッサ性能とメモリ性能における技術動向が続くならそれを例証することであり、恐らく平行関係のようなテクニックを使用して、技術が比例するとき提案されたIPngが比例すると信じる理由があります。)
5.4 Robust Service
5.4 体力を要しているサービス
CRITERION
The network service and its associated routing and control
protocols must be robust.
CRITERION、そのネットワーク・サービス、関連ルーティング、および制御プロトコルは体力を要するに違いありません。
DISCUSSION
Murphy's Law applies to networking. Any proposed IPng protocol
must be well-behaved in the face of malformed packets, mis-
information, and occasional failures of links, routers and hosts.
IPng should perform gracefully in response to willful management
and configuration mistakes (i.e., service outages should be
minimized).
DISCUSSIONマーフィーの法則はネットワークに適用されます。 どんな提案されたIPngプロトコルも誤った形式のパケット、誤情報、リンクの時々の失敗、ルータ、およびホストに直面して品行方正であるに違いありません。 IPngは優雅に意図的な管理と構成誤りに対応して働くはずです(すなわち、サービス供給停止は最小にされるべきです)。
Putting this requirement another way, IPng must make it possible
to continue the Internet tradition of being conservative in what
is sent, but liberal in what one is willing to receive.
この要件別の方法を置いて、IPngは送られるもので保守的ですが、受けても構われない1が思っているもので寛容であることのインターネット伝統を続けているのを可能にしなければなりません。
Partridge and Kastenholz [Page 10] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[10ページ]RFC1726IPng
We note that IPv4 is reasonably robust and any proposed IPng must
be at least as robust as IPv4.
私たちが、IPv4が合理的に強健であることに注意して、どんな提案されたIPngもIPv4と少なくとも同じくらい強健であるに違いありません。
Hostile attacks on the network layer and Byzantine failure modes
must be dealt with in a safe and graceful manner.
安全で優雅な方法でネットワーク層と込み入った故障モードに対する敵対的な攻撃に対処しなければなりません。
We note that Robust Service is, in some form, a part of security
and vice-versa.
私たちは、Robust Serviceが何らかのフォームのセキュリティの一部であることに注意します、そして、逆もまた同様です。
The detrimental effects of failures, errors, buggy
implementations, and misconfigurations must be localized as much
as possible. For example, misconfiguring a workstation's IP
Address should not break the routing protocols. in the event of
misconfigurations, IPng must to be able to detect and at least
warn, if not work around, any misconfigurations.
失敗、誤り、バギーの実現、およびmisconfigurationsの有害な影響をできるだけ局部にとどめなければなりません。 例えば、ワークステーションのIP Addressをmisconfiguringする場合、ルーティング・プロトコルは破られるべきではありません。misconfigurations、できるIPng必須の場合、あらゆるmisconfigurationsにおよそ仕事でないなら検出して、少なくとも、警告してください。
Due to its size, complexity, decentralized administration, error-
prone users and administrators, and so on, The Internet is a very
hostile environment. If a protocol can not be used in such a
hostile environment then it is not suitable for use in the
Internet.
サイズ、複雑さ、分散管理、誤りの傾向があるユーザ、管理者などのために、インターネットは非常に敵対的な環境です。 そのような敵対的環境にプロトコルを使用できないなら、インターネットでの使用に適していません。
Some predictions have been made that, as the Internet grows and as
more and more technically less-sophisticated sites get connected,
there will be more failures in the network. These failures may be
a combination of simple size; if the size of the network goes up
by a factor of n, then the total number of failures in the network
can be expected to increase by some function of n. Also, as the
network's users become less sophisticated, it can be assumed that
they will make more, innocent and well meaning, mistakes, either
in configuration or use of their systems.
インターネットが発展して、ますます多くの技術的に精巧でないサイトが接続されるので、ネットワークには、より多くの失敗があるといういくつかの予測をしました。 これらの失敗は簡単なサイズの組み合わせであるかもしれません。 ネットワークのサイズがnの要素で上がるなら、ネットワークにおける、失敗の総数がnの何らかの機能で増加すると予想できます。 また、ネットワークのユーザが、より洗練されないようになるとき、彼らが、より多くて、潔白で善意の誤りをすると思うことができます、それらのシステムを構成か使用で。
The IPng protocols should be able to continue operating in an
environment that suffers more, total, outages than we are
currently used to. Similarly, the protocols must protect the
general population from errors (either of omission or commission)
made by individual users and sites.
IPngプロトコルは、私たちが現在使用されているよりさらに多くて、総供給停止を受ける環境で作動し続けることができるべきです。 同様に、プロトコルは個々のユーザとサイトによってされた誤り(省略かコミッションの)から一般住民を保護しなければなりません。
Time Frame
We believe that the elements of Robust Service should be available
immediately in the protocol with two exceptions.
時間Frame Weは、Robust Serviceの要素が2つの例外ですぐプロトコルで有効であるべきであると信じています。
The security aspects of Robust Service are, in fact, described
elsewhere in this document.
事実上、Robust Serviceのセキュリティ局面はほかの場所で本書では説明されます。
Partridge and Kastenholz [Page 11] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[11ページ]RFC1726IPng
Protection against Byzantine failure modes is not needed
immediately. A proposed architecture for it should be done
immediately. Prototype development should be completed in 12-18
months, with final deployment as needed.
込み入った故障モードに対する保護はすぐに、必要ではありません。 すぐに、それのための提案された構造をするべきです。 原型開発は12-18カ月後に必要に応じて最終的な展開で終了するべきです。
5.5 Transition
5.5 変遷
CRITERION
The protocol must have a straightforward transition plan from the
current IPv4.
CRITERION、プロトコルには、現在のIPv4からの簡単な変遷プランがなければなりません。
DISCUSSION
A smooth, orderly, transition from IPv4 to IPng is needed. If we
can't transition to the new protocol, then no matter how wonderful
it is, we'll never get to it.
IPv4からIPngまでのDISCUSSIONのA滑らかで、規則的な変遷が必要です。 私たちであるなら、新しさへの変遷は議定書を作ることができないで、それがどんなに素晴らしくても、次に、私たちはそれを決して始めるつもりではありません。
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
私たちは、すべてのホストとルータがすぐに切り替わらなければならない変遷の「旗の日」フォームを持っているのが可能でないと信じています。 インターネットのサイズ、複雑さ、および分散型管理はそのようなカットオーバを不可能にします。
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
むしろ、IPngは、いつかの期間の間、IPv4と共存する必要があるでしょう。 ホストが2つのスタックを支えるのが必要であることなどのこの共存を達成する多くの方法があります、プロトコルの間で変換するか、または後方のコンパチブル拡張子をIPv4に使用して。 各体系には、その長所と短所があります。(短所は重さがなければなりません)。
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
その上、私たちは、IPv4ホストがいつまでもインターネットにきっと有効にいることに注意します。IPngはこれらのホストがコミュニケートするのを許容するメカニズムを提供しなければなりません、IPngがインターネットで優位なネットワーク層プロトコルになった後にさえ。
The absence of a rational and well-defined transition plan is not
acceptable. Indeed, the difficulty of running a network that is
transitioning from IPv4 to IPng must be minimized. (A good target
is that running a mixed IPv4-IPng network should be no more and
preferably less difficult than running IPv4 in parallel with
existing non-IP protocols).
合理的で明確な変遷プランの欠如は許容できません。 本当に、IPv4からIPngに移行しているネットワークを経営しているという困難を最小にしなければなりません。 (良い目標はもう、そして、望ましくは、複雑なIPv4-IPngネットワークを経営しているのが既存の非IPプロトコルと平行してIPv4を実行するより難しいはずがないということです。)
Furthermore, a network in transition must still be robust. IPng
schemes which maximize stability and connectivity in mixed IPv4-
IPng networks are preferred.
その上、変遷におけるネットワークはまだ強健でなければなりません。 複雑なIPv4- IPngネットワークで安定性と接続性を最大にするIPng体系が好まれます。
Finally, IPng is expected to evolve over time and therefore, it
must be possible to have multiple versions of IPng, some in
production use, some in experimental, developmental, or evaluation
use, to coexist on the network. Transition plans must address
this issue.
最終的に、IPngが時間がたつにつれて発展すると予想されて、したがって、それは、ネットワークに共存するためにはIPngの複数のバージョン、生産使用でのいくつか、実験的の開発上のいくつかを持つのにおいて可能であるか評価使用でなければなりません。 変遷プランはこの問題を扱わなければなりません。
Partridge and Kastenholz [Page 12] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[12ページ]RFC1726IPng
The transition plan must address the following general areas of
the Internet's infrastructure:
変遷プランは、↓これがインターネットのインフラストラクチャの一般的な領域であると扱わなければなりません:
Host Protocols and Software
Router Protocols and Software
Security and Authentication
Domain Name System
Network Management
Operations Tools (e.g., Ping and Traceroute)
Operations and Administration procedures
ホストのプロトコル、Software Routerプロトコル、Software Security、およびAuthenticationドメインネームシステムNetwork Management Operations Tools(例えば、PingとTraceroute)操作と政権手順
The impact on protocols which use IP addresses as data (e.g., DNS,
distributed file systems, SNMP and FTP) must be specifically
addressed.
明確にデータ(例えば、DNS、分散ファイルシステム、SNMP、およびFTP)としてIPアドレスを使用するプロトコルの影響を扱わなければなりません。
The transition plan should address the issue of cost distribution.
That is, it should identify what tasks are required of the service
providers, of the end users, of the backbones and so on.
変遷プランは、コストの問題が分配であると扱うべきです。 すなわち、それは、エンドユーザ、バックボーンのサービスプロバイダーなどがどんなタスクに要求されるかを特定するべきです。
Time Frame
A transition plan is required immediately.
時間Frame A変遷プランがすぐに、必要です。
5.6 Media Independence
5.6 メディア独立
CRITERION
The protocol must work across an internetwork of many different
LAN, MAN, and WAN media, with individual link speeds ranging from
a ones-of-bits per second to hundreds of gigabits per second.
Multiple-access and point-to-point media must be supported, as
must media supporting both switched and permanent circuits.
個人がいる必須が多くの異なったLANのインターネットワークの向こう側に扱うプロトコル、MAN、およびWANメディアがリンクするCRITERIONは、bpsのa1つ〜1秒あたりのギガビットの数百まで及びながら、疾走します。 両方が切り換えられて永久的な回路であるとサポートするメディアでなければならないことのように複数のアクセスと二地点間メディアをサポートしなければなりません。
DISCUSSION
The joy of IP is that it works over just about anything. This
generality must be preserved. The ease of adding new
technologies, and ability to continue operating with old
technologies must be maintained.
DISCUSSION、IPの喜びはほとんど何でも上で働いているということです。 この一般性を保存しなければなりません。 新技術を加える容易さ、および旧テクノロジー必須が維持されている状態で作動し続ける能力。
We believe this range of speed is right for the next twenty years,
though we may wish to require terabit performance at the high-end.
We believe that, at a minimum, media running at 500 gigabits per
second will be commonly available within 10 years. The low end of
the link-speed range is based on the speed of systems like pagers
and ELF (ELF connects to submerged submarines and has a "speed" on
the order of <10 characters per second).
私たちは、この範囲の速度が次の20年間正しいと信じています、ハイエンドにおけるテラビット性能を必要とするかもしれなくたいと思いますが。 私たちは、1秒あたり500のギガビットで経営しているメディアが10年以内に最小限で利用可能に一般的になると信じています。 リンク速度範囲のローエンドはポケットベルとELFのようなシステムの速度に基づいています(ELFは1秒あたり10のキャラクタに<の注文に潜水中の潜水艦に接続して、「速度」を持っています)。
By switched circuits we mean both "permanent" connections such as
X.25 and Frame Relay services AND "temporary" types of dialup
connections similar to today's SLIP and dialup PPP services, and
そして交換回線網のそばでは、私たちがX.25などの「永久的な」接続とFrame Relayサービスと「一時的な」タイプの電話での接続の今日のSLIPとダイアルアップPPPサービスと同様の両方を言っている。
Partridge and Kastenholz [Page 13] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[13ページ]RFC1726IPng
perhaps, ATM SVCs. The latter form of connection implies that
dynamic network access (i.e., the ability to unplug a machine,
move it to a different point on the network topology, and plug it
back in, possibly with a changed IPng address) is required. We
note that this is an aspect of mobility.
恐らくATM SVCs。 後者の形式の接続は、ダイナミックなネットワークアクセス(すなわち、マシンのプラグを抜いて、それをネットワーク形態の異なったポイントに動かして、ことによると変えられたIPngアドレスでそれのプラグを差し込み返す能力)が必要であると暗示します。 私たちは、これが移動性の局面であることに注意します。
By work, we mean we have hopes that a stream of IPng datagrams
(whether from one source, or many) can come close to filling the
link at high speeds, but also scales gracefully to low speeds.
仕事で、私たちは、IPngデータグラム(1つのソース、または多くにかかわらず)のストリームが高速でリンクをいっぱいにする近くで来ることができますが、優雅に低速にまた比例するという望みがあると言っています。
Many network media are multi-protocol. It is essential that IPng
be able to peacefully co-exist on such media with other protocols.
Routers and hosts must be able to discriminate among the protocols
that might be present on such a medium. For example, on an
Ethernet, a specific, IPng Ethernet Type value might be called
for; or the old IPv4 Ethernet type is used and the first four
(version number in the old IPv4 header) bits would distinguish
between IPv4 and IPng.
多くのネットワークメディアがマルチプロトコルです。 IPngがそのようなメディアに平和に他のプロトコルに共存できるのは、不可欠です。 ルータとホストはそのような媒体に存在するかもしれないプロトコルの中で差別できなければなりません。 例えば、イーサネットでは、特定のIPngイーサネットType価値は求められるかもしれません。 または、年取ったIPv4イーサネットタイプは使用されています、そして、最初の4(年取ったIPv4ヘッダーのバージョン番号)ビットはIPv4とIPngを見分けるでしょう。
Different media have different MAC address formats and schemes.
It must be possible for a node to dynamically determine the MAC
address of a node given that node's IP address. We explicitly
prohibit using static, manually configured mappings as the
standard approach.
異なったメディアには、異なったMACアドレス形式と体系があります。 そのノードのIPアドレスを考えて、ノードがダイナミックにノードのMACアドレスを決定するのは、可能であるに違いありません。 私たちは、標準のアプローチとして静的で、手動で構成されたマッピングを使用するのを明らかに禁止します。
Another aspect of this criterion is that many different MTUs will
be found in an IPng internetwork. An IPng must be able to operate
in such a multi-MTU environment. It must be able to adapt to the
MTUs of the physical media over which it operates. Two possible
techniques for dealing with this are path MTU discovery and
fragmentation and reassembly; other techniques might certainly be
developed.
この評価基準のもう一つの側面は多くの異なったMTUsがIPngインターネットワークで見つけられるということです。 IPngはそのようなマルチMTU環境で作動できなければなりません。 それはそれが作動する物理的なメディアのMTUsに順応できなければなりません。 これに対処するための2つの可能なテクニックが、経路MTU探索と断片化であり、再アセンブリされます。 確かに、他の技術は見いだされるかもしれません。
We note that, as of this writing (mid 1994), ATM seems to be set
to become a major network media technology. Any IPng should be
designed to operate over ATM. However, IPng still must be able to
operate over other, more "traditional" network media.
Furthermore, a host on an ATM network must be able to interoperate
with a host on another, non-ATM, medium, with no more difficulty
or complexity than hosts on different media can interoperate today
using IPv4.
私たちは、ATMが、この書くこと(1994年中頃)現在主要なネットワークメディア技術になるように設定されるように思えることに注意します。 どんなIPngも、ATMの上で作動するように設計されるべきです。 しかしながら、IPngは他の、そして、より「伝統的な」ネットワークメディアの上でまだ作動できなければなりません。 その上、ATMネットワークのホストは別のもののホストと共に共同利用できなければなりません、非ATMです、中型である、困難か複雑さよりホストがオンである場合、異なったメディアが、今日、IPv4を使用することで共同利用できます。
IPng must be able to deal both with "dumb" media, such as we have
today, and newer, more intelligent, media. In particular, IPng
functions must be able to exist harmoniously with lower-layer
realizations of the same, or similar, functions. Routing and
resource management are two areas where designers should pay
particular attention. Some subnetwork technologies may include
IPngは私たちなどの「馬鹿な」メディアがある両方が今日持っている取引、および、より新しくて、より知的なメディアにできるに違いありません。 特に、IPng機能は同じであるか、同様の機能の下層実現で円満に存在できなければなりません。 ルート設定と資源管理はデザイナーが特別の注意を向けるべきである2つの領域です。 技術が含むかもしれないあるサブネットワーク
Partridge and Kastenholz [Page 14] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[14ページ]RFC1726IPng
integral accounting and billing capabilities, and IPng must
provide the correct control information to such subnetworks.
不可欠の会計と能力、およびIPngに必須を請求すると、正しい制御情報はそのようなサブネットワークに提供されます。
Time Frame
Specifications for current media encapsulations (i.e., all
encapsulations that are currently Proposed standards, or higher,
in the IETF) are required immediately. These specifications must
include any auxiliary protocols needed (such as an address
resolution mechanism for Ethernet or the link control protocol for
PPP). A general 'guide' should also be available immediately to
help others develop additional media encapsulations. Other,
newer, encapsulations can be developed as the need becomes
apparent.
現在のメディアカプセル化(現在Proposed規格であるか、より高さIETFでそうであるすなわちすべてのカプセル化)のための時間Frame Specificationsがすぐに、必要です。 これらの仕様は補助のプロトコルが必要としたいずれ(イーサネットのためのアドレス解決メカニズムかPPPのためのリンク制御プロトコルなどの)も含まなければなりません。 また、一般的な'ガイド'も、すぐに、他のものが追加メディアカプセル化を開発するのを助けるために利用可能であるべきです。 必要性が明らかになるとき、他の、そして、より新しいカプセル化を開発できます。
Van Jacobson-like header compression should be shown immediately,
as should any other aspects of very-low-speed media. Similarly,
any specific aspects of high-speed media should be shown
immediately.
圧縮がすぐにまさしくその低速メディアのいかなる他の局面であるべきであることのようにも示されるべきであるジェーコブソンのようなヘッダーをバンに積んでください。 同様に、高速メディアのどんな特定の局面もすぐに、示されるべきです。
5.7 Unreliable Datagram Service
5.7 頼り無いデータグラムサービス
CRITERION
The protocol must support an unreliable datagram delivery service.
プロトコルが頼り無いデータグラムデリバリ・サービスをサポートしなければならないCRITERION。
DISCUSSION
We like IP's datagram service and it seems to work very well. So
we must keep it. In particular, the ability, within IPv4, to send
an independent datagram, without prearrangement, is extremely
valuable (in fact, may be required for some applications such as
SNMP) and must be retained.
IPのデータグラムサービスとそれのようなDISCUSSION Weは、非常によく働くように思えます。 それで、私たちはそれを保たなければなりません。 特に能力、IPv4の中では、独立しているデータグラムを送るのを根回しなしで非常に貴重であり(事実上、SNMPなどのいくつかのアプリケーションに必要であるかもしれません)、保有しなければなりません。
Furthermore, the design principle that says that we can take any
datagram and throw it away with no warning or other action, or
take any router and turn it off with no warning, and have datagram
traffic still work, is very powerful. This vastly enhances the
robustness of the network and vastly eases administration and
maintenance of the network. It also vastly simplifies the design
and implementation of software [14].
その上、私たちがどんなデータグラムも取って、警告も他の動作なしでそれを捨てるか、どんなルータも取って、警告なしでそれをオフにして、またはデータグラムトラフィックをまだ働かせることができると言う設計原理は非常に強力です。 これは、広大にネットワークの丈夫さを高めて、広大にネットワークの管理とメインテナンスを緩和します。 また、それは広大にソフトウェア[14]の設計と実装を簡素化します。
Furthermore, the Unreliable Datagram Service should support some
minimal level of service; something that is approximately
equivalent to IPv4 service. This has two functions; it eases the
task of IPv4/IPng translating systems in mapping IPv4 traffic to
IPng and vice versa, and it simplifies the task of fitting IPng
into small, limited environments such as boot ROMs.
その上、UnreliableデータグラムServiceは何らかの最小量のレベルのサービスをサポートするはずです。 IPv4サービスにほとんど何か同等なもの。 これには、2つの機能があります。 それはIPv4/IPngが逆もまた同様にIPv4トラフィックをIPngに写像する際にシステムを翻訳するタスクを緩和します、そして、ブーツROMなどの小さくて、限られた環境にIPngに合うタスクを簡素化します。
Time Frame
Unreliable Datagram Service must be available immediately.
時間Frame UnreliableデータグラムServiceはすぐに、利用可能であるに違いありません。
Partridge and Kastenholz [Page 15] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[15ページ]RFC1726IPng
5.8 Configuration, Administration, and Operation
5.8 構成、政権、および操作
CRITERION
The protocol must permit easy and largely distributed
configuration and operation. Automatic configuration of hosts and
routers is required.
プロトコルが可能にしなければならないCRITERIONは構成と操作をたやすく、そして主に広げました。 ホストとルータの自動構成が必要です。
DISCUSSION
People complain that IP is hard to manage. We cannot plug and
play. We must fix that problem.
DISCUSSION Peopleは、IPは管理しにくいと不平を言います。 私たちは、働いて、プレーできません。 私たちはその問題を修正しなければなりません。
We do note that fully automated configuration, especially for
large, complex networks, is still a topic of research. Our
concern is mostly for small and medium sized, less complex,
networks; places where the essential knowledge and skills would
not be as readily available.
私たちは、それでも、完全に自動化された構成が特に大きくて、複雑なネットワークにおいて研究の話題であることに注意します。 私たちの関心はほとんど小さくて中型の大きさで分けられて、より少ない複合体、ネットワークのためのものです。 不可欠の知識と技能が容易に同じくらい利用可能でない場所。
In dealing with this criterion, address assignment and delegation
procedures and restrictions should be addressed by the proposal.
Furthermore, "ownership" of addresses (e.g., user or service
provider) has recently become a concern and the issue should be
addressed.
この評価基準に対処する際に、アドレス課題、委譲手順、および制限は提案で扱われるべきです。 その上、アドレス(例えば、ユーザかサービスプロバイダー)の「所有権」は最近関心になりました、そして、問題は扱われるべきです。
We require that a node be able to dynamically obtain all of its
operational, IP-level parameters at boot time via a dynamic
configuration mechanism.
私たちは、ノードが動的設定メカニズムでダイナミックにブート時間における操作上の、そして、IP平らなパラメタのすべてを得ることができるのを必要とします。
A host must be able to dynamically discover routers on the host's
local network. Ideally, the information which a host learns via
this mechanism would also allow the host to make a rational
selection of which first-hop router to send any given packet to.
IPng must not mandate that users or administrators manually
configure first-hop routers into hosts.
ホストはホストの企業内情報通信網でダイナミックにルータを発見できなければなりません。 また、理想的に、ホストがこのメカニズムで学ぶ情報で、ホストはどの最初に、ホップルータに何か与えられたパケットを送るかに関する合理的な選択をすることができるでしょう。 IPngは、ユーザか管理者が手動で最初に、ホップルータをホストに構成するのを強制してはいけません。
Also, a strength of IPv4 has been its ability to be used on
isolated subnets. IPng hosts must be able to work on networks
without routers present.
また、IPv4の強さはその孤立しているサブネットで使用されるべき性能です。 IPngホストは存在しているルータなしでネットワークに取り組むことができなければなりません。
Additional elements of this criterion are:
この評価基準の追加要素は以下の通りです。
* Ease of address allocation.
* Ease of changing the topology of the network within a particular
routing domain.
* Ease of changing network provider.
* Ease of (re)configuring host/endpoint parameters such as
addressing and identification.
* Ease of (re)configuring router parameters such as addressing and
identification.
* アドレス配分の容易さ。 * 特定の経路ドメインの中でネットワークのトポロジーを変える容易さ。 * ネットワーク内の提供者を変える容易さ。 * (re)がアドレシングや識別などのホスト/終点パラメタを構成する容易さ。 * (re)がアドレシングや識別などのルータパラメタを構成する容易さ。
Partridge and Kastenholz [Page 16] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[16ページ]RFC1726IPng
* Address allocation and assignment authority must be delegated as
far 'down' the administrative hierarchy as possible.
* 管理の遠い'down'としてアドレス配分と課題権威を代表として派遣しなければなりません。可能であるとしての階層構造。
The requirements of this section apply only to IPng and its
supporting protocols (such as for routing, address resolution, and
network-layer control). Specifically, as far as IPng is
concerned, we are concerned only with how routers and hosts get
their configuration information.
このセクションの要件はIPngとプロトコル(ルーティングや、アドレス解決や、ネットワーク層コントロールなどの)をサポートするだけに適用されます。 明確に、IPngに関する限り、私たちはルータとホストがどう彼らの設定情報を得るだけであるかに関係があります。
We note that in general, automatic configuration of hosts is a
large and complex problem and getting the configuration
information into hosts and routers is only one, small, piece of
the problem. A large amount of additional, non-Internet-layer
work is needed in order to be able to do "plug-and-play"
networking. Other aspects of "plug-and-play" networking include
things like: Autoregistration of new nodes with DNS, configuring
security service systems (e.g., Kerberos), setting up email relays
and mail servers, locating network resources, adding entries to
NFS export files, and so on. To a large degree, these
capabilities do not have any dependence on the IPng protocol
(other than, perhaps, the format of addresses).
私たちは、一般に、ホストの自動構成が大きくて複雑な問題であることに注意します、そして、ホストとルータに設定情報を届けるのが、1であるだけです、小さいです、問題の断片。 多量の追加非インターネットの層の仕事が、「プラグアンドプレイ」ネットワークができるのに必要です。 「プラグアンドプレイ」ネットワークの他の局面は以下のようなものを含んでいます。 ネットワーク資源の場所を見つけて、メールリレーとメールサーバをセットアップして、セキュリティサービス・システム(例えば、ケルベロス)を構成するDNSとの新しいノードのAutoregistration、NFSへの付加エントリーはファイルなどをエクスポートします。 かなり、これらの能力がIPngプロトコルに少しの依存も持っていない、(恐らくアドレスの形式、)
We require that any IPng proposal not impede or prevent, in any
way, the development of "plug-and-play" network configuration
technologies.
私たちは、どんなIPng提案も何らかの方法で「プラグアンドプレイ」ネットワーク・コンフィギュレーション技術の開発を妨害もしませんし、防ぎもしないのを必要とします。
Automatic configuration of network nodes must not prevent users or
administrators from also being able to manually configure their
systems.
また、ユーザか管理者がネットワーク・ノードの自動構成によって手動で彼らのシステムを構成できないではいけません。
Time Frame
A method for plug and play on small subnets is immediately
required.
小さいサブネットに関するプラグアンドプレイのための時間Frame Aメソッドがすぐに、必要です。
We believe that this is an extremely critical area for any IPng as
a major complaint of the IP community as a whole is the difficulty
in administering large IP networks. Furthermore, ease of
installation is likely to speed the deployment of IPng.
私たちは、これが全体でIP共同体の主要な苦情が大きいIPネットワークを管理することにおいて苦労であるのでどんなIPngのための非常に重大な領域であるとも信じています。 その上、インストールの容易さはIPngの展開を促進しそうです。
5.9 Secure Operation
5.9 安全な操作
CRITERION
IPng must provide a secure network layer.
CRITERION IPngは安全なネットワーク層を提供しなければなりません。
DISCUSSION
We need to be sure that we have not created a network that is a
cracker's playground.
DISCUSSION Weは、いかにも私たちがクラッカーの遊び場であるネットワークを創設しない必要があります。
Partridge and Kastenholz [Page 17] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[17ページ]RFC1726IPng
In order to meet the Robustness criterion, some elements of what
is commonly shrugged off as "security" are needed; e.g., to prevent
a villain from injecting bogus routing packets, and destroying the
routing system within the network. This criterion covers those
aspects of security that are not needed to provide the Robustness
criterion.
Robustness評価基準を満たすために、「セキュリティ」として一般的に無視されることに関するいくつかの要素が必要です。 例えば悪人がにせのルーティングパケットを注入して、ネットワークの中でルーティングシステムを破壊するのを防ぐために。 この評価基準はRobustness評価基準を提供するのに必要でないセキュリティのそれらの局面をカバーしています。
Another aspect of security is non-repudiation of origin. In order
to adequately support the expected need for simple accounting, we
believe that this is a necessary feature.
セキュリティのもう一つの側面は発生源の非拒否です。 適切に単式簿記の予想された必要性をサポートするために、私たちは、これが必要な特徴であると信じています。
In order to safely support requirements of the commercial world,
IPng-level security must have capabilities to prevent
eavesdroppers from monitoring traffic and deducing traffic
patterns. This is particularly important in multi-access networks
such as cable TV networks [5].
安全に商業界の要件をサポートするために、IPng-レベルセキュリティに立ち聞きする者がトラフィックをモニターして、トラフィック・パターンを推論するのを防ぐ能力がなければなりません。 これはケーブルテレビネットワーク[5]などのマルチアクセスネットワークで特に重要です。
Aspects of security at the IP level to be considered include:
考えられるIPレベルにおけるセキュリティの局面は:
* Denial of service protections [6],
* Continuity of operations [6],
* Precedence and preemption [6],
* Ability to allow rule-based access control technologies [6]
* Protection of routing and control-protocol operations [9],
* Authentication of routing information exchanges, packets, data,
and sources (e.g., make sure that the routing packet came from a
router) [9],
* QOS security (i.e., protection against improper use of network-
layer resources, functions, and capabilities),
* Auto-configuration protocol operations in that the host must be
assured that it is getting its information from proper sources,
* Traffic pattern confidentiality is strongly desired by several
communities [9] and [5].
* **サービス保護6の否定、操作6の連続、先行と先取り6、規則ベースのアクセスを許す*能力はルーティングと制御プロトコル操作9の技術6*保護を制御します、ルーティング情報交換、パケット、データ、およびソース(例えば、ルーティングパケットがルータから来たのを確実にする)9の*認証; *適切なソースから情報を得ているとホストを確信しなければならないので、QOSセキュリティ(すなわち、ネットワーク層のリソース、機能、および能力の不適当な使用に対する保護)、*自動構成は操作について議定書の中で述べて、*トラフィック・パターン秘密性はいくつかの9と5の共同体によって強く望まれています。
Time Frame
Security should be an integral component of any IPng from the
beginning.
時間Frame Securityは始めからのどんなIPngの不可欠の部品であるべきです。
5.10 Unique Naming
5.10 ユニークな命名
CRITERION
IPng must assign all IP-Layer objects in the global, ubiquitous,
Internet unique names. These names may or may not have any
location, topology, or routing significance.
CRITERION IPngはグローバルで、遍在しているインターネットのすべてのIP-層のオブジェクトにユニークな名前を割り当てなければなりません。 これらの名前には、どんな位置、トポロジー、またはルーティング意味もあるかもしれません。
DISCUSSION
We use the term "Name" in this criterion synonymously with the
term "End Point Identifier" as used in the NIMROD proposal, or as
またはDISCUSSION Weがニムロデ提案に使用されるように「エンドポイント識別子」という用語でこの評価基準に同じ意味で「名前」という用語を使用する。
Partridge and Kastenholz [Page 18] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[18ページ]RFC1726IPng
IP Addresses uniquely identify interfaces/hosts in IPv4. These
names may or may not carry any routing or topology information.
See [11] for more discussion on this topic.
IP AddressesはIPv4で唯一インタフェース/ホストを特定します。 これらの名前はどんなルーティングやトポロジー情報も運ぶかもしれません。 この話題についての、より多くの議論のための[11]を見てください。
IPng must provide identifiers which are suitable for use as
globally unique, unambiguous, and ubiquitous names for endpoints,
nodes, interfaces, and the like. Every datagram must carry the
identifier of both its source and its destination (or some method
must be available to determine these identifiers, given a
datagram). We believe that this is required in order to support
certain accounting functions.
IPngはグローバルにユニークで、明白であるとして使用に適した識別子を提供して、終点、ノード、インタフェース、および同様のもののために遍在している名前を提供しなければなりません。 あらゆるデータグラムがソースとその目的地の両方に関する識別子を運ばなければなりません(データグラムを考えて、何らかのメソッドがこれらの識別子を決定するために利用可能でなければなりません)。 私たちは、これが、ある会計が機能であるとサポートするのに必要であると信じています。
Other functions and uses of unique names are:
ユニークな名前の他の機能と用途は以下の通りです。
* To uniquely identify endpoints (thus if the unique name and
address are not the same, the TCP pseudo-header should include
the unique name rather than the address)
* To allow endpoints to change topological location on the network
(e.g., migrate) without changing their unique names.
* To give one or more unique names to a node on the network (i.e.,
one node may have multiple unique names)
* 終点がネットワーク(例えば、移行する)でそれらのユニークな名前を変えないで位相的な位置を変えるのを許容するために唯一終点(その結果、ユニークな名前とアドレスが同じでないなら、TCP疑似ヘッダーはアドレスよりむしろユニークな名前を入れるべきである)*を特定するために。 * 1つ以上のユニークな名前をネットワークのノードに与えるために(すなわち、1つのノードには、複数のユニークな名前があるかもしれません)
An identifier must refer to one and only one object while that
object is in existence. Furthermore, after an object ceases to
exist, the identifier should be kept unused long enough to ensure
that any packets containing the identifier have drained out of the
Internet system, and that other references to the identifier have
probably been lost. We note that the term "existence" is as much
an administrative issue as a technical one. For example, if a
workstation is reassigned, given a new IP address and node name,
and attached to a new subnetwork, is it the same object or not.
This does argue for a namespace that is relatively large and
relatively stable.
そのオブジェクトが現存している間、識別子は唯一無二の1個のオブジェクトについて言及しなければなりません。 その上、オブジェクトが消滅した後に識別子は識別子を含むどんなパケットもインターネット・システムから排水して、識別子の他の参照がたぶん失われたのを保証できるくらいの長い間、未使用に保たれるべきです。 私たちは、「存在」という用語が技術的なものと同じくらい多くの管理問題であることに注意します。 例えば、ワークステーションに新しいIPアドレスとノード名を考えて、再選任されて、付けるなら、新しいサブネットワークは同じオブジェクトであるか否かに関係なく、それです。 これは比較的大きくて、比較的安定した名前空間について賛成の議論をします。
Time Frame
We see this as a fundamental element of the IP layer and it should
be in the protocol from the beginning.
時間Frame WeはIP層の基本的な要素であるとこれをみなします、そして、それは始めからプロトコルで来ているべきです。
5.11 Access
5.11 アクセス
CRITERION
The protocols that define IPng, its associated protocols (similar
to ARP and ICMP in IPv4) and the routing protocols (as in OSPF,
BGP, and RIP for IPv4) must be published as standards track RFCs
and must satisfy the requirements specified in RFC1310. These
documents should be as freely available and redistributable as the
IPv4 and related RFCs. There must be no specification-related
licensing fees for implementing or selling IPng software.
CRITERION、IPngを定義するプロトコル、関連プロトコル(ARPとICMPとIPv4で同様の)、およびルーティング・プロトコル(IPv4のためのOSPF、BGP、およびRIPのように)は、規格がRFCsを追跡するとき発表しなければならなくて、RFC1310で指定された要件を満たさなければなりません。 これらのドキュメントは、IPv4と関連するRFCsと自由に同じくらい利用可能であって、同じくらい再配付可能であるはずです。 ソフトウェアをIPngに実装するか、または販売するためのどんな仕様関連の認可料金もあるはずがありません。
Partridge and Kastenholz [Page 19] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[19ページ]RFC1726IPng
DISCUSSION
An essential aspect of the development of the Internet and its
protocols has been the fact that the protocol specifications are
freely available to anyone who wishes a copy. Beyond simply
minimizing the cost of learning about the technology, the free
access to specifications has made it easy for researchers and
developers to easily incorporate portions of old protocol
specifications in the revised specifications. This type of easy
access to the standards documents is required for IPng.
インターネットの発展とそのプロトコルのDISCUSSION Anの不可欠の局面はコピーを願っているだれにはも、プロトコル仕様が自由に利用可能であるという事実です。 単に技術に関して知る費用を最小にすることを超えて、仕様へのフリー・アクセスで研究者と開発者が容易に訂正明細書による古いプロトコル仕様の部分を取り入れるのが簡単になりました。 このタイプの規格文書への簡単なアクセスがIPngに必要です。
Time Frame
An IPng and its related protocols must meet these standards for
openness before an IPng can be approved.
IPngを承認できる前に時間Frame An IPngとその関連するプロトコルは風通しの良さのこれらの規格を満たさなければなりません。
5.12 Multicast
5.12 マルチキャスト
CRITERION
The protocol must support both unicast and multicast packet
transmission. Part of the multicast capability is a requirement
to be able to send to "all IP hosts on a given subnetwork".
Dynamic and automatic routing of multicasts is also required.
プロトコルがユニキャストとマルチキャストパケット伝送の両方をサポートしなければならないCRITERION。 マルチキャスト能力の一部が「与えられたサブネットワークの上のすべてのIPホスト」に発信できるという要件です。 また、マルチキャストのダイナミックで自動であるルーティングが必要です。
DISCUSSION
IPv4 has made heavy use of the ability to multicast requests to
all IPv4 hosts on a subnet, especially for autoconfiguration.
This ability must be retained in IPng.
DISCUSSION IPv4はマルチキャスト要求への能力の重い使用をサブネットのすべてのIPv4ホストに作りました、特に自動構成のために。 IPngでこの能力を保有しなければなりません。
Unfortunately, IPv4 currently uses the local media broadcast
address to multicast to all IP hosts. This behavior is anti-
social in mixed-protocol networks and should be fixed in IPng.
There's no good reason for IPng to send to all hosts on a subnet
when it only wishes to send to all IPng hosts. The protocol must
make allowances for media that do not support true multicasting.
残念ながら、IPv4は現在、すべてのIPホストへのマルチキャストに地元マスコミ放送演説を使用します。 この振舞いは、複雑なプロトコルネットワークで反社会的であり、IPngで修理されるべきです。 すべてのIPngホストに発信するだけでありたいとき、IPngがサブネットですべてのホストに発信するように、もっともな理由は全くありません。 プロトコルは本当のマルチキャスティングをサポートしないメディアを考慮に入れなければなりません。
In the past few years, we have begun to deploy support for wide-
area multicast addressing in the Internet, and it has proved
valuable. This capability must not be lost in the transition to
IPng.
過去数年間で、私たちはインターネットの広い領域マルチキャストアドレシングのサポートを配布し始めました、そして、それは貴重であると判明しました。 IPngへの変遷でこの能力を失ってはいけません。
The ability to restrict the range of a multicast to specific
networks is also important. Furthermore, it must be possible to
"selectively" multicast packets. That is, it must be possible to
send a multicast to a remote, specific portion or area of the
Internet (such as a specific network or subnetwork) and then have
that multicast limited to just that specific area. Furthermore,
any given network or subnetwork should be capable of supporting
2**16 "local" multicast groups, i.e., groups that are not
propagated to other networks. See [8].
また、マルチキャストの範囲を特定のネットワークに制限する能力も重要です。 その上、それは「選択的に」というマルチキャストパケットに可能であるに違いありません。 すなわち、インターネット(特定のネットワークかサブネットワークなどの)の遠く離れて、特定の部分か領域にマルチキャストを送って、次に、そのマルチキャストをまさしくその特定の領域に制限させるのは可能であるに違いありません。 その上、どんな与えられたネットワークやサブネットワークも、2**が16の「地方」のマルチキャストグループ(すなわち、他のネットワークに伝播されないグループ)であるとサポートすることができるべきです。 [8]を見てください。
Partridge and Kastenholz [Page 20] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[20ページ]RFC1726IPng
It should be noted that addressing -- specifically the syntax and
semantics of addresses -- has a great impact on the scalability of
the architecture.
アドレシング(明確にアドレスの構文と意味論)がアーキテクチャのスケーラビリティですばらしい影響を与えることに注意されるべきです。
Currently, large-scale multicasts are routed manually through the
Internet. While this is fine for experiments, a "production"
system requires that multicast-routing be dynamic and automatic.
Multicast groups must be able to be created and destroyed, hosts
must be able to join and leave multicast groups and the network
routing infrastructure must be able to locate new multicast groups
and destinations and route traffic to those destinations all
without manual intervention.
現在、大規模なマルチキャストはインターネットを通して手動で発送されます。 実験に、これは大丈夫ですが、「生産」システムは、マルチキャストルーティングがダイナミックであって、自動であることを必要とします。 マルチキャストグループは、作成されて、破壊できなければなりません、そして、ホストは、マルチキャストグループに加わって、出ることができなければなりません、そして、ネットワークルーティングインフラストラクチャは手動の介入なしですべて、新しいマルチキャストグループ、目的地、およびルートトラフィックのそれらの目的地に場所を見つけることができなければなりません。
Large, topologically dispersed, multicast groups (with up to 10**6
participants) must be supported. Some applications are given in
[8].
大きくて、位相的に分散しているマルチキャストグループ(最大10**6関係者がいる)をサポートしなければなりません。 [8]でいくつかのアプリケーションを与えます。
Time Frame
Obviously, address formats, algorithms for processing and
interpreting the multicast addresses must be immediately available
in IPng. Broadcast and Multicast transmission/reception of
packets are required immediately. Dynamic routing of multicast
packets must be available within 18 months.
時間Frame Obviously、アドレス形式であり、マルチキャストが扱う処理と解釈のためのアルゴリズムはすぐに、IPngで利用可能であるに違いありません。 パケットの放送とMulticastトランスミッション/レセプションがすぐに、必要です。 マルチキャストパケットのダイナミックルーティングは18カ月以内に利用可能であるに違いありません。
We believe that Multicast Addressing is vital to support future
applications such as remote conferencing. It is also used quite
heavily in the current Internet for things like service location
and routing.
私たちは、Multicast Addressingがリモート会議などの将来のアプリケーションをサポートするのに必要であると信じています。 また、それはサービス位置とルーティングのようなものに現在のインターネットで全く大いに使用されます。
5.13 Extensibility
5.13 伸展性
CRITERION
The protocol must be extensible; it must be able to evolve to meet
the future service needs of the Internet. This evolution must be
achievable without requiring network-wide software upgrades. IPng
is expected to evolve over time. As it evolves, it must be able to
allow different versions to coexist on the same network.
CRITERION、プロトコルは広げることができるに違いありません。 それは、インターネットの将来のサービス需要を満たすために発展できなければなりません。 ネットワーク全体のソフトウェアの更新を必要としないで、この発展は達成可能であるに違いありません。 IPngが時間がたつにつれて発展すると予想されます。 発展するとき、それは、異なった見解が同じネットワークに共存するのを許容できなければなりません。
DISCUSSION
We do not today know all of the things that we will want the
Internet to be able to do 10 years from now. At the same time, it
is not reasonable to ask users to transition to a new protocol
with each passing decade. Thus, we believe that it must be
possible to extend IPng to support new services and facilities.
Furthermore, it is essential that any extensions can be
incrementally deployed to only those systems which desire to use
them. Systems upgraded in this fashion must still be able to
communicate with systems which have not been so upgraded.
DISCUSSION Weは今日、私たちが、インターネットに現在から10年間することができて欲しいつもりであるものについてすべてを知りません。 同時に、それぞれの一時的な10年間新しいプロトコルへの変遷にユーザを招くのは妥当ではありません。 したがって、私たちは、新種業務と施設をサポートするためにIPngを広げるのが可能であるに違いないと信じています。 その上、それらを使用することを望んでいるそれらのシステムだけにどんな拡大も増加して配布することができるのは不可欠です。 こんなやり方でアップグレードしたシステムはまだそのようにアップグレードしていないシステムとコミュニケートできなければなりません。
Partridge and Kastenholz [Page 21] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[21ページ]RFC1726IPng
There are several aspects to extensibility:
伸展性へのいくつかの局面があります:
5.13.1 Algorithms
The algorithms used in processing IPng information should be
decoupled from the protocol itself. It should be possible to
change these algorithms without necessarily requiring protocol,
datastructure, or header changes.
5.13.1 アルゴリズムが処理IPng情報で使用したアルゴリズムはプロトコル自体から衝撃を吸収されるべきです。 必ずプロトコル、datastructure、またはヘッダー変化を必要とするというわけではなくてこれらのアルゴリズムを変えるのは可能であるべきです。
5.13.2 Headers
The content of packet headers should be extensible. As more
features and functions are required of IPng, it may be
necessary to add more information to the IPng headers. We note
that for IPv4, the use of options has proven less than entirely
satisfactory since options have tended to be inefficient to
process.
5.13.2 ヘッダー、パケットのヘッダーの内容は広げることができるべきです。 IPngが、より多くの特徴と機能に要求されるとき、IPngヘッダーに詳しい情報を加えるのが必要であるかもしれません。 私たちはIPv4によってそれに注意して、オプションが、処理するために効率が悪い傾向があって以来、オプションの使用は完全にあまり満足できないと判明しています。
5.13.3 Data Structures
The fundamental data structures of IPng should not be bound
with the other elements of the protocol. E.g., things like
address formats should not be intimately tied with the routing
and forwarding algorithms in the way that the IPv4 address
class mechanism was tied to IPv4 routing and forwarding.
5.13.3 IPngの基本的なデータ構造がもう片方があるバウンドがプロトコルの原理であるならそうしないデータStructures。 例えば、アドレス形式のようなことは、ルーティングで親密に結ばれて、IPv4アドレスクラスメカニズムがIPv4ルーティングと推進に結ばれた方法でアルゴリズムを進めることであるべきではありません。
5.13.4 Packets
It should be possible to add additional packet-types to IPng.
These could be for, _e._g., new control and/or monitoring
operations.
5.13.4 パケットItは追加パケットタイプをIPngに加えるのにおいて可能であるべきです。 これらがあるかもしれない、_e._g.、新しいコントロール、そして/または、モニターしている操作。
We note that, everything else being equal, having larger,
oversized, number spaces is preferable to having number spaces
that are "just large enough". Larger spaces afford more
flexibility on the part of network designers and operators and
allow for further experimentation on the part of the scientists,
engineers, and developers. See [7].
私たちは、ものが他の何もかも等しくて、より大きくて、特大の数の空間を持っているのが「ちょうど十分大きい」数の空間を持っているより望ましいことに注意します。 より大きい空間は、ネットワーク設計者とオペレータ側のより多くの柔軟性を提供して、科学者、技術者、および開発者側のさらなる実験を考慮します。 [7]を見てください。
Time Frame
A framework showing mechanisms for extending the protocol must be
provided immediately.
すぐに、プロトコルを広げるためにメカニズムを見せている時間Frame Aフレームワークを提供しなければなりません。
5.14 Network Service
5.14 ネットワーク・サービス
CRITERION
The protocol must allow the network (routers, intelligent media,
hosts, and so on) to associate packets with particular service
classes and provide them with the services specified by those
classes.
プロトコルで、特定のサービスのクラスにパケットを関連づけて、ネットワーク(ルータ、知的なメディア、ホストなど)をそれらにサービスを提供しなければならないCRITERIONはそれらのクラスで指定しました。
Partridge and Kastenholz [Page 22] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[22ページ]RFC1726IPng
DISCUSSION
For many reasons, such as accounting, security and multimedia, it
is desirable to treat different packets differently in the
network.
会計や、セキュリティやマルチメディアなどのDISCUSSION For多くの理由であり、ネットワークで異なったパケットを異なって扱うのは望ましいです。
For example, multimedia is now on our desktop and will be an
essential part of future networking. So we have to find ways to
support it; and a failure to support it may mean users choose to
use protocols other than IPng.
例えば、マルチメディアは、現在、私たちのデスクトップの上にあって、将来のネットワークの不可欠の部分になるでしょう。 それで、私たちはそれをサポートする方法を見つけなければなりません。 そして、それをサポートしない場合、ユーザが、IPng以外のプロトコルを使用するのを選ぶことを意味するかもしれません。
The IETF multicasts have shown that we can currently support
multimedia over internetworks with some hitches. If the network
can be guaranteed to provide the necessary service levels for this
traffic, we will dramatically increase its success.
IETFマルチキャストは、私たちが現在インターネットワークの上でいくつかの故障でマルチメディアをサポートすることができるのを示しました。 必要なサービスレベルをこのトラフィックに提供するためにネットワークを保証できるなら、私たちは成功を劇的に増強するつもりです。
This criterion includes features such as policy-based routing,
flows, resource reservation, network service technologies, type-
of-service and quality-of-service and so on.
この評価基準は方針ベースのルーティングなどの特徴を含んで、流れ(資源予約)はなどにサービス技術、サービスのタイプ、およびサービスの品質をネットワークでつなぎます。
In order to properly support commercial provision and use of
Internetwork service, and account for the use of these services
(i.e., support the economic principle of "value paid for value
received") it must be possible to obtain guarantees of service
levels. Similarly, if the network can not support a previously
guaranteed service level, it must report this to those to whom it
guaranteed the service.
適切にInternetworkの商業支給と使用をサポートするには、サービスレベルの保証を得るのにおいて可能な状態でそれがこれらのサービスでなければならないの(すなわち、「値は対価領収の代価を払った」経済原則をサポートする)の使用を修理して、説明してください。 同様に、ネットワークが、以前に保証されたサービスがレベルであるとサポートすることができないなら、それはサービスを保証したそれらにこれを報告しなければなりません。
Network service provisions must be secure. The network-layer
security must generally prevent one host from surreptitiously
obtaining or disrupting the use of resources which another host
has validly acquired. (Some security failures are acceptable, but
the failure rate must be very low and the rate should be
quantifiable).
ネットワーク・サービス条項は安全であるに違いありません。 ネットワーク層セキュリティによって、1人のホストは、こっそりと別のホストが確実に取得したリソースの使用を得るか、または一般に、中断できなくなければなりません。 (故障率は非常に低くなければなりません、そして、いくつかのセキュリティ失敗が許容できますが、レートは定量化可能であるべきです。)
One of the parameters of network service that may be requested
must be cost-based.
要求されているかもしれないネットワーク・サービスのパラメタの1つは費用ベースであるに違いありません。
As far as possible, given the limitations of underlying media and
IP's model of a robust internet datagram service, real-time,
mission-critical applications must be supported by IPng [6].
基本的なメディアの制限とIPの体力を要しているインターネットデータグラムサービスのモデルを考えて、できるだけ、IPng[6]はリアルタイムで、ミッションクリティカルなアプリケーションをサポートしなければなりません。
Users must be able to confirm that they are, in fact, getting the
services that they have requested.
ユーザは、事実上、自分達がそれらが要求したサービスを得ていると確認できなければなりません。
Time Frame
This should be available within 24 months.
時間Frame Thisは24カ月以内に利用可能であるべきです。
Partridge and Kastenholz [Page 23] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[23ページ]RFC1726IPng
5.15 Support for Mobility
5.15 移動性のサポート
CRITERION
The protocol must support mobile hosts, networks and
internetworks.
プロトコルがモバイルホスト、ネットワーク、およびインターネットワークをサポートしなければならないCRITERION。
DISCUSSION
Again, mobility is becoming increasingly important. Look at the
portables that everyone is carrying. Note the strength of the
Apple commercial showing someone automatically connecting up her
Powerbook to her computer back in the office. There have been a
number of pilot projects showing ways to support mobility in IPv4.
All have some drawbacks. But like network service grades, if we
can support mobility, IPng will have features that will encourage
transition.
DISCUSSION Again、移動性はますます重要になっています。 portablesが運ばれるのを見てください。 だれかが自動的に職場の彼女のコンピュータに彼女のPowerbookをつなぐのを示すアップルコマーシャルの強さに注意してください。 IPv4で移動性をサポートする方法を示している多くの試験計画がありました。 すべてには、いくつかの欠点があります。 しかし、ネットワーク職階のように、私たちが移動性をサポートすることができると、IPngには変遷を奨励する特徴があるでしょう。
We use an encompassing definition of "mobility" here. Mobility
typically means one of two things to people: 1) Hosts that
physically move and remain connected (via some wireless datalink)
with sessions and transport-layer connections remaining 'open' or
'active' and 2) Disconnecting a host from one spot in the network,
connecting it back in another arbitrary spot and continuing to
work. Both forms are required.
私たちはここで「移動性」の取り囲む定義を使用します。 移動性は2つのものの1つを人々に通常意味します: 1) 物理的に移行して、残っているホストがセッション、'開く'か'アクティブな'ままで残っているトランスポート層接続、および2に)接しました(何らかのワイヤレスのデータリンクで)。 ネットワークにおける1つのスポットからホストから切断して、それを接続するのは、仕事に別の任意の場所で支持して、続きます。 両方のフォームが必要です。
Reference [6] discusses possible future use of IP-based networks
in the US Navy's ships, planes, and shore installations. Their
basic model is that each ship, plane and shore installation
represents at least one IP network. The ship- and plane-based
networks, obviously, are mobile as these craft move around the
world. Furthermore, most, if not all, Naval surface combatants
carry some aircraft (at a minimum, a helicopter or two). So, not
only must there be mobile networks (the ships that move around),
but there must be mobile internetworks: the ships carrying the
aircraft where each aircraft has its own network, which is
connected to the ship's network and the whole thing is moving.
参照[6]は米国海軍の船、飛行機、および岸のインストールにおけるIP接続を基本にしたネットワークの可能な今後の使用について議論します。 彼らの基本型は各船、飛行機、および岸のインストールが少なくとも1つのIPネットワークを代表するということです。 これらの工芸品が世界中に移行するとき、船と飛行機を拠点とするネットワーク明らかにモバイルです。 その上、Naval水上戦闘艦は最も皆、いくつかの航空機(ヘリコプターか1か2つの最小限、時の)を運びます。 それで、モバイルネットワーク(動き回る船)があるに違いないだけではなく、モバイルインターネットワークがあるに違いありません: 船が各航空機がそれ自身のネットワークを持っているところに航空機を乗せて、どれが船のネットワークと全体のものに関連づけられるかは移行しています。
There is also the requirement for dynamic mobility; a plane might
take off from aircraft carrier A and land on carrier B so it
obviously would want to "connect" to B's network. This situation
might be even more complex since the plane might wish to retain
connectivity to its "home" network; that is, the plane might
remain connected to the ship-borne networks of both aircraft
carriers, A and B.
また、ダイナミックな移動性のための要件があります。 飛行機が航空母艦Aから立ち去って、キャリヤーBを非難するかもしれないので、それは明らかにビーズネットワークに「接続したがっているでしょう」。 飛行機が「ホーム」ネットワークに接続性を保有したがっているかもしれないので、この状況はさらに複雑であるかもしれません。 すなわち、飛行機は航空母艦、AとBの両方の船で生まれたネットワークに関連していたままで残るかもしれません。
These requirements are not limited to just the navy. They apply
to the civilian and commercial worlds as well. For example, in
civil airliners, commercial cargo and passenger ships, trains,
cars and so on.
これらの要件はまさしく海軍に制限されません。 彼らはまた、民間で商業の世界に適用します。 例えば民間定期旅客機、商業貨物、旅客船、列車、車などで。
Partridge and Kastenholz [Page 24] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[24ページ]RFC1726IPng
Time Frame
The mobility algorithms are stabilizing and we would hope to see
an IPng mobility framework within a year.
移動性アルゴリズムが安定していて、私たちが1年以内にIPng移動性フレームワークを見ることを望んでいる時間Frame。
5.16 Control Protocol
5.16 制御プロトコル
CRITERION
The protocol must include elementary support for testing and
debugging networks.
CRITERION、プロトコルはネットワークをテストして、デバッグする基本のサポートを含まなければなりません。
DISCUSSION
An important feature of IPv4 is the ICMP and its debugging,
support, and control features. Specific ICMP messages that have
proven extraordinarily useful within IPv4 are Echo Request/Reply
(a.k.a ping), Destination Unreachable and Redirect. Functions
similar to these should be in IPng.
IPv4のDISCUSSION Anの重要な特徴は、ICMPと、デバッグと、サポートと、コントロール機能です。 IPv4の中で異常に有用であることが分かった特定のICMPメッセージは、Echo Request/回答(a. k. ピング)と、Destination UnreachableとRedirectです。 これらと同様の機能がIPngにあるべきです。
This criterion explicitly does not concern itself with
configuration related messages of ICMP. We believe that these are
adequately covered by the configuration criterion in this memo.
この評価基準自体は明らかにICMPの関連するメッセージが構成に関係がありません。 私たちは、これらがこのメモで構成評価基準で適切にカバーされていると信じています。
One limitation of today's ICMP that should be fixed in IPng's
control protocol is that more than just the IPng header plus 64
bits of a failed datagram should be returned in the error message.
In some situations, this is too little to carry all the critical
protocol information that indicates why a datagram failed. At
minimum, any IPng control protocol should return the entire IPng
and transport headers (including options or nested headers).
今日のIPngの制御プロトコルで修理されるべきであるICMPの1つの限界はエラーメッセージでまさしくIPngヘッダー以上と失敗したデータグラムの64ビットを返すべきであるということです。 いくつかの状況で、これはデータグラムがなぜ失敗したかを示すすべての重要なプロトコル情報は運ぶことができないくらい小さいです。 最小限では、どんなIPng制御プロトコルも全体のIPngと輸送ヘッダーを返すべきです(オプションか入れ子にされたヘッダーを含んでいて)。
Time Frame
Support for these functions is required immediately.
これらの機能のための時間Frame Supportがすぐに、必要です。
5.17 Private Networks
5.17 私設のネットワーク
CRITERION
IPng must allow users to build private internetworks on top of the
basic Internet Infrastructure. Both private IP-based
internetworks and private non-IP-based (e.g., CLNP or AppleTalk)
internetworks must be supported.
CRITERION IPngはユーザに基本的なインターネットInfrastructureの上で個人的なインターネットワークを築き上げさせなければなりません。 プライベートアイピーベースのインターネットワークと個人的な非IPベース(例えば、CLNPかAppleTalk)のインターネットワークの両方をサポートしなければなりません。
DISCUSSION
In the current Internet, these capabilities are used by the
research community to develop new IP services and capabilities
(e.g., the MBone) and by users to interconnect non-IP islands over
the Internet (e.g., CLNP and DecNet use in the UK).
DISCUSSION Inの現在のインターネット、これらの能力は、インターネット(イギリスでの例えば、CLNPとDecNet使用)の上で非IP島とインタコネクトするのに新しいIPサービスと能力(例えば、MBone)を見いだす研究団体とユーザによって使用されます。
The capability of building networks on top of the Internet have
been shown to be useful. Private networks allow the Internet to
インターネットの上にネットワークを造る能力は、役に立つように示されました。 ネットワークがインターネットを許容する兵士
Partridge and Kastenholz [Page 25] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[25ページ]RFC1726IPng
be extended and modified in ways that 1) were not foreseen by the
original builders and 2) do not disrupt the day-to-day operations
of other users.
広げられて方法で変更されていて、その1つは)オリジナルのビルダーによって見通されませんでした、そして、2は)他のユーザのその日その日の操作を中断しません。
We note that, today in the IPv4 Internet, tunneling is widely used
to provide these capabilities.
私たちはそれに注意して、今日、IPv4インターネットでは、トンネリングは、これらの能力を提供するのに広く使用されます。
Finally, we note that there might not be any features that
specifically need to be added to IPng in order to support the
desired functions (i.e., one might treat a private network protocol
simply as another IP client protocol, just like TCP or UDP). If
this is the case, then IPng must not prevent these functions from
being performed.
最終的に、私たちは、明確に必要な機能をサポートするためにIPngに加えられる必要があるどんな特徴もないかもしれないことに注意します(すなわち、人が単に別のIPクライアントプロトコルとして個人的なネットワーク・プロトコルを扱うかもしれません、まさしくTCPやUDPのように)。 これがそうであるなら、IPngは、これらの機能が実行されるのを防いではいけません。
Time Frame
Some of these capabilities may be required to support other
criteria (e.g., transition) and as such, the timing of the
specifications is governed by the other criteria (e.g., immediately
in the case of transition). Others may be produced as desired.
これらの能力の時間Frame Someは、他の評価基準が(例えば、変遷)であるとサポートしなければならないかもしれません、そして、他の評価基準(例えば、すぐ変遷の場合における)によってそういうものとして、仕様のタイミングは決定されます。 他のものは望まれているように生産されるかもしれません。
6. Things We Chose Not to Require
6. 私たちが必要でないことを選んだもの
This section contains items which we felt should not impact the choice of an IPng. Listing an item here does not mean that a protocol MUST NOT do something. It means that the authors do not believe that it matters whether the feature is in the protocol or not. If a protocol includes one of the items listed here, that's cool. If it doesn't; that's cool too. A feature might be necessary in order to meet some other criterion. Our point is merely that the feature need not be required for its own sake.
このセクションは私たちがIPngの選択に影響を与えるはずがないと感じた項目を含みます。 ここに項目を記載するのは、プロトコルが何かをしてはいけないことを意味しません。 それは、作者が、プロトコルには特徴があるかが重要であると信じていないことを意味します。 プロトコルがここに記載された項目の1つを含んでいるなら、それはクールです。 そうしないなら。 また、それはクールです。 特徴が、ある他の評価基準を満たすのに必要であるかもしれません。 単に、私たちのポイントは特徴が自分自身のために必要である必要はないということです。
6.1 Fragmentation
6.1 断片化
The technology exists for path MTU discovery. Presumably, IPng will continue to provide this technology. Therefore, we believe that IPng Fragmentation and Reassembly, as provided in IPv4, is not necessary. We note that fragmentation has been shown to be detrimental to network performance and strongly recommend that it be avoided.
技術は経路MTU探索のために存在しています。 IPngは、おそらく、この技術を提供し続けるでしょう。 したがって、私たちはそのIPng Fragmentationを信じています、そして、IPv4に提供するReassemblyは必要ではありません。 私たちは、断片化がネットワーク性能に有害であり、それが避けられることを強く勧めるために示されたことに注意します。
6.2 IP Header Checksum
6.2 IPヘッダーチェックサム
There has been discussion indicating that the IP Checksum does not provide enough error protection to warrant its performance impact. The argument states that there is almost always a stronger datalink level CRC, and that end-to-end protection is provided by the TCP checksum. Therefore we believe that an IPng checksum is not required per-se.
IP Checksumが性能影響を保証できるくらいの誤り保護を提供しないのを示す議論がありました。 より強いデータリンクがほとんどいつもある議論州はCRCを平らにします、そして、TCPチェックサムは終わりから終わりへのその保護を提供します。 したがって、私たちは、IPngチェックサムがそういうものとして必要でないと信じています。
Partridge and Kastenholz [Page 26] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[26ページ]RFC1726IPng
6.3 Firewalls
6.3 ファイアウォール
Some have requested that IPng include support for firewalls. The authors believe that firewalls are one particular solution to the problem of security and, as such, do not consider that support for firewalls is a valid requirement for IPng. (At the same time, we would hope that no IPng is hostile to firewalls without offering some equivalent security solution).
或るものは、IPngがファイアウォールのサポートを含んでいるよう要求しました。 作者は、ファイアウォールがセキュリティの問題の1つの特殊解であると信じて、ファイアウォールのサポートがIPngに、有効な要件であるとそういうものとして考えません。 (同時に、私たちは、どんなIPngも何らかの同等なセキュリティソリューションを提供しないでファイアウォールに敵軍でないことを望んでいるでしょう。)
6.4 Network Management
6.4 ネットワークマネージメント
Network Management properly is a task to be carried out by additional protocols and standards, such as SNMP and its MIBs. We believe that network management, per se, is not an attribute of the IPng protocol. Furthermore, network management is viewed as a support, or service, function. Network management should be developed to fit IPng and not the other way round.
ネットワークManagementは適切に追加議定書と規格によって行われるべきタスクです、SNMPやそのMIBsのように。 私たちは、ネットワークマネージメントがそういうものとしてIPngプロトコルの属性でないと信じています。 その上、サポート、またはサービスが機能するとき、ネットワークマネージメントは見られます。 ネットワークマネージメントは、もう片方の道ではなく、IPngをしっかりつかむために開発されるべきです。
6.5 Accounting
6.5 会計
We believe that accounting, like network management, must be designed to fit the IPng protocol, and not the other way round. Therefore, accounting, in and of itself, is not a requirement of IPng. However, there are some facets of the protocol that have been specified to make accounting easier, such as non-repudiation of origin under security, and the unique naming requirement for sorting datagrams into classes. Note that a parameter of network service that IPng must support is cost.
私たちは、ぐるりと他の道ではなく、IPngプロトコルに合うようにネットワークマネージメントのように会計を設計しなければならないと信じています。 したがって、会計はそういうものとしてIPngの要件ではありません。 しかしながら、より簡単な状態で勘定するために指定されたプロトコルのいくつかの一面があります、セキュリティの下における発生源の非拒否や、データグラムをクラスに分類するためのユニークな命名要件などのように。 IPngがサポートしなければならないネットワーク・サービスのパラメタが費用であることに注意してください。
6.6 Routing
6.6 ルート設定
Routing is a very critical part of the Internet. In fact, the Internet Engineering Task Force has a separate Area which is chartered to deal only with routing issues. This Area is separate from the more general Internet Area.
ルート設定はインターネットの非常に重大な地域です。 事実上、インターネット・エンジニアリング・タスク・フォースはルーティング問題だけに対処するためにチャーターされる別々のAreaを持っています。 このAreaは、より一般的なインターネットAreaから別々です。
We see that routing is also a critical component of IPng. There are several criteria, such as Scaling, Addressing, and Network Services, which are intimately entwined with routing. In order to stress the critical nature and importance of routing, we have chosen to devote a separate chapter to specifically enumerating some of the requirements and issues that IPng routing must address. All of these issues, we believe, fall out of the general criteria presented in the previous chapter.
私たちは、また、ルーティングがIPngの重要な要素であることがわかります。 ルーティングで親密にからませられるScalingや、Addressingや、Network Servicesなどのいくつかの評価基準があります。 ルーティングの重要な自然と重要性を強調するために、私たちは、明確にIPngルーティングが扱わなければならない要件と問題のいくつかを列挙するのに別々の章をささげるのを選びました。 私たちは、これらの問題のすべてが前の章に提示された一般的な評価基準から落下すると信じています。
Partridge and Kastenholz [Page 27] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[27ページ]RFC1726IPng
6.6.1 Scale
6.6.1 スケール
First and foremost, the routing architecture must scale to support
a very large Internet. Current expectations are for an Internet
of about 10**9 to 10**12 networks. The routing architecture must
be able to deal with networks of this size. Furthermore, the
routing architecture must be able to deal with this size without
requiring massive, global databases and algorithms. Such
databases or algorithms would, in effect, be single points of
failure in the architecture (which is not robust), and because of
the nature of Internet administration (cooperative anarchy), it
would be impossible to maintain the needed consistency.
まず第一に、ルーティングアーキテクチャは非常に大きいインターネットについてサポートに合わせて調整しなければなりません。 およそ10**9〜10**12のネットワークのインターネットには現在の期待があります。 ルーティングアーキテクチャはこのサイズのネットワークと取り引きできなければなりません。 その上、大規模で、グローバルなデータベースとアルゴリズムを必要としないで、ルーティングアーキテクチャはこのサイズに対処できなければなりません。事実上、そのようなデータベースかアルゴリズムがアーキテクチャ(強健でない)での単一のポイントの失敗でしょう、そして、インターネット管理(協力的なアナーキー)の本質のために、必要な一貫性を維持するのは不可能でしょう。
6.6.2 Policy
6.6.2 方針
Networks (both transit and non-transit) must be able to set their
own policies for the types of traffic that they will admit. The
routing architecture must make these policies available to the
network as a whole. Furthermore, nodes must be able to select
routes for their traffic based on the advertised policies.
ネットワーク(トランジットと非トランジットの両方)は彼らが認めるトラフィックのタイプにそれら自身の方針を設定できなければなりません。 ルーティングアーキテクチャで、これらの方針は全体でネットワークに利用可能にならなければなりません。 その上、ノードは広告を出している方針に基づくそれらのトラフィックのためにルートを選択できなければなりません。
6.6.3 QOS
6.6.3 QOS
A key element of the network service criteria is that differing
applications wish to acquire differing grades of network service.
It is essential that this service information be propagated around
the network.
ネットワーク業務基準の主要な要素は異なったアプリケーションがネットワーク・サービスの異なったグレードを取得したがっているということです。 このサービス情報がネットワークの周りで伝播されるのは、不可欠です。
6.6.4 Feedback
6.6.4 フィードバック
As users select specific routes over which to send their traffic,
they must be provided feedback from the routing architecture. This
feedback should allow the user to determine whether the desired
routes are actually available or not, whether the desired services
are being provided, and so forth.
ユーザがそれらのトラフィックを送る特定のルートを選択するとき、フィードバックをルーティングアーキテクチャからそれらに提供しなければなりません。 ユーザは、このフィードバックで必要なルートが実際に利用可能であるかどうかと決心できるべきです、必要なサービスが提供されて、などであるか否かに関係なく。
This would allow users to modify their service requirements or
even change their routes, as needed.
これで、ユーザは、彼らのサービス要件を変更するか、または必要であるようにそれらのルートを変えるだろうというのさえ。
6.6.5 Stability
6.6.5 安定性
With the addition of additional data into the routing system
(i.e., routes are based not only on connectivity, as in IPv4, but
also on policies, service grades, and so on), the stability of the
routes may suffer. We offer as evidence the early ARPANET which
experimented with load-based routing. Routes would remain in flux,
changing from one saturated link, to another, unused, link.
ルーティングシステム(すなわち、ルートはサービスがIPv4にもかかわらず、方針の上でも等級付けする接続性だけ、などではなく基づいている)への追加データの追加で、ルートの安定性に苦しむかもしれません。 私たちは証拠として負荷ベースのルーティングを実験した早めのアルパネットを提供します。 別のものへの未使用の1個の飽和したリンクから変化して、ルートは流動的に残って、リンクしてください。
Partridge and Kastenholz [Page 28] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[28ページ]RFC1726IPng
This must not be allowed to happen. If anything, routes should be
even more stable under IPng's routing architecture than under the
current architecture.
これを起こらせてはいけません。 どちらかと言えば、ルートは現在のアーキテクチャよりIPngのルーティングアーキテクチャの下でさらに安定しているべきです。
6.6.6 Multicast
6.6.6 マルチキャスト
Multicast will be more important in IPng than it is today in IPv4.
Multicast groups may be very large and very distributed.
Membership in multicast groups will be very dynamic. The routing
architecture must be able to cope with this.
マルチキャストは今日のそれよりIPngでIPv4でさらに重要になるでしょう。 マルチキャストグループは、非常に大きく非常に分配されているかもしれません。 マルチキャストグループにおける会員資格は非常にダイナミックになるでしょう。 ルーティングアーキテクチャはこれに対処できなければなりません。
Furthermore, the routing architecture must be able to build
multicast routes dynamically, based on factors such as group
membership, member location, requested and available qualities of
service, and so on.
その上、ルーティングアーキテクチャはダイナミックにマルチキャストルートを造ることができなければなりません、会員資格(メンバー位置)が要求したグループなどの要素、利用可能なサービスの品質などに基づいて。
7. References
7. 参照
[1] Internet Architecture Board, "IP Version 7", Draft 8, Work in
Progress, July, 1992.
[1]インターネット・アーキテクチャ委員会、「7インチ(草稿8)が進歩、1992年7月に扱うIPバージョン。」
[2] Gross, P., and P. Almquist, "IESG Deliberations on Routing and
Addressing", RFC 1380, IESG Chair, IESG Internet AD, November
1992.
[2] グロス、P.とP.Almquist、「ルート設定とアドレシングにおけるIESG熟考」RFC1380、IESG議長、IESGインターネット西暦(1992年11月)。
[3] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
"Toward the Future Internet Architecture", RFC 1287, MIT, BBN,
CNRI, USC/Information Sciences Institute, UC Davis, December
1991.
[3] クラークとD.とチェーピンとL.とサーフとV.とブレーデン、R.とR.趣味、「将来のインターネットアーキテクチャ」、RFC1287、MIT、BBN、CNRI、科学が設けるUSC/情報、UCデイヴィス(1991年12月)。
[4] Dave Clark's paper at SIGCOMM '88 where he pointed out that the
design of TCP/IP was guided, in large part, by an ordered list of
requirements.
[4] SIGCOMM88年の要件の規則正しいリストによる彼が、TCP/IPのデザインがかなりの部分で案内されたと指摘したデーブ・クラークの新聞。
[5] Vecchi, M., "IPng Requirements: A Cable Television Industry
Viewpoint", RFC 1686, Time Warner Cable, August 1994.
[5] ヴェッキ、M.、「IPng要件:」 「ケーブルテレビ産業観点」、RFC1686、タイム・ワーナーケーブル、1994年8月。
[6] Green, D., Irey, P., Marlow, D. and K. O'Donoghue, "HPN Working
Group Input to the IPng Requirements Solicitation, RFC 1679,
NSWC-DD, August 1994.
[6] グリーン、D.、Irey、P.、マーロウ、D.、およびK.オダナヒュー、「HPN作業部会は1994年8月にIPng要件懇願、RFCに1679、NSWC-DDを入力しました」。
[7] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T Bell
Laboratories, August 1994.
[7] Bellovin、S. 「多くの1ホストあたりのアドレス」のRFC1681、AT&Tベル研究所、1994年8月。
[8] Symington, S., Wood, D., and J. Pullen, "Modelling and Simulation
Requirements for IPng", RFC 1667, Mitre Corporation and George
Mason University, August 1994.
[8] サイミントン、S.、木、D.とJ.ピューレン、「IPngのためのモデル化とシミュレーション要件」RFC1667、斜め継ぎ社、およびジョージメイスン大学(1994年8月)。
Partridge and Kastenholz [Page 29] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[29ページ]RFC1726IPng
[9] Internet Architecture Board, "Report of the IAB Workshop on
Security in the Internet Architecture, RFC 1636, IAB, June 1994.
[9]インターネット・アーキテクチャ委員会、「インターネットアーキテクチャにおけるセキュリティに関するIABワークショップ、RFC1636、IAB、1994年6月のレポート。」
[10] Private EMAIL from Tony Li to IPNG Directorate Mailing List, 18
April 1994 18:42:05.
[10] 個人的なトニー・李からIPNG管理職メーリングリスト、1994年4月18日の18:42:05までのメール。
[11] Saltzer, J., On the Naming and Binding of Network Destinations",
RFC 1498, M.I.T. Laboratory for Computer Science, August 1993.
「[11]Saltzer、ネットワークの目的地の命名と結合でのJ.」、RFC1498、マサチューセッツ工科大学コンピュータ科学研究所、8月1993
[12] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, DARPA, September
1981.
[12] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、DARPA、1981年9月。
[13] EMAIL from Robert Elz to the Big Internet mailing list,
approximately 4 May 1994.
[13] ロバートから、BigインターネットメーリングリストへのElz、1994年5月4日頃をメールしてください。
[14] Chiappa, N., "Nimrod and IPng Technical Requirements", Work in
Progress.
[14] N.と、「ニムロデとIPng技術的要求事項」というChiappaは進行中で働いています。
8. Security Considerations
8. セキュリティ問題
Security is not directly addressed by this memo. However, as this memo codifies goals for a new generation of network layer protocol, the security provided by such a protocol is addressed. Security has been raised as an issue in several of the requirements stated in this memo. Furthermore, a specific requirement for security has been made.
セキュリティはこのメモで直接扱われません。 しかしながら、このメモがネットワーク層プロトコルの新しい世代の目標を成文化するとき、そのようなプロトコルによって提供されたセキュリティは扱われます。 いくつかの要件の問題がこのメモに述べたようにセキュリティは上げられました。 その上、セキュリティのための決められた一定の要求は作られています。
9. Acknowledgements
9. 承認
The authors gratefully acknowledge the assistance and input provided by the many people who have reviewed and commented upon this document.
作者は感謝してこのドキュメントを再検討して、批評した多くの人々によって提供された支援と入力を承諾します。
Partridge and Kastenholz [Page 30] RFC 1726 IPng Technical Criteria December 1994
評価基準1994年12月に技術的なヤマウズラとKastenholz[30ページ]RFC1726IPng
10. Authors' Addresses
10. 作者のアドレス
Craig Partridge BBN Systems and Technologies 10 Moulton St. Cambridge, MA 02138
クレイグヤマウズラBBNシステムとケンブリッジ、技術10モールトン通りMA 02138
EMail: craig@aland.bbn.com
メール: craig@aland.bbn.com
Frank Kastenholz FTP Software, Inc. 2 High St. North Andover, MA, 01845-2620 USA
フランクKastenholz FTPソフトウェアInc.2の高い聖ノースアンドーバー、MA01845-2620米国
EMail: kasten@ftp.com
メール: kasten@ftp.com
Partridge and Kastenholz [Page 31]
ヤマウズラとKastenholz[31ページ]
一覧
スポンサーリンク
