RFC1958 日本語訳

Network Working Group                               B. Carpenter, Editor
Request for Comments: 1958                                           IAB
Category: Informational                                        June 1996

ワーキンググループのB.大工、コメントを求めるエディタ要求をネットワークでつないでください: 1958年のIABカテゴリ: 情報の1996年6月

                Architectural Principles of the Internet

インターネットの建築プリンシプルズ

Status of This 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

要約

   The Internet and its architecture have grown in evolutionary fashion
   from modest beginnings, rather than from a Grand Plan. While this
   process of evolution is one of the main reasons for the technology's
   success, it nevertheless seems useful to record a snapshot of the
   current principles of the Internet architecture. This is intended for
   general guidance and general interest, and is in no way intended to
   be a formal or invariant reference model.

インターネットとその構造はGrand Planからというよりむしろ穏やかな始めからの進化論のファッションで発展しました。 発展のこの過程は技術の成功の主な理由の1つですが、それにもかかわらず、インターネット構造の現在の原理のスナップを記録するのは役に立つように思えます。 これは、一般的な指導と一般的興味のために意図して、正式であるか不変な規範モデルであることを決して意図しません。

Table of Contents

目次

      1. Constant Change..............................................1
      2. Is there an Internet Architecture?...........................2
      3. General Design Issues........................................4
      4. Name and address issues......................................5
      5. External Issues..............................................6
      6. Related to Confidentiality and Authentication................6
      Acknowledgements................................................7
      References......................................................7
      Security Considerations.........................................8
      Editor's Address................................................8

1. 一定の変化…1 2. インターネットArchitectureがありますか?2 3. 一般デザイン問題…4 4. 問題を命名して、記述してください…5 5. 外部の問題…6 6. 秘密性と認証に関連します…6つの承認…7つの参照箇所…7 セキュリティ問題…8エディタのアドレス…8

1. Constant Change

1. 一定の変化

   In searching for Internet architectural principles, we must remember
   that technical change is continuous in the information technology
   industry. The Internet reflects this.  Over the 25 years since the
   ARPANET started, various measures of the size of the Internet have
   increased by factors between 1000 (backbone speed) and 1000000
   (number of hosts). In this environment, some architectural principles
   inevitably change.  Principles that seemed inviolable a few years ago
   are deprecated today. Principles that seem sacred today will be
   deprecated tomorrow. The principle of constant change is perhaps the
   only principle of the Internet that should survive indefinitely.

インターネットの建築原則を捜し求める際に、私たちは、技術変化が情報技術産業で連続しているのを覚えていなければなりません。 インターネットはこれを反映します。 アルパネットが始まって以来の25年間、インターネットのサイズの様々な基準は1000の間の要素(背骨速度)と1000000(ホストの数)増加しています。 この環境で、いくつかの建築原則が必然的に変化します。 数年前に神聖に思えた原則は今日、非難されます。 今日神聖に見える原則は明日、非難されるでしょう。 一定の変化の原則は恐らく無期限に存続するべきであるインターネットの唯一の原則です。

IAB                          Informational                      [Page 1]

RFC 1958        Architectural Principles of the Internet       June 1996

インターネットプリンシプルズ1996年6月に建築しているIAB情報[1ページ]のRFC1958

   The purpose of this document is not, therefore, to lay down dogma
   about how Internet protocols should be designed, or even about how
   they should fit together. Rather, it is to convey various guidelines
   that have been found useful in the past, and that may be useful to
   those designing new protocols or evaluating such designs.

したがって、それらがインターネットプロトコルがどう設計されるべきであるか、そして、どう一緒に合いさえするべきであるかに関する教義を定めるために、このドキュメントの目的はありません。 むしろ、それは過去に役に立つのが見つけられた、新しいプロトコルを設計するか、またはそのようなデザインを評価するものの役に立つかもしれない様々なガイドラインを伝えることになっています。

   A good analogy for the development of the Internet is that of
   constantly renewing the individual streets and buildings of a city,
   rather than razing the city and rebuilding it. The architectural
   principles therefore aim to provide a framework for creating
   cooperation and standards, as a small "spanning set" of rules that
   generates a large, varied and evolving space of technology.

