RFC1009 日本語訳
1009 Requirements for Internet gateways. R.T. Braden, J. Postel. June 1987. (Format: TXT=128173 bytes) (Obsoletes RFC0985) (Obsoleted by RFC1812) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden
Request for Comments: 1009 J. Postel
Obsoletes: 985 ISI
June 1987
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 1009 J.ポステルは以下を時代遅れにします。 985 ISI1987年6月
Requirements for Internet Gateways
インターネットゲートウェイのための要件
Status of this Memo
このMemoの状態
This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community. Distribution of this memo is unlimited.
このドキュメントはインターネット・システムで使用されるゲートウェイによって会われるという要件の正式な声明です。 そういうものとして、それはインターネットコミュニティのための公式の仕様書です。 このメモの分配は無制限です。
This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. While it was written specifically to support National Science Foundation research programs, the requirements are stated in a general context and are applicable throughout the Internet community.
このRFCはインターネットがプロトコルであるとサポートしながらゲートウェイがネットワークの間で使用されるという要件をまとめます。 それは特に科学基金が研究計画であるとサポートするために書かれましたが、要件は、一般情勢に述べられていて、インターネットコミュニティ中で適切です。
The purpose of this document is to present guidance for vendors offering gateway 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. As other specifications are updated this document will be revised. Vendors are encouraged to maintain contact with the Internet research community.
このドキュメントの目的はインターネットアプリケーションにおける使用のために使用されるか、または適合させられるかもしれないゲートウェイ製品を提供するベンダーのために指導を提示することです。 それは、現在の仕様を説明するRFCsと他のドキュメントに、必要であるプロトコルを列挙して、参照を与えます。 件数では、仕様は、発展していて、あいまいであるか不完全な情報を含むかもしれません。 これらの場合では、特定の指導を与えるさらなる議論が本書では含まれています。 NSFの科学的ネットワーク共同体に関連している特定保険証券問題はAppendixにまとめられます。 他の仕様をアップデートするとき、このドキュメントを改訂するでしょう。 ベンダーがインターネット研究団体との接触を維持するよう奨励されます。
1. Introduction
1. 序論
The following material is intended as an introduction and background for those unfamiliar with the 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], see also [19, 28, 30, 31].
インターネットアーキテクチャとインターネット・ゲートウェイになじみがないそれらのための序論とバックグラウンドがモデル化されるとき、以下の材料は意図します。 DDNプロトコルHandbook[25]とアルパネット情報Brochure[26]でインターネットアーキテクチャとプロトコル群を支えるのと一般バックグラウンドと議論を見つけることができます、と[19、28、30、31]も見ます。
The Internet protocol architecture was originally developed under DARPA sponsorship to meet both military and civilian communication requirements [32]. The Internet system presently supports a variety of government and government-sponsored operational and research activities. In particular, the National Science Foundation (NSF) is building a major extension to the Internet to provide user access to
インターネットプロトコルアーキテクチャは、元々、軍事のものと同様に民間であるコミュニケーション必要条件[32]を満たすためにDARPAスポンサーシップの下で開発されました。 インターネット・システムは現在、さまざまな政府と操作上と研究の政府によって後援された活動をサポートします。 特に、国立科学財団(NSF)は主要な拡大をユーザアクセスを提供するインターネットに組み込んでいます。
Braden & Postel [Page 1]
ブレーデンとポステル[1ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
national supercomputer centers and other national scientific resources, and to provide a computer networking capability to a large number of universities and colleges.
国家のスーパーコンピュータセンターと他の国家の科学的リソース、多くの大学と大学にコンピュータのネットワーク化能力を供給します。
In this document there are many terms that may be obscure to one unfamiliar with the Internet protocols. There is not much to be done about that but to learn, so dive in. There are a few terms that are much abused in general discussion but are carefully and intentionally used in this document. These few terms are defined here.
本書では、インターネットプロトコルになじみのない1つに不鮮明であるかもしれない多くの用語があります。 それに関してするために多くがあるのではなく、学ぶためにあるので、飛び込んでください。 一般に、たくさん乱用されて、しかし、議論はそうです。いくつかの用語がある、慎重に故意に本書では使用されます。 これらのわずかな用語がここで定義されます。
Packet A packet is the unit of transmission on a physical
network.
パケットAパケットは物理ネットワークにおけるトランスミッションのユニットです。
Datagram A datagram is the unit of transmission in the IP
protocol. To cross a particular network a datagram is
encapsulated inside a packet.
データグラムAデータグラムはIPプロトコルのトランスミッションのユニットです。 特定のネットワークに交差するように、データグラムはパケットの中でカプセル化されます。
Router A router is a switch that receives data transmission
units from input interfaces and, depending on the
addresses in those units, routes them to the
appropriate output interfaces. There can be routers
at different levels of protocol. For example,
Interface Message Processors (IMPs) are packet-level
routers.
ルータAルータは適切な出力インタフェースに入力インタフェースからデータ伝送単位を受けて、それらのユニットのアドレスによって、それらを発送するスイッチです。 異なったレベルのプロトコルにはルータがあることができます。 例えば、Interface Message Processors(IMPs)はパケット・レベルルータです。
Gateway In the Internet documentation generally, and in this
document specifically, a gateway is an IP-level
router. In the Internet community the term has a long
history of this usage [32].
ゲートウェイIn、インターネットドキュメンテーション、一般に、そして、本書では明確に、ゲートウェイはIP-レベルルータです。 インターネットコミュニティでは、用語はこの用法[32]の長い歴史を持っています。
1.1. The DARPA Internet Architecture
1.1. DARPAインターネットアーキテクチャ
1.1.1. Internet Protocols
1.1.1. インターネットプロトコル
The Internet system consists of a number of interconnected
packet networks supporting communication among host computers
using the Internet protocols. These protocols include the
Internet Protocol (IP), the Internet Control Message Protocol
(ICMP), the Transmission Control Protocol (TCP), and
application protocols depending upon them [22].
インターネット・システムはホストコンピュータの中でインターネットプロトコルを使用することでコミュニケーションをサポートする多くのインタコネクトされたパケット網から成ります。 それらによって、これらのプロトコルはインターネットプロトコル(IP)、インターネット・コントロール・メッセージ・プロトコル(ICMP)、通信制御プロトコル(TCP)、およびアプリケーション・プロトコルを含んでいます。[22]。
All Internet protocols use IP as the basic data transport
mechanism. IP [1,31] is a datagram, or connectionless,
internetwork service and includes provision for addressing,
type-of-service specification, fragmentation and reassembly,
and security information. ICMP [2] is considered an integral
すべてのインターネットプロトコルが基礎データ移送機構としてIPを使用します。 IP[1、31]はデータグラム、またはコネクションレスなインターネットワークサービスであり、サービスのタイプのアドレシング、仕様、断片化、および再アセンブリへの支給、およびセキュリティ情報を含めます。 ICMP[2]は全体であると考えられます。
Braden & Postel [Page 2]
ブレーデンとポステル[2ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
part of IP, although it is architecturally layered upon IP.
ICMP provides error reporting, flow control and first-hop
gateway redirection.
それはIPで建築上層にされますが、IPの一部。 ICMPは誤り報告、フロー制御、および最初に、ホップゲートウェイリダイレクションを提供します。
Reliable data delivery is provided in the Internet protocol
suite by transport-level protocols such as the Transmission
Control Protocol (TCP), which provides end-end retransmission,
resequencing and connection control. Transport-level
connectionless service is provided by the User Datagram
Protocol (UDP).
通信制御プロトコル(TCP)などの輸送レベルプロトコルは確実な資料配送をインターネット・プロトコル群に提供します。(通信制御プロトコルは、終わり-終わりの「再-トランスミッション」、再配列、および接続コントロールを提供します)。 輸送レベルコネクションレス型サービスはユーザー・データグラム・プロトコル(UDP)によって提供されます。
1.1.2. Networks and Gateways
1.1.2. ネットワークとゲートウェイ
The constituent networks of the Internet system are required
only to provide packet (connectionless) transport. This
requires only delivery of individual packets. According to the
IP service specification, datagrams can be delivered out of
order, be lost or duplicated and/or contain errors. Reasonable
performance of the protocols that use IP (e.g., TCP) requires
an IP datagram loss rate of less than 5%. 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 necessary for Internet operation.
インターネット・システムの構成しているネットワークはパケットの(コネクションレス)の輸送を提供するだけでよいです。 これは個々のパケットの配送だけを必要とします。 IPサービス仕様に従って、データグラムは、誤りを故障していた状態で提供されるか、失われているか、コピーする、そして/または、含むことができます。 IP(例えば、TCP)を使用するプロトコルの妥当な性能は5%未満のIPデータグラム損失率を必要とします。 コネクション型サービスを提供するそれらのネットワークでは、仮想の回路によって提供された付加的な信頼性は、システムの終わり-終わりの丈夫さを高めますが、インターネット操作に必要ではありません。
Constituent networks may generally be divided into two classes:
一般に、構成しているネットワークは2つのクラスに分割されるかもしれません:
* Local-Area Networks (LANs)
* ローカル・エリア・ネットワーク(LAN)
LANs may have a variety of designs, typically based upon
buss, ring, or star topologies. In general, a LAN will
cover a small geographical area (e.g., a single building or
plant site) and provide high bandwidth with low delays.
LANは、荷舟に通常基づくさまざまなデザインを持っているか、鳴るか、またはtopologiesに主演するかもしれません。 一般に、LANは、小さい地理的な領域(例えば、単一のビルかプラント建設地)をカバーしていて、低い遅れを高帯域に提供するでしょう。
* Wide-Area Networks (WANs)
* ワイドエリアネットワーク(WAN)
Geographically-dispersed hosts and LANs are interconnected
by wide-area networks, also called long-haul networks.
These networks may have a complex internal structure of
lines and packet-routers (typified by ARPANET), or they may
be as simple as point-to-point lines.
地理的に分散しているホストとLANは、広域ネットワークによってインタコネクトされて、また、長期ネットワークと呼ばれます。 これらのネットワークには系列とパケット・ルータ(アルパネットで、代表される)の複雑な内部の構造が同じくらいあるかもしれないか、それらはポイントツーポイントが立ち並んでいるのとまたは同じくらい簡単であるかもしれません。
In the Internet model, constituent networks are connected
together by IP datagram forwarders which are called "gateways"
or "IP routers". In this document, every use of the term
"gateway" is equivalent to "IP router". In current practice,
gateways are normally realized with packet-switching software
インターネットモデルでは、構成しているネットワークはIPデータグラム混載業者どれが「ゲートウェイ」と呼ばれるか、そして、「IPルータ」によって一緒に接続されます。 本書では、「ゲートウェイ」という用語のあらゆる使用が「IPルータ」に同等です。 実際には、現在の通常、ゲートウェイはパケット交換ソフトウェアで実感されます。
Braden & Postel [Page 3]
ブレーデンとポステル[3ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
executing on a general-purpose CPU, but special-purpose
hardware may also be used (and may be required for future
higher-throughput gateways).
また、汎用CPUの上の実行、しかし、専用ハードウェアは使用されるかもしれません(そして、将来の、より高いスループットゲートウェイに必要であるかもしれません)。
A gateway is connected to two or more networks, appearing to
each of these networks as a connected host. Thus, it has a
physical interface and an IP address on each of the connected
networks. Forwarding an IP datagram generally requires the
gateway to choose the address of the next-hop gateway or (for
the final hop) the destination host. This choice, called
"routing", depends upon a routing data-base within the gateway.
This routing data-base should be maintained dynamically to
reflect the current topology of the Internet system; a gateway
normally accomplishes this by participating in distributed
routing and reachability algorithms with other gateways.
Gateways provide datagram transport only, and they seek to
minimize the state information necessary to sustain this
service in the interest of routing flexibility and robustness.
接続ホストとしてそれぞれのこれらのネットワークにおいて現れて、ゲートウェイは2つ以上のネットワークに接続されます。 したがって、それには、それぞれの接続ネットワークに関する物理インターフェースとIPアドレスがあります。 一般に、IPデータグラムを進めるのは、次のホップゲートウェイのアドレスか(最終的なホップのための)あて先ホストを選ぶためにゲートウェイを必要とします。 「ルーティング」と呼ばれるこの選択はゲートウェイの中のルーティングデータベースによります。 このルーティングデータベースはインターネット・システムの現在のトポロジーを反映するためにダイナミックに維持されるべきです。 通常、ゲートウェイは、他のゲートウェイで分配されたルーティングと可到達性アルゴリズムに参加することによって、これを達成します。 ゲートウェイはデータグラム輸送だけを前提とします、そして、それらはルーティングの柔軟性と丈夫さのためにこのサービスを維持するのに必要な州の情報を最小にすると求めます。
Routing devices may also operate at the network level; in this
memo we will call such devices MAC routers (informally called
"level-2 routers", and also called "bridges"). The name
derives from the fact that MAC routers base their routing
decision on the addresses in the MAC headers; e.g., in IEEE
802.3 networks, a MAC router bases its decision on the 48-bit
addresses in the MAC header. Network segments which are
connected by MAC routers share the same IP network number,
i.e., they logically form a single IP network.
また、ルート設定デバイスはネットワークレベルで作動するかもしれません。 このメモでは、私たちは、そのようなデバイスMACルータが(非公式に「レベル-2つのルータ」と呼ばれて、また、「ブリッジ」と呼ばれます。)であると言うつもりです。 名前がMACルータがMACヘッダーで彼らのルーティング決定をアドレスに基礎づけるという事実に由来しています。 例えば、IEEEでは、802.3のネットワークであり、MACルータはMACヘッダーで決定を48ビットのアドレスに基礎づけます。 MACルータによって接続されるネットワークセグメントは同じIPネットワーク・ナンバーを共有します、すなわち、それらがただ一つのIPネットワークを論理的に形成します。
Another variation on the simple model of networks connected
with gateways sometimes occurs: a set of gateways may be
interconnected with only serial lines, to effectively form a
network in which the routing is performed at the internetwork
(IP) level rather than the network level.
ゲートウェイに接続されたネットワークの単純モデルの別の変化は時々起こります: 1セットのゲートウェイはシリアル・ラインだけでインタコネクトされて、事実上、ルーティングがネットワークレベルよりむしろインターネットワーク(IP)レベルで実行されるネットワークを形成するかもしれません。
1.1.3. Autonomous Systems
1.1.3. 自律システム
For technical, managerial, and sometimes political reasons, the
gateways of the Internet system are grouped into collections
called "autonomous systems" [35]. The gateways included in a
single autonomous system (AS) are expected to:
技術的で、経営者の、そして、時々政治上の理由で、インターネット・システムのゲートウェイは「自律システム」[35]と呼ばれる収集に分類されます。 単一の自律システム(AS)に含まれていたゲートウェイによる以下のことと予想されます。
* Be under the control of a single operations and
maintenance (O&M) organization;
* ただ一つの操作とメインテナンス(O&M)組織のコントロールの下にいてください。
* Employ common routing protocols among themselves, to
maintain their routing data-bases dynamically.
* 自分たちの中で一般的なルーティング・プロトコルを使って、ダイナミックにそれらのルーティングデータベースを維持してください。
Braden & Postel [Page 4]
ブレーデンとポステル[4ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
A number of different dynamic routing protocols have been
developed (see Section 4.1); the particular choice of routing
protocol within a single AS is generically called an interior
gateway protocol or IGP.
多くの異なったダイナミックルーティングプロトコルを開発してあります(セクション4.1を見てください)。 独身のASの中のルーティング・プロトコルの特定の選択は一般的に内部のゲートウェイプロトコルかIGPと呼ばれます。
An IP datagram may have to traverse the gateways of two or more
ASs to reach its destination, and the ASs must provide each
other with topology information to allow such forwarding. The
Exterior Gateway Protocol (EGP) is used for this purpose,
between gateways of different autonomous systems.
IPデータグラムは目的地に到着するように2ASsのゲートウェイを横断しなければならないかもしれません、そして、ASsはそのような推進を許すためにトポロジー情報を互いに提供しなければなりません。 Exteriorゲートウェイプロトコル(EGP)は異なった自律システムのゲートウェイの間でこのために使用されます。
1.1.4. Addresses and Subnets
1.1.4. アドレスとサブネット
An IP datagram carries 32-bit source and destination addresses,
each of which is partitioned into two parts -- a constituent
network number and a host number on that network.
Symbolically:
IPデータグラムは32ビットのソースとそれのそれぞれが2つの部品に仕切られる送付先アドレスを運びます--構成しているネットワーク・ナンバーとそのネットワークのホスト番号。 象徴的に:
IP-address ::= { <Network-number>, <Host-number> }
以下をIP扱ってください:= <ネットワーク・ナンバー>、<ホスト番号>。
To finally deliver the datagram, the last gateway in its path
must map the host-number (or "rest") part of an IP address into
the physical address of a host connection to the constituent
network.
最終的にデータグラムを提供するために、経路における最後のゲートウェイはIPアドレスのホスト番号(「休息する」)部分を構成しているネットワークとのホスト接続の物理アドレスに写像しなければなりません。
This simple notion has been extended by the concept of
"subnets", which were 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.
Subnets essentially provide a two-level hierarchical routing
structure for the Internet system. The subnet extension,
described in RFC-950 [21], is now a required part of the
Internet architecture. The basic idea is to partition the
<host number> field into two parts: a subnet number, and a true
host number on that subnet.
この簡単な概念は組織の中にインタコネクトされたLAN構造の任意の複雑さを許容するためにネットワーク・ナンバーとルーティングの複雑さにおける爆発的成長に対してインターネット・システムを絶縁している間、導入された「サブネット」の概念によって敷衍されました。 サブネットは本質的には2レベルの階層型ルーティング構造をインターネット・システムに供給します。 現在、RFC-950[21]で説明されたサブネット拡大はインターネットアーキテクチャの必要な部分です。 基本的な考え方は<ホスト番号>分野を2つの部品に仕切ることです: サブネット番号、およびそのサブネットの真のホスト番号。
IP-address ::=
{ <Network-number>, <Subnet-number>, <Host-number> }
以下をIP扱ってください:= <ネットワーク・ナンバー>、<サブネット番号>、<ホスト番号>。
The interconnected LANs of an organization will be given the
same network number but different subnet numbers. The
distinction between the subnets of such a subnetted network
must not be visible outside that network. Thus, wide-area
routing in the rest of the Internet will be based only upon the
<Network-number> part of the IP destination address; gateways
outside the network will lump <Subnet-number> and <Host-number>
同じネットワーク・ナンバーの、しかし、異なったサブネット番号を組織のインタコネクトされたLANに与えるでしょう。 そのようなサブネット化したネットワークのサブネットの区別はそのネットワークの外で目に見えるはずがありません。 したがって、インターネットの残りにおける広い領域ルーティングはNetwork-数の>が分ける受信者IPアドレスの<だけに基づくでしょう。 ネットワークの外におけるゲートウェイは<Subnet-番号>と<Host-番号>をひとまとめにするでしょう。
Braden & Postel [Page 5]
ブレーデンとポステル[5ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
together to form an uninterpreted "rest" part of the 32-bit IP
address. Within the subnetted network, the local gateways must
route on the basis of an extended network number:
32ビットのIPアドレスの非解釈された「休息」部分を形成するために、一緒にいます。 サブネット化したネットワークの中では、地方のゲートウェイは拡大ネットワーク番号に基づいて以下を発送しなければなりません。
{ <Network-number>, <Subnet-number> }.
<ネットワーク・ナンバー>、<サブネット番号>。
The bit positions containing this extended network number are
indicated by a 32-bit mask called the "subnet mask" [21]; it is
recommended but not required that the <Subnet-number> bits be
contiguous and fall between the <Network-number> and the
<Host-number> fields. No subnet should be assigned the value
zero or -1 (all one bits).
この拡大ネットワーク番号を含むビット位置は「サブネットマスク」[21]と呼ばれる32ビットのマスクによって示されます。 それがお勧めですが、必要でないことで、<が>ビットにSubnet付番するのは、隣接であり、<Network-番号>と>がさばく<Host-番号の間で低下します。 値ゼロか-1(すべての1ビット)をどんなサブネットにも割り当てるべきではありません。
Flexible use of the available address space will be
increasingly important in coping with the anticipated growth of
the Internet. Thus, we allow a particular subnetted network to
use more than one subnet mask. Several campuses with very
large LAN configurations are also creating nested hierarchies
of subnets, sub-subnets, etc.
利用可能なアドレス空間のフレキシブルな使用はますますインターネットの予期された成長に対処する際に重要になるでしょう。 したがって、私たちは特定のサブネット化したネットワークに1個以上のサブネットマスクを使用させます。 また、非常に大きいLAN構成があるいくつかのキャンパスがサブネットの入れ子にされた階層構造、サブサブネットなどを作成しています。
There are special considerations for the gateway when a
connected network provides a broadcast or multicast capability;
these will be discussed later.
接続ネットワークが放送かマルチキャスト能力を提供するとき、ゲートウェイへの特別な問題があります。 後でこれらについて議論するでしょう。
1.2. The Internet Gateway Model
1.2. インターネットゲートウェイモデル
There are two basic models for interconnecting local-area networks
and wide-area (or long-haul) networks in the Internet. In the
first, the local-area network is assigned a network number and all
gateways in the Internet must know how to route to that network.
In the second, the local-area network shares (a small part of) the
address space of the wide-area network. Gateways that support
this second model are called "address sharing gateways" or
"transparent gateways". The focus of this memo is on gateways
that support the first model, but this is not intended to exclude
the use of transparent gateways.
ローカル・エリア・ネットワークとインタコネクトするための2人の基本型と広い領域(または、長期)ネットワークがインターネットにあります。 1番目では、ネットワーク・ナンバーとインターネットのゲートウェイが、どのようにがそのネットワークに発送するかを知らなければならないすべてがローカル・エリア・ネットワークに配属されます。 2番目では、ローカル・エリア・ネットワークが共有される、(小さい部分、)、広域ネットワークのアドレス空間。 この2番目のモデルをサポートするゲートウェイは「ゲートウェイを共有するアドレスか透明なゲートウェイ」と呼ばれます。 第1代モデルをサポートするゲートウェイの上にこのメモの焦点がありますが、これが透明なゲートウェイの使用を除くことを意図しません。
1.2.1. Internet Gateways
1.2.1. インターネットゲートウェイ
An Internet gateway is an IP-level router that performs the
following functions:
インターネット・ゲートウェイは以下の機能を実行するIP-レベルルータです:
1. Conforms to specific Internet protocols specified in
this document, including the Internet Protocol (IP),
Internet Control Message Protocol (ICMP), and others as
necessary. See Section 2 (Protocols Required).
1. 必要に応じてインターネットプロトコル(IP)、インターネット・コントロール・メッセージ・プロトコル(ICMP)、および他のものを含んでいて、本書では指定された特定のインターネットプロトコルに従います。 セクション2を見てください(プロトコルが必要です)。
2. Interfaces to two or more packet networks. For each
2. 2つ以上のパケット網へのインタフェース。 それぞれのために
Braden & Postel [Page 6]
ブレーデンとポステル[6ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
connected network the gateway must implement the
functions required by that network. These functions
typically include:
ゲートウェイが機能を実装しなければならない接続ネットワークがそのネットワークが必要です。 通常これらの機能は:
a. encapsulating and decapsulating the IP datagrams with
the connected network framing (e.g., an Ethernet
header and checksum);
a. 接続ネットワークが(例えば、イーサネットヘッダーとチェックサム)を縁どっているIPデータグラムをカプセル化して、decapsulatingします。
b. sending and receiving IP datagrams up to the maximum
size supported by that network, this size is the
network's "Maximum Transmission Unit" or "MTU";
b. そのネットワークによってサポートされた最大サイズまでの送受信IPデータグラム、このサイズは、ネットワークの「マキシマム・トランスミッション・ユニット」か"MTU"です。
c. translating the IP destination address into an
appropriate network-level address for the connected
network (e.g., an Ethernet hardware address);
c. 適切なネットワークレベルに受信者IPアドレスを翻訳して、接続ネットワークのために(例えば、イーサネットハードウェア・アドレス)を扱ってください。
d. responding to the network flow control and error
indication, if any.
d. もしあればネットワークフロー制御と誤り表示に応じること。
See Section 3 (Constituent Network Interface), for
details on particular constituent network interfaces.
特定の構成しているネットワーク・インターフェースに関する詳細に関してセクション3(構成しているNetwork Interface)を見てください。
3. Receives and forwards Internet datagrams. Important
issues are buffer management, congestion control, and
fairness. See Section 4 (Gateway Algorithms).
3. そして、受信、インターネットデータグラムImportantが発行するフォワードは、バッファ管理と、輻輳制御と、公正です。 セクション4(ゲートウェイアルゴリズム)を見てください。
a. Recognizes various error conditions and generates
ICMP error and information messages as required.
a。 必要に応じてICMP誤りと情報がメッセージであると様々なエラー条件を認めて、生成します。
b. Drops datagrams whose time-to-live fields have
reached zero.
b。 生きる時間野原がゼロに達したデータグラムを下げます。
c. Fragments datagrams when necessary to fit into the
MTU of the next network.
c。 次のネットワークのMTUに収まるのに必要であるときに、データグラムを断片化します。
4. Chooses a next-hop destination for each IP datagram,
based on the information in its routing data-base. See
Section 4 (Gateway Algorithms).
4. ルーティングデータベースの中の情報に基づいたそれぞれのIPデータグラムのための次のホップの目的地を選びます。 セクション4(ゲートウェイアルゴリズム)を見てください。
5. Supports an interior gateway protocol (IGP) to carry out
distributed routing and reachability algorithms with the
other gateways in the same autonomous system. In
addition, some gateways will need to support the
Exterior Gateway Protocol (EGP) to exchange topological
information with other autonomous systems. See
Section 4 (Gateway Algorithms).
5. 他のゲートウェイが同じ自律システムにある状態で分配されたルーティングと可到達性アルゴリズムを行うために、内部のゲートウェイプロトコル(IGP)をサポートします。 さらに、数門は、他の自律システムと位相的な情報を交換するのにExteriorがゲートウェイプロトコル(EGP)であるとサポートする必要があるでしょう。セクション4(ゲートウェイAlgorithms)を見てください。
Braden & Postel [Page 7]
ブレーデンとポステル[7ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
6. Provides system support facilities, including loading,
debugging, status reporting, exception reporting and
control. See Section 5 (Operation and Maintenance).
6. ロードするのを含んでいるデバッグ、状態報告、例外報告書、およびコントロールをシステム支援施設に提供します。 セクション5(維持管理)を見てください。
1.2.2. Embedded Gateways
1.2.2. 埋め込まれたゲートウェイ
A gateway may be a stand-alone computer system, dedicated to
its IP router functions. Alternatively, it is possible to
embed gateway functionality within a host operating system
which supports connections to two or more networks. The
best-known example of an operating system with embedded gateway
code is the Berkeley BSD system. The embedded gateway feature
seems to make internetting easy, but it has a number of hidden
pitfalls:
ゲートウェイはIPルータ機能に捧げられたスタンドアロンのコンピュータシステムであるかもしれません。 あるいはまた、2つ以上のネットワークに接続をサポートするホスト・オペレーティング・システムの中でゲートウェイの機能性を埋め込むのは可能です。 埋め込まれたゲートウェイコードがあるオペレーティングシステムの最もよく知られている例はバークレーBSDシステムです。 埋め込まれたゲートウェイの特徴はinternettingを簡単にするように思えますが、それには、多くの隠れた落とし穴があります:
1. If a host has only a single constituent-network
interface, it should not act as a gateway.
1. ホストに単一の構成しているネットワーク・インターフェースしかないなら、それはゲートウェイとして機能するべきではありません。
For example, hosts with embedded gateway code that
gratuitously forward broadcast packets or datagrams on
the same net often cause packet avalanches.
例えば、埋め込まれたゲートウェイコードをもっている同じネットで無償で放送パケットかデータグラムを進めるホストがしばしばパケット殺到を引き起こします。
2. If a (multihomed) host acts as a gateway, it must
implement ALL the relevant gateway requirements
contained in this document.
2. (「マルチ-家へ帰」りました)ホストがゲートウェイとして務めるなら、それは本書では含まれたすべての関連ゲートウェイ要件を実装しなければなりません。
For example, the routing protocol issues (see Sections
2.6 and 4.1) and the control and monitoring problems are
as hard and important for embedded gateways as for
stand-alone gateways.
例えば、埋め込まれたゲートウェイに、ルーティング・プロトコル問題(セクション2.6と4.1を見る)、コントロール、およびモニターしている問題は、スタンドアロンのゲートウェイのように同じくらい固くて、同じくらい重要です。
Since Internet gateway requirements and
specifications may change independently of operating
system changes, an administration that operates an
embedded gateway in the Internet is strongly advised
to have an ability to maintain and update the gateway
code (e.g., this might require gateway code source).
インターネット・ゲートウェイ要件と仕様がオペレーティングシステム変化の如何にかかわらず変化するかもしれないので、インターネットの埋め込まれたゲートウェイを運用する管理がゲートウェイコードを維持して、アップデートする能力を持っているように強くアドバイスされます(例えば、これはゲートウェイコードソースを必要とするかもしれません)。
3. Once a host runs embedded gateway code, it becomes part
of the Internet system. Thus, errors in software or
configuration of such a host can hinder communication
between other hosts. As a consequence, the host
administrator must lose some autonomy.
3. ホストがいったん埋め込まれたゲートウェイコードを実行すると、それはインターネット・システムの一部になります。 したがって、そのようなホストのソフトウェアか構成における誤りは他のホストのコミュニケーションを妨げる場合があります。 結果として、ホスト管理者は何らかの自治を失わなければなりません。
In many circumstances, a host administrator will need to
disable gateway coded embedded in the operating system,
and any embedded gateway code must be organized so it
can be easily disabled.
多くの事情では、ホスト管理者は、オペレーティングシステムに埋め込まれていた状態でコード化されたゲートウェイを無効にする必要があるでしょう、そして、容易にそれを無効にすることができるようにどんな埋め込まれたゲートウェイコードも組織化しなければなりません。
Braden & Postel [Page 8]
ブレーデンとポステル[8ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
4. If a host running embedded gateway code is concurrently
used for other services, the O&M (operation and
maintenance) requirements for the two modes of use may
be in serious conflict.
4. 埋め込まれたゲートウェイコードを実行するホストが他のサービスに同時に使用されるなら、使用の2つの方法のためのO&M(維持管理)要件は重大な闘争中であるかもしれません。
For example, gateway O&M will in many cases be performed
remotely by an operations center; this may require
privileged system access which the host administrator
would not normally want to distribute.
例えば、多くの場合、ゲートウェイO&Mは操作センターによって離れて実行されるでしょう。 これは通常、ホスト管理者が広げたがっていない特権があるシステムアクセスを必要とするかもしれません。
1.2.3. Transparent Gateways
1.2.3. 透明なゲートウェイ
The basic idea of a transparent gateway is that the hosts on
the local-area network behind such a gateway share the address
space of the wide-area network in front of the gateway. In
certain situations this is a very useful approach and the
limitations do not present significant drawbacks.
透明なゲートウェイの基本的な考え方はそのようなゲートウェイの後ろのローカル・エリア・ネットワークのホストがゲートウェイの正面で広域ネットワークのアドレス空間を共有するということです。 ある状況で、これは非常に役に立つアプローチです、そして、制限は重要な欠点を提示しません。
The words "in front" and "behind" indicate one of the
limitations of this approach: this model of interconnection is
suitable only for a geographically (and topologically) limited
stub environment. It requires that there be some form of
logical addressing in the network level addressing of the
wide-area network (that is, all the IP addresses in the local
environment map to a few (usually one) physical address in the
wide-area network, in a way consistent with the { IP address
<-> network address } mapping used throughout the wide-area
network).
単語の「前部」と“behind"はこのアプローチの制限の1つを示します: インタコネクトのこのモデルは地理的に限られた(位相的に)スタッブ環境だけに適しています。 それはネットワークレベルの何らかのフォームの論理的なアドレシングが広域ネットワークのアドレシングであったならそこでそれを必要とします(すなわち、地方の環境におけるすべてのIPアドレスが広域ネットワーク、写像されるIPアドレス<->ネットワーク・アドレスと一致した方法でいくつか(通常1)に物理アドレスを広域ネットワーク中で使用されていた状態で写像します)。
Multihoming is possible on one wide-area network, but may
present routing problems if the interfaces are geographically
or topologically separated. Multihoming on two (or more)
wide-area networks is a problem due to the confusion of
addresses.
マルチホーミングは、1つの広域ネットワークで可能ですが、インタフェースが地理的か位相的に切り離されるなら、ルーティング問題を提示するかもしれません。 アドレスの混乱のために2つ(さらに)の広域ネットワークに関するマルチホーミングは問題です。
The behavior that hosts see from other hosts in what is
apparently the same network may differ if the transparent
gateway cannot fully emulate the normal wide-area network
service. For example, if there were a transparent gateway
between the ARPANET and an Ethernet, a remote host would not
receive a Destination Dead message [3] if it sent a datagram to
an Ethernet host that was powered off.
ホストが他のホストからことで見る振舞いは透明なゲートウェイが完全に通常の広域ネットワークサービスを見習うことができるというわけではないなら明らかに同じネットワークが異なるかもしれないということです。 例えば、アルパネットとイーサネットの間には、透明なゲートウェイがあれば、[3] 離れて動かされたイーサネットホストにデータグラムを送るなら、リモートホストはDestination Deadメッセージを受け取らないでしょうに。
Braden & Postel [Page 9]
ブレーデンとポステル[9ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
1.3. Gateway Characteristics
1.3. ゲートウェイの特性
Every Internet gateway must perform the functions listed above.
However, a vendor will have many choices on power, complexity, and
features for a particular gateway product. It may be helpful to
observe that the Internet system is neither homogeneous nor
fully-connected. For reasons of technology and geography, it is
growing into a global-interconnect system plus a "fringe" of LANs
around the "edge".
あらゆるインターネット・ゲートウェイが上に記載された機能を実行しなければなりません。 しかしながら、ベンダーは特定のゲートウェイ製品のためのパワー、複雑さ、および特徴に多くの選択を持つでしょう。 インターネット・システムが同次でなくて完全に接続されているというわけではないのを観測するのは役立っているかもしれません。 技術と地理学の理由で、それは「縁」の周りでグローバルな内部連絡システムとLANの「フリンジ」になっています。
* The global-interconnect system is comprised of a number of
wide-area networks to which are attached gateways of several
ASs; there are relatively few hosts connected directly to
it. The global-interconnect system includes the ARPANET,
the NSFNET "backbone", the various NSF regional and
consortium networks, other ARPA sponsored networks such as
the SATNET and the WBNET, and the DCA sponsored MILNET. It
is anticipated that additional networks sponsored by these
and other agencies (such as NASA and DOE) will join the
global-interconnect system.
* グローバルな内部連絡システムはどれが数個のASsの付属ゲートウェイであるかに多くの広域ネットワークから成ります。 直接それに接されたホストは比較的わずかしかいません。 グローバルな内部連絡システムはアルパネット、NSFNET「バックボーン」、NSF地方と共同体の様々なネットワークを含んで、他のARPAはSATNETやWBNETなどの後援されたネットワークです、そして、DCAはMILNETを後援しました。 これらによって後援された追加ネットワークと他の政府機関(NASAやDOEなどの)がグローバルな内部連絡システムに合流すると予期されます。
* Most hosts are connected to LANs, and many organizations
have clusters of LANs interconnected by local gateways.
Each such cluster is connected by gateways at one or more
points into the global-interconnect system. If it is
connected at only one point, a LAN is known as a "stub"
network.
* ほとんどのホストがLANに接続されます、そして、多くの組織が地方のゲートウェイでLANのクラスタとインタコネクトさせます。 そのような各クラスタは1ポイント以上でゲートウェイによってグローバルな内部連絡システムに接続されます。 それが1ポイントだけで接続されるなら、LANは「スタッブ」ネットワークとして知られています。
Gateways in the global-interconnect system generally require:
一般に、グローバルな内部連絡システムのゲートウェイは以下を必要とします。
* Advanced routing and forwarding algorithms
* 高度なルーティングとアルゴリズムを進めること。
These gateways need routing algorithms which are highly
dynamic and also offer type-of-service routing. Congestion
is still not a completely resolved issue [24]. Improvements
to the current situation will be implemented soon, as the
research community is actively working on these issues.
これらのゲートウェイは、非常にダイナミックなルーティング・アルゴリズムを必要として、また、サービスのタイプにルーティングを提供します。 それでも、混雑は完全な決心している問題[24]であるというわけではない。 研究団体が活発にこれらの問題に取り組んでいるとき、現在の状況への改良はすぐ、実装されるでしょう。
* High availability
* 高可用性
These gateways need to be highly reliable, providing 24 hour
a day, 7 days a week service. In case of failure, they must
recover quickly.
1日あたり24時間提供して、これらのゲートウェイは、高信頼性である必要があって、年中無休はサービスです。 失敗の場合には、彼らはすぐに回復しなければなりません。
* Advanced O&M features
* 高度なOとMの特徴
These gateways will typically be operated remotely from a
regional or national monitoring center. In their
通常、これらのゲートウェイは地方の、または、国家のモニターしている中心から離れて操作されるでしょう。 中、それら
Braden & Postel [Page 10]
ブレーデンとポステル[10ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
interconnect role, they will need to provide sophisticated
means for monitoring and measuring traffic and other events
and for diagnosing faults.
内部連絡の役割、彼らはトラフィックと他のイベントをモニターして、測定して、欠点を診断するための高度な手段を提供する必要があるでしょう。
* High performance
* 高性能
Although long-haul lines in the Internet today are most
frequently 56 Kbps, DS1 lines (1.5 Mbps) are of increasing
importance, and even higher speeds are likely in the future.
Full-duplex operation is provided at any of these speeds.
最も頻繁に今日のインターネットの長期系列は56Kbpsですが、DS1系列(1.5Mbps)は増加して重要です、そして、さらに高い速度は将来、ありそうです。 これらの速度のいずれでも全二重操作を提供します。
The average size of Internet datagrams is rather small, of
the order of 100 bytes. At DS1 line speeds, the
per-datagram processing capability of the gateways, rather
than the line speed, is likely to be the bottleneck. To
fill a DS1 line with average-sized Internet datagrams, a
gateway would need to pass -- receive, route, and send --
2,000 datagrams per second per interface. That is, a
gateway which supported 3 DS1 lines and and Ethernet
interface would need to be able to pass a dazzling 2,000
datagrams per second in each direction on each of the
interfaces, or a aggregate throughput of 8,000 datagrams per
second, in order to fully utilize DS1 lines. This is beyond
the capability of current gateways.
インターネットデータグラムの平均のサイズは100バイトの注文でかなりわずかです。 DS1ライン・スピードでは、ゲートウェイの1データグラムあたりの処理能力はライン・スピードよりむしろボトルネックである傾向があります。 平均サイズのインターネットデータグラムでDS1系列を満たすには、ゲートウェイは、通る必要があるでしょう--受信してください、ルート、そして、発信してください--1インタフェースあたりの秒あたり2,000個のデータグラム。 そして、すなわち、3つのDS1系列をサポートした門、そして、DS1系列を完全に利用するために2番目のコネあたり2,000個のデータグラムにそれぞれのインタフェース、または1秒あたり8,000個のデータグラムの集合スループットに各方向を幻惑するインタフェースがaを通過できるように必要とするイーサネット。 これは現在のゲートウェイの能力を超えています。
Note: some vendors count input and output operations
separately in datagrams per second figures; for these
vendors, the above example would imply 16,000 datagrams
per second !
以下に注意してください。 いくつかのベンダーが別々に2番目の数字あたりのデータグラムで入出力操作を数えます。 これらのベンダーに関しては、上記の例は1秒あたり1万6000個のデータグラムを含意します!
Gateways used in the "LAN fringe" (e.g., campus networks) will
generally have to meet less stringent requirements for
performance, availability, and maintenance. These may be high or
medium-performance devices, probably competitively procured from
several different vendors and operated by an internal organization
(e.g., 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. In this environment, there will be less formal O&M,
more hand-crafted static configurations for special cases, and
more need for inter-operation with gateways of other vendors. The
routing mechanism will need to be very flexible, but need not be
so highly dynamic as in the global-interconnect system.
一般に、「LANフリンジ」(例えば、キャンパスネットワーク)に使用されるゲートウェイは性能、有用性、およびメインテナンスのためのそれほど厳しくない必要条件を満たさなければならないでしょう。 これらはたぶんいくつかの異なったベンダーから競争的に調達されて、内部の組織(例えば、キャンパス計算機センタ)によって運用された高いか中くらいの性能のデバイスであるかもしれません。 これらのゲートウェイのデザインは低い平均値遅れと良い炸裂性能を強調するべきです、遅れとサービスのタイプの敏感な資源管理と共に。 この環境には、他のベンダーのゲートウェイによる相互操作のそれほど正式でないO&M、特別なケースのための、より手作りの静的な構成、および、より多くの必要があるでしょう。 ルーティングメカニズムは、非常にフレキシブルであることが必要ですが、グローバルな内部連絡システムのようにあまりに非常にダイナミックである必要はありません。
It is important to realize that Internet gateways normally operate
in an unattended mode, but that equipment and software faults can
have a wide-spread (sometimes global) effect. In any environment,
インターネット・ゲートウェイが無人のモードで通常作動しますが、設備とソフトウェア欠点が広範囲(時々グローバルな)の効果を持つことができるとわかるのは重要です。 どんな環境でも
Braden & Postel [Page 11]
ブレーデンとポステル[11ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
a gateway must be highly robust and able to operate, possibly in a
degraded state, under conditions of extreme congestion or failure
of network resources.
ゲートウェイは、非常に強健であって、作動できなければなりません、ことによると降格している状態で、極端な混雑の状態かネットワーク資源の失敗の下で。
Even though the Internet system is not fully-interconnected, many
parts of the system do need to have redundant connectivity. A
rich connectivity allows reliable service despite failures of
communication lines and gateways, and it can also improve service
by shortening Internet paths and by providing additional capacity.
The engineering tradeoff between cost and reliability must be made
for each component of the Internet system.
インターネット・システムは完全にインタコネクトされているというわけではありませんが、システムの多くの部分が余分な接続性を必要とします。 通信回線とゲートウェイの失敗にもかかわらず、豊かな接続性は信頼できるサービスを許します、そして、また、それはインターネット経路を短くして、追加容量を提供することによって、サービスを改良できます。 インターネット・システムの各部品のために費用と信頼性の間で工学見返りを作らなければなりません。
Braden & Postel [Page 12]
ブレーデンとポステル[12ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
2. Protocols Required in Gateways
2. プロトコルがゲートウェイで必要です。
The Internet architecture uses datagram gateways to interconnect constituent networks. This section describes the various protocols which a gateway needs to implement.
インターネットアーキテクチャは、構成しているネットワークとインタコネクトするのにデータグラムゲートウェイを使用します。 このセクションはゲートウェイが実装する必要がある様々なプロトコルについて説明します。
2.1. Internet Protocol (IP)
2.1. インターネットプロトコル(IP)
IP is the basic datagram protocol used in the Internet system [19,
31]. It is described in RFC-791 [1] and also in MIL-STD-1777 [5]
as clarified by RFC-963 [36] ([1] and [5] are intended to describe
the same standard, but in quite different words). The subnet
extension is described in RFC-950 [21].
IPはインターネット・システム[19、31]で使用される基本的なデータグラムプロトコルです。 それがRFC-791[1]で説明されて、1777年にも軍規格-、RFC-963[36]([1]によってはっきりさせられる[5]と[5]が同じ規格について説明することを意図しますが、全く異なった単語にある、) サブネット拡大はRFC-950[21]で説明されます。
With respect to current gateway requirements the following IP
features can be ignored, although they may be required in the
future: Type of Service field, Security option, and Stream ID
option. However, if recognized, the interpretation of these
quantities must conform to the standard specification.
現在のゲートウェイ要件に関して、以下のIPの特徴を無視できます、それらが将来、必要であるかもしれませんが: Service分野、Securityオプション、およびStream IDオプションのタイプ。 しかしながら、認識されるなら、これらの量の解釈は標準の仕様に従わなければなりません。
It is important for gateways to implement both the Loose and
Strict Source Route options. The Record Route and Timestamp
options are useful diagnostic tools and must be supported in all
gateways.
ゲートウェイが、両方がLooseとStrict Source Routeオプションであると実装するのは、重要です。 Record RouteとTimestampオプションを役に立つ診断用道具であり、すべてのゲートウェイでサポートしなければなりません。
The Internet model requires that a gateway be able to fragment
datagrams as necessary to match the MTU of the network to which
they are being forwarded, but reassembly of fragmented datagrams
is generally left to the destination hosts. Therefore, a gateway
will not perform reassembly on datagrams it forwards.
インターネットモデルは、ゲートウェイがそれらが送られているネットワークのMTUを合わせるために必要に応じてデータグラムを断片化できるのを必要としますが、一般に、断片化しているデータグラムの再アセンブリはあて先ホストに残されます。 したがって、ゲートウェイは再アセンブリにそれが進めるデータグラムに働かないでしょう。
However, a gateway will generally receive some IP datagrams
addressed to itself; for example, these may be ICMP Request/Reply
messages, routing update messages (see Sections 2.3 and 2.6), or
for monitoring and control (see Section 5). For these datagrams,
the gateway will be functioning as a destination host, so it must
implement IP reassembly in case the datagrams have been fragmented
by some transit gateway. The destination gateway must have a
reassembly buffer which is at least as large as the maximum of the
MTU values for its network interfaces and 576. Note also that it
is possible for a particular protocol implemented by a host or
gateway to require a lower bound on reassembly buffer size which
is larger than 576. Finally, a datagram which is addressed to a
gateway may use any of that gateway's IP addresses as destination
address, regardless of which interface the datagram enters.
しかしながら、一般に、ゲートウェイはそれ自体に扱われたいくつかのIPデータグラムを受けるでしょう。 例えば、これらはICMP Request/応答メッセージであるかもしれません、アップデートメッセージ(セクション2.3と2.6を見る)を発送するか、またはモニターとコントロールのために(セクション5を見てください)。 これらのデータグラムに関しては、ゲートウェイがあて先ホストとして機能するので、データグラムが、あるトランジットゲートウェイによって断片化されたといけないので、それは、IPが再アセンブリであると実装しなければなりません。 目的地ゲートウェイには、ネットワークのためのMTU値の最大が連結するのと少なくとも同じくらい大きい再アセンブリバッファと576がなければなりません。 また、ホストかゲートウェイによって実装された特定のプロトコルに、576より大きい再アセンブリバッファサイズで下界を必要とするのが可能であることに注意してください。 最終的に、ゲートウェイに扱われるデータグラムは送付先アドレスとしてそのゲートウェイのIPアドレスのどれかを使用するかもしれません、データグラムがどのインタフェースに入るかにかかわらず。
There are five classes of IP addresses: Class A through
Class E [23]. Of these, Class D and Class E addresses are
5つのクラスのIPアドレスがあります: クラスE[23]を通してAを分類してください。 これらでは、Class DとEが扱うClassはそうです。
Braden & Postel [Page 13]
ブレーデンとポステル[13ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
reserved for experimental use. A gateway which is not
participating in these experiments must ignore all datagrams with
a Class D or Class E destination IP address. ICMP Destination
Unreachable or ICMP Redirect messages must not result from
receiving such datagrams.
実験用のために、予約されます。 これらの実験に参加していないゲートウェイはClass DかClass E送付先IPアドレスがあるすべてのデータグラムを無視しなければなりません。 ICMP Destination UnreachableかICMP Redirectメッセージがそのようなデータグラムを受けるのから結果として生じてはいけません。
There are certain special cases for IP addresses, defined in the
latest Assigned Numbers document [23]. These special cases can be
concisely summarized using the earlier notation for an IP address:
IPアドレスのための最新のAssigned民数記ドキュメント[23]で定義されたある特別なケースがあります。 IPアドレスに以前の記法を使用することでこれらの特別なケースを簡潔にまとめることができます:
IP-address ::= { <Network-number>, <Host-number> }
以下をIP扱ってください:= <ネットワーク・ナンバー>、<ホスト番号>。
or
または
IP-address ::= { <Network-number>, <Subnet-number>,
<Host-number> }
以下をIP扱ってください:= <ネットワーク・ナンバー>、<サブネット番号>、<ホスト番号>。
if we also use the notation "-1" to mean the field contains all 1
bits. Some common special cases are as follows:
また、私たちが記法を使用するなら、「-何1インチも、分野を意味するのはすべての1ビットを含んでいます」。 いくつかの一般的な特別なケースは以下の通りです:
(a) {0, 0}
(a){0, 0}
This host on this network. Can only be used as a source
address (see note later).
このネットワークのこのホスト。 ソースアドレスとして使用できるだけです(後で注意を見てください)。
(b) {0, <Host-number>}
(b)0、<ホスト番号>。
Specified host on this network. Can only be used as a
source address.
このネットワークの指定されたホスト。 ソースアドレスとして使用できるだけです。
(c) { -1, -1}
(c){ -1, -1}
Limited broadcast. Can only be used as a destination
address, and a datagram with this address must never be
forwarded outside the (sub-)net of the source.
株式会社は放送されました。 送付先アドレスとして使用できるだけであって、このアドレスがあるデータグラムを外に決して送ってはいけない、(サブ、)、ソースのネット。
(d) {<Network-number>, -1}
(d)<ネットワーク・ナンバー>、-1
Directed broadcast to specified network. Can only be used
as a destination address.
指定されたネットワークへの指示された放送。 送付先アドレスとして使用できるだけです。
(e) {<Network-number>, <Subnet-number>, -1}
(e)<ネットワーク・ナンバー>、<サブネット番号>、-1
Directed broadcast to specified subnet. Can only be used as
a destination address.
指定されたサブネットへの指示された放送。 送付先アドレスとして使用できるだけです。
(f) {<Network-number>, -1, -1}
(f)<ネットワーク・ナンバー>、-1、-1
Braden & Postel [Page 14]
ブレーデンとポステル[14ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
Directed broadcast to all subnets of specified subnetted
network. Can only be used as a destination address.
指定されたサブネット化したネットワークのすべてのサブネットへの指示された放送。 送付先アドレスとして使用できるだけです。
(g) {127, <any>}
(g)127、<、どんな>。
Internal host loopback address. Should never appear outside
a host.
内部のホストループバックアドレス。 ホストの外に決して現れるべきではありません。
The following two are conventional notation for network numbers,
and do not really represent IP addresses. They can never be used
in an IP datagram header as an IP source or destination address.
以下の2は、ネットワーク・ナンバーのための従来の記法であり、本当にIPアドレスを表しません。 IPソースか送付先アドレスとしてIPデータグラムヘッダーでそれらを決して使用できません。
(h) {<Network-number>, 0}
(h)<ネットワーク・ナンバー>、0
Specified network (no host).
指定されたネットワーク(ホストがありません)。
(i) {<Network-number>, <Subnet-number>, 0}
(i)<ネットワーク・ナンバー>、<サブネット番号>、0
Specified subnet (no host).
指定されたサブネット(ホストがありません)。
Note also that the IP broadcast address, which has primary
application to Ethernets and similar technologies that support an
inherent 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 not in conformance with
the specification [23, 49, 50].
また、IP放送演説(固有の放送機能をサポートするEthernetsと同様の技術にプライマリアプリケーションを持っている)がIPアドレスのホスト分野にオールもの値を持っていることに注意してください。 いくつかの早めの実装がこの目的のためのオールゼロ値を選びました。(目的は順応仕様[23、49、50]で中ではありません)。
2.2. Internet Control Message Protocol (ICMP)
2.2. インターネット・コントロール・メッセージ・プロトコル(ICMP)
ICMP is an auxiliary protocol used to convey advice and error
messages and is described in RFC-792 [2].
ICMPはアドバイスとエラーメッセージを伝えるのに使用される補助のプロトコルであり、RFC-792[2]で説明されます。
We will discuss issues arising from gateway handling of particular
ICMP messages. The ICMP messages are grouped into two classes:
error messages and information messages. ICMP error messages are
never sent about ICMP error messages, nor about broadcast or
multicast datagrams.
私たちは特定のICMPメッセージのゲートウェイ取り扱いから起こる問題について議論するつもりです。 ICMPメッセージは2つのクラスに分類されます: エラーメッセージと情報メッセージ。 ICMPエラーメッセージの周りと、そして、放送かマルチキャストデータグラムの周りに関してICMPエラーメッセージを決して送りません。
The ICMP error messages are: Destination Unreachable, Redirect,
Source Quench, Time Exceeded, and Parameter Problem.
ICMPエラーメッセージは以下の通りです。 目的地の手の届かなくて、再直接のソース焼き入れ、超えられていた時間、およびパラメタ問題。
The ICMP information messages are: Echo, Information,
Timestamp, and Address Mask.
ICMP情報メッセージは以下の通りです。 エコー、情報、タイムスタンプ、およびアドレスマスク。
Braden & Postel [Page 15]
ブレーデンとポステル[15ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
2.2.1. Destination Unreachable
2.2.1. 目的地手が届きません。
The distinction between subnets of a subnetted network, which
depends on the address mask described in RFC-950 [21], must not
be visible outside that network. This distinction is important
in the case of the ICMP Destination Unreachable message.
RFC-950[21]で説明されたアドレスマスクによるサブネット化したネットワークのサブネットの区別はそのネットワークの外で目に見えるはずがありません。 この区別はICMP Destination Unreachableメッセージの場合で重要です。
The ICMP Destination Unreachable message is sent by a gateway
in response to a datagram which it cannot forward because the
destination is unreachable or down. The gateway chooses one of
the following two types of Destination Unreachable messages to
send:
目的地が手が届かないか、または下がっているので、ゲートウェイはそれが進めることができないデータグラムに対応してICMP Destination Unreachableメッセージを送ります。 ゲートウェイは発信する以下の2つのタイプに関するDestination Unreachableメッセージの1つを選びます:
* Net Unreachable
* ネット手が届きません。
* Host Unreachable
* ホスト手が届きません。
Net unreachable implies that an intermediate gateway was unable
to forward a datagram, as its routing data-base gave no next
hop for the datagram, or all paths were down. Host Unreachable
implies that the destination network was reachable, but that a
gateway on that network was unable to reach the destination
host. This might occur if the particular destination network
was able to determine that the desired host was unreachable or
down. It might also occur when the destination host was on a
subnetted network and no path was available through the subnets
of this network to the destination. Gateways should send Host
Unreachable messages whenever other hosts on the same
destination network might be reachable; otherwise, the source
host may erroneously conclude that ALL hosts on the network are
unreachable, and that may not be the case.
ネット手の届かない、ルーティングデータベースが次にデータグラムのためのホップ、または経路があったすべてをいいえに与えたとき、中間ゲートウェイがデータグラムを進めることができなかったのを含意します。 ホストUnreachableは、送信先ネットワークが届いていましたが、そのネットワークのゲートウェイがあて先ホストに届くことができなかったのを含意します。 特定の送信先ネットワークが、必要なホストが手が届かないか、または下がっていたことを決定できるなら、これは起こるでしょうに。 また、あて先ホストがサブネット化したネットワークの一員であり、どんな経路もこのネットワークのサブネットを通して目的地に利用可能でなかったときに、それは起こるかもしれません。 同じ送信先ネットワークの他のホストが届くかもしれないときはいつも、ゲートウェイはメッセージをHost Unreachableに送るはずです。 さもなければ、送信元ホストは、ネットワークのすべてのホストが手が届かないと誤って結論を下すかもしれません、そして、それはそうでないかもしれません。
2.2.2. Redirect
2.2.2. 再直接
The ICMP Redirect message is sent by a gateway to a host on the
same network, in order to change the gateway used by the host
for routing certain datagrams. A choice of four types of
Redirect messages is available to specify datagrams destined
for a particular host or network, and possibly with a
particular type-of-service.
同じネットワークでゲートウェイでICMP Redirectメッセージをホストに送ります、あるデータグラムを発送するのにホストによって使用されたゲートウェイを変えるために。4つのタイプに関するRedirectメッセージの選択は、特定のホストかネットワーク、およびことによると特定のサービスのタイプで運命づけられたデータグラムを指定するために利用可能です。
If the directly-connected network is not subnetted, a gateway
can normally send a network Redirect which applies to all hosts
on a specified remote network. Using a network rather than a
host Redirect may economize slightly on network traffic and on
host routing table storage. However, the saving is not
significant, and subnets create an ambiguity about the subnet
直接接続されたネットワークが「副-網で覆」われないなら、通常、ゲートウェイはすべてのホストに適用するネットワークRedirectを指定されたリモートネットワークに送ることができます。 ホストRedirectよりむしろネットワークを使用するのはわずかなネットワークトラフィックとホスト経路指定テーブルストレージのときに締められるかもしれません。 しかしながら、節約は重要ではありません、そして、サブネットはサブネットに関してあいまいさを作成します。
Braden & Postel [Page 16]
ブレーデンとポステル[16ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
mask to be used to interpret a network Redirect. In a general
subnet environment, it is difficult to specify precisely the
cases in which network Redirects can be used.
ネットワークRedirectを解釈するのに使用されるために、マスクをかけます。 一般的なサブネット環境で、正確にネットワークRedirectsを使用できる場合を指定するのは難しいです。
Therefore, it is recommended that a gateway send only host (or
host and type-of-service) Redirects.
したがって、ゲートウェイが発信するのは、お勧めです。ホスト(ホストとサービスのタイプ)だけが向け直します。
2.2.3. Source Quench
2.2.3. ソース焼き入れ
All gateways must contain code for sending ICMP Source Quench
messages when they are forced to drop IP datagrams due to
congestion. Although the Source Quench mechanism is known to
be an imperfect means for Internet congestion control, and
research towards more effective means is in progress, Source
Quench is considered to be too valuable to omit from production
gateways.
混雑のためやむを得ずIPデータグラムを下げるとき、すべてのゲートウェイが送付ICMP Source Quenchメッセージのためのコードを含まなければなりません。 Source Quenchメカニズムはインターネット輻輳制御のための不完全な手段であることが知られています、そして、より効果的な手段に向かった研究は進行していますが、Source Quenchが生産ゲートウェイから省略できないくらい貴重であると考えられます。
There is some argument that the Source Quench should be sent
before the gateway is forced to drop datagrams [62]. For
example, a parameter X could be established and set to have
Source Quench sent when only X buffers remain. Or, a parameter
Y could be established and set to have Source Quench sent when
only Y per cent of the buffers remain.
ゲートウェイがやむを得ずデータグラム[62]を下げる前にSource Quenchを送るべきであるという何らかの主張があります。 例えば、パラメタXは、Xバッファだけが残っているとき、Source Quenchを送らせるように確立されて、設定されるかもしれません。 または、パラメタYは、バッファのYパーセントだけが残っているとき、Source Quenchを送らせるように確立されて、設定されるかもしれません。
Two problems for a gateway sending Source Quench are: (1) the
consumption of bandwidth on the reverse path, and (2) the use
of gateway CPU time. To ameliorate these problems, a gateway
must be prepared to limit the frequency with which it sends
Source Quench messages. This may be on the basis of a count
(e.g., only send a Source Quench for every N dropped datagrams
overall or per given source host), or on the basis of a time
(e.g., send a Source Quench to a given source host or overall
at most once per T millseconds). The parameters (e.g., N or T)
must be settable as part of the configuration of the gateway;
furthermore, there should be some configuration setting which
disables sending Source Quenches. These configuration
parameters, including disabling, should ideally be specifiable
separately for each network interface.
Source Quenchを送るゲートウェイへの2つの問題は以下の通りです。 (1) (2) 逆の経路における帯域幅の消費、およびゲートウェイCPU時間の使用。 これらの問題を改善するために、メッセージをSource Quenchにそれと送る頻度を制限するようにゲートウェイを準備しなければなりません。 これはカウント(例えば、全体的に見てか与えられた送信元ホストあたりN下げられたデータグラム毎のためにSource Quenchを送るだけである)に基づいた時間(例えば、全体的に見て高々T millsecondsに一度与えられた送信元ホストにSource Quenchを送る)に基づいたそうです。 パラメタ(例えば、NかT)はゲートウェイの構成の一部として「舗装用敷石-可能」であるに違いありません。 その上、送付がSource Quenchesであると無効にする何らかの構成設定があるはずです。 各ネットワーク・インターフェースにおいて、無効にするのを含むこれらの設定パラメータは別々に理想的に明記できるべきです。
Note that a gateway itself may receive a Source Quench as the
result of sending a datagram targeted to another gateway. Such
datagrams might be an EGP update, for example.
ゲートウェイ自体がもう1門に狙うデータグラムを送るという結果としてSource Quenchを受けるかもしれないことに注意してください。 例えば、そのようなデータグラムはEGPアップデートであるかもしれません。
2.2.4. Time Exceeded
2.2.4. 超えられていた時間
The ICMP Time Exceeded message may be sent when a gateway
discards a datagram due to the TTL being reduced to zero. It
ゲートウェイがゼロまで減少するTTLのためデータグラムを捨てるとき、ICMP Time Exceededメッセージを送るかもしれません。 それ
Braden & Postel [Page 17]
ブレーデンとポステル[17ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
may also be sent by a gateway if the fragments of a datagram
addressed to the gateway itself cannot be reassembled before
the time limit.
また、タイムリミットの前にゲートウェイ自体に扱われたデータグラムの断片を組み立て直すことができないなら、ゲートウェイは送るかもしれません。
2.2.5. Parameter Problem
2.2.5. パラメタ問題
The ICMP Parameter Problem message may be sent to the source
host for any problem not specifically covered by another ICMP
message.
別のICMPメッセージで明確にカバーされなかったどんな問題によってもICMP Parameter Problemメッセージを送信元ホストに送るかもしれません。
2.2.6. Address Mask
2.2.6. アドレスマスク
Host and gateway implementations are expected to support the
ICMP Address Mask messages described in RFC-950 [21].
ホストとゲートウェイ実装がRFC-950[21]で説明されたICMP Address Maskメッセージをサポートすると予想されます。
2.2.7. Timestamp
2.2.7. タイムスタンプ
The ICMP Timestamp message has proven to be useful for
diagnosing Internet problems. The preferred form for a
timestamp value, the "standard value", is in milliseconds since
midnight GMT. However, it may be difficult to provide this
value with millisecond resolution. For example, many systems
use clocks which update only at line frequency, 50 or 60 times
per second. Therefore, some latitude is allowed in a
"standard" value:
ICMP Timestampメッセージはインターネット問題を診断することの役に立つと判明しました。グリニッジ標準時に、真夜中以来タイムスタンプ値のための「基準値」という好まれた形がミリセカンドであります。しかしながら、ミリセカンド解決をこの値に提供するのは難しいかもしれません。 例えば、多くのシステムが単に回線周波数、50または60歳のときに1秒あたりの回をアップデートする時計を使用します。 したがって、何らかの緯度が「標準」の値で許容されています:
* The value must be updated at a frequency of at least 30
times per second (i.e., at most five low-order bits of
the value may be undefined).
* 1秒あたり少なくとも30回(すなわち、価値のほとんどの5下位のビットでは、未定義であるかもしれない)の頻度で値をアップデートしなければなりません。
* The origin of the value must be within a few minutes of
midnight, i.e., the accuracy with which operators
customarily set CPU clocks.
* 数分の真夜中(すなわち、オペレータが通例にCPU時計を設定する精度)以内に、価値の発生源があるに違いありません。
To meet the second condition for a stand-alone gateway, it will
be necessary to query some time server host when the gateway is
booted or restarted. It is recommended that the UDP Time
Server Protocol [44] be used for this purpose. A more advanced
implementation would use NTP (Network Time Protocol) [45] to
achieve nearly millisecond clock synchronization; however, this
is not required.
ゲートウェイがブートされるか、または再開されるとき、スタンドアロンのゲートウェイのための第2条件を満たすために、いつかサーバー・ホストについて質問するのが必要でしょう。 UDP Time Serverプロトコル[44]がこのために使用されるのは、お勧めです。 より高度な実装はほとんどミリセカンド時計同期を達成するのにNTP(ネットワークTimeプロトコル)[45]を使用するでしょう。 しかしながら、これは必要ではありません。
Even if a gateway is unable to establish its time origin, it
ought to provide a "non-standard" timestamp value (i.e., with
the non-standard bit set), as a time in milliseconds from
system startup.
ゲートウェイが時間発生源を確立できないでも、「標準的でない」タイムスタンプ値を提供するべきです(すなわち、標準的でないビットで、セットしてください)、システム起動からのミリセカンドで表現される時間として。
Braden & Postel [Page 18]
ブレーデンとポステル[18ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
New gateways, especially those expecting to operate at T1 or
higher speeds, are expected to have at least millisecond
clocks.
新しいゲートウェイ(特にT1か、より高い速度で作動すると予想するもの)には少なくともミリセカンド時計があると予想されます。
2.2.8. Information Request/Reply
2.2.8. 情報要求/回答
The Information Request/Reply pair was intended to support
self-configuring systems such as diskless workstations, to
allow them to discover their IP network numbers at boot time.
However, the Reverse ARP (RARP) protocol [15] provides a better
mechanism for a host to use to discover its own IP address, and
RARP is recommended for this purpose. Information
Request/Reply need not be implemented in a gateway.
ブート時間におけるそれらのIPネットワーク・ナンバーを発見するために情報Request/回答組が、それらを許容するために自己にディスクレスワークステーションなどのシステムを構成するのを支持することを意図しました。 しかしながら、Reverseアルプ(RARP)プロトコル[15]はホストがそれ自身のIPアドレスを発見するのに使用するより良いメカニズムを提供します、そして、RARPはこのためにお勧めです。 情報Request/回答はゲートウェイで実行される必要はありません。
2.2.9. Echo Request/Reply
2.2.9. エコー要求/回答
A gateway must implement ICMP Echo, since it has proven to be
an extremely useful diagnostic tool. A gateway must be
prepared to receive, reassemble, and echo an ICMP Echo Request
datagram at least as large as the maximum of 576 and the MTU's
of all of the connected networks. See the discussion of IP
reassembly in gateways, Section 2.1.
非常に役に立つ診断用道具であると判明したので、ゲートウェイはICMP Echoを実行しなければなりません。 接続ネットワークについて576の最大とすべてのMTUがあるのと少なくとも同じくらい大きいICMP Echo Requestデータグラムを受けて、組み立て直して、反響するようにゲートウェイを準備しなければなりません。 IPの議論がゲートウェイ、セクション2.1で再アセンブリされるのを見てください。
The following rules resolve the question of the use of IP
source routes in Echo Request and Reply datagrams. Suppose a
gateway D receives an ICMP Echo Request addressed to itself
from host S.
以下の規則はEcho RequestとReplyデータグラムにおけるIP送信元経路の使用の問題を解決します。ゲートウェイDが受信されるなら、ICMP Echo Requestはホストからそれ自体にSを記述しました。
1. If the Echo Request contained no source route, D should
send an Echo Reply back to S using its normal routing
rules. As a result, the Echo Reply may take a different
path than the Request; however, in any case, the pair
will sample the complete round-trip path which any other
higher-level protocol (e.g., TCP) would use for its data
and ACK segments between S and D.
1. Echo Requestが送信元経路を全く含んでいないなら、Dは、正常なルーティング規則を使用することでEcho ReplyをSに送り返すでしょうに。 その結果、Echo ReplyはRequestと異なった経路を取るかもしれません。 しかしながら、どのような場合でも、組はいかなる他の上位レベル・プロトコル(例えば、TCP)もSとDの間のデータとACKセグメントに使用する完全な往復の経路を抽出するでしょう。
2. If the Echo Request did contain a source route, D should
send an Echo Reply back to S using as a source route the
return route built up in the source-routing option of
the Echo Request.
2. Echo Requestが送信元経路を含んでいるなら、Dは、送信元経路としてEcho Requestのソースルーティングオプションで確立された戻り経路を使用することでEcho ReplyをSに送り返すでしょうに。
Braden & Postel [Page 19]
ブレーデンとポステル[19ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
2.3. Exterior Gateway Protocol (EGP)
2.3. 外のゲートウェイプロトコル(EGP)
EGP is the protocol used to exchange reachability information
between Autonomous Systems of gateways, and is defined in
RFC-904 [11]. See also RFC-827 [51], RFC-888 [46], and
RFC-975 [27] for background information. The most widely used EGP
implementation is described in RFC-911 [13].
EGPはゲートウェイのAutonomous Systemsの間で可到達性情報を交換するのに使用されるプロトコルであり、RFC-904[11]で定義されます。 また、基礎的な情報に関してRFC-827[51]、RFC-888[46]、およびRFC-975[27]を見てください。 最も広く使用されたEGP実現はRFC-911[13]で説明されます。
When a dynamic routing algorithm is operated in the gateways of an
Autonomous System (AS), the routing data-base must be coupled to
the EGP implementation. This coupling should ensure that, when a
net is determined to be unreachable by the routing algorithm, the
net will not be declared reachable to other ASs via EGP. This
requirement is designed to minimize spurious traffic to "black
holes" and to ensure fair utilization of the resources on other
systems.
ダイナミックルーティングアルゴリズムがAutonomous System(AS)のゲートウェイで操作されるとき、EGP実現とルーティングデータベースを結合しなければなりません。 このカップリングは、ネットがルーティング・アルゴリズムで手が届かないことを決定しているとき、ネットがEGPを通して他のASsに届くと宣言されないのを確実にするはずです。 この要件は、「ブラックホール」への偽りの交通を最小にして、他のシステムにおけるリソースの公正な利用を確実にするように設計されています。
The present EGP specification defines a model with serious
limitations, most importantly a restriction against propagating
"third party" EGP information in order to prevent long-lived
routing loops [27]. This effectively limits EGP to a two-level
hierarchy; the top level is formed by the "core" AS, while the
lower level is composed of those ASs which are direct neighbor
gateways to the core AS. In practice, in the current Internet,
nearly all of the "core gateways" are connected to the ARPANET,
while the lower level is composed of those ASs which are directly
gatewayed to the ARPANET or MILNET.
現在のEGP仕様は重大な制限でモデルを定義して、最も重要に、長命のルーティングを防ぐために「第三者」EGP情報を伝播することに対する制限は[27]を輪にします。 事実上、これはEGPを2レベルの階層構造に制限します。 トップレベルは「コア」ASによって形成されます、下のレベルはコアASへのダイレクト隣人ゲートウェイであるそれらのASsで構成されますが。 習慣、現在のインターネットでは、ほとんど「コアゲートウェイ」のすべてがアルパネットに関連づけられます、下のレベルは直接アルパネットにgatewayedされるそれらのASsかMILNETで構成されますが。
RFC-975 [27] suggested one way to generalize EGP to lessen these
topology restrictions; it has not been adopted as an official
specification, although its ideas are finding their way into the
new EGP developments. There are efforts underway in the research
community to develop an EGP generalization which will remove these
restrictions.
RFC-975[27]はこれらのトポロジー制限を少なくするためにEGPを一般化する1つの方法を勧めました。 それは公式の仕様書として採用されません、考えが新しいEGP開発に届いていますが。 これらの制限を取り除くEGP一般化を開発するために、研究団体の進行中の努力があります。
In EGP, there is no standard interpretation (i.e., metric) for the
distance fields in the update messages, so distances are
comparable only among gateways of the same AS. In using EGP data,
a gateway should compare the distances among gateways of the same
AS and prefer a route to that gateway which has the smallest
distance value.
EGPでは、アップデートメッセージには距離分野にはどんな標準の解釈もないので(すなわち、メートル法の)、距離が同じASのゲートウェイだけの中で匹敵しています。 EGPデータを使用する際に、ゲートウェイは、同じASのゲートウェイの中で距離を比較して、最も小さい距離値を持っているそのゲートウェイよりルートを好むはずです。
The values to be announced in the distance fields for particular
networks within the local AS should be a gateway configuration
parameter; by suitable choice of these values, it will be possible
to arrange primary and backup paths from other AS's. There are
other EGP parameters, such as polling intervals, which also need
to be set in the gateway configuration.
遠くに発表されて、地方のASの中の特定のネットワークのための分野がゲートウェイ設定パラメータであるべきであるということである値。 これらの値の適当な選択で、他のASから予備選挙をアレンジして、経路のバックアップをとるのは可能でしょう。 ポーリングインタバルなどの他のEGPパラメタがあります。(また、ポーリングインタバルはゲートウェイ構成で設定される必要があります)。
Braden & Postel [Page 20]
ブレーデンとポステル[20ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
When routing updates become large they must be transmitted in
parts. One strategy is to use IP fragmentation, another is to
explicitly send the routing information in sections. The Internet
Engineering Task Force is currently preparing a recommendation on
this and other EGP engineering issues.
ルーティングアップデートが大きくなるとき、部品でそれらを伝えなければなりません。 別のものは、1つの戦略がIP断片化を使用することであり、明らかにセクションのルーティング情報を送ることになっています。 インターネット・エンジニアリング・タスク・フォースは、現在、これで推薦を準備して、他のEGP工学問題です。
2.4. Address Resolution Protocol (ARP)
2.4. アドレス解決プロトコル(アルプ)
ARP is an auxiliary protocol used to perform dynamic address
translation between LAN hardware addresses and Internet addresses,
and is described in RFC-826 [4].
ARPはLANハードウェア・アドレスの間の動的アドレス変換を実行するのに使用される補助のプロトコルとインターネット・アドレスであり、RFC-826[4]で説明されます。
ARP depends upon local network broadcast. In normal ARP usage,
the initiating host broadcasts an ARP Request carrying a target IP
address; the corresponding target host, recognizing its own IP
address, sends back an ARP Reply containing its own hardware
interface address.
ARPは地方のネットワーク放送によります。 正常なARP用法で、開始しているホストは目標IPアドレスを運ぶARP Requestを放送します。 それ自身のIPアドレスを認識して、対応する目標ホストはそれ自身のハードウェアインターフェース・アドレスを含むARP Replyを返送します。
A variation on this procedure, called "proxy ARP", has been used
by gateways attached to broadcast LANs [14]. The gateway sends an
ARP Reply specifying its interface address in response to an ARP
Request for a target IP address which is not on the
directly-connected network but for which the gateway offers an
appropriate route. By observing ARP and proxy ARP traffic, a
gateway may accumulate a routing data-base [14].
「プロキシARP」と呼ばれるこの手順の変化は添付のゲートウェイによって使用されて、LAN[14]を放送しました。 ゲートウェイで、ARP Replyは直接接続されたネットワークにありませんが、ゲートウェイが適切なルートを提供する目標IPアドレスのためのARP Requestに対応してインターフェース・アドレスを指定します。 ARPとプロキシARP交通を観測することによって、ゲートウェイはルーティングデータベース[14]を蓄積するかもしれません。
Proxy ARP (also known in some quarters as "promiscuous ARP" or
"the ARP hack") is useful for routing datagrams from hosts which
do not implement the standard Internet routing rules fully -- for
example, host implementations which predate the introduction of
subnetting. Proxy ARP for subnetting is discussed in detail in
RFC-925 [14].
プロキシARP(また、場所によっては「無差別なARP」か「ARPハッキング」として、知られている)はホストからの完全に標準のインターネット・ルーティング規則を実行するというわけではないルーティングデータグラムの役に立ちます--例えば、サブネッティングの導入より前に起こる実現を主催してください。 RFC-925[14]で詳細にサブネッティングのためのプロキシARPについて議論します。
Reverse ARP (RARP) allows a host to map an Ethernet interface
address into an IP address [15]. RARP is intended to allow a
self-configuring host to learn its own IP address from a server at
boot time.
逆のアルプ(RARP)で、ホストはIPアドレス[15]にイーサネットインターフェース・アドレスを写像できます。 RARPが、自己を構成するホストがサーバからブート時間でそれ自身のIPアドレスを学ぶのを許容することを意図します。
2.5. Constituent Network Access Protocols
2.5. 構成しているネットワークアクセス・プロトコル
See Section 3.
セクション3を見てください。
Braden & Postel [Page 21]
ブレーデンとポステル[21ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
2.6. Interior Gateway Protocols
2.6. 内部のゲートウェイプロトコル
Distributed routing algorithms continue to be the subject of
research and engineering, and it is likely that advances will be
made over the next several years. A good algorithm needs to
respond rapidly to real changes in Internet connectivity, yet be
stable and insensitive to transients. It needs to synchronize the
distributed data-base across gateways of its Autonomous System
rapidly (to avoid routing loops), while consuming only a small
fraction of the available bandwidth.
研究テーマと分配されたルーティング・アルゴリズムはずっと工学です、そして、次の数年間進歩をしそうでしょう。 良いアルゴリズムは、過渡現象に急速にインターネットの接続性における本当の変化に応じますが、安定していて神経が鈍い必要があります。 それは、利用可能な帯域幅のわずかな部分だけを消費する間、Autonomous Systemのゲートウェイの向こう側に分散データベースを急速(輪を発送するのを避ける)に同期させる必要があります。
Distributed routing algorithms are commonly broken down into the
following three components:
分配されたルーティング・アルゴリズムは一般的に以下の3つのコンポーネントへ砕けています:
A. An algorithm to assign a "length" to each Internet path.
A. 「長さ」を各インターネット経路に割り当てるアルゴリズム。
The "length" may be a simple count of hops (1, or infinity
if the path is broken), or an administratively-assigned
cost, or some dynamically-measured cost (usually an average
delay).
「長さ」がホップの簡単なカウントであるかもしれない、(1、無限が経路であるなら壊れている、)、行政上割り当てられた費用、または何らかのダイナミックに測定された費用(通常平均した遅れ)
In order to determine a path length, each gateway must at
least test whether each of its neighbors is reachable; for
this purpose, there must be a "reachability" or "neighbor
up/down" protocol.
経路の長さを測定するために、その各人隣人が届いているか否かに関係なく、各ゲートウェイは少なくともテストされなければなりません。 このために、「可到達性」か「隣人は/にダウンする」プロトコルがあるに違いありません。
B. An algorithm to compute the shortest path(s) to a given
destination.
B. 与えられた目的地に最短パスを計算するアルゴリズム。
C. A gateway-gateway protocol used to exchange path length and
routing information among gateways.
C. ゲートウェイゲートウェイプロトコルは以前はゲートウェイの中でよく経路の長さとルーティング情報を交換していました。
The most commonly-used IGPs in Internet gateways are as follows.
インターネット・ゲートウェイの最も多くの一般的に使用されたIGPsは以下の通りです。
2.6.1. Gateway-to-Gateway Protocol (GGP)
2.6.1. ゲートウェー間プロトコル(GGP)
GGP was designed and implemented by BBN for the first
experimental Internet gateways [41]. It is still in use in the
BBN LSI/11 gateways, but is regarded as having serious
drawbacks [58]. GGP is based upon an algorithm used in the
early ARPANET IMPs and later replaced by SPF (see below).
GGPはBBNによって最初の実験的なインターネット・ゲートウェイ[41]に設計されて、実行されました。 それは、BBN LSI/11門でまだ使用中ですが、重大な欠点[58]を持っていると見なされます。 GGPは前のアルパネットIMPsで使用されて、後でSPFに取り替えられたアルゴリズムに基づいています(以下を見てください)。
GGP is a "min-hop" algorithm, i.e., its length measure is
simply the number of network hops between gateway pairs. It
implements a distributed shortest-path algorithm, which
requires global convergence of the routing tables after a
change in topology or connectivity. Each gateway sends a GGP
GGPが「分ホップ」アルゴリズムである、すなわち、長さの測定は単にゲートウェイ組の間のネットワークホップの数です。 それは分配された最短パスアルゴリズムを実行します。(それは、トポロジーか接続性における変化の後に経路指定テーブルのグローバルな集合を必要とします)。 各ゲートウェイはGGPを送ります。
Braden & Postel [Page 22]
ブレーデンとポステル[22ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
routing update only to its neighbors, but each update includes
an entry for every known network, where each entry contains the
hop count from the gateway sending the update.
隣人だけへのルーティングアップデート、各アップデートだけがあらゆる知られているネットワークのためのエントリーを含んでいます。(そこでは、各エントリーがアップデートを送るゲートウェイからのホップカウントを含みます)。
2.6.2. Shortest-Path-First (SPF) Protocols
2.6.2. 最も短い経路最初(SPF)のプロトコル
SPF [40] is the name for a class of routing algorithms based on
a shortest-path algorithm of Dijkstra. The current ARPANET
routing algorithm is SPF, and the BBN Butterfly gateways also
use SPF. Its characteristics are considered superior to
GGP [58].
SPF[40]はダイクストラの最短パスアルゴリズムに基づくルーティング・アルゴリズムのクラスのための名前です。 現在のアルパネットルーティング・アルゴリズムはSPFです、そして、また、BBN ButterflyゲートウェイはSPFを使用します。 特性はGGP[58]より優れていると考えられます。
Under SPF, the routing data-base is replicated rather than
distributed. Each gateway will have its own copy of the same
data-base, containing the entire Internet topology and the
lengths of every path. Since each gateway has all the routing
data and runs a shortest-path algorithm locally, there is no
problem of global convergence of a distributed algorithm, as in
GGP. To build this replicated data-base, a gateway sends SPF
routing updates to ALL other gateways; these updates only list
the distances to each of the gateway's neighbors, making them
much smaller than GGP updates. The algorithm used to
distribute SPF routing updates involves reliable flooding.
SPFの下では、ルーティングデータベースは分配されるよりむしろ模写されます。 各ゲートウェイには、それ自身の同じデータベースのコピーがあるでしょう、全体のインターネットトポロジーとあらゆる経路の長さを含んでいて。 各ゲートウェイがすべてのルーティングデータを持って、最短パスアルゴリズムを局所的に走らせるので、分配されたアルゴリズムのグローバルな集合の問題が全くありません、GGPのように。 この模写されたデータベースを造るために、ゲートウェイは他のすべてのゲートウェイへのルーティングアップデートをSPFに送ります。 彼らをGGPアップデートよりはるかに小さくして、これらのアップデートはゲートウェイの隣人各人に距離を記載するだけです。 SPFルーティングアップデートを広げるのに使用されるアルゴリズムは信頼できる氾濫を伴います。
2.6.3. Routing Information (RIP)
2.6.3. 経路情報(リップ)
RIP is the name often used for a class of routing protocols
based upon the Xerox PUP and XNS routing protocols. These are
relatively simple, and are widely available because they are
incorporated in the embedded gateway code of Berkeley BSD
systems. Because of this simplicity, RIP protocols have come
the closest of any to being an "Open IGP", i.e., a protocol
which can be used between different vendors' gateways.
Unfortunately, there is no standard, and in fact not even a
good document, for RIP.
RIPはゼロックスPUPとXNSルーティング・プロトコルに基づくルーティング・プロトコルのクラスにしばしば使用される名前です。 これらは、比較的簡単であり、それらがバークレーBSDシステムの埋め込まれたゲートウェイコードで組み込んでいるので、広く利用可能です。この簡単さのために、RIPプロトコルは「開いているIGP」に最も近くにいずれも来させました、すなわち、異なった業者のゲートウェイの間で使用できるプロトコル。 残念ながら、いいえ標準であって、事実上、同等でない状態で、良いドキュメントがRIPのためにあります。
As in GGP, gateways using RIP periodically broadcast their
routing data-base to their neighbor gateways, and use a
hop-count as the metric.
GGPのように、定期的にRIPを使用するゲートウェイが、それらのルーティングデータベースをそれらの隣人ゲートウェイに放送して、メートル法としてホップカウントを使用します。
A fixed value of the hop-count (normally 16) is defined to be
"infinity", i.e., network unreachable. A RIP implementation
must include measures to avoid both the slow-convergence
phenomen called "counting to infinity" and the formation of
routing loops. One such measure is a "hold-down" rule. This
rule establishes a period of time (typically 60 seconds) during
which a gateway will ignore new routing information about a
given network, once the gateway has learned that network is
ホップカウント(通常16)の一定の価値は、「無限」で、すなわち、ネットワーク手が届かなくなるように定義されます。 RIP実現は「無限勘定」であると呼ばれる遅い集合phenomenとルーティング輪の構成の両方を避ける測定を含まなければなりません。 そのような測定の1つは「抑制」定規です。 この規則はゲートウェイが与えられたネットワークの新しいルーティング情報を無視する期間(通常60秒)を設置します、ゲートウェイが、ネットワークがそうであることをいったん学ぶと
Braden & Postel [Page 23]
ブレーデンとポステル[23ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
unreachable (has hop-count "infinity"). The hold-down period
must be settable in the gateway configuration; if gateways with
different hold-down periods are using RIP in the same
Autonomous System, routing loops are a distinct possibility.
In general, the hold-down period is chosen large enough to
allow time for unreachable status to propagate to all gateways
in the AS.
手が届きません(ホップカウント「無限」を持っています)。 抑制の期間はゲートウェイ構成で「舗装用敷石-可能」であるに違いありません。 異なった抑制の期間があるゲートウェイが同じAutonomous SystemでRIPを使用しているなら、ルーティング輪は異なった可能性です。 一般に、抑制の期間は手の届かない状態がASのすべてのゲートウェイに伝播される時間を許容できるくらい大きい状態で選ばれています。
2.6.4. Hello
2.6.4. こんにちは
The "Fuzzball" software for an LSI/11 developed by Dave Mills
incorporated an IGP called the "Hello" protocol [39]. This IGP
is mentioned here because the Fuzzballs have been widely used
in Internet experimentation, and because they have served as a
testbed for many new routing ideas.
LSI/11がデーヴ・ミルズで展開したので、"Fuzzball"ソフトウェアは「こんにちは」というプロトコル[39]と呼ばれるIGPを組み込みました。 Fuzzballsがインターネット実験に広く使用されて、彼らが多くの新しいルーティングアイデアのためのテストベッドとして機能したので、このIGPはここに言及されます。
2.7. Monitoring Protocols
2.7. モニターしているプロトコル
See Section 5 of this document.
このドキュメントのセクション5を見てください。
2.8. Internet Group Management Protocol (IGMP)
2.8. インターネットグループ管理プロトコル(IGMP)
An extension to the IP protocol has been defined to provide
Internet-wide multicasting, i.e., delivery of copies of the same
IP datagram to a set of Internet hosts [47, 48]. This delivery is
to be performed by processes known as "multicasting agents", which
reside either in a host on each net or (preferably) in the
gateways.
IPプロトコルへの拡大は、インターネット全体のマルチキャスティング(すなわち、1セットのインターネット・ホスト[47、48]への同じIPデータグラムのコピーの配送)を提供するために定義されました。 この配送は各ネットのホストか(望ましくは、)ゲートウェイに住んでいる「マルチキャスティングエージェント」として知られている工程で実行されることです。
The set of hosts to which a datagram is delivered is called a
"host group", and there is a host-agent protocol called IGMP,
which a host uses to join, leave, or create a group. Each host
group is distinguished by a Class D IP address.
データグラムが届けられるホストのセットは「ホストグループ」と呼ばれます、そして、ホストが接合するか、いなくなるか、またはグループを創設するのに使用するIGMPと呼ばれるホスト兼エージェントプロトコルがあります。 それぞれのホストグループはClass D IPアドレスによって区別されます。
This multicasting mechanism and its IGMP protocol are currently
experimental; implementation in vendor gateways would be premature
at this time. A datagram containing a Class D IP address must be
dropped, with no ICMP error message.
このマルチキャスティングメカニズムとそのIGMPプロトコルは現在、実験しています。 業者ゲートウェイでの実現はこのとき、時期尚早でしょう。 ICMPエラーメッセージなしでClass D IPアドレスを含むデータグラムを落とさなければなりません。
Braden & Postel [Page 24]
ブレーデンとポステル[24ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
3. Constituent Network Interface
3. 構成しているネットワーク・インターフェース
This section discusses the rules used for transmission of IP datagrams on the most common types of constituent networks. A gateway must be able to send and receive IP datagrams of any size up to the MTU of any constituent network to which it is connected.
このセクションは最も一般的なタイプの構成しているネットワークにおけるIPデータグラムのトランスミッションに使用される規則について論じます。 ゲートウェイは、どんなサイズのIPデータグラムも送って、それが関連しているどんな構成しているネットワークのMTUまでも受け取ることができなければなりません。
3.1. Public data networks via X.25
3.1. X.25を通した公衆データネットワーク
The formats specified for public data networks accessed via X.25
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. Link-level
retransmission, resequencing and flow control are performed by the
network for each virtual circuit and by the LAPB link-level
protocol. Note that a single X.25 virtual circuit may be used to
multiplex all IP traffic between a pair of hosts. However,
multiple parallel virtual circuits may be used in order to improve
the utilization of the subscriber access line, in spite of small
X.25 window sizes; this can result in random resequencing.
X.25を通してアクセスされた公衆データネットワークに指定された形式はRFC-877[8]で説明されます。 データグラムは完全なパケット系列としてレベル-3個の標準の仮想の回路の上に送られます。 仮想の回路はトラフィックがない通常、必要に応じてダイナミックに設立されていて、タイムアウトaの後期間です。 リンク・レベル「再-トランスミッション」、再配列、およびフロー制御はそれぞれの仮想の回路へのネットワークとLAPBリンク・レベルプロトコルによって実行されます。 ただ一つのX.25仮想の回路が1組のホストの間にすべてのIPトラフィックを多重送信するのに使用されるかもしれないことに注意してください。 しかしながら、複数の平行な仮想の回路が加入者アクセス回線の利用を改良するのに使用されるかもしれません、小さいX.25ウィンドウサイズにもかかわらず。 これは無作為の再配列をもたらすことができます。
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 the future. The
table of the hosts on the Public Data Network is in the Assigned
Numbers [23].
通常、インターネットとX.121アドレスとの通信は索表によって確立されます。 これが将来ある種のディレクトリ手順に取り替えられると予想されます。 Assigned民数記[23]にはPublic Data Networkの上のホストのテーブルがあります。
The normal MTU is 576; however, the two DTE's (hosts or gateways)
can use X.25 packet size negotiation to increase this value [8].
正常なMTUは576歳です。 しかしながら、2DTEのもの(ホストかゲートウェイ)は、この値[8]を増強するのにX.25パケットサイズ交渉を使用できます。
3.2. ARPANET via 1822 LH, DH, or HDH
3.2. 1822LH、DH、またはHDHを通したアルパネット
The formats specified for ARPANET networks using 1822 access are
described in BBN Report 1822 [3], which includes the procedures
for several subscriber access methods. The Distant Host (DH)
method is used when the host and IMP (the Defense Communication
Agency calls it a Packet Switch Node or PSN) are separated by not
more than about 2000 feet of cable, while the HDLC Distant Host
(HDH) is used for greater distances where a modem is required.
Under HDH, retransmission, resequencing and flow control are
performed by the network and by the HDLC link-level protocol.
1822年のアクセスを使用することでアルパネットネットワークに指定された形式はBBN Report1822[3]で説明されます。([3]はいくつかの加入者アクセス法のための手順を含んでいます)。 ホストとIMP(防衛通信委員会は、それをPacket Switch NodeかPSNと呼ぶ)がおよそ2000フィート以下切り離されるとき、Distant Host(DH)メソッドはケーブルで使用されています、HDLC Distant Host(HDH)はモデムが必要であるより長い距離に使用されますが。 HDHの下では、「再-トランスミッション」、再配列、およびフロー制御はネットワークとHDLCリンク・レベルプロトコルによって実行されます。
The IP encapsulation format is simply to include the IP datagram
as the data portion of an 1822 message. In addition, the
high-order 8 bits of the Message Id field (also known as the
"link" field") should be set to 155 [23]. The MTU is 1007 octets.
IPカプセル化形式は1822年のメッセージのデータ部として単にIPデータグラムを含むことです。 「さらに、Message Idの高位8ビットがさばく、(また、「リンク」分野として知られている、」、)、155[23]に設定されるべきです。 MTUは1007の八重奏です。
Braden & Postel [Page 25]
ブレーデンとポステル[25ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
While the ARPANET 1822 protocols are widely used at present, they
are expected to be eventually overtaken by the DDN Standard X.25
protocol (see Section 3.3). The original IP address mapping
(RFC-796 [38]) is in the process of being replaced by a new
interface specification called AHIP-E; see RFC-1005 [61] for the
proposal.
1822年のアルパネットプロトコルは現在のところ広く使用されますが、結局DDN Standard X.25プロトコルによって追いつかれると予想されます(セクション3.3を見てください)。 オリジナルのIPはマッピングを扱います。(AHIP-Eと呼ばれる新しいインターフェース仕様に取り替えることの途中にRFC-796[38])があります。 提案に関してRFC-1005[61]を見てください。
Gateways connected to ARPANET or MILNET IMPs using 1822 access
must incorporate features to avoid host-port blocking (i.e., RFNM
counting) and to detect and report as ICMP Unreachable messages
the failure of destination hosts or gateways (i.e., convert the
1822 error messages to the appropriate ICMP messages).
1822年のアクセスを使用することでアルパネットかMILNET IMPsに接続されたゲートウェイはICMP Unreachableメッセージとしてあて先ホストかゲートウェイの失敗をホストポートブロッキングを避けて(すなわち、RFNMが数えて)、検出して、報告する特徴を取り入れなければなりません(すなわち、1822年のエラーメッセージを適切なICMPメッセージに変換してください)。
In the development of a network interface it will be useful to
review the IMP end-to-end protocol described in RFC-979 [29].
ネットワーク・インターフェースの開発では、IMP終わりから終わりへのRFC-979[29]で説明されたプロトコルを見直すのは役に立ちます。
3.3. ARPANET via DDN Standard X.25
3.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],
which describes two sets of procedures: the DDN Basic X.25, and
the DDN Standard X.25. Only DDN Standard X.25 provides the
functionality required for interoperability assumptions of the
Internet protocol.
X.25を通してアルパネットネットワークに指定された形式はDefense Data Network X.25 Host Interface Specification[6]で説明されます:(Defense Data Network X.25 Host Interface Specificationは2セットの手順について説明します)。 DDNの基本的なX.25、およびDDNの標準のX.25。 DDN Standard X.25だけがインターネットプロトコルの相互運用性仮定に必要である機能性を提供します。
The DDN Standard X.25 procedures are similar to the public data
network 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. Multiple parallel
virtual circuits may be used in order to improve the utilization
of the subscriber access line; this can result in random
resequencing.
アドレス・マッピングを除いて、DDN Standard X.25手順は公衆データネットワークX.25手順と同様です。 Retransmission、再配列、およびフロー制御はネットワークとLAPBリンク・レベルプロトコルによって実行されます。 複数の平行な仮想の回路が加入者アクセス回線の利用を改良するのに使用されるかもしれません。 これは無作為の再配列をもたらすことができます。
Gateways connected to ARPANET or MILNET using Standard X.25 access
must detect and report as ICMP Unreachable messages the failure of
destination hosts or gateways (i.e., convert the X.25 diagnostic
codes to the appropriate ICMP messages).
アルパネットに接続されたゲートウェイかStandard X.25アクセスを使用するMILNETがICMP Unreachableメッセージとしてあて先ホストかゲートウェイの失敗を検出して、報告しなければなりません(すなわち、X.25の診断コードを適切なICMPメッセージに変換してください)。
To achieve compatibility with 1822 interfaces, the effective MTU
for a Standard X.25 interface is 1007 octets.
1822のインタフェースとの互換性を獲得するために、Standard X.25インタフェースへの有効なMTUは1007の八重奏です。
Braden & Postel [Page 26]
ブレーデンとポステル[26ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
3.4. Ethernet and IEEE 802
3.4. イーサネットとIEEE802
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 (the type field values are listed in the Assigned
Numbers [23]). 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 link-level retransmission, resequencing or flow control,
although most hardware interfaces will retransmit automatically in
case of collisions on the cable.
イーサネットネットワークに指定された形式はRFC-894[10]で説明されます。 データグラムはイーサネットパケットとして48ビットのソース、目的地アドレス・フィールド、および16ビットのタイプ分野でカプセル化されます。(タイプ分野値はAssigned民数記[23])で記載されています。 イーサネット・アドレスとインターネット・アドレスの間のアドレス変換はAddress Resolutionプロトコルによって管理されます。(それが、すべてのイーサネット実装で必要です)。 どんな明白なリンク・レベル「再-トランスミッション」、再配列もまたはフロー制御もありません、ほとんどのハードウェア・インタフェースがケーブルにおける衝突の場合に自動的に再送されるでしょうが。
The IEEE 802 networks use a Link Service Access Point (LSAP) field
in much the same way the ARPANET uses the "link" field. Further,
there is an extension of the LSAP header called the Sub-Network
Access Protocol (SNAP).
IEEE802ネットワークはアルパネットが「リンク」分野を使用する似たり寄ったりの方法でLink Service Access Point(LSAP)分野を使用します。 さらに、Sub-ネットワークAccessプロトコル(SNAP)と呼ばれるLSAPヘッダーの拡大があります。
The 802.2 encapsulation is used on 802.3, 802.4, and 802.5 network
by using the SNAP with an organization code indicating that the
following 16 bits specify the Ether-Type code [23].
802.2カプセル化は、802.3、802.4、および802.5ネットワークで以下の16ビットがEther-タイプコード[23]を指定するのを示す組織コードでSNAPを使用することによって、使用されます。
Headers:
ヘッダー:
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
...--------+--------+--------+ MACヘッダー| 長さ| 802. 3/4/5、Mac…--------+--------+--------+
+--------+--------+--------+
| DSAP=K1| SSAP=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+--------+ | DSAP=K1| SSAP=K1| コントロール| 802.2 SAP+--------+--------+--------+
+--------+--------+--------+--------+--------+
|protocol id or org code=K2| Ether-Type | 802.2 SNAP
+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+ |プロトコルイドかorgコードがケーツーと等しいです。| エーテル型| 802.2 スナップ+--------+--------+--------+--------+--------+
The total length of the SAP Header and the SNAP header is
8-octets, making the 802.2 protocol overhead come out on a 64-bit
boundary.
SAP HeaderとSNAPヘッダーの全長は8八重奏です、802.2プロトコルオーバーヘッドを64ビットの境界で出て来させて。
K1 is 170. The IEEE likes to talk about things in bit
transmission order and specifies this value as 01010101. In
big-endian order, as used in the Internet specifications, this
becomes 10101010 binary, or AA hex, or 170 decimal. K2 is 0
(zero).
K1は170歳です。 IEEEはビット伝送命令でものに関して話すのが好きであり、01010101としてこの値を指定します。 ビッグエンディアンオーダーでは、インターネット仕様で使用されるように、これは10101010の2進の小数、AA十六進法、または170小数になります。 ケーツーは0(ゼロ)です。
The use of the IP LSAP (K1 = 6) is reserved for future
development.
IP LSAP(K1=6)の使用は今後の開発のために控えられます。
Braden & Postel [Page 27]
ブレーデンとポステル[27ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
The assigned values for the Ether-Type field are the same for
either this IEEE 802 encapsulation or the basic Ethernet
encapsulation [10].
このIEEE802カプセル化か基本的なイーサネットカプセル化[10]のどちらかに、Ether-タイプ分野への割り当てられた値は同じです。
In either Ethernets or IEEE 802 nets, the IP datagram is the data
portion of the packet immediately following the Ether-Type.
EthernetsかIEEE802ネットのどちらかでは、IPデータグラムはすぐにEther-タイプに従うパケットのデータ部です。
The MTU for an Ethernet or its IEEE-standard equivalent (802.3) is
1500 octets.
イーサネットのためのMTUかそのIEEE標準の同等物(802.3)が1500の八重奏です。
3.5. Serial-Line Protocols
3.5. シリアル・ラインプロトコル
In some configurations, gateways may be interconnected with each
other 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 single Internet standard for this
protocol, it is suggested that one of the following protocols be
used.
いくつかの構成では、連続の非同期であるか同期の系列によってゲートウェイは互いと共にインタコネクトされるかもしれません、モデムのあるなしにかかわらず。期待誤差率と他の要素によって正当化されると、リンク・レベルプロトコルがシリアル・ラインの上で必要であるかもしれません。 このプロトコルのどんなただ一つのインターネット標準もない間、以下のプロトコルの1つが使用されることが提案されます。
* X.25 LAPB (Synchronous Lines)
* X.25 LAPB(同期線)
This is the link-level protocol used for X.25 network
access. It includes HDLC "bit-stuffing" as well as
rotating-window flow control and reliable delivery.
これはX.25ネットワークアクセサリーに使用されるリンク・レベルプロトコルです。 それは回転する窓のフロー制御と同様にHDLC「ビット・スタッフィング」と信頼できる配信を含んでいます。
A gateway must be configurable to play the role of either
the DCE or the DTE.
ゲートウェイはDCEかDTEのどちらかの役割を果たすのにおいて構成可能であるに違いありません。
* HDLC Framing (Synchronous Lines)
* HDLC縁どり(同期線)
This is just the bit-stuffing and framing rules of LAPB. It
is the simplest choice, although it provides no flow control
or reliable delivery; however, it does provide error
detection.
これは、まさしくビット・スタッフィングとLAPBの規則を縁どることです。 どんなフロー制御も信頼できる配信も提供しませんが、それは最も簡単な選択です。 しかしながら、それは誤り検出を提供します。
* Xerox Synchronous Point-to-Point (Synchronous Lines)
* ゼロックスの同期ポイントツーポイント(同期線)
This Xerox protocol is an elaboration upon HDLC framing that
includes negotiation of maximum packet sizes, dial-up or
dedicated circuits, and half- or full-duplex operation [12].
このゼロックスプロトコルは、最大のパケットサイズ、ダイヤルアップまたは専用回線の交渉を含んでいるHDLC縁どりでの労作と、半分か全二重操作[12]です。
* Serial Line Framing Protocol (Asynchronous Lines)
* シリアル・ライン縁どりプロトコル(非同期な線)
This protocol is included in the MIT PC/IP package for an
IBM PC and is defined in Appendix I to the manual for that
system [20].
このプロトコルは、IBM PCのためにMIT PC/IPパッケージで含められていて、そのシステム[20]のためにAppendix Iでマニュアルと定義されます。
Braden & Postel [Page 28]
ブレーデンとポステル[28ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
It will be important to make efficient use of the bandwidth
available on a serial line between gateways. For example, it is
desirable to provide some form of data compression. One possible
standard compression algorithm, "Thinwire II", is described in
RFC-914 [42]. This and similar algorithms are tuned to the
particular types of redundancy which occur in IP and TCP headers;
however, more work is necessary to define a standard serial-line
compression protocol for Internet gateways. Until a standard has
been adopted, each vendor is free to choose a compression
algorithm; of course, the result will only be useful on a serial
line between two gateways using the same compression algorithm.
ゲートウェイの間でシリアル・ラインの上で帯域幅の効率的な使用を利用可能にするのは重要でしょう。 例えば、何らかのフォームのデータ圧縮を提供するのは望ましいです。 「Thinwire II」という1つの可能な標準の圧縮アルゴリズムがRFC-914[42]で説明されます。 これと同様のアルゴリズムは冗長のどれがIPで起こるか、そして、TCPの特定のタイプに調整されたヘッダーです。 しかしながら、より多くの仕事が、標準のシリアル・ライン圧縮プロトコルをインターネット・ゲートウェイと定義するのに必要です。 規格が採用されるまで、各ベンダーは自由に圧縮アルゴリズムを選ぶことができます。 もちろん、結果は、単に2門の間のシリアル・ラインで同じ圧縮アルゴリズムを使用することで役に立ちます。
Another way to ensure maximum use of the bandwidth is to avoid
unnecessary retransmissions at the link level. For some kinds of
IP traffic, low delay is more important than reliable delivery.
The serial line driver could distinguish such datagrams by their
IP TOS field, and place them on a special high-priority,
no-retransmission queue.
帯域幅の最大の使用を確実にする別の方法はリンク・レベルで不要な「再-トランスミッション」を避けることです。 数種類のIPトラフィックにおいて、低い遅れは信頼できる配信より重要です。 シリアル・ラインドライバーは、それらのIP TOS分野でそのようなデータグラムを区別して、特別な高い優先度(再送キューがない)に彼らを置くことができました。
A serial point-to-point line between two gateways may be
considered to be a (particularly simple) network, a "null net".
Considered in this way, a serial line requires no special
considerations in the routing algorithms of the connected
gateways, but does need an IP network number. To avoid the
wholesale consumption of Internet routing data-base space by null
nets, we strongly recommend that subnetting be used for null net
numbering, whenever possible.
2門の間の連続の二地点間系列は(特に簡単)のネットワーク、「ヌルネット」であると考えられるかもしれません。 このように考えられて、シリアル・ラインは、接続ゲートウェイのルーティング・アルゴリズムでどんな特別な問題も必要としませんが、IPネットワーク・ナンバーを必要とします。 ヌルネットでインターネット・ルーティングデータベースのスペースの大量の消費を避けるために、私たちは、サブネッティングがヌルネットの付番に使用されることを強く勧めます、可能であるときはいつも。
For example, assume that network 128.203 is to be constructed
of gateways joined by null nets; these nets are given (sub-)net
numbers 128.203.1, 128.203.2, etc., and the two interfaces on
each end of null net 128.203.s might have IP addresses
128.203.s.1 and 128.203.s.2.
例えば、ネットワーク128.203がヌルネットによって接合されたゲートウェイについて建設されることになっていると仮定してください。 これらのネットを与える、(サブ、)、ネットの数、128.203、.1、128.203 .2、など、およびヌルネットの128.203.sの各端の2つのインタフェースには、IPアドレスの128.203.s.1と128.203.s.2があるかもしれません。
An alternative model of a serial line is that it is not a network,
but rather an internal communication path joining two "half
gateways". It is possible to design an IGP and routing algorithm
that treats a serial line in this manner [39, 52].
シリアル・ラインの代替のモデルはそれがネットワークではなく、むしろ2「半分ゲートウェイ」を接合する内部の通信路であるということです。 IGPとルーティング・アルゴリズムを設計するために、それがこの様に[39、52]シリアル・ラインを扱うのは、可能です。
Braden & Postel [Page 29]
ブレーデンとポステル[29ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
4. Gateway Algorithms
4. ゲートウェイアルゴリズム
Gateways are general packet-switches that forward packets according to the IP address, i.e., they are IP routers. While it is beyond the scope of this document to specify the details of the mechanisms used in any particular, perhaps proprietary, gateway architecture, there are a number of basic algorithms which must be provided by any acceptable design.
ゲートウェイがIPに従った前進のパケットが扱う一般的なパケット交換機である、すなわち、それらはIPルータです。 どんな特定の、そして、恐らく独占であるゲートウェイアーキテクチャにも使用されるメカニズムの細部を指定するためにこのドキュメントの範囲を超えていますが、多くのどんな許容できるデザインでも提供しなければならない基本的なアルゴリズムがあります。
4.1. Routing Algorithm
4.1. ルーティング・アルゴリズム
The routing mechanism is fundamental to Internet operation. In
all but trivial network topologies, robust Internet service
requires some degree of routing dynamics, whether it be effected
by manual or automatic means or by some combination of both. In
particular, if routing changes are made manually, it must be
possible to make these routing changes from a remote Network
Operation Center (NOC) without taking down the gateway for
reconfiguration. If static routes are used, there must be
automatic fallback or rerouting features.
ルーティングメカニズムはインターネット操作に基本的です。 ほとんど些細なネットワークtopologiesでは、それが作用しているか否かに関係なく、強健なインターネットのサービスは手動の、または、自動である手段か両方の何らかの組み合わせでいくらかのルーティング力学を必要とします。 ルーティング変更が手動で行われるなら、遠く離れたNetwork Operationセンター(NOC)から再構成のためにゲートウェイを降ろさないでこれらのルーティング変更を行うのは特に、可能でなければなりません。 スタティックルートが使用されているなら、自動後退かコースを変更することの特徴があるに違いありません。
Handling unpredictable changes in Internet connectivity must be
considered the normal case, so that systems of gateways will
normally be expected to have a routing algorithm with the
capability of reacting to link and other gateway failures and
changing the routing automatically.
正常なケースであるとインターネットの接続性における予測できない変化を扱うのを考えなければなりません、通常、ゲートウェイのシステムには反応がリンクされる能力と、他のゲートウェイの故障と自動的にルーティングを変えるルーティング・アルゴリズムがあると予想されるように。
This document places no restriction on the type of routing
algorithm, e.g., node-based, link-based or any other algorithm, or
on the routing distance metric, e.g., delay or hop-count.
However, the following features are considered necessary for a
successful gateway routing algorithm:
このドキュメントはルーティング・アルゴリズムのタイプ、例えば、ベースの、または、リンクベースの、または、いかなる他のアルゴリズムの、または、ルーティング距離のメートル法の例えば、遅れの、または、ホップで数えているノードに関して制限を全く課しません。 しかしながら、以下の特徴はうまくいっているゲートウェイルーティング・アルゴリズムに必要であると考えられます:
1. The algorithm must sense the failure or restoration of a
link or other gateway and switch to appropriate paths. A
design objective is to switch paths within an interval less
than the typical TCP user time-out (one minute is a safe
assumption).
1. アルゴリズムは、経路を当てるためにリンクか他のゲートウェイとスイッチの失敗か修復を感じなければなりません。 設計目標は間隔以内に典型的なTCPユーザタイムアウトほど経路を切り換えない(1分は安全な仮定です)ことです。
2. The algorithm must suppress routing loops between neighbor
gateways and must contain provisions to avoid or suppress
routing loops that may form between non-neighbor gateways.
A design objective is for no loop to persist for longer
than an interval greater than the typical TCP user
time-out.
2. アルゴリズムは、非隣人ゲートウェイの間で形成されるかもしれない輪を発送しながら、隣人ゲートウェイの間のルーティング輪を抑圧しなければならなくて、避けるか、または抑圧する条項を含まなければなりません。 設計目標は輪が全く典型的なTCPユーザタイムアウトより大きい間隔より長い間持続しないことです。
3. The control traffic necessary to operate the routing
algorithm must not significantly degrade or disrupt normal
3. ルーティング・アルゴリズムを操作するのに必要なコントロールトラフィックは、標準をかなり下げてはいけませんし、また混乱させてはいけません。
Braden & Postel [Page 30]
ブレーデンとポステル[30ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
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.
操作をネットワークでつないでください。 しばらく局部で通常の操作を中断するかもしれない状態の変化はネットワークの遠隔地で分裂を引き起こしてはいけません。
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 incremental changes
broadcast over a wide-area.
4. ネットワークのサイズが増加するのに従って、効率的な方法でリソースにおける要求を制御しなければなりません。 索表は少しずつ扱われた例えば、論じ尽くされるのとデータベースアップデート、漸進的変化放送だけが終わっている広い領域であるべきです。
5. The size of the routing data-base must not be allowed to
exceed a constant, independent of network topology, times
the number of nodes times the mean connectivity (average
number of incident links). An advanced design might not
require that the entire routing data-base be kept in any
particular gateway, so that discovery and caching
techniques would be necessary.
5. ルーティングデータベースのサイズに定数を超えさせてはいけなくて、ネットワーク形態、回の如何にかかわらずノード時間の数は卑劣な接続性(平均した数の付随しているリンク)です。 高度なデザインは、全体のルーティングデータベースがどんな特定のゲートウェイにも保たれるのを必要としないかもしれません、発見とテクニックをキャッシュするのが必要であるように。
6. Reachability and delay metrics, if used, must not depend on
direct connectivity to all other gateways or on the use of
network-specific broadcast mechanisms. Polling procedures
(e.g., for consistency checking) must be used only
sparingly and in no case introduce an overhead exceeding a
constant, independent of network topology, times the
longest non-looping path.
6. 使用されるなら、可到達性と遅れ測定基準は、ネットワーク特有の放送メカニズム世論調査手順(例えば、一貫性の照合のための)の使用のときに他のすべてのゲートウェイへのダイレクト接続性に依存してはいけませんし、控えめにだけ使用されて、また定数(ネットワーク形態、回の如何にかかわらず最も長い非ループ経路)を超えているオーバーヘッドを決して導入してはいけません。
7. Default routes (generally intended as a means to reduce the
size of the routing data-base) must be used with care,
because of the many problems with multiple paths, loops,
and mis-configurations which routing defaults have caused.
7. 複数の経路、輪、およびルーティングデフォルトが引き起こした誤構成に関する多くの問題のために、慎重に、デフォルトルート(一般に、ルーティングデータベースのサイズを減少させる手段として、意図する)を使用しなければなりません。
The most common application of defaults is for routing
within an Internet region which is connected in a strictly
hierarchical fashion and is a stub from the rest of the
Internet system. In this case, the default is used for
routing "up" the tree. Unfortunately, such restricted
topology seldom lasts very long, and defaults cease to
work.
厳密に階層的なファッションで接続されて、インターネット・システムの残りからのスタッブであるインターネット地域の中にデフォルトの最も一般的な利用はルーティングのためにあります。 この場合、デフォルトはルーティング“up"に使用されます。木。 残念ながら、そのような制限されたトポロジーは非常に長い間、めったに続きません、そして、デフォルトは働くのをやめます。
More generally, defaults could be used for initial routing
guesses, with final routes to be discovered and cached from
external or internal data-bases via the routing algorithm
or EGP.
より一般に、初期のルーティング推測にデフォルトを使用できました、外部の、または、内部のデータベースからルーティング・アルゴリズムで発見された、キャッシュされるべき最終的なルートかEGPと共に。
Braden & Postel [Page 31]
ブレーデンとポステル[31ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
4.2. Subnets and Routing
4.2. サブネットとルート設定
We will call a gateway "subnetted" if at least one of its
interfaces is connected to a subnet; the set of gateways directly
connected to subnets of the same network will be referred to as a
"subnet cluster". For example, in the following diagram, network
2 is subnetted, with subnets 2.1 and 2.2, but network 1 is not;
gateways 1, 2, and 3 are subnetted and are members of the same
subnet cluster.
私たちは少なくともインタフェースの1つがサブネットに関連づけられるなら"「副-網で覆」い"であったゲートウェイを呼ぶつもりです。 直接同じネットワークのサブネットに接続されたゲートウェイのセットは「サブネットクラスタ」と呼ばれるでしょう。 例えば、以下のダイヤグラムで、ネットワーク2はサブネット2.1と2.2で「副-網で覆」われますが、ネットワーク1は「副-網で覆」われるというわけではありません。 ゲートウェイ1、2、および3は、「副-網で覆」われて、同じサブネットクラスタのメンバーです。
(Net 1) === [Gwy 1] === (Net 2.1) === [Gwy 2] === (Net 2.2)
| |
| |
=================== [Gwy 3] =======================
(ネット1)=== [Gwy1]=== (ネットの2.1) === [Gwy2]=== (ネットの2.2) | | | | =================== [Gwy3]=======================
Subnets have the following effects on gateway routing:
サブネットはゲートウェイルーティングに以下の影響を与えます:
A. Non-subnetted gateways are not affected at all.
A.の非「副-網で覆」われたゲートウェイは全く影響を受けません。
B. The routing data-base in a subnetted gateway must consider
the address mask for subnet entries.
B. 「副-網で覆」われたゲートウェイのルーティングデータベースはサブネットエントリーのためのアドレスマスクを考えなければなりません。
C. Routing updates among the gateways in the same subnet
cluster must include entries for the various subnets. The
corresponding address mask(s) may be implicit, but for full
generality the mask needs to be given explicitly for each
entry. Note that if the routing data-base included a full
32-bit mask for every IP network, the gateway could deal
with networks and subnets in a natural way. This would
also handle the case of multiple subnet masks for the same
subnetted network.
同じサブネットクラスタのゲートウェイの中のC.ルート設定アップデートは様々なサブネットのためのエントリーを含まなければなりません。 対応するアドレスマスクは内在しているかもしれませんが、完全な一般性のために、マスクは、明らかに各エントリーに与えられている必要があります。 ルーティングデータベースがあらゆるIPネットワークに、完全な32ビットのマスクを含んでいるなら、ゲートウェイが自然な方法でネットワークとサブネットと取り引きするかもしれないことに注意してください。 また、これは同じサブネット化したネットワークのために複数のサブネットマスクのケースを扱うでしょう。
D. Routing updates from a subnetted gateway to a gateway
outside the cluster can contain nets, never subnets.
クラスタの外のゲートウェイへの「副-網で覆」われたゲートウェイからのD.ルート設定アップデートはネット、決してどんなサブネットも含むことができません。
E. If a subnetted gateway (e.g., gateway 2 above) is unable to
forward a datagram from one subnet to another subnet of the
same network, then it must return a Host Unreachable, not a
Net Unreachable, as discussed in Section 2.2.1.
E. 「副-網で覆」われたゲートウェイ(例えば、ゲートウェイ2上)が、あるサブネットから同じネットワークの別のサブネットまでデータグラムを進めることができないなら、ネットUnreachableではなく、Host Unreachableを返さなければなりません、セクション2.2.1で議論するように。
When considering the choice of routing protocol, a gateway builder
must consider how that protocol generalizes for subnets. For some
routing protocols it will be possible to use the same procedures
in a regular gateway and a subnetted gateway, with only a change
of parameters (e.g., address masks).
ルーティング・プロトコルの選択を考えるとき、ゲートウェイビルダーは、そのプロトコルがサブネットのためにどのように広められるかを考えなければなりません。 通常のゲートウェイと「副-網で覆」われたゲートウェイで同じ手順を用いるのはいくつかのルーティング・プロトコルに、可能になるでしょう、パラメタ(例えば、アドレスマスク)の変化だけで。
A different subnet address mask must be configurable for each
それぞれに、異なったサブネットアドレスマスクは構成可能であるに違いありません。
Braden & Postel [Page 32]
ブレーデンとポステル[32ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
interface of a given gateway. This will allow a subnetted gateway
to connect to two different subnetted networks, or to connect two
subnets of the same network with different masks.
与えられたゲートウェイのインタフェース。 これで、「副-網で覆」われたゲートウェイは、2つの異なったサブネット化したネットワークに接続するか、または同じネットワークの2つのサブネットを異なったマスクに接続するでしょう。
4.3 Resource Allocation
4.3 資源配分
In order to perform its basic datagram-forwarding functions, a
gateway must allocate resources; its packet buffers and CPU time
must be allocated to packets it receives from connected networks,
while the bandwidth to each of the networks must also be allocated
for sending packets. The choice of allocation strategies will be
critical when a particular resource is scarce. The most obvious
allocation strategy, first-come-first-served (FCFS), may not be
appropriate under overload conditions, for reasons which we will
now explore.
基本的なデータグラムを進める機能を実行するために、ゲートウェイはリソースを割り当てなければなりません。 それが接続ネットワークから受けるパケットにそのパケットバッファとCPU時間を割り当てなければなりません、また、送付パケットのためにそれぞれのネットワークへの帯域幅を割り当てなければなりませんが。 特定のリソースが不十分であるときに、配分戦略の選択は重要になるでしょう。 最も明白な配分戦略(先着順(FCFS))は過負荷条件の下で適切でないかもしれません、私たちが今探るつもりである理由で。
A first example is buffer allocation. It is important for a
gateway to allocate buffers fairly among all of its connected
networks, even if these networks have widely varying bandwidths.
A high-speed interface must not be allowed to starve slower
interfaces of buffers. For example, consider a gateway with a
10 Mbps Ethernet connection and two 56 Kbps serial lines. A buggy
host on the Ethernet may spray that gateway interface with packets
at high speed. Without careful algorithm design in the gateway,
this could tie up all the gateway buffers in such a way that
transit traffic between the serial lines would be completely
stopped.
最初の例はバッファ配分です。 ゲートウェイが接続ネットワークのすべてにバッファを公正に割り当てるのは、重要です、これらのネットワークに広く異なった帯域幅があっても。 高速インタフェースにバッファの、より遅いインタフェースを飢えさせてはいけません。 例えば、10Mbpsイーサネット接続とtwo56のKbpsの連続の系列があるゲートウェイを考えてください。 イーサネットのバギーのホストは高速でそのゲートウェイインタフェースにパケットを吹きかけるかもしれません。 ゲートウェイの慎重なアルゴリズムデザインがなければ、これはすべてのゲートウェイバッファをシリアル・ラインの間のトランジット通行が完全に止められるような方法でタイアップするかもしれません。
Allocation of output bandwidth may also require non-FCFS
strategies. In an advanced gateway design, allocation of output
bandwidth may depend upon Type-of-Service bits in the IP headers.
A gateway may also want to give priority to datagrams for its own
up/down and routing protocols.
また、出力帯域幅の配分は非FCFS戦略を必要とするかもしれません。 高度なゲートウェイデザインでは、出力帯域幅の配分はIPヘッダーでサービス・ビットのTypeによるかもしれません。 また、それ自身のもののためのデータグラムを上がるか下がっているのに最優先させたいかもしれなくて、プロトコルを発送するゲートウェイ。
Finally, Nagle [24] has suggested that gateways implement "fair
queueing", i.e., sharing output bandwidth equitably among the
current traffic sources. In his scheme, for each network
interface there would be a dynamically-built set of output queues,
one per IP source address; these queues would be serviced in a
round-robin fashion to share the bandwidth. If subsequent
research shows fair queueing to be desirable, it will be added to
a future version of this document as a universal requirement.
最終的に、ネーグル[24]は、すなわち、ゲートウェイが現在のトラフィックソースの中で公正に出力帯域幅を共有しながら「公正な待ち行列」を実装することを提案しました。 彼の体系には、各ネットワーク・インターフェースには、ダイナミックに組立のセットの出力キューがあるでしょう、IPソースアドレスあたり1つ。 これらの待ち行列は、帯域幅を共有するために連続ファッションで修理されるでしょう。 その後の研究が、公正な待ち行列が望ましいのを示すと、それは普遍的な要件としてこのドキュメントの将来のバージョンに追加されるでしょう。
Braden & Postel [Page 33]
ブレーデンとポステル[33ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
4.4. Special Addresses and Filters
4.4. 特別なアドレスとフィルタ
Section 2.1 contained a list of the 32-bit IP addresses which have
special meanings. They do not in general represent unique IP
addresses of Internet hosts, and there are restrictions on their
use in IP headers.
セクション2.1は特別な意味を持っている32ビットのIPアドレスのリストを含みました。 一般に、彼らはインターネット・ホストの固有のIPアドレスを表しません、そして、IPヘッダーにおける彼らの使用には制限があります。
We can distinguish two classes of these special cases. The first
class (specifically, cases (a), (b), (c), (g), (h), and (i) in
section 2.1) contains addresses which should never appear in the
destination address field of any IP datagram, so a gateway should
never be asked to route to one of these addresses. However, in
the real world of imperfect implementations and configuration
errors, such bad destination addresses do occur. It is the
responsibility of a gateway to avoid propagating such erroneous
addresses; this is especially important for gateways included in
the global interconnect system. In particular, a gateway which
receives a datagram with one of these forbidden addresses should:
私たちはこれらの特別なケースの2つのクラスを区別できます。 一流(明確にセクション2.1のケース(a)、(b)、(c)、(g)、(h)、および(i))がどんなIPデータグラムの目的地アドレス・フィールドにも決して現れるべきでないアドレスを含んでいるので、これらのアドレスの1つへのルートはゲートウェイに決して尋ねられるべきではありません。 しかしながら、不完全な実装と構成誤りの本当の世界では、そのような悪い送付先アドレスが起こります。 そのような誤ったアドレスを伝播するのを避けるのは、ゲートウェイの責任です。 グローバルな内部連絡システムにゲートウェイを含んでいるのに、これは特に重要です。 特に、アドレスが禁じられたこれらの1つでデータグラムを受けるゲートウェイはそうするべきです:
1. Avoid inserting that address into its routing database, and
avoid including it in routing updates to any other gateway.
1. そのアドレスをルーティングデータベースに挿入するのを避けてください、そして、ルーティングアップデートでいかなる他のゲートウェイにもそれを含めるのを避けてください。
2. Avoid forwarding a datagram containing that address as a
destination.
2. 目的地としてそのアドレスを含むデータグラムを進めるのを避けてください。
To enforce these restrictions, it is suggested that a gateway
include a configurable filter for datagrams and routing updates.
A typical filter entry might consist of a 32-bit mask and value
pair. If the logical AND of the given address with the mask
equals the value, a match has been found. Since filtering will
consume gateway resources, it is vital that the gateway
configuration be able to control the degree of filtering in use.
これらの制限を実施するために、ゲートウェイがデータグラムとルーティングアップデートのための構成可能なフィルタを含んでいることが提案されます。 典型的なフィルタエントリーは32ビットのマスクと値の組から成るかもしれません。 マスクがある与えられたアドレスの論理的なANDが値と等しいなら、マッチは見つけられました。 フィルタリングがゲートウェイリソースを消費するので、ゲートウェイ構成が使用中のフィルタリングの度合いを制御できるのは、重大です。
There is a second class of special case addresses (cases (d), (e),
and (f) in section 2.1), the so-called "directed broadcasts". A
directed broadcast is a datagram to be forwarded normally to the
specified destination (sub-)net and then broadcast on the final
hop. An Internet gateway is permitted, but not required, to
filter out directed broadcasts destined for any of its
locally-connected networks. Hence, it should be possible to
configure the filter to block the delivery of directed broadcasts.
特別なケースアドレス(セクション2.1のケース(d)、(e)、および(f))、いわゆる「指示された放送」の二等があります。 指示された放送が通常、指定された目的地に送られるデータグラムである、(サブ、)、決勝のネットと次に放送は跳びます。 インターネット・ゲートウェイは、局所的に接続されたネットワークのいずれのためにも運命づけられた指示された放送を無視するのに受入れられますが、必要ではありません。 したがって、指示された放送の配送を妨げるためにフィルタを構成するのは可能であるべきです。
Finally, it will also be useful for Internet O&M to have a
configurable filter on the IP source address. This will allow a
network manager to temporarily block traffic from a particular
misbehaving host, for example.
また、最終的に、インターネットO&MがIPソースアドレスに構成可能なフィルタを持っているのも、役に立ちます。 これで、ネットワークマネージャは例えば、特定のふらちな事をしているホストから一時交通の妨害になるでしょう。
Braden & Postel [Page 34]
ブレーデンとポステル[34ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
4.5. Redirects
4.5. 向け直します。
The ICMP Redirect message is specified only for use by a gateway
to update the routing table of a host on the same connected net.
However, the Redirect message is sometimes used between gateways,
due to the following considerations:
ICMP Redirectメッセージは指定されますが、ゲートウェイのそばでの使用は同じ接続ネットでホストの経路指定テーブルをアップデートします。 しかしながら、Redirectメッセージは以下の問題のためゲートウェイの間で時々使用されます:
The routing function in a host is very much like that in a
"dumb gateway" (i.e., a gateway having only static routes). It
is desirable to allow the routing tables of a dumb gateway to
be changed under the control of a dynamic gateway (i.e., a
gateway with full dynamic routing) on the same network. By
analogy, it is natural to let the dynamic gateway send ICMP
Redirect messages to dumb gateway.
ホストの経路選択機能は「馬鹿なゲートウェイ」(すなわち、スタティックルートしか持っていないゲートウェイ)のそれに似ています。 馬鹿なゲートウェイの経路指定テーブルが同じネットワークにおけるダイナミックなゲートウェイ(すなわち、完全なダイナミックルーティングがあるゲートウェイ)のコントロールの下で変えられるのを許容するのは望ましいです。 類推で、ダイナミックなゲートウェイに馬鹿なゲートウェイにICMP Redirectにメッセージを送らせるのは、当然です。
The use of ICMP Redirect between gateways in this fashion may be
considered to be part of the IGP (in fact, the totality of the
IGP, as far as the dumb gateway is concerned!) in the particular
Autonomous System. Specification of an IGP is outside the scope
of this document, so we only note the possibility of using
Redirect in this fashion. Gateways are not required to receive
and act upon redirects, and in fact dynamic gateways must ignore
them. We also note that considerable experience shows that dumb
gateways often create problems resulting in "black holes"; a full
routing gateway is always preferable.
ゲートウェイの間のICMP Redirectの使用は特定のAutonomous SystemのIGP(事実上、馬鹿なゲートウェイは関係があるのと同じくらい遠いIGPの全体!)の一部であるとこんなやり方で考えられるかもしれません。 このドキュメントの範囲の外にIGPの仕様があるので、私たちはこんなやり方でRedirectを使用する可能性に注意するだけです。 そして、ゲートウェイが受ける必要はなくて、行為が向け直す、事実上、ダイナミックなゲートウェイはそれらを無視しなければなりません。 また、私たちは、豊富な経験が、馬鹿なゲートウェイが「ブラックホール」をもたらすことにおける問題をしばしば生じさせるのを示すことに注意します。 完全なルーティングゲートウェイはいつも望ましいです。
Routing table entries established by redirect messages must be
removed automatically, either by a time-out or when a use count
goes to zero.
自動的に再直接のメッセージによって設置された経路指定テーブルエントリーを取り除かなければならなくて、どちらかaで、タイムアウトかそれとも使用がいつ重要であるかがゼロまで行きます。
4.6. Broadcast and Multicast
4.6. 放送とマルチキャスト
A host which is connected to a network (generally a LAN) with an
intrinsic broadcast capability may want to use this capability to
effect multidestination delivery of IP datagrams. The basic
Internet model assumes point-to-point messages, and we must take
some care when we incorporate broadcasting. It is important to
note that broadcast addresses may occur at two protocol levels:
the local network header and the IP header.
本質的な放送能力でネットワーク(一般にLAN)に接続されるホストはIPデータグラムの効果「マルチ-目的地」配送にこの能力を使用したがっているかもしれません。基本的なインターネットモデルは二地点間メッセージを仮定します、そして、放送を取り入れるとき、私たちはいくつか注意しなければなりません。 放送演説が2つのプロトコルレベルで起こるかもしれないことに注意するのは重要です: 企業内情報通信網ヘッダーとIPヘッダー。
Incorrect handling of broadcasting has often been the cause of
packet avalanches (sometimes dubbed "meltdown") in LANs. These
avalanches are generally caused by gratuitous datagram-forwarding
by hosts, or by hosts sending ICMP error messages when they
discard broadcast datagrams.
しばしば放送の不正確な取り扱いはLANにおけるパケット殺到(時々「炉心溶解」と呼ばれる)の原因です。 一般に、これらの殺到はホスト、またはそれらがブロードキャスト・データグラムを捨てるときエラーメッセージをICMPに送るホストによる無料のデータグラム推進で引き起こされます。
Gateways have a responsibility to prevent avalanches, or datagrams
which can trigger avalanches, from escaping into another network.
ゲートウェイには、別のネットワークに逃げるので殺到の引き金となることができる殺到、またはデータグラムを防ぐ責任があります。
Braden & Postel [Page 35]
ブレーデンとポステル[35ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
In general, a gateway must not forward a datagram which arrives
via local network broadcast, and must not send an ICMP error
message when dropping the datagram. A discussion of the rules
will be found in Appendix A; see also [50].
一般に、ゲートウェイは、地方のネットワーク放送で届くデータグラムを進めてはいけなくて、データグラムを下げるとき、ICMPエラーメッセージを送ってはいけません。 規則の議論はAppendix Aで見つけられるでしょう。 また、[50]を見てください。
As noted in Section 4.4, a gateway is permitted to filter out
directed broadcasts. Hence, directed broadcasts will only be
useful in limited Internet regions (e.g., the within the subnets
of a particular campus) in which delivery is supported by the
gateway administrators. Host group multicasting (see Sections 2.8
and 4.6) will soon provide a much more efficient mechanism than
directed broadcasting. Gateway algorithms for host group
multicasting will be specified in future RFC's.
セクション4.4に述べられるように、ゲートウェイが指示された放送を無視することが許可されています。 したがって、指示された放送が単に限られたインターネット地域で役に立つ、(例えば、特定のキャンパス) 配送がゲートウェイ管理者によってサポートされるコネのサブネットの中で。 ホストグループマルチキャスティング(セクション2.8と4.6を見る)はすぐ、指示された放送よりはるかに効率的なメカニズムを提供するでしょう。 Gateway algorithms for host group multicasting will be specified in future RFC's.
4.7. Reachability Procedures
4.7. 可到達性手順
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
messages across each link. This function might be intrinsic to
the link-level protocols used (e.g., LAPB). However, it is in
general ill-advised to assume a host or gateway is operating
correctly even 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).
アーキテクチャはネットワークにおけるそれぞれのリンクとノードの操作上の状態を証明するために強健なメカニズムを提供しなければなりません、ゲートウェイ(また、それらと適切であるところのホストに接するリンク)を含んでいて 通常、これは少なくとも各リンクの向こう側にメッセージの周期的な交換にかかわるリンク・レベル可到達性プロトコルを必要とします。 この機能はプロトコルが使用したリンク・レベル(例えば、LAPB)に本質的であるかもしれません。 しかしながら、リンク・レベル可到達性プロトコルが正しく作動していても一般に、ホストかゲートウェイに就くためにあさはかであるのが、正しく作動することであるということです。 追加確認が操作ルーティング・アルゴリズムか同輩レベル可到達性プロトコルの形で必要です(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.
リンク、そして/または、ゲートウェイの失敗と修復をネットワークイベントであると考えられて、コントロールセンターに報告しなければなりません。 必要ではありませんが、報告経路がルーティング・アルゴリズム自体の正しい機能を必要としないのは、望ましいです。
4.8. Time-To-Live
4.8. 生きる時間
The Time-to-Live (TTL) field of the IP header is defined to be a
timer limiting the lifetime of a datagram in the Internet. It is
an 8-bit field and the units are seconds. This would imply that
for a maximum TTL of 255 a datagram would time-out after about 4
and a quarter minutes. Another aspect of the definition requires
each gateway (or other module) that handles a datagram to
decrement the TTL by at least one, even if the elapsed time was
much less than a second. Since this is very often the case, the
TTL effectively becomes a hop count limit on how far a datagram
can propagate through the Internet.
IPヘッダーの生きるTime(TTL)分野は、インターネットでデータグラムの生涯を制限するタイマになるように定義されます。 それは8ビットの分野です、そして、ユニットは秒です。 これは、255の最大のTTLに関して、データグラムは4時後頃のタイムアウトと4分の1分そうするのを含意するでしょう。 定義のもう一つの側面は、データグラムを扱う各ゲートウェイ(または、他のモジュール)がTTLを少なくとも1つ減少させるのを必要とします、経過時間が2番目よりはるかに少なかったとしても。 これによる頻繁に、事実上、ケース、TTLがホップになるということであるので、データグラムがインターネットを通してどれくらい遠くに伝播されることができるかに関して限界を数えてください。
Braden & Postel [Page 36]
ブレーデンとポステル[36ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
As the Internet grows, the number of hops needed to get from one
edge to the opposite edge increases, i.e., the Internet diameter
grows.
インターネットが発展するのに従って、1つの縁から反対の縁に到着するのが必要であるホップの数は増加します、すなわち、インターネット直径が成長します。
If a gateway holds a datagram for more than one second, it must
decrement the TTL by one for each second.
ゲートウェイが1秒以上間、データグラムを維持するなら、それはTTLを各2番目あたり1つ減少させなければなりません。
If the TTL is reduced to zero, the datagram must be discarded, and
the gateway may send an ICMP Time Exceeded message to the source.
A datagram should never be received with a TTL of zero.
TTLがゼロまで減少するなら、データグラムを捨てなければなりません、そして、ゲートウェイはICMP Time Exceededメッセージをソースに送るかもしれません。 ゼロのTTLと共にデータグラムを決して受け取るべきではありません。
When it originates a datagram, a gateway is acting in the role of
a host and must supply a realistic initial value for the TTL.
データグラムを溯源するとき、ゲートウェイは、ホストの役割で行動していて、現実的な初期の値をTTLに供給しなければなりません。
Braden & Postel [Page 37]
ブレーデンとポステル[37ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
5. Operation and Maintenance
5. 維持管理
5.1. Introduction
5.1. 序論
Facilities to support operation and maintenance (O&M) activities
form an essential part of any gateway implementation. The
following kinds of activity are included under gateway O&M:
維持管理(O&M)が活動であるとサポートする施設はどんなゲートウェイ実装の不可欠の部分も形成します。 活動の以下の種類はゲートウェイO&Mの下に含まれています:
* Diagnosing hardware problems in the gateway processor, in
its network interfaces, or in the connected networks,
modems, or communication lines.
* ゲートウェイプロセッサ、ネットワーク・インターフェース、接続ネットワーク、モデム、または通信回線でハードウェア問題を診断します。
* Installing a new version of the gateway software.
* ゲートウェイソフトウェアの新しいバージョンをインストールします。
* Restarting or rebooting a gateway after a crash.
* クラッシュの後にゲートウェイを再開するか、またはリブートします。
* Configuring (or reconfiguring) the gateway.
* ゲートウェイを構成します(または、再構成)。
* Detecting and diagnosing Internet problems such as
congestion, routing loops, bad IP addresses, black holes,
packet avalanches, and misbehaved hosts.
* 混雑や、ルーティング輪や、悪いIPアドレスや、ブラックホールや、パケット殺到や、無作法なホストなどのインターネット問題を検出して、診断します。
* Changing network topology, either temporarily (e.g., to
diagnose a communication line problem) or permanently.
* 永久に、一時例えば通信回線問題を診断する()ネットワーク形態を変えます。
* Monitoring the status and performance of the gateways and
the connected networks.
* ゲートウェイと接続ネットワークの状態と性能をモニターします。
* Collecting traffic statistics for use in (Inter-)network
planning.
* 使用のためにトラフィック統計を中に集める、(相互、)、計画をネットワークでつないでください。
Gateways, packet-switches, and their connected communication lines
are often operated as a system by a centralized O&M organization.
This organization will maintain a (Inter-)network operation
center, or NOC, to carry out its O&M functions. It is essential
that gateways support remote control and monitoring from such a
NOC, through an Internet path (since gateways might not be
connected to the same network as their NOC). Furthermore, an IP
datagram traversing the Internet will often use gateways under the
control of more than one NOC; therefore, Internet problem
diagnosis will often involve cooperation of personnel of more than
one NOC. In some cases, the same gateway may need to be monitored
by more than one NOC.
aによるシステムがO&M組織を集結したので、ゲートウェイ、パケット交換機、およびそれらの接続通信回線はしばしば操作されます。 この組織がaを維持する、(相互、)、オペレーション・センター、またはNOCをネットワークでつないで、OとM機能を行ってください。 ゲートウェイがそのようなNOCからの遠隔操作とモニターをサポートするのは、不可欠です、インターネット経路を通って(ゲートウェイがそれらのNOCと同じネットワークに接続されないかもしれないので)。 その上、インターネットを横断するIPデータグラムは1NOCのコントロールの下にゲートウェイをしばしば使用するでしょう。 したがって、インターネット問題診断はしばしば1NOCの人員の協力にかかわるでしょう。 いくつかの場合、同じゲートウェイは、1NOCによってモニターされる必要があるかもしれません。
The tools available for monitoring at a NOC may cover a wide range
of sophistication. Proposals have included multi-window, dynamic
displays of the entire gateway system, and the use of AI
techniques for automatic problem diagnosis.
NOCでのモニターに利用可能なツールはさまざまな洗練をカバーするかもしれません。 提案はマルチ・ウィンドウ、全体のゲートウェイシステムのダイナミックなディスプレイ、および自動問題診断のためのAIのテクニックの使用を含んでいました。
Braden & Postel [Page 38]
ブレーデンとポステル[38ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
Gateway O&M facilities discussed here are only a part of the large
and difficult problem of Internet management. These problems
encompass not only multiple management organizations, but also
multiple protocol layers. For example, at the current stage of
evolution of the Internet architecture, there is a strong coupling
between host TCP implementations and eventual IP-level congestion
in the gateway system [9]. Therefore, diagnosis of congestion
problems will sometimes require the monitoring of TCP statistics
in hosts. Gateway algorithms also interact with local network
performance, especially through handling of broadcast packets and
ARP, and again diagnosis will require access to hosts (e.g.,
examining ARP caches). However, consideration of host monitoring
is beyond the scope of this RFC.
ここで議論した唯一のゲートウェイOとM施設はインターネット管理の大きくて難しい問題の一部です。 これらの問題は複数の経営組織だけではなく、複数のプロトコル層も取り囲みます。 例えば、現在のステージのインターネットアーキテクチャの発展に、ホストTCP実装と最後のIP-レベル混雑の間には、ゲートウェイシステム[9]には強いカップリングがあります。 したがって、混雑問題の診断は時々ホストでのTCP統計のモニターを必要とするでしょう。 また、ゲートウェイアルゴリズムは特に放送パケットとARPの取り扱うことで企業内情報通信網性能と対話します、そして、一方、診断はホスト(例えば、ARPキャッシュを調べます)へのアクセスを必要とするでしょう。 しかしながら、ホストモニターの考慮はこのRFCの範囲を超えています。
There are currently a number of R&D efforts in progress in the
area of Internet management and more specifically gateway O&M. It
is hoped that these will lead quickly to Internet standards for
the gateway protocols and facilities required in this area. This
is also an area in which vendor creativity can make a significant
contribution.
進行中の多くの研究開発取り組みが現在、インターネット管理と、より明確にゲートウェイO&Mの領域にあります。 これらが急速にゲートウェイプロトコルのインターネット標準に通じることを望まれていて、施設がこの領域で必要です。 また、これはベンダーの創造性が力を発揮できる領域です。
5.2. Gateway O&M Models
5.2. ゲートウェイO&Mはモデル化されます。
There is a range of possible models for performing O&M functions
on a gateway. At one extreme is the local-only model, under which
the O&M functions can only be executed locally, e.g., from a
terminal plugged into the gateway machine. At the other extreme,
the fully-remote model allows only an absolute minimum of
functions to be performed locally (e.g., forcing a boot), with
most O&M being done remotely from the NOC. There intermediate
models, e.g., one in which NOC personnel can log into the gateway
as a host, using the Telnet protocol, to perform functions which
can also be invoked locally. The local-only model may be adequate
in a few gateway installations, but in general remote operation
from a NOC will be required, and therefore remote O&M provisions
are required for most gateways.
Oを実行するためのさまざまな可能なモデルがあります、そして、Mはゲートウェイの上で機能します。 1つの極端には、地方に唯一のモデル(局所的にOとM機能を実行できるだけである)があります、例えば、ゲートウェイマシンがプラグを差し込まれた端末から。 それとは正反対に、完全にリモートなモデルは機能の絶対最小値だけを局所的(例えば、ブーツを押し込む)に実行させます、離れてNOCからほとんどのO&Mをしていて。 そこでは、中間的モデル、例えば、NOC人員がホストとしてゲートウェイにログインできるTelnetを使用するものが、また、局所的に呼び出すことができる機能を実行するために議定書を作ります。 一般に、NOCからのリモート操作が必要でしょう、そして、地方に唯一のモデルがいくつかのゲートウェイインストールで適切であるかもしれませんが、したがって、リモートOとM条項がほとんどのゲートウェイに必要です。
Remote O&M functions may be exercised through a control agent
(program). In the direct approach, the gateway would support
remote O&M functions directly from the NOC using standard Internet
protocols (e.g., UDP or TCP); in the indirect approach, the
control agent would support these protocols and control the
gateway itself using proprietary protocols. The direct approach
is preferred, although either approach is acceptable. The use of
specialized host hardware and/or software requiring significant
additional investment is 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
リモートOとM機能はコントロールエージェント(プログラム)を通して運動させられるかもしれません。 ダイレクト方式では、ゲートウェイは、直接NOCからリモートO&Mが機能であると標準のインターネットプロトコル(例えば、UDPかTCP)を使用することでサポートするでしょう。 間接的なアプローチでは、コントロールエージェントは、固有のプロトコルを使用することでこれらにプロトコルを支えて、コントロールにゲートウェイ自体を支えるでしょう。 アプローチは許容できますが、ダイレクト方式は好まれます。 専門化しているホストハードウェア、そして/または、重要な追加出資を必要とするソフトウェアの使用はお勧めできないです。 それにもかかわらず、いくつかのベンダーが、ゲートウェイが部分であるネットワークの統合部分としてコントロールエージェントを提供するのを選ぶかもしれません。 これはそうです。
Braden & Postel [Page 39]
ブレーデンとポステル[39ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
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.
ケース、手段がインターネットプロトコルと経路を使用するリモートサイトと同等な機能性で地方のエージェント端末に関してコントロールエージェントを手術するために利用可能であることが必要です。
It is desirable that a control agent and any other NOC software
tools which a vendor provides operate as user programs in a
standard operating system. The use of the standard Internet
protocols UDP and TCP for communicating with the gateways should
facilitate this.
ベンダーが提供するコントロールエージェントといかなる他のNOCソフトウェアツールも標準のオペレーティングシステムによるユーザ・プログラムとして手術されるのは、望ましいです。 標準のインターネットプロトコルのUDPとTCPのゲートウェイで交信する使用はこれを容易にするべきです。
Remote gateway monitoring and (especially) remote gateway control
present important access control problems which must be addressed.
Care must also be taken to ensure control of the use of gateway
resources for these functions. It is not desirable to let gateway
monitoring take more than some limited fraction of the gateway CPU
time, for example. On the other hand, O&M functions must receive
priority so they can be exercised when the gateway is congested,
i.e., when O&M is most needed.
リモートゲートウェイモニターと(特に)リモートなゲートウェイコントロールは扱わなければならない重要なアクセス制御の問題を提示します。 また、ゲートウェイリソースのこれらの機能の使用のコントロールを確実にするために注意しなければなりません。 或るものがゲートウェイCPU時間の部分を制限したよりさらに、例えば撮影をモニターするゲートウェイを貸すのは望ましくはありません。 他方では、OとM機能は、O&Mが最も必要であるときに、すなわち、ゲートウェイが充血するとき、それらを運動させることができるように優先権を受けなければなりません。
There are no current Internet standards for the control and
monitoring protocols, although work is in progress in this area.
The Host Monitoring Protocol (HMP) [7] could be used as a model
until a standard is developed; however, it is strongly recommended
that gateway O&M protocol be built on top of one of the standard
Internet end-to-end protocols UDP or TCP. An example of a very
simple but effective approach to gateway monitoring is contained
in RFC-996 [43].
仕事はこの領域で進行していますが、コントロールとモニターしているプロトコルのどんな現在のインターネット標準もありません。 規格が開発されるまで、モデルとしてHost Monitoringプロトコル(HMP)[7]を使用できました。 しかしながら、OとMが議定書の中で述べるゲートウェイが標準のインターネットの終わりから終わりへのプロトコルUDPかTCPの1つの上で建設されることが強く勧められます。 ゲートウェイモニターへの非常に簡単な、しかし、有効なアプローチに関する例はRFC-996[43]に含まれています。
5.3. Gateway O&M Functions
5.3. ゲートウェイO&Mは機能します。
The following O&M functions need to be performed in a gateway:
機能がゲートウェイで実行されるために必要とする以下のO&M:
A. Maintenance -- Hardware Diagnosis
A.メインテナンス--ハードウェア診断
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 be able to run diagnostics or dump the gateway
via the network in case of fault. Means should be provided
to allow remote control from the NOC of of modems attached
to the gateway. The most important modem control capability
is entering and leaving loopback mode, to diagnose line
problems.
各ゲートウェイは地方のハードウェアの保守管理の目的のためのスタンドアロンのデバイスとして作動しなければなりません。 手段は、ゲートウェイサイトでディスケットかテープとローカル・ターミナルであるにすぎないかもしれない現場の唯一のツールを使用することで診断プログラムを動かすために利用可能でなければなりません。 それは望ましいです、欠点の場合のネットワークを通して病気の特徴を実行するか、またはゲートウェイをどさっと落とすことができるのが必要ではありませんが。 手段はそうであるべきです。ゲートウェイに取り付けられたモデムについてNOCからの遠隔操作を許すために、提供しています。 最も重要なモデム制御能力は、系列問題を診断するためにループバックをモードに入れて、残しています。
Braden & Postel [Page 40]
ブレーデンとポステル[40ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
B. Control -- Dumping and Rebooting
B.コントロール--ダンピングとリブート
It must be possible to dump and reboot a stand-alone gateway
upon command from the NOC. In addition, a stand-alone
gateway must include a watchdog timer that either initiates
a reboot automatically or signals a remote control site if
not reset periodically by the software. It is desirable
that the boot data involved reside at an Internet host
(e.g., the NOC host) and be transmitted via the net;
however, the use of local devices at the gateway site is
acceptable.
コマンドのときにNOCからスタンドアロンのゲートウェイをどさっと落として、リブートするのは可能であるに違いありません。 さらに、スタンドアロンのゲートウェイは定期的にソフトウェアによってリセットされないなら、自動的にリブートを開始するか、または遠隔操作サイトを示すウオッチドッグタイマーを含まなければなりません。 データがかかわったブーツがインターネット・ホスト(例えば、NOCホスト)に住んでいて、ネットで送られるのは、望ましいです。 しかしながら、ゲートウェイサイトのローカル装置の使用は許容できます。
C. Control -- Configuring the Gateway
C.コントロール--ゲートウェイを構成すること。
Every gateway will have a number of configuration parameters
which must be set (see the next section for examples). It
must be possible to update the parameters without rebooting
the gateway; at worst, a restart may be required.
あらゆるゲートウェイには、設定しなければならない多くの設定パラメータがあるでしょう(例に関して次のセクションを見てください)。 ゲートウェイをリブートしないでパラメタをアップデートするのは可能であるに違いありません。 最悪の場合は、再開が必要であるかもしれません。
D. Monitoring -- Status and Performance
D.モニター--状態とパフォーマンス
A mechanism must be provided for retrieving status and
statistical information from a gateway. A gateway must
supply such information in response to a polling message
from the NOC. In addition, it may be desirable to configure
a gateway to transmit status spontaneously and periodically
to a NOC (or set of NOCs), for recording and display.
ゲートウェイからの状態と統計情報を検索しながら、メカニズムに備えなければなりません。 ゲートウェイはNOCからの世論調査メッセージに対応してそのような情報を提供しなければなりません。 さらに、自然に、そして定期的にNOC(または、NOCsのセット)に状態を伝えるためにゲートウェイを構成するのは望ましいかもしれません、録音とディスプレイのために。
Examples of interesting status information include: link
status, queue lengths, buffer availability, CPU and memory
utilization, the routing data-base, error counts, and packet
counts. Counts should be kept for dropped datagrams,
separated by reason. Counts of ICMP datagrams should be
kept by type and categorized into those originating at the
gateway, and those destined for the gateway. It would be
useful to maintain many of these statistics by network
interface, by source/destination network pair, and/or by
source/destination host pair.
おもしろい状態情報に関する例は: 状態、待ち行列の長さ、バッファの有用性、CPU、メモリ使用量、ルーティングデータベース、誤り件数、およびパケットカウントをリンクしてください。 カウントは理由によって切り離された下げられたデータグラムのために保たれるべきです。 ICMPデータグラムのカウントは、タイプによって保たれて、ゲートウェイで起因するものに分類されるべきでした、そして、それらはゲートウェイに運命づけられました。 ネットワーク・インターフェース、ソース/あて先ホスト組ごとにこれらの統計の多くを維持するのは役に立つでしょう。
Note that a great deal of useful monitoring data is often to
be found in the routing data-base. It is therefore useful
to be able to tap into this data-base from the NOC.
多くの役に立つモニターしているデータがルーティングデータベースの中でしばしば見つけられることであることに注意してください。 したがって、NOCからこのデータベースに軽く打ち込むことができるのは役に立ちます。
E. Monitoring -- Error Logging
E.モニター--エラー・ロギング
A gateway should be capable of asynchronously sending
exception ("trap") reports to one or more specified Internet
addresses, one of which will presumably be the NOC host.
ゲートウェイは例外(「罠」)レポートを1つ以上の指定されたインターネット・アドレスに非同期に送ることができるべきです。おそらく、その1つはNOCホストになるでしょう。
Braden & Postel [Page 41]
ブレーデンとポステル[41ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
There must also be a mechanism to limit the frequency of
such trap reports, and the parameters controlling this
frequency must be settable in the gateway configuration.
また、そのような罠レポートの頻度を制限するメカニズムがあるに違いありません、そして、この頻度を制御するパラメタはゲートウェイ構成で「舗装用敷石-可能」であるに違いありません。
Examples of conditions which should result in traps include:
datagrams discarded because of TTL expiration (an indicator
of possible routing loops); resource shortages; or an
interface changing its up/down status.
罠をもたらすべきである状態に関する例は: データグラムはTTL満了のために捨てられました(可能なルーティングのインディケータは輪にされます)。 リソース不足。 または、上/下に状態を変えるインタフェース。
5.4. Gateway Configuration Parameters
5.4. ゲートウェイ設定パラメータ
Every gateway will have a set of configuration parameters
controlling its operation. It must be possible to set these
parameters remotely from the NOC or locally at any time, without
taking the gateway down.
あらゆるゲートウェイには、操作を制御する1セットの設定パラメータがあるでしょう。 いつでも局所的に離れてNOCからのこれらのパラメタを設定するのは可能であるに違いありません、ゲートウェイを降ろさないで。
The following is a partial but representative list of possible
configuration parameters for a full-function gateway. The items
marked with "(i)" should be settable independently for each
network interface.
↓これは完全な機能ゲートウェイのための可能な設定パラメータの部分的な、しかし、代表しているリストです。 各ネットワーク・インターフェースには、"(i)"でマークされた項目は独自に「舗装用敷石-可能」であるはずです。
* (i) IP (sub-) network address
* (i) IP、(サブ、)、ネットワーク・アドレス
* (i) Subnet address mask
* (i) サブネットアドレスマスク
* (i) MTU of local network
* (i) 企業内情報通信網のMTU
* (i) Hardware interface address
* (i) ハードウェアインターフェース・アドレス
* (i) Broadcast compatibility option (0s or 1s)
* (i) 放送互換性オプション(0か1)
* EGP parameters -- neighbors, Autonomous System number,
and polling parameters
* EGPパラメタ--隣人、Autonomous System番号、および世論調査パラメタ
* Static and/or default routes, if any
* もしあれば静電気、そして/または、デフォルトルート
* Enable/Disable Proxy ARP
* プロキシARPを有効にするか、または無効にしてください。
* Source Quench parameters
* ソースQuenchパラメタ
* Address filter configuration
* アドレスフィルタ構成
* Boot-host address
* ブーツホスト・アドレス
* IP address of time server host
* 時間サーバー・ホストのIPアドレス
* IP address(es) of logging host(s)
* 伐採の(es)がホスティングするIPアドレス(s)
Braden & Postel [Page 42]
ブレーデンとポステル[42ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
* IP address(es) of hosts to receive traps
* 受けるホストのIPアドレス(es)は捕らえられます。
* IP address(es) of hosts authorized to issue control
commands
* ホストの(es)が制御コマンドを発行するのを認可したIPアドレス
* Error level for logging
* 伐採のための誤りレベル
* Maximum trap frequency
* 最大の罠頻度
* Hold-down period (if any)
* 抑制の期間(もしあれば)
Braden & Postel [Page 43]
ブレーデンとポステル[43ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
Appendix A. Technical Details
付録A.技術面の詳細
This Appendix collects a number of technical details and rules concerning datagram forwarding by gateways and datagram handling by hosts, especially in the presence of broadcasting and subnets.
このAppendixはゲートウェイのそばでのデータグラム推進とホストによるデータグラム取り扱いに関して多くの技術的詳細と規則を集めます、特に放送とサブネットがあるとき。
A.1. Rules for Broadcasting
A.1。 放送のための規則
The following rules define how to handle broadcasts of packets and
datagrams [50]:
以下の規則はパケットとデータグラム[50]の放送を扱う方法を定義します:
a. Hosts (which do not contain embedded gateways) must NEVER
forward any datagrams received from a connected network,
broadcast or not.
a。 ホスト(埋め込まれたゲートウェイを含みません)は放送か否かに関係なく、接続ネットワークから受け取られたどんなデータグラムも決して進めてはいけません。
When a host receives an IP datagram, if the destination
address identifies the host or is an IP broadcast address,
the host passes the datagram to its appropriate
higher-level protocol module (possibly sending ICMP
protocol unreachable, but not if the IP address was a
broadcast address). Any other IP datagram must simply be
discarded, without an ICMP error message. Hosts never send
redirects.
ホストが送付先アドレスがホストを特定するか、IP放送演説であるならIPデータグラムを受け取るとき、ホストが適切な上位レベル・プロトコルモジュールにデータグラムを渡す、(ことによると送付ICMPプロトコル手の届かない、IPアドレスが放送演説でなかった、) ICMPエラーメッセージなしでいかなる他のIPデータグラムも単に捨てなければなりません。 ホストは決して発信しません。向け直します。
b. All packets containing IP datagrams which are sent to the
local-network packet broadcast address must contain an IP
broadcast address as the destination address in their IP
header. Expressed in another way, a gateway (or host) must
not send in a local-network broadcast packet an IP datagram
that has a specific IP host address as its destination
field.
b。 企業内情報通信網パケット放送演説に送られるIPデータグラムを含むすべてのパケットが送付先アドレスとして彼らのIPヘッダーにIP放送演説を含まなければなりません。 別の方法的に言い表されて、ゲートウェイ(または、ホスト)は企業内情報通信網放送パケットであて先フィールドとして特定のIPホスト・アドレスを持っているIPデータグラムを送ってはいけません。
c. A gateway must never forward an IP datagram that arrives
addressed to the IP limited broadcast address {-1,-1}.
Furthermore, it must must not send an ICMP error message
about discarding such a datagram.
c。 ゲートウェイは限られた放送演説-1-1をIPに扱われた状態で届くIPデータグラムに決して転送してはいけません。 その上、それは送らなければなりません。そのようなデータグラムを捨てることに関するICMPエラーメッセージを送ってはいけません。
d. A gateway must not forward an IP datagram addressed to
network zero, i.e., {0, *}.
d。 ゲートウェイはすなわち、ゼロ、0、*をネットワークでつなぐために扱われたIPデータグラムを進めてはいけません。
e. A gateway may forward a directed broadcast datagram, i.e.,
a datagram with the IP destination address:
e。 ゲートウェイは指示されたブロードキャスト・データグラム、すなわち、受信者IPアドレスがあるデータグラムを進めるかもしれません:
{ <Network-number>, -1}.
<ネットワーク・ナンバー>、-1。
However, it must not send such a directed broadcast out the
same interface it came in, if this interface has
<Network-number> as its network number. If the code in the
しかしながら、それがそのような指示された放送を出してはいけないので、それがこのインタフェースであるなら来た同じインタフェースはネットワーク・ナンバーとして<Network-番号>を持っています。 中のコードです。
Braden & Postel [Page 44]
ブレーデンとポステル[44ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
gateway making this decision does not know what interface
the directed-broadcast datagram arrived on, the gateway
cannot support directed broadcast to this connected network
at all.
この決定をするゲートウェイは、指示されたブロードキャスト・データグラムがどんなインタフェースで届いたかを知らないで、ゲートウェイは全くこの接続ネットワークに指示された放送をサポートすることができません。
f. A gateway is permitted to protect its connected networks by
discarding directed broadcast datagrams.
f。 ゲートウェイが指示されたブロードキャスト・データグラムを捨てることによって接続ネットワークを保護することが許可されています。
A gateway will broadcast an IP datagram on a connected network if
it is a directed broadcast destined for that network. Some
gateway-gateway routing protocols (e.g., RIP) also require
broadcasting routing updates on the connected networks. In either
case, the datagram must have an IP broadcast address as its
destination.
ゲートウェイはそれがそのネットワークのために運命づけられた指示された放送であるなら接続ネットワークでIPデータグラムを放送するでしょう。 また、いくつかのゲートウェイゲートウェイルーティング・プロトコル(例えば、RIP)が、接続ネットワークに関するルーティング最新情報を放送するのを必要とします。 どちらの場合ではも、データグラムは目的地としてIP放送演説を持たなければなりません。
Note: as observed earlier, some host implementations (those
based on Berkeley 4.2BSD) use zero rather than -1 in the host
field. To provide compatibility during the period until these
systems are fixed or retired, it may be useful for a gateway to
be configurable to send either choice of IP broadcast address
and accept both if received.
以下に注意してください。 より早く観測されるように、いくつかのホスト導入(バークレー4.2BSDに基づくもの)がホスト分野で-1よりむしろゼロを使用します。 これらのシステムが固定されているか、または退職するまで期間、互換性を提供するために、ともに受け取るなら、ゲートウェイがIP放送演説の選択を送って、受け入れるのにおいて構成可能であることは、役に立つかもしれません。
A.2. ICMP Redirects
A.2。 ICMPは向け直します。
A gateway will generate an ICMP Redirect if and only if the
destination IP address is reachable from the gateway (as
determined by the routing algorithm) and the next-hop gateway is
on the same (sub-)network as the source host. Redirects must not
be sent in response to an IP network or subnet broadcast address
or in response to a Class D or Class E IP address.
ゲートウェイがICMP Redirectを生成する、単に送付先IPアドレスがゲートウェイから届いていて(ルーティング・アルゴリズムで決定するように)、次のホップゲートウェイが同じくらいにある、(サブ、)、送信元ホストとして、ネットワークでつなぎます。 向け直す、IPネットワークかサブネット放送演説に対応してClass DかClass E IPアドレスに対応して送ってはいけません。
A host must discard an ICMP Redirect if the destination IP address
is not its own IP address, or the new target address is not on the
same (sub-)network. An accepted Redirect updates the routing
data-base for the old target address. If there is no route
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.
ホストが送付先IPアドレスがそれ自身のIPアドレスでないならICMP Redirectを捨てなければならない、さもなければ、新しいあて先アドレスが同じくらいにない、(サブ、)、ネットワーク。 受け入れられたRedirectは古いあて先アドレスのためにルーティングデータベースをアップデートします。 古いあて先アドレスに関連しているどんなルートもなければ、Redirectは無視されます。 古いルートがデフォルトゲートウェイに関連しているなら、新しいあて先アドレスに関連している新しいルートはデータベースに挿入されます。
Braden & Postel [Page 45]
ブレーデンとポステル[45ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
Appendix B. NSFNET Specific Requirements
付録B.NSFNET決められた一定の要求
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. Proprietary and Extensibility Issues
B.1。 独占、そして、伸展性問題
Although hosts, gateways and networks supporting Internet
technology have been in continuous operation for several years,
vendors users and operators must understand that not all
networking issues are fully resolved. 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 or augment
existing ones. 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 new or augmented protocols.
インターネットが技術であるとサポートするホスト、ゲートウェイ、およびネットワークは継続的作業数年間中ですが、ベンダーのユーザとオペレータは、すべてのネットワーク問題が完全に解決されるというわけではないのを理解しなければなりません。 新たな必要性か、より良い解決策がNSFネットワーク共同体での使用のために見いだされるとき、その結果、新しいプロトコルをさばくか、または既存のものを増大させるのが必要であるかもしれません。 通常、これらの新しいプロトコルは既存のプロトコルですべての実用的な点で共同利用するように設計されるでしょう。 しかしながら、時折、既存のシステムがこれらの新しいか増大しているプロトコルをサポートするためにアップグレードしなければならないのは起こるかもしれません。
NSF systems procurements may favor those vendors who 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, 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.2. Interconnection Technology
B.2。 インタコネクト技術
In order to ensure network-level interoperability of different
vendor's gateways within the NSFNET context, we specify that a
gateway must at a minimum support Ethernet connections and serial
line protocol connections.
NSFNET文脈の中で異なったベンダーのゲートウェイのネットワークレベル相互運用性を確実にするために、私たちは、ゲートウェイが、最小限でイーサネットが接続とシリアル・ラインプロトコル接続であるとサポートしなければならないと指定します。
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. イーサネットコンパチブルシステムは、共通であり、よりそうになっています。
Braden & Postel [Page 46]
ブレーデンとポステル[46ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
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, optical fiber, or other media may also
be considered.
将来のNSFゲートウェイ要件が他のインタコネクト技術を指定すると予想されます。 最もありそうな候補はX.25かIEEE802に基づくものですが、また、広帯域のケーブル、光ファイバ、または他のメディアを含む他の技術は考えられるかもしれません。
B.3. Routing Interoperability
B.3。 ルート設定相互運用性
The Internet does not currently have an "open IGP" standard, i.e.,
a common IGP which would allow gateways from different vendors to
form a single Autonomous System. Several approaches to routing
interoperability are currently in use among vendors and the NSF
networking community.
インターネットには、現在、「開いているIGP」規格(すなわち、異なったベンダーからのゲートウェイに独身のAutonomous Systemを形成させる一般的なIGP)がありません。 ルーティング相互運用性へのいくつかのアプローチが現在、ベンダーとNSFネットワーク共同体で使用中です。
* Proprietary IGP
* 独占IGP
At least one gateway vendor has implemented a proprietary IGP
and uses EGP to interface to the rest of the Internet.
少なくとも1つのゲートウェイベンダーが、独占IGPと用途がインターネットの残りに連結するEGPであると実装しました。
* RIP
* 裂け目
Although RIP is undocumented and various implementations of it
differ in subtle ways, it has been used successfully for
interoperation among multiple vendors as an IGP.
RIPはそれの正式書類のなくて様々な実装ですが、それとなく異なってください、そして、それはinteroperationにIGPとして複数のベンダーの中で首尾よく使用されました。
* Gateway Daemon
* ゲートウェイデーモン
The NSF networking community has built a "gateway daemon"
program which can mediate among multiple routing protocols to
create a mixed-IGP Autonomous System. In particular, the
prototype gateway daemon executes on a 4.3BSD machine acting as
a gateway and exchanges routing information with other
gateways, speaking both RIP and Hello protocols; in addition,
it supports EGP to other Autonomous Systems.
NSFネットワーク共同体は混ぜられたIGP Autonomous Systemを作成するために複数のルーティング・プロトコルの中で調停されることができる「ゲートウェイデーモン」プログラムを組立てました。 特に、プロトタイプゲートウェイデーモンはゲートウェイとして作動する4.3BSDマシンと交換のときに他のゲートウェイでルーティング情報を実行します、RIPとHelloプロトコルの両方を話して。 さらに、それは他のAutonomous SystemsにEGPをサポートします。
Braden & Postel [Page 47]
ブレーデンとポステル[47ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
B.4. Multi-Protocol Gateways
B.4。 マルチプロトコルゲートウェイ
The present NSF gateway requirements specify only the Internet
protocol IP. However, in a few years the Internet will begin a
gradual transition to the functionally-equivalent subset of the
ISO protocols [17]. In particular, an increasing percentage of
the traffic will use the ISO Connectionless Mode Network Service
(CLNS, but commonly called "ISO IP") [33] in place of IP. It is
expected that the ISO suite will eventually become the dominant
one; however, it is also expected that requirements to support
Internet IP will continue, perhaps indefinitely.
現在のNSFゲートウェイ要件はインターネットプロトコルだけIPを指定します。 しかしながら、数年後に、インターネットはISOプロトコル[17]の機能上同等な部分集合へのゆるやかな変遷を始めるでしょう。 特に、トラフィックの増加する割合はIPに代わってISO Connectionless Mode Network Service(CLNSの、しかし、一般的に「ISO IP」と呼ばれた)[33]を使用するでしょう。 ISOスイートが結局優位なものになると予想されます。 しかしながら、また、インターネットがIPであるとサポートするという要件が続くと恐らく無期限に予想されます。
To support the transition to ISO protocols and the coexistence
stage, it is highly desirable that a gateway design provide for
future extensions to support more than one protocol simultaneous,
and in particular both IP and CLNS [18].
ISOへの変遷がプロトコルと共存ステージであるとサポートするために、ゲートウェイデザインが同時の状態で1つ以上のプロトコルをサポートする今後の拡大、および特に両方IPとCLNS[18]に備えるのは、非常に望ましいです。
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 up through the
application level [16]. 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の間でアプリケーションを織り込むという将来の要件がアプリケーションレベル[16]を通して全く複数のプロトコルにレベルをサポートするゲートウェイを売り出す機会をもたらすかもしれないと認めるべきです。 本書ではまとめられたネットワークレベルNSFゲートウェイ要件がこれらのアプリケーションレベルゲートウェイのための要件ドキュメントに組み込むと予想されます。
Internet gateways function as intermediate systems (IS) with
respect to the ISO connectionless network model and incorporate
defined packet formats, routing algorithms and related procedures
[33, 34]. The ISO ES-IS [37] provides the functions of ARP and
ICMP Redirect.
ISOのコネクションレスなネットワークに関する中間システム(ある)がモデル化して、盛込まれるので、インターネット・ゲートウェイ機能は、アルゴリズムを発送して、パケット・フォーマットを定義して、手順[33、34]を関係づけました。 ISO ES存在、[37]はARPとICMP Redirectの機能を提供します。
B.5. Access Control and Accounting
B.5。 アクセスコントロールと会計
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 subsequent edition of this
document. Vendors are encouraged to plan for the introduction of
these mechanisms into their products. While at this 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:
今回のNSFゲートウェイが特定のアクセスコントロールと会計機構をデザインに組み込むという要件が全くありません。 しかしながら、これらの切迫した課題は、現在、研究であって、このドキュメントのその後の版に組み入れられるでしょう。 ベンダーがそれらの製品の中にこれらのメカニズムの導入の計画を立てるよう奨励されます。 アクセスコントロールと会計のためのどんな決定的な一般的なモデルもこのとき現れていませんが、いくつかの一般的な特徴について概説するために、そのようなモデルがそれらの中に以下を持っていそうであるのは、可能です:
Braden & Postel [Page 48]
ブレーデンとポステル[48ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
1. The primary access control and accounting 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
mechanisms may be necessary in the gateways, 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
cannot be specified in advance.
2. アクセスコントロールと会計機構を代表して行動しているエージェントが、データを集めるか、パスワード保護を実施するか、またはリソース優先権と公正を緩和するのにゲートウェイで必要であるかもしれません。 しかしながら、これらのエージェントによって使用されたアーキテクチャとプロトコルは、地域にかかわる事柄であるかもしれなく、あらかじめ、指定できません。
3. NSF gateways may be required to incorporate access control
and accounting mechanisms based on datagram
source/destination address, as well as other fields in the
IP header.
3. NSFゲートウェイはデータグラムソース/送付先アドレスに基づくアクセスコントロールと会計機構を組み込まなければならないかもしれません、IPヘッダーの他の分野と同様に。
4. NSF gateways may be required to enforce policies on access
to gateway and communication resources. These policies may
be based upon equity ("fairness") or upon inequity
("priority").
4. NSFゲートウェイは方針にゲートウェイへのアクセスとコミュニケーションリソースに押しつけなければならないかもしれません。 これらの方針は公平さ(「公正」)か不公平(「優先権」)に基づくかもしれません。
Braden & Postel [Page 49]
ブレーデンとポステル[49ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
Acknowledgments
承認
An earlier version of this document (RFC-985) [60] was prepared by Dave Mills in behalf of 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. This effort was chaired by Dave Mills, and contributed to by many people.
このドキュメント(RFC-985)[60]の以前のバージョンはNSF Network Technical Advisory GroupのゲートウェイRequirements Subcommitteeのためにデーヴ・ミルズによって準備されました、インターネットActivities Board、インターネットArchitecture Task Force、およびインターネット・エンジニアリング・タスク・フォースと提携して。 この取り組みにデーヴ・ミルズによってまとめられて、多くの人々が貢献しました。
The authors of current document have also received assistance from many people in the NSF and ARPA networking community. We thank you, one and all.
また、現在のドキュメントの作者はNSFとARPAネットワーク共同体の多くの人々から支援を受けました。 だれも、私たちは感謝します。
Braden & Postel [Page 50]
ブレーデンとポステル[50ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
References and Bibliography
参照と図書目録
Many of these references are available from the DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Menlo Park, California 94025 (telephone: 800-235-3155).
これらの参照の多くが333レーヴンズウッドAvenue、メンローパーク、カリフォルニア DDN Networkインフォメーション・センター、SRIインターナショナル、94025(電話: 800-235-3155)から利用可能です。
[1] Postel, J., "Internet Protocol", RFC-791, USC Information
Sciences Institute, September 1981.
[1] ポステル、J.、「インターネットプロトコル」、RFC-791、科学が1981年9月に設けるUSC情報。
[2] Postel, J., "Internet Control Message Protocol", RFC-792, USC
Information Sciences Institute, September 1981.
[2] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、RFC-792、科学が1981年9月に設けるUSC情報。
[3] BBN, "Interface Message Processor - Specifications for the
Interconnection of a Host and an IMP", Report 1822, Bolt
Beranek and Newman, December 1981.
[3] BBN、「メッセージプロセッサを連結してください--ホストと悪童のインタコネクトのための仕様」と、1822、ボルトBeranekとニューマン、12月1981日は報告します。
[4] Plummer, D., "An Ethernet Address Resolution Protocol",
RFC-826, Symbolics, September 1982.
[4] プラマー、D.、「イーサネットアドレス解決プロトコル」、RFC-826、信条学、1982年9月。
[5] DOD, "Military Standard Internet Protocol", Military Standard
MIL-STD-1777, United States Department of Defense, August 1983.
[5]DOD、「軍事の標準のインターネットプロトコル」、軍事の標準の軍規格-1777、合衆国国防総省、1983年8月。
[6] BBN, "Defense Data Network X.25 Host Interface Specification",
Report 5476, Bolt Beranek and Newman, December 1983.
[6] BBN(「ディフェンスデータ網X.25ホストインターフェース仕様」、レポート5476)はBeranekとニューマン、1983年12月をボルトで締めます。
[7] Hinden, R., "A Host Monitoring Protocol", RFC-869, BBN
Communications, December 1983.
[7]Hinden、R.、「ホストのモニターしているプロトコル」、RFC-869、BBNコミュニケーション、1983年12月。
[8] Korb, J.T., "A Standard for the Transmission of IP Datagrams
over Public Data Networks", RFC-877, Purdue University,
September 1983.
[8]コルプ、J.T.、「公衆データネットワークの上のIPデータグラムの送信の規格」、RFC-877、パデュー大学、1983年9月。
[9] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC-896, Ford Aerospace, January 1984.
[9] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC-896、フォードAerospace、1984年1月。
[10] Hornig, C., "A Standard for the Transmission of IP Datagrams
over Ethernet Networks", RFC-894, Symbolics, April 1984.
[10] ホーニッグ、C.、「イーサネットネットワークの上のIPデータグラムの送信の規格」、RFC-894、信条学、1984年4月。
[11] Mills, D.L., "Exterior Gateway Formal Specification", RFC-904,
M/A-COM Linkabit, April 1984.
[11]工場、D.L.、「外のゲートウェイ形式仕様」、RFC-904、M1COM Linkabitの/1984年4月。
[12] Xerox, "Xerox Synchronous Point-to-Point Protocol", Xerox
System Integration Standard 158412, December 1984.
[12]ゼロックス、「ゼロックスの同期二地点間プロトコル」、ゼロックスシステムインテグレーション規格158412、1984年12月。
[13] Kirton, P., "EGP Gateway under Berkeley UNIX 4.2", RFC-911, USC
Information Sciences Institute, August 1984.
[13] カートン、P.、「バークレーUNIXの下におけるEGPゲートウェイ、4.2インチ、USC情報科学が1984インチ年8月に設けるRFC-911。
Braden & Postel [Page 51]
ブレーデンとポステル[51ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
[14] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC
Information Sciences Institute, October 1984.
[14] ポステル、J.、「マルチLANアドレス解決」、RFC-925、科学が1984年10月に設けるUSC情報。
[15] Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A Reverse
Address Resolution Protocol", RFC-904, Stanford University,
June 1984.
[15] フィンリースンとR.とT.マン、J.ムガール人とM.Theimer、「逆アドレス解決プロトコル」RFC-904、スタンフォード大学、1984年6月。
[16] NRC, "Transport Protocols for Department of Defense Data
Networks", RFC-942, National Research Council, March 1985.
[16] NRC、「国防総省データ網のためのトランスポート・プロトコル」、RFC-942、調査評議会、1985年3月。
[17] Postel, J., "DOD Statement on NRC Report", RFC-945, USC
Information Sciences Institute, April 1985.
[17] ポステル、J.、「NRCレポートに関するDOD声明」、RFC-945、科学が1985年4月に設けるUSC情報。
[18] ISO, "Addendum to the Network Service Definition Covering
Network Layer Addressing", RFC-941, International Standards
Organization, April 1985.
[18] ISO、「ネットワーク・サービス定義へのネットワーク層アドレシングをカバーする付加物」、RFC-941、世界規格組織、1985年4月。
[19] Leiner, B., J. Postel, R. Cole and D. Mills, "The DARPA
Internet Protocol Suite", Proceedings INFOCOM 85, IEEE,
Washington DC, March 1985. Also in: IEEE Communications
Magazine, March 1985. Also available as ISI-RS-85-153.
[19]LeinerとB.とJ.ポステルとR.コールとD.工場、「DARPAインターネットプロトコル群」、議事INFOCOM85、IEEE、ワシントンD.C.、1985年3月。 以下でも 1985年3月のIEEEコミュニケーション雑誌。 また、ISI-RS-85-153として、利用可能です。
[20] Romkey, J., "PC/IP Programmer's Manual", MIT Laboratory for
Computer Science, pp. 57-59, April 1986.
[20]Romkey、J.、「PC/IPプログラマのマニュアル」、MITコンピュータサイエンス研究所、ページ 57-59と、1986年4月。
[21] Mogul, J., and J. Postel, "Internet Standard Subnetting
Procedure", RFC-950, Stanford University, August 1985.
[21] ムガール人、J.とJ.ポステル、「インターネットの標準のサブネッティング手順」、RFC-950、スタンフォード大学、1985年8月。
[22] Reynolds, J., and J. Postel, "Official Internet Protocols",
RFC-1011, USC Information Sciences Institute, May 1987.
[22] USC情報科学が1987年5月に設けるレイノルズ、J.とJ.ポステル、「公式のインターネットプロトコル」、RFC-1011。
[23] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1010, USC
Information Sciences Institute, May 1987.
[23] USC情報科学が設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC-1010は1987がそうするかもしれません。
[24] Nagle, J., "On Packet Switches with Infinite Storage", RFC-970,
Ford Aerospace, December 1985.
[24] ネーグル、「無限の格納があるパケット交換機」のJ.RFC-970、フォードAerospace、1985年12月。
[25] SRI, "DDN Protocol Handbook", NIC-50004, NIC-50005, NIC-50006,
(three volumes), SRI International, December 1985.
[25]SRI、「DDNプロトコルハンドブック」、NIC-50004、NIC-50005、NIC-50006、(3本のボリューム)、SRIインターナショナル、1985年12月。
[26] SRI, "ARPANET Information Brochure", NIC-50003, SRI
International, December 1985.
[26]様、「アルパネット情報小冊子」、NIC-50003、SRIインターナショナル、1985年12月。
[27] Mills, D.L., "Autonomous Confederations", RFC-975, M/A-COM
Linkabit, February 1986.
[27]工場、D.L.、RFC-975、M1COM Linkabitの/1986年2月の「自動同盟者。」
[28] Jacobsen, O., and J. Postel, "Protocol Document Order
Information", RFC-980, SRI International, March 1986.
[28] ジェイコブセン、O.とJ.ポステル、「プロトコルドキュメントオーダー情報」、RFC-980、SRIインターナショナル、1986年3月。
Braden & Postel [Page 52]
ブレーデンとポステル[52ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
[29] Malis, A.G., "PSN End-to-End Functional Specification",
RFC-979, BBN Communications, March 1986.
[29]Malis、A.G.、「PSN終わりから終わりへの機能的な仕様」、RFC-979、BBNコミュニケーション、1986年3月。
[30] Postel, J, "Internetwork Applications using the DARPA Protocol
Suite", Proceedings INFOCOM 85, IEEE, Washington DC,
March 1985. Also available as ISI-RS-85-151.
[30] ポステル、J、「DARPAプロトコル群を使用するインターネットワークアプリケーション」、議事INFOCOM85、IEEE、ワシントンD.C.、1985年3月。 また、ISI-RS-85-151として、利用可能です。
[31] Postel, J, C. Sunshine, and D. Cohen, "The ARPA Internet
Protocol", Computer Networks, Vol. 5, No. 4, July 1981.
[31] ポステルとJ、C.日光とD.コーエン、「アルパインターネットプロトコル」コンピュータネットワーク、Vol.5、No.4、1981年7月。
[32] Cerf, V., and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Transactions on Communication,
May 1974.
[32] サーフ、V.、およびR.カーン、「パケット網相互通信のためのプロトコル」、コミュニケーションにおけるIEEE取引は1974がそうするかもしれません。
[33] ISO, "Protocol for Providing the Connectionless-mode Network
Service", RFC-994, DIS-8473, International Standards
Organization, March 1986.
[33] ISO、「コネクションレスなモードネットワーク・サービスを提供するためのプロトコル」、RFC-994、不--8473、世界規格組織、1986年3月。
[34] ANSI, "Draft Network Layer Routing Architecture", ANSI X3S3.3,
86-215R, April 1987.
[34]ANSI、「草稿ネットワーク層ルート設定構造」、ANSI X3S3.3、86-215R、1987年4月。
[35] Rosen, E., "Exterior Gateway Protocol (EGP)", RFC-827, Bolt
Beranek and Newman, October 1982.
[35] ローゼンとE.と「外のゲートウェイプロトコル(EGP)」とRFC-827とボルトBeranekとニューマン、1982年10月。
[36] Sidhu, D., "Some Problems with the Specification of the
Military Standard Internet Protocol", RFC-963, Iowa State
University, November 1985.
[36]Sidhu、D.、「軍事の標準のインターネットプロトコルの仕様に関するいくつかの問題」、RFC-963、アイオワ州立大学、1985年11月。
[37] ISO, "End System to Intermediate System Routing Exchange
Protocol for use in conjunction with ISO 8473", RFC-995,
April 1986.
1986年4月の[37]ISO、「ISO8473に関連した使用のためのIntermediate Systemルート設定Exchangeプロトコルへの終わりのSystem」RFC-995。
[38] Postel, J., "Address Mappings", RFC-796, USC/Information
Sciences Institute, September 1981.
[38] ポステル、J.、「アドレス・マッピング」、USC/情報科学が1981年9月に設けるRFC-796。
[39] Mills, D., "DCN Local Network Protocols", RFC-891, M/A-COM
Linkabit, December 1983.
[39] 工場、D.、「DCN企業内情報通信網プロトコル」、RFC-891、M1COM Linkabitの/1983年12月。
[40] McQuillan, J. M., I. Richer, and E. C. Rosen, "The New Routing
Algorithm for the ARPANET", IEEE Transactions on
Communications, May 1980.
[40] マッキラン(J.M.、I.リシェ、およびE.C.ローゼン、「アルパネットのための新しいルーティング・アルゴリズム」、コミュニケーションにおけるIEEE取引)は、1980がそうするかもしれません。
[41] Hinden, R., and A. Sheltzer, "The DARPA Internet Gateway",
RFC-823, Bolt Beranek and Newman, September 1982.
[41] Hinden、R.、およびA.Sheltzer、「DARPAインターネットゲートウェイ」、RFC-823はBeranekとニューマン、1982年9月をボルトで締めます。
[42] Farber, D., G. Delp, and T. Conte, "A Thinwire Protocol for
Connecting Personal Computers to the Internet", RFC-914,
University of Delaware, September 1984.
[42] ファーバー、D.、G.デルプ、およびT.コンテ、「パーソナルコンピュータをインターネットに接続するためのThinwireプロトコル」、RFC-914、デラウエア大学(1984年9月)。
Braden & Postel [Page 53]
ブレーデンとポステル[53ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
[43] Mills, D., "Statistics Server", RFC-996, University Of
Delaware, February 1987.
[43] 工場、D.、「統計サーバ」、RFC-996、デラウェア大学、1987年2月。
[44] Postel, J. and K. Harrenstien, "Time Protocol", RFC-868,
May 1983.
[44] ポステル、J.、およびK.Harrenstien(「時間プロトコル」、RFC-868)は1983がそうするかもしれません。
[45] Mills, D., "Network Time Protocol (NTP)", RFC-958, M/A-Com
Linkabit, September 1985.
[45] 工場、D.、「ネットワーク時間プロトコル(NTP)」、RFC-958、M1Com Linkabitの/1985年9月。
[46] Seamonson, L., and E. Rosen, "Stub Exterior Gateway Protocol",
RFC-888, Bolt Beranek And Newman, January 1984.
[46] Seamonson、L.、およびE.ローゼン、「スタッブの外のゲートウェイプロトコル」、RFC-888はBeranekとニューマン、1984年1月をボルトで締めます。
[47] Deering, S., and D. Cheriton, "Host Groups: A Multicast
Extension to the Internet Protocol", RFC-966, Stanford
University, December 1985.
[47] デアリング、S.、およびD.Cheriton、「グループをホスティングしてください」 「インターネットプロトコルへのマルチキャスト拡大」、RFC-966、スタンフォード大学、1985年12月。
[48] Deering, S., "Host Extensions for IP Multicasting", RFC-988,
Stanford University, July 1986.
[48] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、RFC-988、スタンフォード大学、1986年7月。
[49] Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Stanford
University, October 1984.
[49] ムガール人、J.、「放送インターネットデータグラム」、RFC-919、スタンフォード大学、1984年10月。
[50] Mogul, J., "Broadcasting Internet Datagrams in the Presence of
Subnets", RFC-922, Stanford University, October 1984.
[50] ムガール人、J.、「サブネットがあるとき放送インターネットデータグラム」、RFC-922、スタンフォード大学、1984年10月。
[51] Rosen, E., "Exterior Gateway Protocol", RFC-827, Bolt Beranek
and Newman, October 1982.
[51] ローゼンとE.と「外のゲートウェイプロトコル」とRFC-827とボルトBeranekとニューマン、1982年10月。
[52] Rose, M., "Low Tech Connection into the ARPA Internet: The Raw
Packet Split Gateway", Technical Report 216, Department of
Information and Computer Science, University of California,
Irvine, February 1984.
[52] ローズ、M.、「アルパインターネットとの低い科学技術の接続:」 「生のパケット分裂ゲートウェイ」、技術報告書216、情報とコンピュータサイエンスの部、カリフォルニア大学アーバイン校、1984年2月。
[53] Rosen, E., "Issues in Buffer Management", IEN-182, Bolt Beranek
and Newman, May 1981.
ローゼン(E.)が「バッファ管理では発行する」[53]、IEN-182、ボルトBeranek、およびニューマンは1981がそうするかもしれません。
[54] Rosen, E., "Logical Addressing", IEN-183, Bolt Beranek and
Newman, May 1981.
[54] ローゼン(E.、「論理的なアドレシング」、IEN-183、ボルトBeranek、およびニューマン)は、1981がそうするかもしれません。
[55] Rosen, E., "Issues in Internetting - Part 1: Modelling the
Internet", IEN-184, Bolt Beranek and Newman, May 1981.
[55] ローゼン、E.、「Internettingの問題--、第1部:、」 「インターネットをモデル化し」て、IEN-184(ボルトBeranekとニューマン)は1981をモデル化します。
[56] Rosen, E., "Issues in Internetting - Part 2: Accessing the
Internet", IEN-187, Bolt Beranek and Newman, June 1981.
[56] ローゼン、E.、「Internettingの問題--、第2部:、」 「インターネットにアクセスします」、IEN-187はBeranekとニューマン、1981年6月をボルトで締めます。
[57] Rosen, E., "Issues in Internetting - Part 3: Addressing",
IEN-188, Bolt Beranek and Newman, June 1981.
[57] ローゼン、E.、「Internettingの問題--3を分けてください」 「アドレシング」、IEN-188はBeranekとニューマン、1981年6月をボルトで締めます。
Braden & Postel [Page 54]
ブレーデンとポステル[54ページ]
RFC 1009 - Requirements for Internet Gateways June 1987
RFC1009--インターネットゲートウェイ1987年6月のための要件
[58] Rosen, E., "Issues in Internetting - Part 4: Routing", IEN-189,
Bolt Beranek and Newman, June 1981.
[58] ローゼン、E.、「Internettingの問題--4を分けてください」 「ルート設定」、IEN-189はBeranekとニューマン、1981年6月をボルトで締めます。
[59] Sunshine, C., "Comments on Rosen's Memos", IEN-191, USC
Information Sciences Institute, July 1981.
日光(C.)が「ローゼンのメモに関してコメントする」[59]、IEN-191、科学が1981年7月に設けるUSC情報。
[60] NTAG, "Requirements for Internet Gateways -- Draft", RFC-985,
Network Technical Advisory Group, National Science Foundation,
May 1986.
[60] NTAG、「インターネットゲートウェイのための要件--、草稿、」、RFC-985、ネットワークの技術的な顧問団、科学基金、5月1986
[61] Khanna, A., and Malis, A., "The ARPANET AHIP-E Host Access
Protocol (Enhanced AHIP)", RFC-1005, BBN Communications,
May 1987
[61] Khanna、A.とMalis、A.、「アルパネットAHIP-Eホストアクセス・プロトコル(AHIPを高める)」RFC-1005、BBNコミュニケーション、1987年5月
[62] Nagle, J., "Congestion Control in IP/TCP Internetworks", ACM
Computer Communications Review, Vol.14, no.4, October 1984.
[62] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、ACMコンピュータCommunications Review、Vol.14、no.4、1984年10月。
Braden & Postel [Page 55]
ブレーデンとポステル[55ページ]
一覧
スポンサーリンク
