RFC985 日本語訳
0985 Requirements for Internet gateways - draft. National ScienceFoundation, Network Technical Advisory Group. May 1986. (Format: TXT=59221 bytes) (Obsoleted by RFC1009) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Network Technical Advisory Group
Request for Comments: 985 NSF
May 1986
技術的な顧問団がコメントのために要求するワーキンググループネットワークをネットワークでつないでください: 985 NSF1986年5月
Requirements for Internet Gateways -- Draft
インターネットゲートウェイのための要件--草稿
Status of this Memo
このMemoの状態
This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. This document was prepared by the Gateway Requirements Subcommittee of the NSF Network Technical Advisory Group in cooperation with the Internet Activities Board, Internet Architecture Task Force and Internet Engineering Task Force. It requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCはDARPAインターネットがプロトコルであるとサポートしながらゲートウェイがネットワークで使用されるという要件をまとめます。 それが特に科学基金の研究計画に適用されている間、要件は、一般情勢に述べられていて、インターネットコミュニティ中で適切であると信じられています。 このドキュメントはインターネットActivities Board、インターネットArchitecture Task Force、およびインターネット・エンジニアリング・タスク・フォースと提携してNSF Network Technical Advisory GroupのゲートウェイRequirements Subcommitteeによって準備されました。 それは改良のための議論と提案を要求します。 このメモの分配は無制限です。
The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specifications. In a number of cases the specifications are evolving and may contain ambiguous or incomplete information. In these cases further discussion giving specific guidance is included in this document. Specific policy issues relevant to the NSF scientific networking community are summarized in an Appendix.
このドキュメントの目的はインターネットアプリケーションにおける使用のために使用されるか、または適合させられるかもしれない製品を提供するベンダーのために指導を提示することです。 それは、現在の仕様を説明するRFCsと他のドキュメントに、必要であるプロトコルを列挙して、参照を与えます。 件数では、仕様は、発展していて、あいまいであるか不完全な情報を含むかもしれません。 これらの場合では、特定の指導を与えるさらなる議論が本書では含まれています。 NSFの科学的ネットワーク共同体に関連している特定保険証券問題はAppendixにまとめられます。
*********************************************************************
*********************************************************************
This is a DRAFT edition of this statement of gateway requirements.
Comments are sought on this document for consideration and
possibly incorporated in the final edition. Comments are
especially sought from those actually developing gateways,
particular vendors and potential vendors of gateways. The period
for comments is 90 days ending 15-Aug-86, at which time revised
edition will be issued with a new RFC number.
これはゲートウェイ要件のこの声明のDRAFT版です。 コメントは、考慮のためのこのドキュメントの上に求められて、ことによると最終版に取り入れられます。 コメントはゲートウェイのそれらの実際に展開しているゲートウェイ、特定のベンダー、および潜在的ベンダーから特に求められます。 コメントのための期間は1986年8月15日を終わらせる90日間です。(その時、改訂版は新しいRFC番号で発行されるでしょう)。
*********************************************************************
*********************************************************************
Suggestions and comments on this document can be sent to the subcommittee chairman Dave Mills (mills@usc-isid.arpa), or NTAG committee chairman Dave Farber (farber@huey.udel.edu). The subcommittee members, present affiliations and Internet mailboxes are as follows:
小委員会議長デーヴミルズ( mills@usc-isid.arpa )、またはNTAG委員長のデーヴ・ファーバー( farber@huey.udel.edu )にこのドキュメントの提案とコメントを送ることができます。 小委員会のメンバー、現在の提携、およびインターネットメールボックスは以下の通りです:
Hank Dardy, NRL dardy@nrl.arpa
Dave Farber, U Delaware farber@huey.udel.edu
Dennis Jennings, JVNC jennings%pucc.bitnet@wiscvm.wisc.edu
ハンクDardy、NRL dardy@nrl.arpa デーヴ・ファーバー、Uデラウェア farber@huey.udel.edu デニス・ジョニングス、JVNC jennings%pucc.bitnet@wiscvm.wisc.edu
NTAG [Page 1]
NTAG[1ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
Larry Landweber, U Wisconsin landweber@rsch.wisc.edu
Tony Lauck, DEC rhea!bergil!lauck@decwrl.arpa
Dave Mills (Chairman), Linkabit mills@usc-isid.arpa
Dennis Perry, DARPA/IPTO perry@ipto.arpa
ラリーLandweber、Uウィスコンシン landweber@rsch.wisc.edu トニーLauck12月の rhea!bergil!lauck@decwrl.arpa デーヴ工場(議長)、Linkabit mills@usc-isid.arpa デニスPerry、DARPA/IPTO perry@ipto.arpa
The subcommittee wishes to thank the following additional contributors and invited referees:
小委員会は以下の追加貢献者と招待されたレフリーに感謝したがっています:
Len Bosack, Stanford U/CISCO bosack@su-score.arpa
Bob Braden, ISI braden@isi-braden.arpa
Hans-Werner Braun, U Michigan hwb@gw.umich.edu
Noel Chiappa, MIT/Proteon jnc@proteon.arpa
Doug Comer, Purdue U dec@cs.purdue.edu
Ira Fuchs, Princeton U fuchs%pucc.bitnet@wiscvm.wisc.edu
Ed Krol, U Illinois krol%uiucvmd.bitnet@wiscvm.wisc.edu
Barry Leiner, RIACS leiner@riacs.arpa
Mike Muuss, BRL mike@brl.arpa
Ron Natalie, BRL ron@brl.arpa
Harvey Newman, CIT newman@cit-hex.arpa
Jon Postel, ISI postel@usc-isib.arpa
Marshall Rose, NRTC mrose@nrtc-gremlin.northrop.com
Jeff Schiller, MIT jis@bitsy.mit.edu
Lixia Zhang, MIT lixia@xx.lcs.mit.edu
レンBosack、スタンフォードU/CISCO bosack@su-score.arpa ボブ・ブレーデン、ISI braden@isi-braden.arpa ハンス-ヴェルナーBraun、Uミシガン hwb@gw.umich.edu クリスマスChiappa、MIT/Proteon jnc@proteon.arpa ダグComer、パドゥーUの dec@cs.purdue.edu イラ・フックス、プリンストンU fuchs%pucc.bitnet@wiscvm.wisc.edu エド・クロール(Uイリノイ krol%uiucvmd.bitnet@wiscvm ); wisc.eduバリーLeiner、RIACS leiner@riacs.arpa マイクMuuss、BRL mike@brl.arpa ロンナタリー、BRL ron@brl.arpa ハーヴェイ・ニューマン、CIT newman@cit-hex.arpa ジョン・ポステル、ISI postel@usc-isib.arpa マーシャル・ローズ、NRTC mrose@nrtc-gremlin.northrop.com ジェフ・シラー、MITの jis@bitsy.mit.edu Lixiaチャン、MIT lixia@xx.lcs.mit.edu
1. Introduction
1. 序論
The following sections are intended as an introduction and background for those unfamiliar with the DARPA Internet architecture and the Internet gateway model. General background and discussion on the Internet architecture and supporting protocol suite can be found in the DDN Protocol Handbook [25] and ARPANET Information Brochure [26], both available from the Network Information Center, SRI International, Menlo Park, CA 94025. Readers familiar with these concepts can proceed directly to Section 2.
DARPAインターネットアーキテクチャとインターネット・ゲートウェイになじみがないそれらのための序論とバックグラウンドがモデル化されるとき、以下のセクションは意図します。 DDNプロトコルHandbook[25]とアルパネット情報Brochure[26]でインターネットアーキテクチャとプロトコル群を支えるのと一般バックグラウンドと議論を見つけることができます、Networkインフォメーション・センター、SRIインターナショナル、メンローパーク、カリフォルニア 94025からともに利用可能です。 これらの概念に詳しい読者は直接セクション2に続くことができます。
1.1. The DARPA Internet Architecture
1.1. DARPAインターネットアーキテクチャ
The DARPA Internet system consists of a number of gateways and
networks that collectively provide packet transport for hosts
subscribing to the DARPA Internet protocol architecture. These
protocols include the Internet Protocol (IP), Internet Control
Message Protocol (ICMP), Transmission Control Protocol (TCP) and
application protocols depending upon them. All protocols use IP
as the basic packet-transport mechanism. IP is a datagram, or
connectionless, service and includes provision for service
specification, fragmentation/reassembly and security information.
ICMP is considered an integral part of IP, although it is
DARPAインターネット・システムはDARPAインターネットプロトコルアーキテクチャに加入するホストのためのパケット輸送をまとめて提供する多くのゲートウェイとネットワークから成ります。 これらのプロトコルはインターネットプロトコル(IP)、インターネット・コントロール・メッセージ・プロトコル(ICMP)、通信制御プロトコル(TCP)、およびそれらによるアプリケーション・プロトコルを含んでいます。 すべてのプロトコルが基本的なパケット移送機構としてIPを使用します。 IPはデータグラムの、または、コネクションレスなサービスであり、サービス仕様、断片化/再アセンブリ、およびセキュリティ情報への支給を含めます。 それはありますが、ICMPはIPの不可欠の部分であると考えられます。
NTAG [Page 2]
NTAG[2ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
architecturally layered upon it. ICMP provides error reporting,
flow control and first-hop gateway redirection. Reliable data
delivery is provided in the protocol suite by TCP, which provides
end-end retransmission, resequencing and connection control.
Connectionless service is provided by the User Datagram Protocol
(UDP).
建築上、それで層にされます。 ICMPは誤り報告、フロー制御、および最初に、ホップゲートウェイリダイレクションを提供します。 確実な資料配送はTCPによってプロトコル群に提供されます。(TCPは終わり-終わりの「再-トランスミッション」、再配列、および接続コントロールを提供します)。 コネクションレス型サービスはユーザー・データグラム・プロトコル(UDP)によって提供されます。
The Internet community presently includes several thousand hosts
connected to over 400 networks with about 120 gateways. There are
now well over 2400 hosts registered in the ARPA domain alone and
an unknown number registered in other domains, with the total
increasing at about ten percent each month. Many of the hosts,
gateways and networks in the Internet community are administered
by civil organizations, including universities, research
laboratories and equipment manufacturers. Most of the remainder
are administered by the US DoD and considered part of the DDN
Internet, which presently consists of three sets of networks: the
experimental segment, or ARPANET, the unclassified segment, or
MILNET, and the classified segment, which does not yet have a
collective name.
インターネットコミュニティは現在、およそ120門で400以上のネットワークに接続された数1,000人のホストを含んでいます。 ARPAドメインに単独で登録された2400人以上のホストと他のドメインに示された未知の数が現在よくあります、合計が毎月およそ10パーセントで増加していて。 インターネットコミュニティのホスト、ゲートウェイ、およびネットワークの多くが民間組織によって管理されます、大学、研究所、および設備メーカーを含んでいて。 残りの大部分は、米国DoDによって管理されて、現在3セットのネットワークから成るDDNインターネットの一部であると考えられます: 実験セグメントか、アルパネットか、非分類されたセグメントか、MILNETと、分類されたセグメント。(そのセグメントには、集合名がまだありません)。
The Internet model includes constituent networks, called local
networks to distinguish them from the Internet system as a whole,
which are required only to provide datagram (connectionless)
transport. This requires only best-effort delivery of individual
packets, or datagrams. Each datagram carries 32-bit source and
destination addresses, which are encoded in three formats
providing a two-part address, one of which is the local-network
number and the other the host number on that local net. According
to the Internet service specification, datagrams can be delivered
out of order, be lost or duplicated and/or contain errors. In
those networks providing connection-oriented service the extra
reliability provided by virtual circuits enhances the end-end
robustness of the system, but is not strictly necessary.
インターネットモデルはデータグラムの(コネクションレス)の輸送を提供するだけでよい全体でインターネット・システムとそれらを区別するために企業内情報通信網と呼ばれる構成しているネットワークを入れます。 これは個々のパケット、またはデータグラムのベストエフォート型配送だけを必要とします。各データグラムは32ビットのソースと送付先アドレスを運びます。(アドレスはそれの1つが企業内情報通信網番号である2部分のアドレスともう片方にそのローカルのネットのホスト番号を提供する3つの形式でコード化されます)。 インターネットのサービス仕様に従って、データグラムは、誤りを故障していた状態で提供されるか、失われているか、コピーする、そして/または、含むことができます。 コネクション型サービスを提供するそれらのネットワークでは、仮想の回路によって提供された付加的な信頼性は、システムの終わり-終わりの丈夫さを高めますが、厳密に必要ではありません。
Local networks are connected together in the Internet model by
means of Internet gateways. These gateways provide datagram
transport only and normally seek to minimize the state information
necessary to sustain this service in the interest of routing
flexibility and robustness. In the conventional model the gateway
has a physical interface and address on each of the local nets
between which it provides forwarding services. The gateway also
participates in one or more distributed routing or reachability
algorithm such as the Gateway-Gateway Protocol (GGP) or Exterior
Gateway Protocol (EGP) in order to maintain its routing tables.
企業内情報通信網はインターネット・ゲートウェイによるインターネットモデルで一緒に接続されます。 これらのゲートウェイは、データグラム輸送だけを前提として、通常、ルーティングの柔軟性と丈夫さのためにこのサービスを維持するのに必要な州の情報を最小にすると求めます。 従来機では、ゲートウェイはそれが転送サービスを提供するそれぞれのローカルのネットに関する物理インターフェースとアドレスを持っています。 また、ゲートウェイは、経路指定テーブルを維持するためにゲートウェイ-ゲートウェイプロトコル(GGP)かExteriorゲートウェイプロトコル(EGP)などの1つ以上の分配されたルーティングか可到達性アルゴリズムに参加します。
NTAG [Page 3]
NTAG[3ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
1.2. The Internet Gateway Model
1.2. インターネットゲートウェイモデル
An Internet gateway is a self-contained, stand-alone packet switch
that performs the following functions:
インターネット・ゲートウェイは以下の機能を実行する自己充足的で、スタンドアロンのパケット交換機です:
1. Interfaces to two or more packet-switching networks,
including encapsulation, address transformation and flow
control.
1. カプセル化を含む2つ以上のパケット交換網へのインタフェースは変換とフロー制御を扱います。
2. Conforms to specific DARPA Internet protocols specified in
this document, including the Internet Protocol (IP),
Internet Control Message Protocol (ICMP), Exterior Gateway
Protocol (EGP) and others as necessary.
2. 必要に応じてインターネットプロトコル(IP)、インターネット・コントロール・メッセージ・プロトコル(ICMP)、Exteriorゲートウェイプロトコル(EGP)、および他のものを含んでいて、本書では指定された特定のDARPAインターネットプロトコルに従います。
3. Supports an interior gateway protocol (IGP) reachability or
routing algorithm in cases of multiple gateways operating
as a system. Supports the EGP reachability algorithm to
exchange routes between systems, in particular the DARPA
"core" system operated by BBN.
3. 複数のゲートウェイがシステムとして作動する場合における内部のゲートウェイプロトコル(IGP)の可到達性かルーティング・アルゴリズムをサポートします。 システム、特にBBNによって操作されたDARPA「コア」システムの間のルートを交換するためにEGP可到達性アルゴリズムをサポートします。
4. Receives and forwards Internet datagrams consistent with
good engineering practice in the management of resources,
congestion control and fairness. Recognizes various error
conditions and generates ICMP error and information
messages as required.
4. リソース、輻輳制御、および公正の管理における良いエンジニアリング方式と一致したインターネットデータグラムを受けて、進めます。 必要に応じてICMP誤りと情報がメッセージであると様々なエラー条件を認めて、生成します。
5. Provides system support facilities, including loading,
debugging, status reporting, exception reporting and
control.
5. ロードするのを含んでいるデバッグ、状態報告、例外報告書、およびコントロールをシステム支援施設に提供します。
In some configurations gateways may be connected to
packet-switching local nets that provide generic local-net
routing, error-control and resource-management functions. In
others gateways may be directly connected via serial lines, so
that these functions must be provided by the gateways themselves.
いくつかの構成では、ゲートウェイはジェネリックの地方にネットのルーティング、誤り制御、および資源管理機能を提供するパケット交換のローカルのネットに接続されるかもしれません。 他のものゲートウェイでは、シリアル・ラインを通って直接接続されるかもしれません、ゲートウェイ自体でこれらの機能を提供しなければならないように。
There are three typical scenarios that should be addressed by
gateway vendors:
ゲートウェイベンダーによって扱われるべきである3つの典型的なシナリオがあります:
1. National or regional network. Gateways of this class
should be capable of switching multiple continuous flows in
the 1.5-Mbps range at rates to several thousand packets per
second. They will be high-performance, possibly redundant,
multiple-processor devices, probably procured as a system
and operated remotely from a regional or national
monitoring center. The design of these gateways should
emphasize high aggregate throughput, throughput-sensitive
1. 国家の、または、地方のネットワーク。 このクラスのゲートウェイは速度で1.5-Mbps範囲の複数の連続した流れを1秒あたり数1,000のパケットに切り換えることができるべきです。 それらはたぶんシステムとして調達されて、地方の、または、国家のモニターしている中心から離れて操作された高い性能の、そして、ことによると余分な複数のプロセッサデバイスになるでしょう。 これらのゲートウェイのデザインはスループット敏感な状態で高い集合スループットを強調するべきです。
NTAG [Page 4]
NTAG[4ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
resource management and very high reliability. The typical
application would be an NSF backbone net or one of the
consortium or regional nets.
資源管理と非常に高い信頼性。 主用途は、NSFバックボーンネット、または共同体か地方のネットの1つでしょう。
2. Campus network. Gateways of this class should be capable
of switching some burst flows at 10-Mbps (Ethernets, etc.),
together with some flows in the 64-Kbps range or lower, at
rates to perhaps several thousand packets per second. They
will be medium-performance devices, probably competitively
procured from different vendors for each campus and
operated from a campus computing center. The design of
these gateways should emphasize low average delay and good
burst performance, together with delay and type-of-service
sensitive resource management. Their chief function might
be to interconnect various LANs and campus computing
resources, including a high-speed interconnect to a
national or regional net. An important factor will be a
very flexible routing mechanism, since these gateways may
have to select among several backbone nets based on
cost/performance considerations.
2. キャンパスネットワーク。 このクラスのゲートウェイは、1秒あたり1,000のパケットに64キロビット毎秒の範囲のいくつかの流れと共に10-Mbps(イーサネットなど)でいくつかの炸裂流れを切り換えることができるか、またはレートで恐らく数個に低いはずです。 それらはたぶん異なったベンダーから各キャンパスに競争的に調達されて、キャンパス計算機センタから操作された中くらいの性能デバイスになるでしょう。 これらのゲートウェイのデザインは低い平均値遅れと良い炸裂性能を強調するべきです、遅れとサービスのタイプの敏感な資源管理と共に。 それらの主要な機能は様々なLANとキャンパスコンピューティング資源とインタコネクトすることであるかもしれません、国家の、または、地方のネットに高速内部連絡を含めて。 重要な要素は非常にフレキシブルなルーティングメカニズムになるでしょう、これらのゲートウェイが数個のバックボーンの中で費用/性能問題に基づくネットを選択しなければならないかもしれないので。
3. Department network. Gateways of this class should be
capable of switching a small number of burst flows at
10-Mbps (Ethernets, etc.), together with a small number of
flows in the range 64-Kbps or lower, at rates of a few
hundred packets per second. They will be
medium-performance devices procured from a variety of
vendors and used for protocol-matching, LAN repeaters and
as general utility packet switches. They will probably be
locally maintained by the various users and not be used as
transit switches.
3. 部のネットワーク。 このクラスのゲートウェイは、64範囲キロビット毎秒における少ない数の流れと共に10-Mbps(イーサネットなど)で少ない数の炸裂流れを切り換えることができるか、または低いはずです、1秒あたり数100のパケットのレートで。 それらはさまざまなベンダーから調達されて、プロトコルマッチング、LANリピータ、一般的なユーティリティパケットが切り替わっている間に使用される中くらいの性能デバイスになるでしょう。 トランジットが切り替わっている間、それらは、たぶん様々なユーザによって局所的に維持されて、使用されないでしょう。
It is important to realize that Internet gateways normally operate
in an unattended mode, but that equipment and software faults can
affect the entire Internet. While some of the above scenarios
involve positive control of some gateways from a monitoring
center, usually via a path involving other networks and Internet
gateways, others may involve much less formal control procedures.
Thus the gateways must be highly robust and be expected to
operate, possibly in a degraded state, under conditions of extreme
congestion or failure of network resources.
インターネット・ゲートウェイが無人のモードで通常作動しますが、設備とソフトウェア欠点が全体のインターネットに影響できるとわかるのは重要です。 上のシナリオのいくつかがモニターしている中心から数門の正の制御にかかわっている間、通常他のネットワークとインターネット・ゲートウェイにかかわる経路を通して、まして、他のものは正式なコントロール手順にかかわるかもしれません。 したがって、ゲートウェイを非常に強健であり、作動すると予想しなければなりません、ことによると降格している状態で、極端な混雑の状態かネットワーク資源の失敗の下で。
NTAG [Page 5]
NTAG[5ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
2. Protocols Required
2. プロトコルが必要です。
The Internet architecture uses datagram gateways to interconnect networks and subnetworks. These gateways function as intermediate systems (IS) with respect to the ISO connectionless network model and incorporate defined packet formats, routing algorithms and related procedures. In the following it is assumed the protocol implementation supports the full protocol, including all required options, with exceptions only as noted.
インターネットアーキテクチャは、ネットワークとサブネットワークとインタコネクトするのにデータグラムゲートウェイを使用します。 ISOのコネクションレスなネットワークに関する中間システム(ある)が定義されたパケット・フォーマット、ルーティング・アルゴリズム、および関連する手順をモデル化して、取り入れるとき、これらのゲートウェイは機能します。 以下では、プロトコル実装が完全なプロトコルをサポートすると思われます、すべての必要なオプションを含んでいて、注意されるように例外だけで。
2.1. Internet Protocol (IP)
2.1. インターネットプロトコル(IP)
This is the basic datagram protocol used in the Internet system.
It is described in RFC-791 [1] and also MIL-STD-1777 [5], both of
which are intended to describe the same standard, but in quite
different words.
これはインターネット・システムで使用される基本的なデータグラムプロトコルです。 それはRFC-791[1]と軍規格-1777[5]にもかかわらずも、全く異なった単語で説明されます。その両方が同じ規格について説明するつもりです。
With respect to current gateway requirements the following can be
ignored, although they may be required in future: Type of Service
field, Security option, Stream ID option and Timestamp option.
However, if recognized, the interpretation of these quantities
must conform to the standard specification.
現在のゲートウェイ要件に関して、それらがこれから、必要であるかもしれませんが、以下を無視できます: Service分野、Securityオプション、Stream IDオプション、およびTimestampオプションのタイプ。 しかしながら、認識されるなら、これらの量の解釈は標準の仕様に従わなければなりません。
Note that the Internet gateway model does not require that the
gateway reassemble IP datagrams with destination address other
than the gateway itself. However, in the case of those protocols
in which the gateway directly participates as a peer, including
routing and monitor/control protocols, the gateway may have to
reassemble datagrams addressed to it. This consideration is most
pertinent to EGP.
インターネット・ゲートウェイモデルが、ゲートウェイがゲートウェイ自体以外の送付先アドレスでIPデータグラムを組み立て直すのを必要としないことに注意してください。 しかしながら、ゲートウェイが同輩として直接関与するそれらのプロトコルに関するケースにルーティングとモニター/制御プロトコルを含んでいて、ゲートウェイはそれに扱われたデータグラムを組み立て直さなければならないかもしれません。 この考慮はEGPに最も適切です。
Note that, of the five classes of IP addresses. Class-A through
Class-E, Class-D and Class-E addresses are reserved for
experimental use. A gateway which is not participating in these
experiments should ignore all packets with a Class-D or Class-E
destination IP address. No ICMP Destination Unreachable or ICMP
Redirect messages should result from receiving such packets.
5つのクラスのIPアドレスのものに注意してください。 Class-Eを通したクラスA、Class-D、およびClass-Eアドレスは実験用のために予約されます。 これらの実験に参加していないゲートウェイはClass-DかClass-E送付先IPアドレスがあるすべてのパケットを無視するはずです。 いいえICMP Destination UnreachableかICMP Redirectメッセージがそのようなパケットを受けながら生じるべきである。
2.2. Internet Control Message Protocol (ICMP)
2.2. インターネット・コントロール・メッセージ・プロトコル(ICMP)
This is an auxiliary protocol used to convey advice and error
messages and is described in RFC-792 [2].
これは、アドバイスとエラーメッセージを伝えるのに使用される補助のプロトコルであり、RFC-792[2]で説明されます。
The distinction between subnets of a subnetted network, which
depends on an arbitrary mask as described in RFC-950 [21], is in
general not visible outside that network. This distinction is
important in the case of certain ICMP messages, including the ICMP
サブネット化したネットワーク(それがネットワークでつなぐ目に見える外部ではなく、一般に、RFC-950[21]で説明されるように任意のマスクによって、あるもの)のサブネットの区別。 この区別はICMPを含むあるICMPメッセージの場合で重要です。
NTAG [Page 6]
NTAG[6ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
Destination Unreachable and ICMP Redirect messages. The ICMP
Destination Unreachable message is sent by a gateway in response
to a datagram which cannot be forwarded because the destination is
unreachable or down. A choice of several types of these messages
is available, including one designating the destination network
and another the destination host. However, the span of addresses
implied by the former is ill-defined unless the subnet mask is
known to the sender, which is in general not the case. It is
recommended that use of the ICMP Destination Network Unreachable
messages be avoided. Instead, an ICMP Destination Host
Unreachable message should be sent for each distinct unreachable
IP address.
目的地UnreachableとICMP Redirectメッセージ。 ゲートウェイは目的地が手が届かないか、または下がっているので進めることができないデータグラムに対応してICMP Destination Unreachableメッセージを送ります。 これらのメッセージのいくつかのタイプの選択は利用可能です、送信先ネットワークと別のものをあて先ホストに指定しながら1つを含んでいて。 しかしながら、サブネットマスクが送付者(一般に、そうである)にとって知られていない場合、前者によって含意されたアドレスの長さはほとんど定義されていません。そうでない。 ICMP Destination Network Unreachableメッセージの使用が避けられるのは、お勧めです。 代わりに、それぞれの異なった手の届かないIPアドレスのためにICMP Destination Host Unreachableメッセージを送るべきです。
The ICMP Redirect message is sent by a gateway to a host in order
to change the address used by the host for a designated host or
net. A choice of four types of messages is available, depending
on whether it applies to a particular host, network or service.
As in the previous case, these distinctions may depend upon the
subnet mask. As in the above case, it is recommended that the use
of ICMP messages implying a span of addresses (e.g. net
unreachable, net redirect) be avoided in favor of those implying
specific addresses (e.g. host unreachable, host redirect).
ゲートウェイは、指定されたホストかネットにホストによって使用されたアドレスを変えるためにICMP Redirectメッセージをホストに送ります。 4つのタイプに関するメッセージの選択は利用可能です、それが特定のホスト、ネットワークまたはサービスに適用されるかどうかによって。 先の事件のように、これらの区別はサブネットマスクによるかもしれません。 アドレス(例えば、手が届かなくて、ネット再直接で、網状になる)の長さを含意するICMPメッセージの使用が特定のアドレスを含意するものを支持して避けられるのが、上のケースのようにお勧めである、(例えば、ホスト手の届かないのと、ホスト再直接、)
The ICMP Source Quench message has been the subject of much
controversy. It is not considered realistic at this time to
specify in detail the conditions under which this message is to be
generated or interpreted by a host or gateway.
ICMP Source Quenchメッセージは多くの論争の対象です。 それはこのとき詳細に、ホストかゲートウェイによって生成されるか、または解釈されるこのメッセージがことである状態を指定するために現実的であると考えられません。
New host and gateway implementations are expected to support the
ICMP Address Mask messages described in RFC-950. It is highly
desirable, although not required, to provide correct data for ICMP
Timestamp messages, which have been found useful in network
debugging and maintenance.
新しいホストとゲートウェイ実装がRFC-950で説明されたICMP Address Maskメッセージをサポートすると予想されます。 それは非常に望ましいです、ネットワークデバッグとメインテナンスで役に立つわかったICMP Timestampメッセージのための正しいデータを提供するのが必要ではありませんが。
2.3. Exterior Gateway Protocol (EGP)
2.3. 外のゲートウェイプロトコル(EGP)
This is the basic protocol used to exchange information between
gateway systems of the Internet and is described in RFC-904 [11].
However, EGP as presently specified is an asymmetric protocol with
only the "non-core" procedures defined in RFC-904. There are at
present no "core" procedures specified, which would be necessary
for a stand-alone Internet. RFC-975 [27] suggests certain
modifications leading to a symmetric model; however, this is not
an official specification.
これは、インターネットのゲートウェイシステムの間で情報交換するのに使用される基本プロトコルであり、RFC-904[11]で説明されます。 しかしながら、現在指定されているとしてのEGPは「中核でない」手順だけがRFC-904で定義されている非対称のプロトコルです。 現在のところ、指定されたどんな「コア」手順もありません。(手順がスタンドアロンのインターネットに必要でしょう)。 RFC-975[27]は対称モデルにつながるある変更を勧めます。 しかしながら、これは公式の仕様書ではありません。
In principle, a stand-alone Internet can be built with non-core
EGP gateways using the EGP distance field to convey some metric
原則として、中核でないEGPゲートウェイがメートル法でいくつかを運ぶのにEGP距離分野を使用している状態で、スタンドアロンのインターネットを造ることができます。
NTAG [Page 7]
NTAG[7ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
such as hop count. However, the use of EGP in this way as a
routing algorithm is discouraged, since typical implementations
adapt very slowly to changing topology and have no loop-protection
features.
ホップカウントなどのように。 しかしながら、ルーティング・アルゴリズムとしてのこのようにおけるEGPの使用はお勧めできないです、典型的な実装が非常にゆっくりトポロジーを変えるのに適合して、輪保護機能を全く持っていないので。
The EGP model requires each gateway belong to an autonomous system
of gateways. If a routing algorithm is operated in one or more
gateways of an autonomous system, its data base must be coupled to
the EGP implementation in such a way that, when a net is declared
down by the routing algorithm, the net is also declared down via
EGP to other autonomous systems. This requirement is designed to
minimize spurious traffic to "black holes" and insure fair
utilization of the resources on other systems.
EGPモデルは各ゲートウェイを必要とします。ゲートウェイの自律システムに属してください。 ルーティング・アルゴリズムが自律システムの1門以上で操作されるなら、また、ネットがルーティング・アルゴリズムで宣言されるときネットが他の自律システムへのEGPを通して宣言されるような方法でEGP実装とデータベースを結合しなければなりません。この要件は、「ブラックホール」に偽りのトラフィックを最小にして、他のシステムにおけるリソースの公正な利用を保障するように設計されています。
There are no peer-discovery or authentication procedures defined
in the present EGP specification and no defined interpretation of
the distance fields in the update messages, although such
procedures may be defined in future (see RFC-975). There is
currently no guidance on the selection of polling parameters and
no specific recovery procedures in case of certain error messages
(e.g. "administratively prohibited"). It is recommended that EGP
implementations include provisions to initialize these parameters
as part of the monitoring and control procedures and that changing
these procedures not require recompilation or rebooting the
gateway.
そこでは、そのような手順がこれから、定義されるかもしれませんが(RFC-975を見てください)、現在のEGP仕様に基づき定義されて、定義されなかった同輩発見か認証手順は全くアップデートメッセージで、距離分野の解釈ですか? 現在、あるエラーメッセージ(例えば、「行政上禁止されている」)の場合に世論調査パラメタにもかかわらず、特定のリカバリ手順がない品揃えには指導が全くありません。 これらの手順を変えるのが、EGP実装がモニターとコントロール手順の一部としてこれらのパラメタを初期化するために条項を含んで、「再-編集」かゲートウェイをリブートするのを必要としないのは、お勧めです。
2.4. Address Resolution Protocol (ARP)
2.4. アドレス解決プロトコル(アルプ)
This is an auxiliary protocol used to manage the
address-translation function between hardware addresses in a
local-net environment and Internet addresses and described in
RFC-826 [4]. However, there are a number of unresolved issues
having to do with subnets and response to addresses not in the
same subnet or net. These issues, which are intertwined with ICMP
and various gateway models, are discussed in Appendix A.
これは地方にネットの環境とインターネット・アドレスのハードウェア・アドレスの間のアドレス変換機能を管理するのにおいて中古の、そして、RFC-826[4]で説明された補助のプロトコルです。 しかしながら、同じサブネットかどんなネットにもサブネットとアドレスへの応答と関係がある多くの未解決問題がありません。 Appendix Aでこれらの問題(ICMPと様々なゲートウェイモデルと共にからみ合う)について議論します。
3. Subnets
3. サブネット
The concept of subnets was introduced in order to allow arbitrary complexity of interconnected LAN structures within an organization, while insulating the Internet system against explosive growth in network numbers and routing complexity. The subnet architecture, described in RFC-950 [21], is intended to specify a standard approach that does not require reconfiguration for host implementations, regardless of subnetting scheme. The document also specifies a new
サブネットの概念は、組織の中にインタコネクトされたLAN構造の任意の複雑さを許容するためにネットワーク・ナンバーとルーティングの複雑さにおける爆発的成長に対してインターネット・システムを絶縁している間、紹介されました。 RFC-950[21]で説明されたサブネットアーキテクチャがホスト導入のために再構成を必要としない標準のアプローチを指定することを意図します、サブネッティング体系にかかわらず。 また、ドキュメントは新しい状態でaを指定します。
NTAG [Page 8]
NTAG[8ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
ICMP Address Mask message, which a gateway can use to specify certain details of the subnetting scheme to hosts and is required in new host and gateway implementations.
ICMP Address Maskメッセージ、どのaゲートウェイが、サブネッティング体系のある詳細をホストに指定するのを使用できて、新しいホストで必要であるか、そして、およびゲートウェイ実装。
The current subnet specification RFC-950 does not describe the specific procedures to be used by the gateway, except by implication. It is recommended that a (sub)net address and address mask be provided for each network interface and that these values be established as part of the gateway configuration procedure. It is not usually necessary to change these values during operation of any particular gateway; however, it should be possible to add new gateways and/or (sub)nets and make other configuration changes to a gateway without taking the entire network down.
現在のサブネット仕様RFC-950は、含意以外に、ゲートウェイによって使用されるために特定の手順について説明しません。 ネットのアドレスとアドレスがマスクをかける(潜水艦)を各ネットワーク・インターフェースに提供して、ゲートウェイ構成手順の一部とこれらの値を書き立てるのはお勧めです。 通常、どんな特定のゲートウェイの操作の間も、これらの値を変えるのは必要ではありません。 しかしながら、新しいゲートウェイ、そして/または、(潜水艦)ネットを加えて、全体のネットワークを降ろさないでゲートウェイへの他の構成変更を作るのは可能であるべきです。
4. Local Network Interface
4. 企業内情報通信網インタフェース
The packet format used for transmission of datagrams on the various subnetworks is described in a number of documents summarized below.
様々なサブネットワークにおけるデータグラムのトランスミッションに使用されるパケット・フォーマットは以下へまとめられた多くのドキュメントで説明されます。
4.1. Public data networks via X.25
4.1. X.25を通した公衆データネットワーク
The formats specified for public data networks via X.25 access are
described in RFC-877 [8]. Datagrams are transmitted over standard
level-3 virtual circuits as complete packet sequences. Virtual
circuits are usually established dynamically as required and time
out after a period of no traffic. Retransmission, resequencing
and flow control are performed by the network for each virtual
circuit and by the LAPB link-level protocol. Multiple parallel
virtual circuits are often used in order to improve the
utilization of the subscriber access line, which can result in
random resequencing. The correspondence between Internet and
X.121 addresses is usually established by table-lookup. It is
expected that this will be replaced by some sort of directory
procedure in future.
X.25アクセスで公衆データネットワークに指定された形式はRFC-877[8]で説明されます。 データグラムは完全なパケット系列としてレベル-3個の標準の仮想の回路の上に送られます。 仮想の回路はトラフィックがない通常、必要に応じてダイナミックに設立されていて、タイムアウトaの後期間です。 Retransmission、再配列、およびフロー制御はそれぞれの仮想の回路へのネットワークとLAPBリンク・レベルプロトコルによって実行されます。 複数の平行な仮想の回路が、無作為の再配列をもたらすことができる加入者アクセス回線の利用を改良するのにしばしば使用されます。 通常、インターネットとX.121アドレスとの通信は索表によって確立されます。 これがこれからある種のディレクトリ手順に取り替えられると予想されます。
4.2. ARPANET via 1822 Local Host, Distant Host or HDLC Distant Host
4.2. 1822Local Host、Distant HostまたはHDLC Distant Hostを通したアルパネット
The formats specified for ARPANET networks via 1822 access are
described in BBN Report 1822 [3], which includes the procedures
for several subscriber access methods. The Local Host (LH) and
Very Distant Host (VDH) methods are not recommended for new
implementations. The Distant Host (DH) method is used when the
host and IMP are separated by not more than about 2000 feet of
cable, while the HDLC Distant Host is used for greater distances
where a modem is required. Retransmission, resequencing and flow
control are performed by the network and by the HDLC link-level
protocol, when used. While the ARPANET 1822 protocols are widely
1822年のアクセスでアルパネットネットワークに指定された形式はBBN Report1822[3]で説明されます。([3]はいくつかの加入者アクセス法のための手順を含んでいます)。 Local Host(LH)とVery Distant Host(VDH)メソッドは新しい実装のために推薦されません。 ホストとIMPがおよそ2000フィート以下切り離されるとき、Distant Host(DH)メソッドはケーブルで使用されています、HDLC Distant Hostがモデムが必要であるより長い距離に使用されますが。 使用されると、Retransmission、再配列、およびフロー制御はネットワークとHDLCリンク・レベルプロトコルによって実行されます。 アルパネット1822プロトコルは広くそうですが
NTAG [Page 9]
NTAG[9ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
used at present, they are expected to be eventually overtaken by
the DDN Standard X.25 protocol (see below) and the new PSN
End-to-End Protocol described in RFC-979 [29].
現在のところ使用されていて、結局DDN Standard X.25プロトコル(以下を見る)とPSN Endから終わりへのRFC-979[29]で説明された新しいプロトコルによって彼らが追いつかれると予想されます。
While the cited report gives details of the various ARPANET
subscriber access methods, it specifies neither the IP packet
encapsulation format nor address mappings. While these are
generally straightforward and easy to implement, the details
involve considerations beyond the scope of readily accessable
documentation. Potential vendors are encouraged to contact one of
the individuals listed at the beginning of this document for
further information.
引用されたレポートは様々なアルパネット加入者アクセス法の詳細を明らかにしますが、それはIPパケットカプセル化形式もアドレス・マッピングも指定しません。 これらは一般に、簡単であって、実装しやすい間、詳細は容易にアクセス可能なドキュメンテーションの範囲を超えて問題にかかわります。 潜在的ベンダーが詳細のためのこのドキュメントの始めに記載された個人のひとりに連絡するよう奨励されます。
Gateways connected to ARPANET/MILNET IMPs must incorporate
features to avoid host-port blocking (RFNM counting) and to detect
and report (as ICMP Unreachable messages) the failure of
destination hosts or gateways.
アルパネット/MILNET IMPsに接続されたゲートウェイはあて先ホストかゲートウェイの失敗をホストポートブロッキングを避けて(RFNMが数えて)、検出して、報告する(ICMP Unreachableメッセージとして)特徴を取り入れなければなりません。
4.3. ARPANET via DDN Standard X.25
4.3. DDN Standard X.25を通したアルパネット
The formats specified for ARPANET networks via X.25 are described
in the Defense Data Network X.25 Host Interface Specification [6].
This document describes two sets of procedures, the DDN Basic X.25
and the DDN Standard X.25, but only the latter is suitable for use
in the Internet system. The DDN Standard X.25 procedures are
similar to the public data subnetwork X.25 procedures, except in
the address mappings. Retransmission, resequencing and flow
control are performed by the network and by the LAPB link-level
protocol.
X.25を通してアルパネットネットワークに指定された形式はDefense Data Network X.25 Host Interface Specification[6]で説明されます。 このドキュメントは2セットの手順、DDN Basic X.25、およびDDN Standard X.25について説明しますが、後者だけがインターネット・システムにおける使用に適しています。 アドレス・マッピングを除いて、DDN Standard X.25手順は公衆データサブネットワークX.25手順と同様です。 Retransmission、再配列、およびフロー制御はネットワークとLAPBリンク・レベルプロトコルによって実行されます。
4.4. Ethernets
4.4. イーサネット
The formats specified for Ethernet networks are described in
RFC-894 [10]. Datagrams are encapsulated as Ethernet packets with
48-bit source and destination address fields and a 16-bit type
field. Address translation between Ethernet addresses and Internet
addresses is managed by the Address Resolution Protocol, which is
required in all Ethernet implementations. There is no explicit
retransmission, resequencing or flow control. although most
hardware interfaces will retransmit automatically in case of
collisions on the cable.
イーサネットネットワークに指定された形式はRFC-894[10]で説明されます。 データグラムはイーサネットパケットとして48ビットのソース、目的地アドレス・フィールド、および16ビットのタイプ分野でカプセル化されます。 イーサネット・アドレスとインターネット・アドレスの間のアドレス変換はAddress Resolutionプロトコルによって管理されます。(それが、すべてのイーサネット実装で必要です)。 いいえ、明白な「再-トランスミッション」、再配列またはフロー制御があります。大部分ですが、ハードウェア・インタフェースにケーブルにおける衝突の場合に自動的に再送されるでしょう。
It is expected that amendments will be made to this specification
as the result of IEEE 802.3 evolution. See RFC-948 [20] for
further discussion and recommendations in this area. Note also
that the IP broadcast address, which has primary application to
Ethernets and similar technologies that support an inherent
IEEE802.3発展の結果として修正をこの仕様にすると予想されます。 この領域でさらなる議論と推薦に関してRFC-948[20]を見てください。 また、IPがそれがサポートするEthernetsと同様の技術にプライマリアプリケーションを持っているアドレスを放送したことに注意してください、固有
NTAG [Page 10]
NTAG[10ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
broadcast function, has an all-ones value in the host field of the
IP address. Some early implementations chose the all-zeros value
for this purpose, which is presently not in conformance with the
definitive specification RFC-950 [21].
放送は、IPアドレスのホスト分野に機能して、オールもの値を持っています。 いくつかの早めの実装がこの目的のためのオールゼロ値を選びました。(目的は現在、順応でない決定的な仕様RFC-950[21]がある中です)。
See Appendix A for further considerations.
さらなる問題に関してAppendix Aを見てください。
4.5. Serial-Line Protocols
4.5. シリアル・ラインプロトコル
Gateways may be used as packet switches in order to build
networks. In some configurations gateways may be interconnected
with each other and some hosts by means of serial asynchronous or
synchronous lines, with or without modems. When justified by the
expected error rate and other factors, a link-level protocol may
be required on the serial line. While there is no requirement that
a particular standard protocol be used for this, it is recommended
that standard hardware and protocols be used, unless a convincing
reason to the contrary exists. In order to support the greatest
variety of configurations, it is recommended that some variation
on full X.25 (i.e. "symmetric mode") be used where resources
permit; however, X.25 LAPB would also be acceptable where
requirements permit. In the case of asynchronous lines no clear
choice is apparent.
ゲートウェイは、ネットワークを造るのにパケット交換機として使用されるかもしれません。 いくつかの構成では、連続の非同期であるか同期の系列によってゲートウェイは互いと何人かのホストと共にインタコネクトされるかもしれません、モデムのあるなしにかかわらず。期待誤差率と他の要素によって正当化されると、リンク・レベルプロトコルがシリアル・ラインの上で必要であるかもしれません。 特定の標準プロトコルがこれに使用されるという要件が全くありませんが、標準のハードウェアとプロトコルが使用されるのは、お勧めです、納得のいく理由がそれと反対に存在していない場合。 最大級のバラエティーの構成をサポートするために、完全なX.25(すなわち、「左右対称のモード」)の何らかの変化がリソースが可能にするところで使用されるのは、お勧めです。 しかしながら、また、X.25 LAPBも要件が可能にするところで許容できるでしょう。 非同期な系列の場合では、どんな明確な選択も明らかではありません。
5. Interoperability
5. 相互運用性
In order to assure interoperability between gateways procured from different vendors, it is necessary to specify points of protocol demarcation. With respect to interoperability of the routing function, this is specified as EGP. All gateway systems must include one or more gateways which support EGP with a core gateway, as described in RFC-904 [11]. It is desirable that these gateways be able to operate in a mode that does not require a core gateway or system. Additional discussion on these issues can be found in RFC-975 [27].
異なったベンダーから調達されたゲートウェイの間の相互運用性を保証するために、ポイントのプロトコル画定を指定するのが必要です。 経路選択機能の相互運用性に関して、これはEGPとして指定されます。 すべてのゲートウェイシステムがコアゲートウェイでEGPをサポートする1門以上を含まなければなりません、RFC-904[11]で説明されるように。 これらのゲートウェイがコアゲートウェイかシステムを必要としないモードで作動できるのは、望ましいです。 RFC-975[27]でこれらの問題についての追加議論を見つけることができます。
With respect to the interoperability at the network layer and below, two points of protocol demarcation are specified, one for Ethernets and the other for serial lines. In the case of Ethernets the protocols are as specified in Section 4.4 and Appendix A of this document. For serial lines between gateways of different vendors, the protocols are specified in Section 4.5 of this document. Exceptions to these requirements may be appropriate in some cases.
ネットワーク層における以下の相互運用性に関して、2ポイントのプロトコル画定は指定されます、Ethernetsのためのもの、シリーズのためのもう片方が立ち並んでいます。 Ethernetsの場合には、プロトコルがこのドキュメントのセクション4.4とAppendix Aで指定されるようにあります。 異なったベンダーのゲートウェイの間のシリアル・ラインとして、プロトコルはこのドキュメントのセクション4.5で指定されます。 いくつかの場合、これらの要件への例外は適切であるかもしれません。
NTAG [Page 11]
NTAG[11ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
6. Subnetwork Architecture
6. サブネットワークアーキテクチャ
It is recognized that gateways may also function as general packet switches to build networks of modest size. This requires additional functionality in order to manage network routing, control and configuration. While it is beyond the scope of this document to specify the details of the mechanisms used in any particular, perhaps proprietary, architecture, there are a number of basic requirements which must be provided by any acceptable architecture.
また、ゲートウェイがまずまずのサイズのネットワークを造るために一般的なパケット交換機として機能するかもしれないと認められます。 これは、ネットワークルーティング、コントロール、および構成を管理するために追加機能性を必要とします。 どんな特定の、そして、恐らく独占であるアーキテクチャにも使用されるメカニズムの細部を指定するためにこのドキュメントの範囲を超えていますが、どんな許容できるアーキテクチャでも提供しなければならない多くの基本的な要件があります。
6.1. Reachability Procedures
6.1. 可到達性手順
The architecture must provide a robust mechanism to establish the
operational status of each link and node in the network, including
the gateways, the links connecting them and, where appropriate,
the hosts as well. Ordinarily, this requires at least a
link-level reachability protocol involving a periodic exchange of
hello messages across each link. This function might be intrinsic
to the link-level protocols used (e.g. LAPB, DDCMP). However, it
is in general ill-advised to assume a host or gateway is operating
correctly if its link-level reachability protocol is operating
correctly. Additional confirmation is required in the form of an
operating routing algorithm or peer-level reachability protocol,
such as used in EGP.
アーキテクチャはネットワークにおけるそれぞれのリンクとノードの操作上の状態を証明するために強健なメカニズムを提供しなければなりません、ゲートウェイ(また、それらと適切であるところのホストに接するリンク)を含んでいて 通常、これが少なくともa周期的な交換にかかわるリンク・レベル可到達性プロトコルを必要とする、こんにちは、それぞれの向こう側のメッセージはリンクされます。 この機能はプロトコルが使用したリンク・レベル(例えば、LAPB、DDCMP)に本質的であるかもしれません。 しかしながら、リンク・レベル可到達性プロトコルが正しく作動しているなら一般に、ホストかゲートウェイに就くためにあさはかであるのが、正しく作動することであるということです。 追加確認が操作ルーティング・アルゴリズムか同輩レベル可到達性プロトコルの形で必要です、EGPで使用されるように。
Failure and restoration of a link and/or gateway are considered
network events and must be reported to the control center. It is
desirable, although not required, that reporting paths not require
correct functioning of the routing algorithm itself.
リンク、そして/または、ゲートウェイの失敗と修復をネットワークイベントであると考えられて、コントロールセンターに報告しなければなりません。 必要ではありませんが、報告経路がルーティング・アルゴリズム自体の正しい機能を必要としないのは、望ましいです。
6.2. Routing Algorithm
6.2. ルーティング・アルゴリズム
It has been the repeated experience of the Internet community
participants that the routing mechanism, whether static or
dynamic, is the single most important engineering issue in network
design. In all but trivial network topologies it is necessary
that some degree of routing dynamics is vital to successful
operation, whether it be affected by manual or automatic means or
some combination of both. In particular, if routing changes are
made manually, the changes must be possible without taking down
the gateways for reconfiguration and, preferably, be possible from
a remote site such as a control center.
それはインターネットコミュニティ関係者の繰り返された経験です。ルーティングメカニズムは静電気か動力であることにかかわらずネットワークデザインで最も重要な工学問題です。 それがそれが影響を受けるか否かに関係なく、いくらかのルーティング力学がうまくいっている操作に重大であることが必要である些細なネットワークtopologies以外のすべての手動の、または、自動である手段か両方の何らかの組み合わせ。 ルーティング変更が手動で行われるなら、変化は、特に、再構成のためにゲートウェイを降ろさないで可能であり、望ましくは、コントロールセンターなどのリモートサイトから可能でなければなりません。
It is not likely that all nets can be maintained from a
full-service control center, so that automatic-fallback or
rerouting features may be required. This must be considered the
normal case, so that systems of gateways operating as the only
その自動後退か特徴を別ルートで送るのを必要とすることができるようにフルサービスコントロールセンターからすべてのネットを維持できそうであるというわけではありません。 正常なケースであるとこれを考えなければならなくて、そうはゲートウェイが唯一として作動するそのシステムです。
NTAG [Page 12]
NTAG[12ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
packet switches in a network would normally be expected to have a
routing algorithm with the capability of reacting to link and
other gateway failures and changing the routing automatically.
Following is a list of features considered necessary:
通常、ネットワークにおけるパケット交換機には反応がリンクされる能力と、他のゲートウェイの故障と自動的にルーティングを変えるルーティング・アルゴリズムがあると予想されるでしょう。 以下に、必要であると考えられた特徴のリストがあります:
1. The algorithm must sense the failure or restoration of a
link or other gateway and switch to appropriate paths
within an interval less than the typical TCP user timeout
(one minute is a safe assumption).
1. アルゴリズムは、間隔以内に典型的なTCPユーザタイムアウトほど経路を当てないようにリンクか他のゲートウェイとスイッチの失敗か修復を感じなければなりません(1分は安全な仮定です)。
2. The algorithm must never form routing loops between
neighbor gateways and must contain provisions to avoid and
suppress routing loops that may form between non-neighbor
gateways. In no case should a loop persist for longer than
an interval greater than the typical TCP user timeout.
2. アルゴリズムは、非隣人ゲートウェイの間で形成されるかもしれない輪を発送しながら、隣人ゲートウェイの間でルーティング輪を決して形成してはいけなくて、避けて、抑圧する条項を含まなければなりません。 輪は典型的なTCPユーザタイムアウトより大きい間隔より長い間、決して、持続するはずがありません。
3. The control traffic necessary to operate the routing
algorithm must not significantly degrade or disrupt normal
network operation. Changes in state which might momentarily
disrupt normal operation in a local area must not cause
disruption in remote areas of the network.
3. ルーティング・アルゴリズムを操作するのに必要なコントロールトラフィックは、通常のネットワーク操作をかなり下がってはいけませんし、また中断してはいけません。 しばらく局部で通常の操作を中断するかもしれない状態の変化はネットワークの遠隔地で分裂を引き起こしてはいけません。
4. As the size of the network increases, the demand on
resources must be controlled in an efficient way. Table
lookups should be hashed, for example, and data-base
updates handled piecemeal, with only the changes broadcast
over a wide area. Reachability and delay metrics, if used,
must not depend on direct connectivity to all other
gateways or the use of network-specific broadcast
mechanisms. Polling procedures (e.g. for consistency
checking) should be used only sparingly and in no case
introduce an overhead exceeding a constant independent of
network topology times the longest non-looping path.
4. ネットワークのサイズが増加するのに従って、効率的な方法でリソースにおける要求を制御しなければなりません。 例えば、索表は論じ尽くされるべきでした、そして、アップデートが変化だけで少しずつ扱ったデータベースは広い領域にわたって放送されました。 使用されるなら、可到達性と遅れ測定基準は他のすべてのゲートウェイへのダイレクト接続性かネットワーク特有の放送メカニズムの使用に依存してはいけません。世論調査手順(例えば、一貫性の照合のための)は、控えめにだけ使用されて、ネットワーク形態回の如何にかかわらず最も長い非ループの一定の経路を超えているオーバーヘッドを決して導入するべきではありません。
5. The use of a default gateway as a means to reduce the size
of the routing data base is strongly discouraged in view of
the many problems with multiple paths, loops and
mis-configuration vulnerabilities. If used at all, it
should be limited to a discovery function, with operational
routes cached from external or internal data bases via
either the routing algorithm or EGP.
5. ルーティングデータベースのサイズを減少させる手段としてのデフォルトゲートウェイの使用は強く複数の経路(輪と誤構成脆弱性)に関する多くの問題から見てお勧めできないです。 少しでも使用されるなら、それは発見機能に制限されるべきです、操作上のルートがルーティング・アルゴリズムかEGPのどちらかを通して外部の、または、内部のデータベースからキャッシュされている状態で。
6. This document places no restriction on the type of routing
algorithm, such as node-based, link-based or any other
algorithm, or metric, such as delay or hop-count. However,
the size of the routing data base must not be allowed to
exceed a constant independent of network topology times the
6. このドキュメントはルーティング・アルゴリズムのタイプに関して制限を全く課しません、ノードベース、リンクベース、いかなる他のアルゴリズム、またはメートル法であることのようにも、遅れやホップカウントのように。 しかしながら、ルーティングデータベースのサイズにネットワーク形態回の如何にかかわらず定数を超えさせてはいけません。
NTAG [Page 13]
NTAG[13ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
number of nodes times the mean connectivity (average number
of incident links). An advanced design would not require
that the entire routing data base be kept in any particular
gateway, so that discovery and caching techniques would be
necessary.
ノード時間の数、卑劣な接続性(平均した数の付随しているリンク)。 高度なデザインは、全体のルーティングデータベースがどんな特定のゲートウェイにも保たれるのを必要としないでしょう、発見とテクニックをキャッシュするのが必要であるように。
7. Operation and Maintenance
7. 維持管理
Gateways and packets switches are often operated as a system by some organization who agrees to operate and maintain the gateways, as well as to resolve link problems with the respective common carriers. It is important to note that the network control site may not be physically attached to the network being monitored. In general, the following requirements apply:
ゲートウェイとパケットスイッチはシステムとしてしばしばゲートウェイを操作して、維持して、それぞれの運輸業者に関するリンク問題を解決するのに同意する何らかの組織によって、運用されます。 ネットワーク制御サイトが物理的にモニターされるネットワークに添付されないかもしれないことに注意するのは重要です。 一般に、以下の要件は適用されます:
1. Each gateway must operate as a stand-alone device for the
purposes of local hardware maintenance. Means must be
available to run diagnostic programs at the gateway site using
only on-site tools, which might be only a diskette or tape and
local terminal. It is desirable, although not required, to
run diagnostics via the network and to automatically reboot
and dump the gateway via the net in case of fault. In
general, this requires special hardware.
1. 各ゲートウェイは地方のハードウェアの保守管理の目的のためのスタンドアロンのデバイスとして作動しなければなりません。 手段は、ゲートウェイサイトでディスケットかテープとローカル・ターミナルであるにすぎないかもしれない現場の唯一のツールを使用することで診断プログラムを動かすために利用可能でなければなりません。 それは望ましいです、欠点の場合のネットで自動的にゲートウェイをネットワークを通して病気の特徴を実行して、リブートして、どさっと落とすのが必要ではありませんが。 一般に、これは特別なハードウェアを必要とします。
The use of full-blown transport services such as TCP is in
general ill-advised if required just to reboot and dump the
gateway. Consideration should be given simple
retransmission-overlay protocols based on UDP or specific
monitoring protocols such as HMP described in RFC-869 [7].
花盛りの使用は必要なら、ただ、ゲートウェイをリブートして、どさっと落とすためにあさはかな状態で一般に、TCPのようなサービスを輸送します。 考慮は、RFC-869[7]で説明されたHMPなどのUDPに基づく与えられた簡単な「再-トランスミッション」-オーバレイプロトコルか特定のモニターしているプロトコルであるべきです。
2. It must be possible to reboot and dump the gateway manually
from the control site. Every gateway must include a watchdog
timer that either initiates a reboot or signals a remote
control site if not reset periodically by the software. It is
desirable that the data involved reside at the control site
and be transmitted via the net; however, the use of local
devices at the gateway site is acceptable. Nevertheless, the
operation of initiating reboot or dump must be possible via
the net, assuming a path is available and the connecting links
are operating.
2. 規制サイトからゲートウェイを手動でリブートして、どさっと落とすのは可能であるに違いありません。 あらゆるゲートウェイが定期的にソフトウェアによってリセットされないなら、リブートを開始するか、または遠隔操作サイトを示すウオッチドッグタイマーを含まなければなりません。 かかわったデータが規制サイトに住んでいて、ネットで送られるのは、望ましいです。 しかしながら、ゲートウェイサイトのローカル装置の使用は許容できます。 それにもかかわらず、リブートかダンプを開始する操作はネットで可能であるに違いありません、経路が利用可能であり、結合リンクが運転していると仮定して。
3. A mechanism must be provided to accumulate traffic statistics
including, but not limited to, packet tallies, error-message
tallies and so forth. The preferred method of retrieving
these data is by explicit, periodic request from the control
site using a standard datagram protocol based on UDP or HMP.
3. トラフィック統計包含、他、パケット合札、エラーメッセージ合札などを蓄積するためにメカニズムを提供しなければなりません。 これらのデータを検索する適した方法は、UDPかHMPに基づく標準のデータグラムプロトコルを使用しながら、規制サイトから要求します明白で、周期的な。
NTAG [Page 14]
NTAG[14ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
The use of full-blown transport services such as TCP is in
general ill-advised if required just to collect statistics
from the gateway. Consideration should be given simple
retransmission-overlay protocols based on UDP or HMP.
花盛りの使用は必要なら、ただゲートウェイから統計を集めるためにあさはかな状態で一般に、TCPのようなサービスを輸送します。 UDPかHMPに基づく簡単な「再-トランスミッション」-オーバレイプロトコルを考慮に与えるべきです。
4. Exception reports ("traps") occuring as the result of hardware
or software malfunctions should be transmitted immediately
(batched to reduce packet overheads when possible) to the
control site using a standard datagram protocol based on UDP
or HMP.
4. ハードウェアかソフトウェアの結果が誤動作するとき、例外レポート(「罠」)存在は、すぐに(可能であるときに、パケットオーバーヘッドを下げるために、batchedされる)、UDPかHMPに基づく標準のデータグラムプロトコルを使用することで規制サイトに送られるべきです。
5. A mechanism must be provided to display link and node status
on a continuous basis at the control site. While it is
desirable that a complete map of all links and nodes be
available, it is acceptable that only those components in use
by the routing algorithm be displayed. This information is
usually available locally at the control site, assuming that
site is a participant in the routing algorithm.
5. 規制サイトの随時でディスプレイリンクとノード状態にメカニズムを提供しなければなりません。 すべてのリンクとノードの完全な地図が利用可能であることが、望ましいのですが、ルーティング・アルゴリズムによって使用中のそれらのコンポーネントだけを表示するのは許容できます。 通常、この情報は局所的に利用可能です。サイトがルーティング・アルゴリズムの関係者であると仮定する規制サイトで。
The above functions require in general the participation of a control site or agent. The preferred way to provide this is as a user program suitable for operation in a standard software environment such as Unix. The program would use standard IP protocols such as TCP, UDP, and HMP to control and monitor the gateways. The use of specialized host hardware and software requiring significant additional investment is strongly discouraged; nevertheless, some vendors may elect to provide the control agent as an integrated part of the network in which the gateways are a part. If this is the case, it is required that a means be available to operate the control agent from a remote site using Internet protocols and paths and with equivalent functionality with respect to a local agent terminal.
一般に、上の機能は規制サイトかエージェントの参加を必要とします。 Unixなどの標準のソフトウェア環境における操作に適したユーザ・プログラムとしてこれを提供する都合のよい方法があります。 プログラムは、ゲートウェイを制御して、モニターするのにTCPや、UDPや、HMPなどの標準のIPプロトコルを使用するでしょう。 専門化しているホストハードウェアと重要な追加出資を必要とするソフトウェアの使用は強くお勧めできないです。 それにもかかわらず、いくつかのベンダーが、ゲートウェイが部分であるネットワークの統合部分としてコントロールエージェントを提供するのを選ぶかもしれません。 これがそうであるなら、手段がインターネットプロトコルと経路を使用するリモートサイトと同等な機能性で地方のエージェント端末に関してコントロールエージェントを手術するために利用可能であることが必要です。
Remote control of a gateway via Internet paths can involve either a direct approach, in which the gateway supports TCP and/or UDP directly, or an indirect approach, in which the control agent supports these protocols and controls the gateway itself using proprietary protocols. The former approach is preferred, although either approach is acceptable.
インターネット経路を通るゲートウェイの遠隔操作はダイレクト方式、または間接的なアプローチにかかわることができます。(ゲートウェイはダイレクト方式で直接TCP、そして/または、UDPをサポートします)。(コントロールエージェントは、それでこれらのプロトコルとコントロールがゲートウェイ自体であると固有のプロトコルを使用することでサポートします)。 アプローチは許容できますが、前のアプローチは好まれます。
NTAG [Page 15]
NTAG[15ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
8. References and Bibliography
8. 参照と図書目録
[1] Defense Advanced Research Projects Agency, "Internet Protocol",
DARPA Network Working Group Report RFC-791, USC Information
Sciences Institute, September 1981.
[1] ディフェンス先端研究は政府機関、「インターネットプロトコル」、DARPAネットワークワーキンググループレポートRFC-791、科学が1981年9月に設けるUSC情報を映し出します。
[2] Defense Advanced Research Projects Agency, "Internet Control
Message Protocol", DARPA Network Working Group Report RFC-792,
USC Information Sciences Institute, September 1981.
[2] ディフェンス先端研究は政府機関、「インターネット・コントロール・メッセージ・プロトコル」を映し出します、DARPAネットワークワーキンググループレポートRFC-792、科学が設けるUSC情報、1981年9月。
[3] Advanced Research Projects Agency, "Interface Message Processor
- Specifications for the Interconnection of a Host and an IMP",
BBN Report 1822, Bolt Beranek and Newman, December 1981.
[3] 先端研究プロジェクト代理店、「インタフェースはホストのインタコネクトと悪童のためにプロセッサ--仕様を通信し」てBBNレポート1822とボルトBeranekとニューマン、1981年12月。
[4] Plummer, D., "An Ethernet Address Resolution Protocol", DARPA
Network Working Group Report RFC-826, Symbolics, September 1982.
[4] プラマー、D.、「イーサネットアドレス解決プロトコル」、DARPAネットワークワーキンググループレポートRFC-826、信条学、1982年9月。
[5] United States Department of Defense, "Military Standard Internet
Protocol", Military Standard MIL-STD-1777, August 1983.
[5]合衆国国防総省、「軍事の標準のインターネットプロトコル」、軍事の標準の軍規格-1777、1983年8月。
[6] Defense Communications Agency, "Defense Data Network X.25 Host
Interface Specification", BBN Communications, December 1983.
[6]ディフェンスコミュニケーション代理店、「ディフェンスデータ網X.25ホストインターフェース仕様」、BBNコミュニケーション、1983年12月。
[7] Hinden, R., "A Host Monitoring Protocol", DARPA Network Working
Group Report RFC-869, BBN Communications, December 1983.
[7]Hinden、R.、「ホストのモニターしているプロトコル」、DARPAネットワークワーキンググループレポートRFC-869、BBNコミュニケーション、1983年12月。
[8] Korb, J.T., "A Standard for the Transmission of IP Datagrams
over Public Data Networks", DARPA Network Working Group Report
RFC-877, Purdue University, September 1983.
[8] コルプ、「公衆データの上のIPデータグラムの送信の規格はネットワークでつなぐ」J.T.、DARPAがワーキンググループレポートRFC-877をネットワークでつなぎます、パデュー大学、1983年9月。
[9] Nagle, J., "Congestion Control in IP/TCP Internetworks", DARPA
Network Working Group Report RFC-896, Ford Aerospace,
January 1984.
[9] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、DARPAネットワークワーキンググループレポートRFC-896、フォードAerospace、1984年1月。
[10] Hornig, C., "A Standard for the Transmission of IP Datagrams
over Ethernet Networks", DARPA Network Working Group Report
RFC-894, Symbolics, April 1984.
[10] ホーニッグ、「イーサネットの上のIPデータグラムの送信の規格はネットワークでつなぐ」C.、DARPAがワーキンググループレポートRFC-894をネットワークでつなぎます、信条学、1984年4月。
[11] Mills, D.L., "Exterior Gateway formal Specification", DARPA
Network Working Group Report RFC-904, M/A-COM Linkabit,
April 1984.
[11]工場、D.L.、「外のゲートウェイ正式なSpecification」、DARPA Network作業部会Report RFC-904、1COM Linkabitの/M1984年4月。
[12] Postel, J., and J. Reynolds., "ARPA-Internet Protocol Policy",
DARPA Network Working Group Report RFC-902, USC Information
Sciences Institute, July 1984.
[12]のポステル、J.、およびJ.レイノルズ、「アルパインターネットプロトコル方針」、DARPAネットワークワーキンググループレポートRFC-902(科学が1984年7月に設けるUSC情報)
NTAG [Page 16]
NTAG[16ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
[13] Kirton, P., "EGP Gateway under Berkeley UNIX 4.2", DARPA Network
Working Group Report RFC-911, USC Information Sciences
Institute, August 1984.
[13] カートン、P.、「EGPゲートウェイ、バークレーUNIXの下では、何4.2インチも、DARPAはワーキンググループレポートRFC-911をネットワークでつなぎます、科学が設けるUSC情報、8月1984インチ。
[14] Postel, J., "Multi-LAN Address Resolution", DARPA Network
Working Group Report RFC-925, USC Information Sciences
Institute, October 1984.
[14] ポステル、J.、「マルチLANアドレス解決」、DARPAネットワークワーキンググループレポートRFC-925、科学が1984年10月に設けるUSC情報。
[15] International Standards Organization, "Protocol for Providing
the Connectionless-Mode Network Services", DARPA Network Working
Group Report RFC-926, International Standards Organization,
December 1984.
[15] 世界規格組織、「コネクションレスなモードネットワーク・サービスを提供するためのプロトコル」、DARPAネットワーク作業部会はRFC-926を報告します、世界規格組織、1984年12月。
[16] National Research Council, "Transport Protocols for Department
of Defense Data Networks", DARPA Network Working Group Report
RFC-942, National Research Council, March 1985.
[16] 調査評議会、「国防総省データ網のためにプロトコルを輸送してください」、DARPAネットワークワーキンググループレポートRFC-942、調査評議会、1985年3月。
[17] Postel, J., "DOD Statement on NRC Report", DARPA Network Working
Group Report RFC-945, USC Information Sciences Institute,
April 1985.
[17] ポステル、J.、「NRCレポートに関するDOD声明」、DARPAネットワークワーキンググループレポートRFC-945、科学が1985年4月に設けるUSC情報。
[18] International Standards Organization, "Addendum to the Network
Service Definition Covering Network Layer Addressing", DARPA
Network Working Group Report RFC-941, International Standards
Organization, April 1985.
[18] 世界規格組織、「ネットワーク・サービス定義への付加物はネットワーク層アドレシングをカバーしてい」て、DARPAがワーキンググループレポートRFC-941をネットワークでつなぎます、世界規格組織、1985年4月。
[19] Leiner, B., J. Postel, R. Cole and D. Mills, "The DARPA Internet
Protocol Suite", Proceedings INFOCOM 85, Washington DC,
March 1985] Also in: IEEE Communications Magazine, March 1985.
[19]LeinerとB.とJ.ポステルとR.コールとD.工場、「DARPAインターネットプロトコル群」、議事INFOCOM85、ワシントンD.C.、1985]年3月 以下でも 1985年3月のIEEEコミュニケーション雑誌。
[20] Winston, I., "Two Methods for the Transmission of IP Datagrams
over IEEE 802.3 Networks", DARPA Network Working Group Report
RFC-948, University of Pennsylvania, June 1985.
[20] ウィンストン、「IEEE802.3の上のIPデータグラムの送信のための2つのメソッドがネットワークでつなぐ」I.、DARPAはワーキンググループレポートRFC-948をネットワークでつなぎます、ペンシルバニア大学、1985年6月。
[21] Mogul, J., and J. Postel, "Internet Standard Subnetting
Procedure", DARPA Network Working Group Report RFC-950, Stanford
University, August 1985.
[21] DARPAがネットワークでつなぐムガール人、J.とJ.ポステル、「インターネットの標準のサブネッティング手順」ワーキンググループレポートRFC-950、スタンフォード大学、1985年8月。
[22] Reynolds, J., and J. Postel, "Official ARPA-Internet Protocols",
DARPA Network Working Group Report RFC-961, USC Information
Sciences Institute, October 1985.
[22] レイノルズ、J.、およびJ.ポステル、「公式のアルパインターネットプロトコル」、DARPAネットワーク作業部会はRFC-961を報告します、科学が設けるUSC情報、1985年10月。
[23] Reynolds, J., and J. Postel, "Assigned Numbers", DARPA Network
Working Group Report RFC-960, USC Information Sciences
Institute, December 1985.
[23] USC情報科学が1985年12月に設けるレイノルズ、J.とJ.ポステル、「規定番号」、DARPAネットワークワーキンググループレポートRFC-960。
NTAG [Page 17]
NTAG[17ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
[24] Nagle, J., "On Packet Switches with Infinite Storage", DARPA
Network Working Group Report RFC-970, Ford Aerospace,
December 1985.
[24] ネーグル、「無限のストレージがあるパケット交換機」のJ.DARPAネットワーク作業部会は1985年12月にRFC-970、フォードAerospaceを報告します。
[25] Defense Communications Agency, "DDN Protocol Handbook",
NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI
International, December 1985.
[25]ディフェンスCommunications Agency、「DDNプロトコルハンドブック」、NIC-50004、NIC-50005、NIC-50006、(3本のボリューム)、SRIインターナショナル、1985年12月。
[26] Defense Communications Agency, "ARPANET Information Brochure",
NIC-50003, SRI International, December 1985.
[26] ディフェンスコミュニケーション代理店、「アルパネット情報小冊子」、NIC-50003、SRIインターナショナル、1985年12月。
[27] Mills, D.L., "Autonomous Confederations", DARPA Network Working
Group Report RFC-975, M/A-COM Linkabit, February 1986.
[27] 工場、D.L.、「自動同盟者」、DARPAは1986年2月に1COM Linkabitである状態でワーキンググループレポートRFC-975、M/をネットワークでつなぎます。
[28] Jacobsen, O., and J. Postel, "Protocol Document Order
Information", DARPA Network Working Group Report RFC-980, SRI
International, March 1986.
[28] DARPAがネットワークでつなぐジェイコブセン、O.とJ.ポステル、「プロトコルドキュメントオーダー情報」ワーキンググループレポートRFC-980、SRIインターナショナル、1986年3月。
[29] Malis, A.G., "PSN End-to-End Functional Specification", DARPA
Network Working Group Report RFC-979, BBN Communications,
March 1986.
[29]Malis、A.G.、「PSN終わりから終わりへの機能的な仕様」、DARPAネットワークワーキンググループレポートRFC-979、BBNコミュニケーション、1986年3月。
NTAG [Page 18]
NTAG[18ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
Appendix A. Ethernet Management
付録A.イーサネット管理
Following is a summary of procedures specified for use by hosts and gateways on an Ethernet.
以下に、イーサネットでホストとゲートウェイによって使用に指定された手順の概要があります。
A.1. Hardware
A.1。 ハードウェア
A packet is accepted from the cable only if its destination
Ethernet address matches either the assigned interface address or
a broadcast/multicast address. Presumably, this filtering is done
by the interface hardware; however, the software driver is
expected to do this if the hardware does not. Some hosts
incorporate an optional feature that associates an assigned
multicast address with a specific subnet in order to restrict
access for testing, etc. When this feature is activated, the
assigned multicast address replaces the broadcast address.
目的地イーサネットが割り当てられたインターフェース・アドレスか放送/マルチキャストアドレスのどちらかをマッチに扱う場合にだけ、ケーブルからパケットを受け入れます。 おそらく、インタフェースハードウェアはこのフィルタリングをします。 しかしながら、ハードウェアが予想されないなら、ソフトウェアドライバーがこれをすると予想されます。 ホストの中にはテストなどのためのアクセスを制限するために割り当てられたマルチキャストアドレスを特定のサブネットに関連づけるオプション機能を取り入れる人もいます。 この特徴が活性であるときに、割り当てられたマルチキャストアドレスは放送演説を置き換えます。
A.2. IP datagram
A.2。 IPデータグラム
In case of broadcast/multicast (as determined from the destination
Ethernet address) an IP datagram is discarded if the source IP
address is not in the same subnet, as determined by the assigned
host IP address and subnet mask. It is desirable that this test
be overridden by a configuration parameter, in order to support
the infrequent cases where more than one subnet may coexist on the
same cable.
放送/マルチキャスト(送付先イーサネットアドレスから決定するように)の場合には、同じサブネットにソースIPアドレスがないなら、IPデータグラムは捨てられます、割り当てられたホストIPアドレスとサブネットマスクで決定するように。 このテストが設定パラメータによってくつがえされるのは、望ましいです、1つ以上のサブネットが同じケーブルの上に共存するかもしれない珍しいケースを支えるために。
A.3. ARP datagram
A.3。 ARPデータグラム
An ARP reply is discarded if the destination IP address does not
match the local host address. An ARP request is discarded if the
source IP address is not in the same subnet. It is desirable that
this test be overridden by a configuration parameter, in order to
support the infrequent cases where more than one subnet may
coexist on the same cable (see RFC-925 for examples). An ARP
reply is generated only if the destination protocol IP address is
reachable from the local host (as determined by the routing
algorithm) and the next hop is not via the same interface. If the
local host functions as a gateway, this may result in ARP replies
for destinations not in the same subnet.
送付先IPアドレスがローカル・ホストアドレスに合っていないなら、ARP回答は捨てられます。 同じサブネットにソースIPアドレスがないなら、ARP要求は捨てられます。 このテストが設定パラメータによってくつがえされるのは、望ましいです、1つ以上のサブネットが同じケーブルの上に共存するかもしれない(例に関してRFC-925を見てください)珍しいケースを支えるために。 送付先プロトコルIPアドレスがローカル・ホストから届く場合にだけ(ルーティング・アルゴリズムで決定するように)、ARP回答は発生しています、そして、同じインタフェースを通して次のホップはありません。 ローカル・ホストがゲートウェイとして機能するなら、これは同じサブネットでないのにおける目的地のためのARP回答をもたらすかもしれません。
A.4. ICMP redirect
A.4。 ICMP再直接です。
An ICMP redirect is discarded if the destination IP address does
not match the local host address or the new target address is not
on the same subnet. An accepted redirect updates the routing data
base for the old target address. If there is no route or
ICMP再直接は、目的地であるなら捨てられて、IPアドレスが合っていないということです。ローカルのホスト・アドレスか新しいあて先アドレスが同じサブネットにありません。 ルーティングデータが古いあて先アドレスのために基礎づける受け入れられた再直接のアップデート。 またはルートが全くない。
NTAG [Page 19]
NTAG[19ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
associated with the old target address, the redirect is ignored.
If the old route is associated with a default gateway, a new route
associated with the new target address is inserted in the data
base. Note that it is not possible to send a gratuitous redirect
unless the sender is possessed of considerable imagination.
古いあて先アドレスに関連していて、再直接は無視されます。 古いルートがデフォルトゲートウェイに関連しているなら、新しいあて先アドレスに関連している新しいルートはデータベースに挿入されます。 それが無料でaを送るのにおいて可能でないことに注意してください。かなりの想像について所有されていて、送付者が向け直さない場合、向け直します。
When subnets are in use there is some ambiguity as to the scope of
a redirect, unless all hosts and gateways involved have prior
knowledge of the subnet masks. It is recommended that the use of
ICMP network-redirect messages be avoided in favor of ICMP
host-redirect messages instead. This requires the original sender
(i.e. redirect recipient) to support a general IP
address-translation cache, rather than the usual network table.
However, this is normally done anyway in the case of ARP.
サブネットが使用中であるときに、aの範囲に関する何らかの再直接のあいまいさがあります、ホストとゲートウェイがかかわったすべてがサブネットマスクに関する先の知識を持っていないなら。 ICMPのネットワーク再直接のメッセージの使用がICMPのホスト再直接のメッセージを支持して代わりに避けられるのは、お勧めです。 これは、元の送り主(すなわち、再直接の受取人)が普通のネットワークテーブルよりむしろ一般的なIPアドレス変換キャッシュをサポートするのを必要とします。 しかしながら、通常、ARPの場合でとにかくこれをします。
An ICMP redirect is generated only if the destination IP address
is reachable from the local host (as determined by the routing
algorithm) and the next hop is via the same interface and the
target address is defined in the routing data base. Redirects
should never be sent in response to an IP net or subnet broadcast
address or in response to a Class-D or Class-E IP address.
ICMP再直接は、送付先IPアドレスがローカル・ホストから届いていて(ルーティング・アルゴリズムで決定するように)、同じインタフェースを通して次のホップがあるだけであるか、そして、あて先アドレスであると生成されているのが、ルーティングデータが基礎づける定義されたコネであるということです。 向け直す、IPネットかサブネット放送演説に対応してClass-DかClass-E IPアドレスに対応して決して送るべきではありません。
ICMP redirects are never forwarded, regardless of destination
address. The source IP address of the ICMP redirect itself is not
checked, since the sending gateway may use one of its addresses
not on the common net. The source IP address of the encapsulated
IP datagram is not checked on the assumption the host or gateway
sending the original IP datagram knows what it is doing.
ICMPが向け直す、送付先アドレスにかかわらず決して進めません。 それ自体はICMPのアドレスが向け直すソースIPではありません。送付ゲートウェイが一般的なネットでないのに関するアドレスの1つを使用するかもしれないので、チェックされます。 カプセル化されたIPデータグラムのソースIPアドレスはオリジナルのIPデータグラムを送るホストかゲートウェイが、それが何をしているかを知っているという前提でチェックされません。
NTAG [Page 20]
NTAG[20ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
Appendix B. Policy Issues
付録B.政策問題
The following sections discuss certain issues of special concern to the NSF scientific networking community. These issues have primary relevance in the policy area, but also have ramifications in the technical area.
以下のセクションはNSFの科学的ネットワーク共同体への特別な関心のある問題について論じます。 これらの問題は、方針領域にプライマリ関連性を持っていますが、テクニカルエリアに分岐をまた持っています。
B.1. Interconnection Technology
B.1。 インタコネクト技術
Currently the most important common interconnection technology
between Internet systems of different vendors is Ethernet. Among
the reasons for this are the following:
異なったベンダーのインターネット・システムの間の現在最も重要な一般的なインタコネクト技術はイーサネットです。 この理由の中に、以下があります:
1. Ethernet specifications are well-understood and mature.
1. イーサネット仕様は、よく理解されていて熟しています。
2. Ethernet technology is in almost all aspects vendor
independent.
2. ほとんどすべての局面のベンダーの独立者にはイーサネット技術があります。
3. Ethernet-compatible systems are common and becoming more
so.
3. イーサネットコンパチブルシステムは、共通であり、よりそうになっています。
These advantages combined favor the use of Ethernet technology as
the common point of demarcation between NSF network systems
supplied by different vendors, regardless of technology. It is a
requirement of NSF gateways that, regardless of the possibly
proprietary switching technology used to implement a given
vendor-supplied network, its gateways must support an Ethernet
attachment to gateways of other vendors.
これらの利点はNSFネットワーク・システムの間の画定の一般的なポイントとしてのイーサネット技術の使用が異なったベンダーから供給した好意を結合しました、技術にかかわらず。 それはゲートウェイが、与えられたベンダーによって供給されたネットワークを実装するのに使用されることによると独占である切り換え技術にかかわらずイーサネットが他のベンダーのゲートウェイへの付属であるとサポートしなければならないというNSFゲートウェイの要件です。
It is expected that future NSF gateway requirements will specify
other interconnection technologies. The most likely candidates
are those based on X.25 or IEEE 802, but other technologies
including broadband cable, fiber-optic or other protocols such as
DDCMP may also be considered.
将来のNSFゲートウェイ要件が他のインタコネクト技術を指定すると予想されます。 最もありそうな候補は広帯域のケーブル、光ファイバーを含むそれらのX.25かIEEE802に基づくのにもかかわらずの、他の技術であるかまた、DDCMPなどの他のプロトコルは考えられるかもしれません。
B.2. Proprietary and Extensible Issues
B.2。 独占で広げることができる問題
Internet technology is a growing, adaptable technology. Although
hosts, gateways and networks supporting this technology have been
in continuous operation for several years, vendors users and
operators should understand that not all networking issues are
fully understood. As a result, when new needs or better solutions
are developed for use in the NSF networking community, it may be
necessary to field new protocols. Normally, these new protocols
will be designed to interoperate in all practical respects with
existing protocols; however, occasionally it may happen that
existing systems must be upgraded to support these protocols.
インターネット技術は増加していて、融通のきく技術です。 この技術をサポートするホスト、ゲートウェイ、およびネットワークは継続的作業数年間中ですが、ベンダーのユーザとオペレータは、問題をすべて完全なネットワークでつなぐというわけではないのが理解されているのを理解するべきです。 新たな必要性か、より良い解決策がNSFネットワーク共同体での使用のために見いだされるとき、その結果、新しいプロトコルをさばくのが必要であるかもしれません。 通常、これらの新しいプロトコルは既存のプロトコルですべての実用的な点で共同利用するように設計されるでしょう。 しかしながら、時折、既存のシステムがこれらのプロトコルをサポートするためにアップグレードしなければならないのは起こるかもしれません。
NTAG [Page 21]
NTAG[21ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
NSF systems vendors should understand that they also undertake a
commitment to remain aware of current Internet technology and be
prepared to upgrade their products from time to time as
appropriate. As a result, these vendors are strongly urged to
consider extensibility and periodic upgrades as fundamental
characteristics of their products. One of the most productive and
rewarding ways to do this on a long-term basis is to participate
in ongoing Internet research and development programs in
partnership with the academic community.
NSFシステムベンダーは、それらがまた、現在のインターネット技術を意識していたままで残る委任を引き受けて、それらの製品を時々適宜アップグレードさせるように準備されるのを理解するべきです。 その結果、これらのベンダーが、伸展性と周期的なアップグレードがそれらの製品の基本的な特性であるとみなすよう強く促されます。 長期的にはこれをする最も生産的で価値ある方法の1つは学界と協力して進行中のインターネット研究開発プログラムに参加することです。
B.3. Multi-Protocol Gateways
B.3。 マルチプロトコルゲートウェイ
Although the present requirements for an NSF gateway specify only
the Internet protocol suite, it is highly desirable that gateway
designs allow future extensions to support additional suites and
allow simultaneous operation with more than a single one.
Clearly, the ISO protocol suite is a prime candidate for one of
these suites. Other candidates include XNS and DECnet.
NSFゲートウェイのための現在の要件はインターネット・プロトコル群だけを指定しますが、今後の拡大がゲートウェイデザインでただ一つのもの以上で追加スイートを支えて、同時処理操作を許容するのは、非常に望ましいです。 明確に、ISOプロトコル群はこれらのスイートの1つの主要な候補です。 他の候補はXNSとDECnetを入れます。
Future requirements for NSF gateways may include provisions for
other protocol suites in addition to Internet, as well as models
and specifications to interwork between them, should that be
appropriate. For instance, it is expected that the ISO suite will
eventually become the dominant one; however, it is also expected
that requirements to support other suites will continue, perhaps
indefinitely.
NSFゲートウェイのための将来の要件はインターネットに加えた他のプロトコル群のための条項を含むかもしれません、それらの間で織り込むモデルと仕様と同様に、それが適切であるなら。 例えば、ISOスイートが結局優位なものになると予想されます。 しかしながら、また、他のスイートを支えるという要件が続くと恐らく無期限に予想されます。
Present NSF gateway requirements do not include protocols above
the network layer, such as TCP, unless necessary for network
monitoring or control. Vendors should recognize that future
requirements to interwork between Internet and ISO applications,
for example, may result in an opportunity to market gateways
supporting multiple protocols at all levels through the
application level. It is expected that the network-level NSF
gateway requirements summarized in this document will be
incorporated in the requirements document for these
application-level gateways.
現在のNSFゲートウェイ要件はネットワーク層を超えてプロトコルを含んでいません、TCPなどのように、ネットワーク監視かコントロールに必要でない場合。 ベンダーは、例えばインターネットとISOの間でアプリケーションを織り込むという将来の要件がアプリケーションレベルを通して全く複数のプロトコルにレベルをサポートするゲートウェイを売り出す機会をもたらすかもしれないと認めるべきです。 本書ではまとめられたネットワークレベルNSFゲートウェイ要件がこれらのアプリケーションレベルゲートウェイのための要件ドキュメントに組み込むと予想されます。
B.4. Access Control and Accounting
B.4。 アクセスコントロールと会計
There are no requirements for NSF gateways at this time to
incorporate specific access-control and accounting mechanisms in
the design; however, these important issues are currently under
study and will be incorporated into a redraft of this document at
an early date. Vendors are encouraged to plan for the early
introduction of these mechanisms in their products. While at this
今回のNSFゲートウェイが特定のアクセスコントロールと会計機構をデザインに組み込むという要件が全くありません。 しかしながら、これらの切迫した課題は、現在、研究であって、期日前半にこのドキュメントの書き直し原稿に組み入れられるでしょう。 ベンダーがそれらの製品における、これらのメカニズムの早めの導入の計画を立てるよう奨励されます。 これで
NTAG [Page 22]
NTAG[22ページ]
RFC 985 May 1986 Requirements for Internet Gateways -- DRAFT
インターネットゲートウェイのためのRFC985 1986年5月要件--草稿
time no definitive common model for access control and accounting
has emerged, it is possible to outline some general features such
a model is likely to have, among them the following:
アクセスコントロールと会計のためのどんな決定的な一般的なモデルも現れていない時、いくつかの一般的な特徴について概説するために、そのようなモデルがそれらの中に以下を持っていそうであるのは、可能です:
1. The primary access control and accounting executive
mechanisms will be in the service hosts themselves, not the
gateways, packet switches or workstations.
1. プライマリアクセス制御と会計幹部社員メカニズムがサービス・ホストに自分たちでゲートウェイ、パケット交換機またはワークステーションではなくあるでしょう。
2. Agents acting on behalf of access control and accounting
executive mechanisms may be necessary in the gateways,
packet switches or workstations. These may be used to
collect data, enforce password protection or mitigate
resource priority and fairness. However, the architecture
and protocols used by these agents may be a local matter
and not possible to specify in advance.
2. アクセスコントロールと会計幹部社員メカニズムを代表して行動しているエージェントがゲートウェイ、パケット交換機またはワークステーションで必要であるかもしれません。 これらは、データを集めるか、パスワード保護を実施するか、またはリソース優先権と公正を緩和するのに使用されるかもしれません。 しかしながら、これらのエージェントによって使用されたアーキテクチャとプロトコルは、あらかじめ指定するのにおいて地域にかかわる事柄であって可能でないかもしれません。
3. NSF gateways may be required to incorporate access control
and accounting mechanisms based on packet
source/destination address, as well as other fields in the
IP header, internal priority and fairness. However, it is
extremely unlikely that these mechanisms would involve a
user-level login to the gateway itself.
3. NSFゲートウェイは、パケットソース/送付先アドレスに基づいてアクセスコントロールと会計機構を取り入れて、IPヘッダー、内部の優先権、および公正で他の分野を取り入れなければならないかもしれません。 しかしながら、これらのメカニズムがユーザレベルログインにゲートウェイ自体にかかわるのは、非常にありそうもないです。
NTAG [Page 23]
NTAG[23ページ]
一覧
スポンサーリンク