インターネットの発展のための良い類推は都市を完全に破壊して、それを再建するより絶えずむしろ都市の個々の通りとビルを取り替えるものです。 したがって、建築原則は、協力と規格を作成するのに枠組みを提供することを目指します、技術の大きくて、様々で発展しているスペースを発生させる小さい「わたるセット」の規則として。

   Some current technical triggers for change include the limits to the
   scaling of IPv4, the fact that gigabit/second networks and multimedia
   present fundamentally new challenges, and the need for quality of
   service and security guarantees in the commercial Internet.

変化のためのいくつかの現在の技術的な引き金が商業インターネットにIPv4のスケーリングへの限界、ギガビット/第2ネットワークとマルチメディアが基本的に新しい挑戦を提示するという事実、およびサービスの質とセキュリティ保証の必要性を含んでいます。

   As Lord Kelvin stated in 1895, "Heavier-than-air flying machines are
   impossible." We would be foolish to imagine that the principles
   listed below are more than a snapshot of our current understanding.

主のケルビンが1895年に述べたように、「空気より重い航空機は不可能です」。 以下に記載された原則が私たちの現在の理解の1以上スナップであると想像するとは私たちは愚かでしょう。

2. Is there an Internet Architecture?

2. インターネットArchitectureがありますか?

   2.1 Many members of the Internet community would argue that there is
   no architecture, but only a tradition, which was not written down for
   the first 25 years (or at least not by the IAB).  However, in very
   general terms, the community believes that the goal is connectivity,
   the tool is the Internet Protocol, and the intelligence is end to end
   rather than hidden in the network.

2.1 インターネットコミュニティの多くのメンバーが、構造がない、しかし、伝統しかないと主張するでしょう。(伝統は最初の25年間(または、少なくともいずれのIABでも、そうしない)書き留められませんでした)。 しかしながら、非常に一般的な用語で、共同体は、ネットワークに隠されるよりむしろ終わるために目標が接続性であり、ツールがインターネットプロトコルであり、知性が終わりであると信じています。

   The current exponential growth of the network seems to show that
   connectivity is its own reward, and is more valuable than any
   individual application such as mail or the World-Wide Web.  This
   connectivity requires technical cooperation between service
   providers, and flourishes in the increasingly liberal and competitive
   commercial telecommunications environment.

ネットワークの現在の急激な増加はその接続性を示しているのがそれ自身の報酬であり、メールかWWWなどのどんな個々のアプリケーションよりも貴重であるように思えます。 この接続性は、サービスプロバイダーの間で技術協力を必要として、ますます寛容で競争力がある商業テレコミュニケーション環境で派手な振る舞いを必要とします。

   The key to global connectivity is the inter-networking layer.  The
   key to exploiting this layer over diverse hardware providing global
   connectivity is the "end to end argument".

グローバルな接続性のキーはインターネットワーキング層です。 グローバルな接続性を提供しながらさまざまのハードウェアの上でこの層を利用するキーは「議論を終わらせる終わり」です。

   2.2 It is generally felt that in an ideal situation there should be
   one, and only one, protocol at the Internet level.  This allows for
   uniform and relatively seamless operations in a competitive, multi-
   vendor, multi-provider public network.  There can of course be
   multiple protocols to satisfy different requirements at other levels,
   and there are many successful examples of large private networks with

2.2 それは一般に、あるべきである理想的な状況で1、および1つだけがインターネットで議定書を作ると感じられたレベルです。 これは競争力があって、マルチ業者の、そして、マルチプロバイダーの公衆通信回線における一定の、そして、比較的シームレスの操作を考慮します。 他のレベルで異なった要件を満たす複数のプロトコルがもちろんあることができます、そして、大きい私設のネットワークの多くのうまくいっている例があります。

IAB                          Informational                      [Page 2]

RFC 1958        Architectural Principles of the Internet       June 1996

インターネットプリンシプルズ1996年6月に建築しているIAB情報[2ページ]のRFC1958

   multiple network layer protocols in use.

使用中の複数のネットワーク層プロトコル。

   In practice, there are at least two reasons why more than one network
   layer protocol might be in use on the public Internet. Firstly, there
   can be a need for gradual transition from one version of IP to
   another.  Secondly, fundamentally new requirements might lead to a
   fundamentally new protocol.

実際には、1つ以上のネットワーク層プロトコルが公共のインターネットで使用中であるかもしれない少なくとも2つの理由があります。 まず第一に、ゆるやかなIPの1つのバージョンから別のバージョンまでの変遷の必要があることができます。 第二に、基本的に新しい要件は基本的に新しいプロトコルにつながるかもしれません。

   The Internet level protocol must be independent of the hardware
   medium and hardware addressing.  This approach allows the Internet to
   exploit any new digital transmission technology of any kind, and to
   decouple its addressing mechanisms from the hardware. It allows the
   Internet to be the easy way to interconect fundamentally different
   transmission media, and to offer a single platform for a wide variety
   of Information Infrastructure applications and services. There is a
   good exposition of this model, and other important fundemental
   issues, in [Clark].

インターネットレベルプロトコルはハードウェア媒体とハードウェアアドレシングから独立しているに違いありません。 このアプローチで、インターネットをどんな種類のどんな新しいデジタルトランスミッション技術も利用して、ハードウェアからメカニズムを記述するのは衝撃を吸収します。 それは、インターネットが基本的に異なったトランスミッションメディアをinterconectして、さまざまな情報Infrastructureアプリケーションとサービスのために単一のプラットホームを提供する簡単な方法であることを許容します。 このモデル、および他の重要なfundemental問題の良い博覧会が[クラーク]であります。

   2.3 It is also generally felt that end-to-end functions can best be
   realised by end-to-end protocols.

2.3 また、一般に、終わりから終わりへのプロトコルで終わりから終わりへの機能を特にわかられることができると感じられます。

   The end-to-end argument is discussed in depth in [Saltzer].  The
    basic argument is that, as a first principle, certain required end-
   to-end functions can only be performed correctly by the end-systems
   themselves. A specific case is that any network, however carefully
   designed, will be subject to failures of transmission at some
   statistically determined rate. The best way to cope with this is to
   accept it, and give responsibility for the integrity of communication
   to the end systems. Another specific case is end-to-end security.

[Saltzer]で終わりから終わりへの議論について徹底的に議論します。 基本的な議論は原則としてエンドシステム自体で正しく終わりまでのある必要な終わりの機能を実行できるだけであるということです。 特定のケースはどんなしかしながら、入念に設計されたネットワークも何らかの統計的に決定しているレートでのトランスミッションの失敗を被りやすくなるということです。 これに対処する最も良い方法は、コミュニケーションの保全のためにエンドシステムにそれを受け入れて、責任を与えることです。別の特定のケースは終わりから終わりへの保証です。

   To quote from [Saltzer], "The function in question can completely and
   correctly be implemented only with the knowledge and help of the
   application standing at the endpoints of the communication system.
   Therefore, providing that questioned function as a feature of the
   communication system itself is not possible. (Sometimes an incomplete
   version of the function provided by the communication system may be
   useful as a performance enhancement.")

[Saltzer]から引用するために、「アプリケーションの知識と助けだけが通信系の終点に立っていて、完全に正しく問題の機能を実行できます」。 したがって、質問されるなら、通信系自体の特徴としての機能は可能ではありません。 「(時々、通信系によって提供された機能の不完全なバージョンがパフォーマンス強化として役に立つかもしれない、」、)。

   This principle has important consequences if we require applications
   to survive partial network failures. An end-to-end protocol design
   should not rely on the maintenance of state (i.e. information about
   the state of the end-to-end communication) inside the network. Such
   state should be maintained only in the endpoints, in such a way that
   the state can only be destroyed when the endpoint itself breaks
   (known as fate-sharing). An immediate consequence of this is that
   datagrams are better than classical virtual circuits.  The network's
   job is to transmit datagrams as efficiently and flexibly as possible.

この原則には、私たちが部分的なネットワーク失敗を乗り切るためにアプリケーションを必要とするなら、重要な結果があります。 終わりから終わりへのプロトコルデザインはネットワークの中で状態(すなわち、エンド・ツー・エンド通信の状態の情報)の維持に依存するべきではありません。 そのような状態は終点だけで維持されるべきです、終点自体が壊れると(運命を共有しているとして、知られています)状態を破壊できるだけであるような方法で。 この即座の結果はデータグラムが古典的な仮想のサーキットより良いということです。 ネットワークの仕事はできるだけ効率的に柔軟にデータグラムを送ることです。

IAB                          Informational                      [Page 3]

RFC 1958        Architectural Principles of the Internet       June 1996

インターネットプリンシプルズ1996年6月に建築しているIAB情報[3ページ]のRFC1958

   Everything else should be done at the fringes.

フリンジで他の何もかもをするべきです。

   To perform its services, the network maintains some state
   information: routes, QoS guarantees that it makes, session
   information where that is used in header compression, compression
   histories for data compression, and the like. This state must be
   self-healing; adaptive procedures or protocols must exist to derive
   and maintain that state, and change it when the topology or activity
   of the network changes. The volume of this state must be minimized,
   and the loss of the state must not result in more than a temporary
   denial of service given that connectivity exists.  Manually
   configured state must be kept to an absolute minimum.

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

   2.4 Fortunately, nobody owns the Internet, there is no centralized
   control, and nobody can turn it off. Its evolution depends on rough
   consensus about technical proposals, and on running code.
   Engineering feed-back from real implementations is more important
   than any architectural principles.

2.4 幸い、だれもインターネットを所有しないで、集中制御が全くなくて、だれもそれをオフにすることができません。 発展は技術条件提案書に関する荒いコンセンサスと、そして、走行コードに依存します。 本当の実現からの工学フィードバックはどんな建築原則よりも重要です。

3. General Design Issues

3. 一般デザイン問題

   3.1 Heterogeneity is inevitable and must be supported by design.
   Multiple types of hardware must be allowed for, e.g. transmission
   speeds differing by at least 7 orders of magnitude, various computer
   word lengths, and hosts ranging from memory-starved microprocessors
   up to massively parallel supercomputers. Multiple types of
   application protocol must be allowed for, ranging from the simplest
   such as remote login up to the most complex such as distributed
   databases.

3.1 異種性を必然であり、故意に支持しなければなりません。 複数のタイプのハードウェアを考慮しなければなりません、例えば伝送速度が少なくとも7桁、様々なコンピュータ語長、およびメモリに飢えるマイクロプロセッサから膨大に平行なスーパーコンピュータまで変化するホストで異なって。 複数のタイプのアプリケーション・プロトコルを考慮しなければなりません、最も多くの複合体までのリモート・ログインなどについて分散データベースなどについて最も簡単であるのから変化して。

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

同じことをするいくつかの方法があれば、3.2に、1つを選んでください。 前のデザインがインターネット文脈かほかの場所で首尾よく同じ問題を解決して、十分な技術的な理由がない場合、同じ解決策を選んでください。 同じプロトコルの機能性の重複はできるだけ避けられるべきです、改良を拒絶するのにもちろんこの議論を使用しないで。

   3.3 All designs must scale readily to very many nodes per site and to
   many millions of sites.

3.3 すべてのデザインが容易に非常に多くの1サイトあたりのノードと、そして、何百万ものサイトに比例しなければなりません。

   3.4 Performance and cost must be considered as well as functionality.

また、機能性であると3.4パフォーマンスと費用をみなさなければなりません。

   3.5 Keep it simple. When in doubt during design, choose the simplest
   solution.

3.5はそれを簡単に保ちます。 デザインの間、疑問で選ぶときには、最も簡単な解決策を選んでください。

   3.6 Modularity is good. If you can keep things separate, do so.

3.6モジュール方式は良いです。 事態を別々に保つことができるなら、そうしてください。

IAB                          Informational                      [Page 4]

RFC 1958        Architectural Principles of the Internet       June 1996

インターネットプリンシプルズ1996年6月に建築しているIAB情報[4ページ]のRFC1958

   3.7 In many cases it is better to adopt an almost complete solution
   now, rather than to wait until a perfect solution can be found.

3.7 多くの場合、完全な解決を見つけることができるまで待つというよりむしろ現在、ほとんど完全な解決策を採用しているほうがよいです。

   3.8 Avoid options and parameters whenever possible.  Any options and
   parameters should be configured or negotiated dynamically rather than
   manually.

可能であるときはいつも、3.8はオプションとパラメタを避けます。 どんなオプションとパラメタも、手動であるというよりむしろダイナミックに構成されるべきであるか、または交渉されるべきです。

   3.9 Be strict when sending and tolerant when receiving.
   Implementations must follow specifications precisely when sending to
   the network, and tolerate faulty input from the network. When in
   doubt, discard faulty input silently, without returning an error
   message unless this is required by the specification.

3.9 発信すると厳しくて、受信するときには許容性があってください。 実現は、まさにネットワークに発信するとき、仕様に従って、ネットワークからの不完全な入力を許容しなければなりません。 疑問で捨てるときには、これが仕様によって必要とされない場合エラーメッセージを返さないで、静かに不完全な入力を捨ててください。

   3.10 Be parsimonious with unsolicited packets, especially multicasts
   and broadcasts.

3.10 求められていないパケット、特にマルチキャスト、および放送にけちにしてください。

   3.11 Circular dependencies must be avoided.

3.11 円形の依存を避けなければなりません。

      For example, routing must not depend on look-ups in the Domain
      Name System (DNS), since the updating of DNS servers depends on
      successful routing.

例えば、ルーティングはドメインネームシステム(DNS)におけるルックアップによってはいけません、DNSサーバのアップデートがうまくいっているルーティングによるので。

   3.12 Objects should be self decribing (include type and size), within
   reasonable limits. Only type codes and other magic numbers assigned
   by the Internet Assigned Numbers Authority (IANA) may be used.

3.12個の物が妥当な限界の中でdecribingする(タイプとサイズを含んでいます)自己であるべきです。 単にコードをタイプしてください。そうすれば、インターネットAssigned民数記Authority(IANA)によって割り当てられた他のマジックナンバーは使用されてもよいです。

   3.13 All specifications should use the same terminology and notation,
   and the same bit- and byte-order convention.

3.13 すべての仕様が同じ用語、記法、同じビット、およびバイトオーダーコンベンションを使用するべきです。

   3.14 And perhaps most important: Nothing gets standardised until
   there are multiple instances of running code.

3.14 恐らく最も重要です: 走行コードの複数の例があるまで、何も標準化されません。

4. Name and address issues

4. 問題を命名して、記述してください。

   4.1 Avoid any design that requires addresses to be hard coded or
   stored on non-volatile storage (except of course where this is an
   essential requirement as in a name server or configuration server).
   In general, user applications should use names rather than addresses.

4.1は非揮発性記憶装置(もちろん、ネームサーバや構成サーバのようにこれが必須の条件であるところで除く)でコード化されるか、または格納されて、アドレスが困難であることを必要とするどんなデザインも避けます。 一般に、ユーザアプリケーションはアドレスよりむしろ名前を使用するべきです。

   4.2 A single naming structure should be used.

4.2 構造を命名するシングルは使用されるべきです。

   4.3 Public (i.e. widely visible) names should be in case-independent
   ASCII.  Specifically, this refers to DNS names, and to protocol
   elements that are transmitted in text format.

4.3 ケースから独立しているASCIIには公共(すなわち、広く目に見える)の名前があるべきです。 明確に、これはDNS名、およびテキスト形式で伝えられるプロトコル要素を参照します。

   4.4 Addresses must be unambiguous (unique within any scope where they
   may appear).

4.4のアドレスが明白であるに違いありません(どんな範囲でも中それらが現れるかもしれないユニークな)。

IAB                          Informational                      [Page 5]

RFC 1958        Architectural Principles of the Internet       June 1996

インターネットプリンシプルズ1996年6月に建築しているIAB情報[5ページ]のRFC1958

   4.5 Upper layer protocols must be able to identify end-points
   unambiguously. In practice today, this means that addresses must be
   the same at start and finish of transmission.

4.5 上側の層のプロトコルは明白にエンドポイントを特定できなければなりません。 今日の習慣では、これは、アドレスがトランスミッションの始めと終わりで同じであるに違いないことを意味します。

5. External Issues

5. 外部の問題

   5.1 Prefer unpatented technology, but if the best technology is
   patented and is available to all at reasonable terms, then
   incorporation of patented technology is acceptable.

5.1は「非-特許をと」られた技術を好みますが、最も良い技術が特許をとられて、無理のない条件にすべてに利用可能であるなら、特許で保護された技術の編入は許容できます。

   5.2 The existence of export controls on some aspects of Internet
   technology is only of secondary importance in choosing which
   technology to adopt into the standards. All of the technology
   required to implement Internet standards can be fabricated in each
   country, so world wide deployment of Internet technology does not
   depend on its exportability from any particular country or countries.

5.2 どの技術を規格に採用したらよいかを選ぶのにおいてインターネット技術のいくつかの局面における輸出管理の存在は二次に単に重要です。 各国にインターネット標準を実行するのに必要である技術のすべてを作ることができます、非常に世界中ので、インターネット技術の展開はどんな特定の国や国からも「外-携帯性」によりません。

   5.3 Any implementation which does not include all of the required
   components cannot claim conformance with the standard.

5.3 必要なコンポーネントのすべてを含んでいないどんな実現も規格で順応を要求できません。

   5.4 Designs should be fully international, with support for
   localisation (adaptation to local character sets). In particular,
   there should be a uniform approach to character set tagging for
   information content.

5.4のデザインが局所化(ローカルキャラクターセットへの適合)のサポートで完全に国際的であるべきです。 特に、情報量のための文字の組タグ付けへの一定のアプローチがあるべきです。

6. Related to Confidentiality and Authentication

6. 秘密性と認証に関連されます。

   6.1 All designs must fit into the IP security architecture.

6.1 すべてのデザインがIPセキュリティー体系に収まらなければなりません。

   6.2 It is highly desirable that Internet carriers protect the privacy
   and authenticity of all traffic, but this is not a requirement of the
   architecture.  Confidentiality and authentication are the
   responsibility of end users and must be implemented in the protocols
   used by the end users. Endpoints should not depend on the
   confidentiality or integrity of the carriers. Carriers may choose to
   provide some level of protection, but this is secondary to the
   primary responsibility of the end users to protect themselves.

6.2 インターネットキャリヤーがすべての交通のプライバシーと信憑性を保護しますが、これが構造の要件でないことは非常に望ましいです。 秘密性と認証をエンドユーザの責任であり、エンドユーザによって使用されたプロトコルで実行しなければなりません。 終点はキャリヤーの秘密性か保全によるべきではありません。 キャリヤーは、何らかのレベルの保護を提供するのを選ぶかもしれませんが、これはエンドユーザが我が身をかばう責務に次ぎます。

   6.3 Wherever a cryptographic algorithm is called for in a protocol,
   the protocol should be designed to permit alternative algorithms to
   be used and the specific algorithm employed in a particular
   implementation should be explicitly labeled. Official labels for
   algorithms are to be recorded by the IANA.

6.3 どこでも、暗号アルゴリズムが求められるところに、プロトコルでは、プロトコルは代替のアルゴリズムが使用されることを許可するように設計されるべきであり、特定の実現で使われた特定のアルゴリズムは明らかにラベルされるべきです。 アルゴリズムのための職名はIANAによって記録されることになっています。

   (It can be argued that this principle could be generalised beyond the
   security area.)

(セキュリティ領域を超えてこの原則を一般化できたと主張できます。)

IAB                          Informational                      [Page 6]

RFC 1958        Architectural Principles of the Internet       June 1996

インターネットプリンシプルズ1996年6月に建築しているIAB情報[6ページ]のRFC1958

   6.4 In choosing algorithms, the algorithm should be one which is
   widely regarded as strong enough to serve the purpose. Among
   alternatives all of which are strong enough, preference should be
   given to algorithms which have stood the test of time and which are
   not unnecessarily inefficient.

6.4 アルゴリズムを選ぶのにおいて、アルゴリズムは広く目的に適うことができるくらい強いと見なされるものであるべきです。 それのすべてが十分強い代替手段の中では、時の試練に耐えている、不必要に効率が悪くないアルゴリズムに優先を与えるべきです。

   6.5 To ensure interoperation between endpoints making use of security
   services, one algorithm (or suite of algorithms) should be mandated
   to ensure the ability to negotiate a secure context between
   implementations. Without this, implementations might otherwise not
   have an algorithm in common and not be able to communicate securely.

6.5 終点の間でセキュリティー・サービスを利用することでinteroperationを確実にするなら、1つのアルゴリズム(または、アルゴリズムのスイート)が、実現の間の安全な関係を交渉する能力を確実にするために強制されるべきです。 これがなければ、実現は、そうでなければ、アルゴリズムが共通でなく、しっかりと交信できないかもしれません。

Acknowledgements

承認

   This document is a collective work of the Internet community,
   published by the Internet Architecture Board. Special thanks to Fred
   Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal
   McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan.

このドキュメントはインターネット・アーキテクチャ委員会によって発行されたインターネットコミュニティの集合著作物です。 フレッド・ベイカー、クリスマスChiappa、ドナルド・イーストレーク、フランクKastenholz、ニールMcBurnett、Masataka太田、ジェフ・シラー、およびランシング・スローンへの特別な感謝。

References

参照

   Note that the references have been deliberately limited to two
   fundamental papers on the Internet architecture.

参照が故意にインターネット構造の2個の基本的な書類に制限されたことに注意してください。

   [Clark] The Design Philosophy of the DARPA Internet Protocols,
   D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988,
   pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995,
   pages 102-111).

[クラーク] DARPAインターネットプロトコル(Proc SIGCOMM88、ACM CCR Vol18、Number4、1988年8月、106-114ページ(ACM CCR Vol25、Number1、1995年1月、102-111ページでは、翻刻します)のD.D.クラーク)のDesign Philosophy。

   [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,
   D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp
   277-288.

System Designの[Saltzer]終わりから終わりへのArguments、J.H.Saltzer、D.P.リード、D.D.クラーク、ACM TOCS Vol2、Number4、1984年11月、pp277-288。

IAB                          Informational                      [Page 7]

RFC 1958        Architectural Principles of the Internet       June 1996

インターネットプリンシプルズ1996年6月に建築しているIAB情報[7ページ]のRFC1958

Security Considerations

セキュリティ問題

   Security issues are discussed throughout this memo.

このメモ中で安全保障問題について議論します。

Editor's Address

エディタのアドレス

   Brian E. Carpenter
   Group Leader, Communications Systems
   Computing and Networks Division
   CERN
   European Laboratory for Particle Physics
   1211 Geneva 23, Switzerland

ブライアンE.大工のグループのリーダーと通信網コンピューティングとネットワーク事業部CERN欧州原子核共同研究機構1211ジュネーブ23、スイス

   Phone:  +41 22 767-4967
   Fax:    +41 22 767-7155
   EMail: brian@dxcoms.cern.ch

以下に電話をしてください。 +41 22 767-4967Fax: +41 22 767-7155 メールしてください: brian@dxcoms.cern.ch

IAB                          Informational                      [Page 8]

IAB情報です。[8ページ]