この文書はRFC 801の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group J. Postel
Request for Comments: 801 ISI
November 1981
NCP/TCP TRANSITION PLAN
ＮＣＰ／ＴＣＰ移行計画
Introduction
はじめに
------------
ARPA sponsored research on computer networks led to the development
of the ARPANET. The installation of the ARPANET began in September
1969, and regular operational use was underway by 1971. The ARPANET
has been an operational service for at least 10 years. Even while it
has provided a reliable service in support of a variety of computer
research activities, it has itself been a subject of continuing
research, and has evolved significantly during that time.
ＡＲＰＡが資金援助するコンピュータ・ネットワークの研究がARPANETの開
発を導きました。ARPANETの導入は１９６９年９月に始まりました、そして
通常運用は１９７１年までに進行しました。ARPANETは少なくとも（今まで）
１０年間使用可能なサービスでした。これはいろいろなコンピュータ研究
活動を支援し、信頼性が高いサービスを提供していましたが、（今まで）
これ自身が継続している研究課題であり、この間に際立って進展しました。
In the past several years ARPA has sponsored additional research on
computer networks, principally networks based on different underlying
communication techniques, in particular, digital packet broadcast
radio and satellite networks. Also, in the ARPA community there has
been significant work on local networks.
ＡＲＰＡがこれまでの数年に、主に異なる基礎の通信技術に基づくコンピュー
タ・ネットワークの追加の研究、特にデジタルパケット広帯域無線と人工衛
星がネットワークを後援しました。また、ＡＲＰＡ共同体はローカルネット
ワーク上で重要な仕事がありました。
It was clear from the start of this research on other networks that
the base host-to-host protocol used in the ARPANET was inadequate for
use in these networks. In 1973 work was initiated on a host-to-host
protocol for use across all these networks. The result of this long
effort is the Internet Protocol (IP) and the Transmission Control
Protocol (TCP).
他のネットワーク上でのこの研究の開始時点で、ARPANETで使われたホスト
対ホストに基づくプロトコルが、これらのネットワークで使用するのに不十
分であることは明確でした。１９７３年の仕事は、これらすべてのネット
ワークを越えたホスト対ホストプロトコルの使用から始められました。こ
の長い努力の結果はインターネット・プロトコル（ＩＰ）そして伝送制御
プロトコル（ＴＣＰ）です。
These protocols allow all hosts in the interconnected set of these
networks to share a common interprocess communication environment.
The collection of interconnected networks is called the ARPA Internet
(sometimes called the "Catenet").
これらのプロトコルはこれらのネットワークで相互接続したすべてのホス
トが共通のプロセス間通信環境を共有することを可能にします。相互接続
ネットワークの集団はＡＲＰＡインターネットと呼ばれます（時々「カテ
ネット」と呼ばれます）。
The Department of Defense has recently adopted the internet concept
and the IP and TCP protocols in particular as DoD wide standards for
all DoD packet networks, and will be transitioning to this
architecture over the next several years. All new DoD packet
networks will be using these protocols exclusively.
国防省は最近すべてのＤｏＤパケットネットワークのＤｏＤ広域標準として
特にインターネットの概念とＩＰとＴＣＰプロトコルを採択しました、そし
て今後数年にわたってこの体系に移行するでしょう。すべての新しいＤｏＤ
パケットネットワークはもっぱらこれらのプロトコルを使うでしょう。
The time has come to put these protocols into use in the operational
ARPANET, and extend the logical connectivity of the ARPANET hosts to
include hosts in other networks participating in the ARPA Internet.
運用中のARPANETでこれらのプロトコルを使用中にし、ARPANETホストと他の
ネットワークのホストの論理的な接続性をＡＲＰＡインターネットに拡張す
る時は来ました。
As with all new systems, there will be some aspects which are not as
robust and efficient as we would like (just as with the initial
ARPANET). But with your help, these problems can be solved and we
can move into an environment with significantly broader communication
services.
すべての新しいシステム同様に、（初期のARPANET同じように）我々が欲し
いほど強靭でなく、効率的でもないいくつかの局面があるでしょう。けれど
もあなたの援助で、これらの問題は解決されるできます、そして我々はより
広範囲の通信サービス環境に引っ越すことができます。
Discussion
論議
----------
The implementation of IP/TCP on several hosts has already been
completed, and the use of some services is underway. It is urgent
that the implementation of of IP/TCP be begun on all other ARPANET
hosts as soon as possible and no later than 1 January 1982 in any
case. Any new host connected to the ARPANET should only implement
IP/TCP and TCP-based services. Several important implementation
issues are discussed in the last section of this memo.
いくつかのホストでＩＰ／ＴＣＰの実装はすでに完了しました、そしてい
くつかのサービスの使用ができます。すべてのARPANETホストで何が何で
も緊急に１９８２年１月１日に遅れないようにＩＰ／ＴＣＰの実装を開始
するべきです。ARPANETに接続した新しいホストはＩＰ／ＴＣＰとＴＣＰ
に基づくサービスを実装するだけであるべきです。いくつかの重要な実装
問題がこの文書の最後の章で論じられます。
Because all hosts can not be converted to TCP simultaneously, and
some will implement only IP/TCP, it will be necessary to provide
temporarily for communication between NCP-only hosts and TCP-only
hosts. To do this certain hosts which implement both NCP and IP/TCP
will be designated as relay hosts. These relay hosts will support
Telnet, FTP, and Mail services on both NCP and TCP. These relay
services will be provided beginning in November 1981, and will be
fully in place in January 1982.
すべてのホストが同時にＴＣＰに変換できず、そして一部がＩＰ／ＴＣＰ
だけを実装するから、ＮＣＰのみのホストとＴＣＰのみのホスト間に一時
的に通信を提供する必要があるでしょう。これをするために、ＮＣＰと
ＩＰ／ＴＣＰの両方を実装する特定のホストがリレーホストに指名される
でしょう。これらのリレーホストはＮＣＰとＴＣＰの両方でＴｅｌｎｅｔ
とＦＴＰとメールサービスをサポートするでしょう。これらのリレーサー
ビスは１９８１年１１月から供給が始まり、１９８２年１月から完全に実
施されるでしょう。
Initially there will be many NCP-only hosts and a few TCP-only hosts,
and the load on the relay hosts will be relatively light. As time
goes by, and the conversion progresses, there will be more TCP
capable hosts, and fewer NCP-only hosts, plus new TCP-only hosts.
But, presumably most hosts that are now NCP-only will implement
IP/TCP in addition to their NCP and become "dual protocol" hosts.
So, while the load on the relay hosts will rise, it will not be a
substantial portion of the total traffic.
当初は多くのＮＣＰのみのホストと少数のＴＣＰのみのホストがあるで
しょう、そしてリレーホストの負荷は比較的軽いでしょう。時が経過し、
変更が進行すると、多くのＴＣＰ対応ホストと少ないＮＣＰのみのホスト
に加えて新しいＴＣＰのみのホストが存在するでしょう。しかし、多分、
現在の多くのＮＣＰのみのホストがＮＣＰ以外にＩＰ／ＴＣＰを実装し、
「二重プロトコル」ホストになるでしょう。それでリレーホストの負荷は
上昇するでしょうが、全体のトラフィックの主要部分ではないでしょう。
The next section expands on this plan, and the following section
gives some milestones in the transition process. The last section
lists the key documents describing the new protocols and services.
Appendices present scenarios for use of the relay services.
次の章はこの計画を詳細に述べます、そして続く章は移行手順のいくつか
のマイルストーンを与えます。最後の章は新しいプロトコルとサービスを
記述している重要文書のリストを書きます。付録がリレーサービスを使用
するシナリオを提出します。
The General Plan
一般的な計画
----------------
The goal is to make a complete switch over from the NCP to IP/TCP by
1 January 1983.
目標は１９８３年１月１日までにＮＣＰからＩＰ／ＴＣＰへ完全な切替を実施
することです。
It is the task of each host organization to implement IP/TCP for
its own hosts. This implementation task must begin by
1 January 1982.
ホストのＩＰ／ＴＣＰの実装はそれぞれのホストの組織の仕事です。この
実装の仕事は１９８２年１月１日から始まらなくてはなりません。
IP:
This is specified in RFCs 791 and 792. Implementations exist
for several machines and operating systems. (See Appendix D.)
これは７９１と７９２のＲＦＣで指定されます。いくつかのマシンと
オペレーティング・システムの実装が存在します。（付録Ｄを見て
ください。）
TCP:
This is specified in RFC793. Implementations exist for several
machines and operating systems. (See Appendix D.)
これはRFC793で指定されます。いくつかのマシンとオペレーティング・
システムの実装が存在します。（付録Ｄを見てください。）
It is not enough to implement the IP/TCP protocols, the principal
services must be available on this IP/TCP base as well. The
principal services are: Telnet, File Transfer, and Mail.
ＩＰ／ＴＣＰプロトコルの実装だけでは十分ではありません、同様にこの
ＩＰ／ＴＣＰベース上で主要サービスが利用可能に違いありません。主要
サービスは以下です：Ｔｅｌｎｅｔ、ファイル転送、メール。
It is the task of each host organization to implement the
principal services for its own hosts. These implementation tasks
must begin by 1 January 1982.
ホストに主要サービスを実装することはそれぞれのホスト組織の仕事
です。これらの実装仕事は１９８２年１月１日までに始まらなくては
なりません。
Telnet:
This is specified in RFC 764. It is very similar to the Telnet
used with the NCP. The primary differences are that the ICP is
eliminated, and the NCP Interrupt is replaced with the TCP
Urgent.
これはＲＦＣ７６４で指定されます。それはＮＣＰで使われた
Ｔｅｌｎｅｔに非常に類似しています。主な相違はＩＣＰが削除
され、ＮＣＰ割り込みがＴＣＰが緊急で、置き換えられることです。
FTP:
This is specified in RFC 765. It is very similar to the FTP
used with the NCP. The primary differences are that in
addition to the changes for Telnet, that the data channel is
limited to 8-bit bytes so FTP features to use other
transmission byte sizes are eliminated.
これはＲＦＣ７６５で指定されます。これはＮＣＰで使われた
ＦＴＰに非常に類似しています。主な相違は、Ｔｅｌｎｅｔの
変更と、データチャネルが８ビットのバイトに限定され、他の送信
バイトサイズを使うＦＴＰ機能が削除される事です。
Mail:
This is specified in RFC 788. Mail is separated completely
from FTP and handled by a distinct server. The procedure is
similar in concept to the old FTP/NCP mail procedure, but is
very different in detail, and supports additional functions --
especially mail relaying, and multi-recipient delivery.
これはＲＦＣ７８８で指定されます。メールが完全にＦＴＰから
分離され、別のサーバーによって処理されます。手順は概念的に
古いＦＴＰ／ＮＣＰメール手順に類似していますが、詳細は非常に
異なり、そして追加の機能−特にメール中継と、複数受取人への
配達−をサポートします。
Beyond providing the principal services in the new environment, there
must be provision for interworking between the new environment and
the old environment between now and January 1983.
新しい環境で主要サービスを提供する過程で、現在と１９８３年１月の間、
新しい環境と古い環境の間を相互接続するための準備があるに違いありませ
ん。
For Telnet, there will be provided one or more relay hosts. A
Telnet relay host will implement both the NCP and TCP environments
and both user and server Telnet in both environments. Users
requiring Telnet service between hosts in different environments
will first connect to a Telnet relay host and then connect to the
destination host. (See Appendix A.)
Ｔｅｌｎｅｔでは１つ以上のホストが中継をするでしょう。Ｔｅｌｎｅｔ
中継ホストはＮＣＰとＴＣＰの両方の環境でユーザとサーバの両方の
Ｔｅｌｎｅｔを実装するでしょう。異なる環境のホスト間のＴｅｌｎｅｔ
サービスを必要としているユーザが最初にＴｅｌｎｅｔ中継ホストに接続
し、次に宛先ホストに接続するでしょう。（付録Ａ参照。）
For FTP, there will be provided one or more relay hosts. An FTP
relay host will implement both the NCP and TCP environments, both
user and server Telnet, and both user and server FTP in both
environments. Users requiring FTP service between hosts in
different environments will first connect via Telnet to an FTP
relay host, then use FTP to move the file from the file donor host
to the FTP relay host, and finally use FTP to move the file from
the FTP relay host to the file acceptor host. (See Appendix B.)
ＦＴＰで、１つ以上の中継ホストがあるでしょう。ＦＴＰ中継ホストが
ＮＣＰとＴＣＰの両方の環境で、ユーザとサーバの両方のＴｅｌｎｅｔと
ユーザとサーバの両方のＦＴＰを実装するでしょう。異なる環境のホスト
の間でＦＴＰサービスを必要としているユーザが最初にＴｅｌｎｅｔに
よってＦＴＰリレーホストに接続し、それからファイルの寄贈者ホスト
からＦＴＰ中継ホストにファイルを動かすためにＦＴＰ使い、そして
最後にＦＴＰ中継ホストからファイル引受ホストにファイルを動かす
ためにＦＴＰ使うでしょう。（付録Ｂを見てください。）
For Mail, hosts will implement the new Simple Mail Transfer
Protocol (SMTP) described in RFC 788. The SMTP procedure provides
for relaying mail among several protocol environments. For
TCP-only hosts, using SMTP will be sufficient. For NCP-only hosts
that have not been modified to use SMTP, the special syntax
"user.host@forwarder" may be used to relay mail via one or more
special forwarding host. Several mail relay hosts will relay mail
via SMTP procedures between the NCP and TCP environments, and at
least one special forwarding host will be provided. (See
Appendix C.)
メールでは、ホストがＲＦＣ７８８で記述された新しいシンプルメール
転送プロトコル（ＳＭＴＰ）を実装するでしょう。いくつかのプロトコル
環境間でメールを中継をＳＭＴＰ手順は供給します。ＴＣＰのみのホスト
はＳＭＴＰを使えば十分でしょう。ＳＭＴＰを使うように修正されていな
いＮＣＰのみのホストは、特別な転送ホストでメールを中継するために、
特別な構文「user.host@forwarder」を使うかもしれません。いくつかの
メールリレーホストはＮＣＰとＴＣＰ環境の間でＳＭＴＰ手順によって
メールを中継するでしょう、そして少なくとも１つの特別な転送ホストが
提供されるでしょう。（付録Ｃを見てください。）
Milestones
マイルストーン
----------
First Internet Service already
最初のインターネットサービス 完了
A few hosts are TCP-capable and use TCP-based services.
少数のホストがＴＣＰ対応であり、ＴＣＰベースのサービスを使います。
First TCP-only Host already
最初のＴＣＰのみのホスト 完了
The first TCP-only host begins use of TCP-based services.
最初のＴＣＰのみのホストはＴＣＰベースのサービスの使用を始めます。
Telnet and FTP Relay Service already
ＴｅｌｎｅｔとＦＴＰ中継サービス 完了
Special relay accounts are available to qualified users with a
demonstrated need for the Telnet or FTP relay service.
ＴｅｌｎｎｅｔあるいはＦＴＰ中継サービスの実行に必要な特別な
中継アカウントは、資格を持つユーザに入手可能です。
Ad Hoc Mail Relay Service already
特別なメール中継サービス 完了
An ad hoc mail relay service using the prototype MTP (RFC 780) is
implemented and mail is relayed from the TCP-only hosts to
NCP-only hosts, but not vice versa. This service will be replaced
by the SMTP service.
原型ＭＴＰ（ＲＦＣ７８０）を使う特別なメール中継サービスが実装
されています、そしてメールが、ＴＣＰのみのホストからＮＣＰのみ
のホストまで中継されますが、逆はそうではありません。このサービ
スはＳＭＴＰサービスで置き換えられるでしょう。
Last NCP Conversion Begins Jan 82
ＮＣＰ変更の開始の最後 １９８２年１月
The last NCP-only host begins conversion to TCP.
最後のＮＣＰのみのホストがＴＣＰへの変更を始めます。
Mail Relay Service Jan 82
メール中継サービス １９８２年１月
The SMTP (RFC 788) mail service begins to operate and at least one
mail relay host is operational, and at least one special forwarder
is operational to provide NCP-only host to TCP-only host mail
connectivity.
ＳＭＴＰ（ＲＦＣ７８８）メールサービスが稼働し始めます、そして
少なくとも１つのメール中継ホストが動作します、そして少なくとも
１つの特別な転送者がＮＣＰのみのホストからＴＣＰのみのホストへ
のメール接続性の提供のために動作します。
Normal Internet Service Jul 82
通常のインターネットサービス １９８２年７月
Most hosts are TCP-capable and use TCP-based services.
たいていのホストがＴＣＰ対応になり、ＴＣＰベースのサービスを使
います。
Last NCP Conversion Completed Nov 82
最後のＮＣＰの変更完了 １９８２年１１月
The last NCP-only host completes conversion to TCP.
最後のＮＣＰのみのホストがＴＣＰへの変更を完了します。
Full Internet Service Jan 83
完全インターネットサービス １９８３年１月
All hosts are TCP-capable and use TCP-based services. NCP is
removed from service, relay services end, all services are
TCP-based.
すべてのホストはＴＣＰ対応となり、ＴＣＰベースのサービスを使い
ます。ＮＣＰはサービスを中止し、中継サービスが終わります、すべて
のサービスはＴＣＰベースです。
Documents
文書
---------
The following RFCs document the protocols to be implemented in the
new IP/TCP environment:
次のＲＦＣは新しいＩＰ / ＴＣＰ環境に実装されるべきプロトコルを
記述します：
IP RFC 791
ICMP RFC 792
TCP RFC 793
Telnet RFC 764
FTP RFC 765
SMTP RFC 788
Name Server IEN 116
Assigned Numbers RFC 790
These and associated documents are to be published in a notebook, and
other information useful to implementers is to be gathered. These
documents will be made available on the following schedule:
これらと関連づけられた文書はノートブックで公布されるはずです、そして
実装に有用な他の情報が集められるはずです。これらの文書は次のスケ
ジュールで提供されるでしょう：
Internet Protocol Handbook Jan 82
インターネット・プロトコルハンドブック １９８２年１月
Implementers Hints Jan 82
実装助言 １９８２年１月
SDC IP/TCP Specifications Jan 82
ＳＤＣ ＩＰ／ＴＣＰ仕様 １９８２年１月
Expanded Host Table Jan 82
拡張ホストテーブル １９８２年１月
Implementation Issues
実装問題
---------------------
There are several implementation issues that need attention, and
there are some associated facilities with these protocols that are
not necessarily obvious. Some of these may need to be upgraded or
redesigned to work with the new protocols.
注意を必要とするいくつかの実装問題があります、そして必ずしも明白で
ないこれらのプロトコルにいくらか関連した機能があります。これらの
いくつかは新しいプロトコルで作動するために更新されるか変更される
必要があるかもしれません。
Name Tables
名前テーブル
Most hosts have a table for converting character string names of
hosts to numeric addresses. There are two effects of this
transition that may impact a host's table of host names: (1) there
will be many more names, and (2) there may be a need to note the
protocol capability of each host (SMTP/TCP, SMTP/NCP, FTP/NCP,
etc.).
たいていのホストがホストの文字列名を数値アドレスに変換する表を
持っています。ホストの持つホスト名テーブルに影響を与えるかもし
れない、この移行の２つの効果があります：（１）もっとずっと多く
の名前があるでしょう、そして（２）それぞれのホストのプロトコル
能力（ＳＭＴＰ／ＴＣＰ、ＳＭＴＰ／ＮＣＰ、ＦＴＰ／ＮＣＰなど）
に注意を払う必要があるかもしれません。
Some hosts have kept this table in the operating system address
space to provide for fast translation using a system call. This
may not be practical in the future.
あるホストは、システムコールを使う素早い翻訳に提供するため、
このテーブルをオペレーティング・システムのアドレス空間に置き
ました。これは将来実用的ではないかもしれません。
There may be applications that could take alternate actions if
they could easily determine if a remote host supported a
particular protocol. It might be useful to extend host name
tables to note which protocols are supported.
もし容易に遠隔のホストが特定のプロトコルをサポートしたかどうか
決定することができたなら、代わりの行動をとることができるアプリ
ケーションがあるかもしれません。どのプロトコルがサポートされる
か知るためにホスト名テーブルを拡張することは有用であるかもしれ
ません。
It might be necessary for the host name table to contain names of
hosts reachable only via relays if this name table is used to
verify the spelling of host names in application programs such as
mail composition programs.
メールプログラムのようなアプリケーションプログラムで、ホスト名を
確認することのホスト名テーブルを使うなら、中継によって到達可能な
ホストの名前も含むように必要であるかもしれません。
It might be advantageous to do away with the host name table and
use a Name Server instead, or to keep a relatively small table as
a cache of recently used host names.
ホスト名テーブルを廃止して、そしてその代わりにネームサーバを使う
ことか、あるいは比較的小さいテーブルを最近使われたホスト名の
キャッシュとして保持することが有利であるかもしれません。
A format, distribution, and update procedure for the expanded host
table will be published soon.
拡張されたホストテーブルのためのフォーマットと配布と更新手続きが
まもなく発表されるでしょう。
Mail Programs
メールプログラム
It may be possible to move to the new SMTP mail procedures by
changing only the mailer-daemon and implementing the SMTP-server,
but in some hosts there may be a need to make some small changes
to some or all of the mail composition programs.
メーラー・デーモンだけを変え、ＳＭＴＰサーバを実装することで、
新しいＳＭＴＰメール手順に移行することが可能かもしれませんが、
しかしあるホストでメール作成プログラムにいくつかの小さい変更
もしくは全ての変更をする必要があるかもしれません。
There may be a need to allow users to identify relay hosts for
messages they send. This may require a new command or address
syntax not now currently allowed.
ユーザが、自分の送るメッセージの中継ホストを識別することを可能
にする必要があるかもしれません。これは新しいコマンドを必要とする
か、あるいは現在許されない構文を扱うかもしれません。
IP/TCP
ＩＰ / ＴＣＰ
Continuing use of IP and TCP will lead to a better understanding
of the performance characteristics and parameters. Implementers
should expect to make small changes from time to time to improve
performance.
ＩＰとＴＣＰの継続使用により性能特性とパラメータのより良い理解
を導くでしょう。実装は性能を改善するための時折の小さい変更を
予期するべきです。
Shortcuts
近道
There are some very tempting shortcuts in the implementation of IP
and TCP. DO NOT BE TEMPTED! Others have and they have been
caught! Some deficiencies with past implementations that must be
remedied and are not allowed in the future are the following:
ＩＰとＴＣＰの実装にある非常に誘惑的な近道があります。誘惑されな
いでください！ ある者がそうして、捕えられました！ 過去の実装で
修復されなくてはならず、将来の実装で許されないいくつかの欠陥が次
です：
IP problems:
ＩＰ問題：
Some IP implementations did not verify the IP header
checksum.
あるＩＰ実装がＩＰヘッダのチェックサムを検証しませんでした。
Some IP implementations did not implement fragment
reassembly.
あるＩＰ実装が分割パケットの組立てを実行しませんでした。
Some IP implementations used static and limited routing
information, and did not make use of the ICMP redirect
message information.
あるＩＰ実装が静的で限定された経路指定情報を使い、ＩＣＭＰ
リダイレクトメッセージ情報を利用しませんでした。
Some IP implementations did not process options.
あるＩＰ実装がオプションを処理しませんでした。
Some IP implementations did not report errors they detected
in a useful way.
あるＩＰ実装が有用な方法で検出したエラーを報告しませんでした。
TCP problems:
ＴＣＰ問題：
Some TCP implementations did not verify the TCP checksum.
あるＴＣＰ実装がＴＣＰチェックサムを検証しませんでした。
Some TCP implementations did not reorder segments.
あるＴＣＰ実装がセグメントの再要求をしませんでした。
Some TCP implementations did not protect against silly
window syndrome.
あるＴＣＰ実装が愚かなウインドウ症候群からの保護をしませんで
した。
Some TCP implementations did not report errors they detected
in a useful way.
あるＴＣＰ実装が有用な方法で検出したエラーを報告しませんでした。
Some TCP implementations did not process options.
あるＴＣＰ実装がオプションを処理しませんでした。
Host problems:
ホスト問題：
Some hosts had limited or static name tables.
あるホストが限定的か、あるいは静的な名前テーブルを持っていました。
Relay Service
中継サービス
The provision of relay services has started. There are two
concerns about the relay service: (1) reliability, and (2) load.
中継サービスの供給は始まりました。中継サービスについて２つの懸
念があります：（１）信頼性と（２）負荷。
The reliability is a concern because relaying puts another host in
the chain of things that have to all work at the same time to get
the job done. It is desirable to provide alternate relay hosts if
possible. This seems quite feasible for mail, but it may be a bit
sticky for Telnet and FTP due to the need for access control of
the login accounts.
中継は、中継鎖の他のホストが同時に仕事をする必要があるので、信頼
性の懸念があります。もし可能なら、代用の中継ホストを提供すること
が望ましいです。これはメールに非常に適しているように思われます、
しかしログインアカウントのアクセス制御が必要なためTelnetとFTPでは
少しやっかいであるかもしれません。
The load is a potential problem, since an overloaded relay host
will lead to unhappy users. This is another reason to provide a
number of relay hosts, to divide the load and provide better
service.
負荷は潜在的な問題で、過負荷の中継ホストは不幸なユーザを生むでしょ
う。これは多くの中継ホストを提供し、負荷を分割し、より良いサービス
を提供する、もう１つの理由です。
A Digression on the Numbers
数に関する余談
How bad could it be, this relay load? Essentially any "dual
protocol" host takes itself out of the game (i.e., does not need
relay services). Let us postulate that the number of NCP-only
hosts times the number of TCP-only hosts is a measure of the relay
load.
このリレー負荷はどれぐらい悪くなり得ますか？ 本質的に「二重のプ
ロトコル」ホストは対象外です（すなわち、中継サービスを必要としま
せん）。ＴＣＰのみのホストの数掛けるＮＣＰのみのホストの数が中継
負荷の基準であると仮定しましょう。
Total Hosts Dual Hosts NCP Hosts TCP Hosts "Load" Date
全ホスト 二重ホスト NCPホスト TCPホスト 負荷 日付
200 20 178 2 356 Jan-82
210 40 158 12 1896 Mar-82
220 60 135 25 3375 May-82
225 95 90 40 3600 Jul-82
230 100 85 45 3825 Sep-82
240 125 55 60 3300 Nov-82
245 155 20 70 1400 Dec-82
250 170 0 80 0 31-Dec-82
250 0 0 250 0 1-Jan-83
This assumes that most NCP-only hosts (but not all) will become to
dual protocol hosts, and that 50 new host will show up over the
course of the year, and all the new hosts are TCP-only.
これはＮＣＰのみのホスト（しかしすべてではない）が二重プロトコル
ホストとなり、この１年間に５０の新しいホストが現れ、全ての新しい
ホストがＴＣＰのみと想定します。
If the initial 200 hosts immediately split into 100 NCP-only and
100 TCP-only then the "load" would be 10,000, so the fact that
most of the hosts will be dual protocol hosts helps considerably.
もし最初の２００のホストがすぐに１００のＴＣＰのみと１００のＮＣ
Ｐのみのホストに分かれるなら、「負荷」は１０,０００でしょう、そ
れでホストの大部分が二重のプロトコルホストであるという事実はか
なり助かります。
This load measure (NCP hosts times TCP hosts) may over state the
load significantly.
この負荷計測（ＮＣＰホスト掛けるＴＣＰホスト）は著しく過剰かも
しれません。
Please note that this digression is rather speculative!
この余談が憶測であることに注意してください！
Gateways
ゲートウェイ
There must be continuing development of the internet gateways.
The following items need attention:
インターネットゲートウェイの継続する開発があるに違いありません。
次の項目は注意を必要とします：
Congestion Control via ICMP
ＩＣＭＰによる混雑制御
Gateways use connected networks intelligently
ゲートウェイが聰明に接続されたネットワークを使います
Gateways have adequate buffers
ゲートウェイが適切なバッファを持っています
Gateways have fault isolation instrumentation
ゲートウェイが障害隔離器具を持っています
Note that the work in progress on the existing gateways will
provide the capability to deal with many of these issues early in
1982. Work is also underway to provide improved capability
gateways based on new hardware late in 1982.
既存のゲートウェイの進行中の仕事が１９８２年の早期にこれらの問題
の多くを取り扱う能力を提供するであろうことに注意してください。
１９８２年の遅くに新しいハードウェアに基づいて改善された能力ゲー
トウェイを提供するための仕事が同じく進行中です。
APPENDIX A. Telnet Relay Scenario
付録Ａ． Ｔｅｌｎｅｔ中継のシナリオ
Suppose a user at a TCP-only host wishes to use the interactive
services of an NCP-only service host.
ＴＣＰのみのホストのユーザがＮＣＰのみのサービスホストの対話型の
サービスを使うことを望むと考えてください。
1) Use the local user Telnet program to connect via Telnet/TCP to
the RELAY host.
1) 中継ホストにＴｅｌｎｅｔ／ＴＣＰで接続するために、ローカルな
ユーザＴｅｌｎｅｔプログラムを使ってください。
2) Login on the RELAY host using a special account for the relay
service.
2) 中継サービスのための特別アカウントを使って中継ホストにログ
インしてください。
3) Use the user Telnet on the RELAY host to connect via
Telnet/NCP to the service host. Since both Telnet/TCP and
Telnet/NCP are available on the RELAY host the user must
select which is to be used in this step.
3) Ｔｅｌｎｅｔ／ＮＣＰでサービスホストに接続するために中継
ホストのユーザＴｅｌｎｅｔを使ってください。Ｔｅｌｎｅｔ／
ＴＣＰとＴｅｌｎｅｔ／ＮＣＰの両方が中継ホストで利用可能
ですので、ユーザはどちらがこのステップで使われるはずか選
択しなくてはなりません。
4) Login on the service host using the regular account.
4) 通常のアカウントを使ってサービスホストにログインしてください。
+---------+ +---------+ +---------+
| | Telnet | | Telnet | |
| Local |<-------->| Relay |<-------->| Service |
| Host | TCP | Host | NCP | Host |
+---------+ +---------+ +---------+
Suppose a user at a NCP-only host wishes to use the interactive
services of an TCP-only service host.
ＮＣＰのみのホストのユーザがＴＣＰのみのサービスホストの対話型の
サービスを使うことを望むと考えてください。
1) Use the local user Telnet program to connect via Telnet/NCP to
the RELAY host.
1) Ｔｅｌｎｅｔ／ＮＣＰで中継ホストに接続するためにローカルな
ユーザＴｅｌｎｅｔプログラムを使ってください。
2) Login on the RELAY host using a special account for the relay
service.
2) 中継サービスのための特別アカウントを使って中継ホストにログ
インしてください。
3) Use the user Telnet on the RELAY host to connect via
Telnet/NCP to the service host. Since both Telnet/TCP and
Telnet/NCP are available on the RELAY host the user must
select which is to be used in this step.
3) Ｔｅｌｎｅｔ／ＮＣＰでサービスホストに接続するために中継
ホストのユーザＴｅｌｎｅｔを使ってください。Ｔｅｌｎｅｔ
／ＴＣＰとＴｅｌｎｅｔ／ＮＣＰの両方が中継ホストで利用
可能ですから、ユーザはどちらがこのステップで使われるか
選択しなくてはなりません。
4) Login on the service host using the regular account.
4) 通常のアカウントを使ってサービスホストにログインしてください。
+---------+ +---------+ +---------+
| | Telnet | | Telnet | |
| Local |<-------->| Relay |<-------->| Service |
| Host | NCP | Host | TCP | Host |
+---------+ +---------+ +---------+
APPENDIX B. FTP Relay Scenario
付録Ｂ。 ＦＴＰ中継シナリオ
Suppose a user at a TCP-only host wishes copy a file from a NCP-only
donor host.
ＴＣＰのみのホストのユーザがＮＣＰのみのドナーホストからファイルを
コピーしたいと考えていると想定します。
Phase 1:
第１段階：
1) Use the local user Telnet program to connect via Telnet/TCP
to the RELAY host.
1) Ｔｅｌｎｅｔ／ＴＣＰで中継ホストに接続するためにローカルな
ユーザＴｅｌｎｅｔプログラムを使ってください。
2) Login on the RELAY host using a special account for the
relay service.
2) 中継サービスのための特別アカウントを使って中継ホストにログ
インしてください。
3) Use the user FTP on the RELAY host to connect via FTP/NCP
to the donor host.
3) ＦＴＰ／ＮＣＰでドナー者ホストに接続するために中継ホストの
ユーザＦＴＰを使ってください。
4) FTP login on the donor host using the regular account.
4) 通常のアカウントを使ってドナーホストにＦＴＰログインします。
5) Copy the file from the donor host to the RELAY host.
5) ドナーホストから中継ホストまでファイルをコピーしてください。
6) End the FTP session, and disconnect from the donor host.
6) ＦＴＰセッションを終わらせて、ドナーホストとの接続を閉じて
ください。
7) Logout of the RELAY host, close the Telnet/TCP connection,
and quit Telnet on the local host.
7) 中継ホストからログアウトし、Ｔｅｌｎｅｔ／ＴＣＰ接続を閉じ、
そしてローカルホストのＴｅｌｎｅｔから抜けてください。
+---------+ +---------+ +---------+
| | Telnet | | FTP | |
| Local |<-------->| Relay |<-------->| Service |
| Host | TCP | Host | NCP | Host |
+---------+ +---------+ +---------+
Phase 2:
第２段階：
1) Use the local user FTP to connect via FTP/TCP to the RELAY
host.
1) ＦＴＰ／ＴＣＰで中継ホストに接続するためにローカルなユーザ
ＦＴＰを使ってください。
2) FTP login on the RELAY host using the special account for
the relay service.
2) 中継サービスの特別アカウントを使って中継ホストにＦＴＰ
ログインします。
3) Copy the file from the RELAY host to the local host, and
delete the file from the RELAY host.
3) 中継器ホストからローカルなホストまでファイルをコピーし、
そして中継ホストからファイルを削除してください。
4) End the FTP session, and disconnect from the RELAY host.
4) ＦＴＰセッションを終わらせて、そして中継ホストを切ってください。
+---------+ +---------+
| | FTP | |
| Local |<-------->| Relay |
| Host | TCP | Host |
+---------+ +---------+
Note that the relay host may have a policy of deleting files more
than a few hours or days old.
中継ホストが数時間あるいは数日以上古いファイルを削除するポリシーを持つ
かもしれないことに注意を払ってください。
APPENDIX C. Mail Relay Scenario
付録Ｃ。 メール中継シナリオ
Suppose a user on a TCP-only host wishes to send a message to a user
on an NCP-only host which has implemented SMTP.
ＴＣＰのみのホストのユーザがＳＭＴＰを実装したＮＣＰのみのホストのユー
ザへメッセージを送ることを考えてください。
1) Use the local mail composition program to prepare the message.
Address the message to the recipient at his or her host. Tell
the composition program to queue the message.
1) メッセージを準備するためにローカルなメール構成プログラムを使っ
てください。彼あるいは彼女のホストをメッセージの宛先にしてくだ
さい。メッセージを待ち行列に入れるように構成プログラムに示して
ください。
2) The background mailer-daemon finds the queued message. It
checks the destination host name in a table to find the
internet address. Instead it finds that the destination host
is a NCP-only host. The mailer-daemon then checks a list of
mail RELAY hosts and selects one. It send the message to the
selected mail RELAY host using the SMTP procedure.
2) バックグラウンドメーラー・デーモンは待ち行列に入れられたメッ
セージを発見します。デーモンはインターネットアドレスを見いだす
ためにテーブルの宛先ホスト名をチェックします。アドレスの代わり
にデーモンは宛先ホストがＮＣＰのみのホストである事を発見します。
メーラー・デーモンはメール中継ホストのリストをチェック、１つを
選択します。デーモンはＳＭＴＰ手順を使ってメッセージを選ばれた
メール中継ホストに送ります。
3) The mail RELAY host accepts the message for relaying. It
checks the destination host name and discovers that it is a
NCP-only host which has implemented SMTP. The mail RELAY host
then sends the message to the destination using the SMTP/NCP
procedure.
3) メール中継ホストは中継するためにメッセージを受け入れます。中継
ホストは宛先ホスト名をチェックし、宛先ホストがＳＭＴＰを実装し
たＮＣＰのみのホストであることを見いだします。メール中継ホスト
はＳＭＴＰ／ＮＣＰ手順を使って宛先にメッセージを送ります。
+---------+ +---------+ +---------+
| | SMTP | | SMTP | |
| Source |<-------->| Relay |<-------->| Dest. |
| Host | TCP | Host | NCP | Host |
+---------+ +---------+ +---------+
Suppose a user on a TCP-only host wishes to send a message to a user
on an NCP-only non-SMTP host.
ＴＣＰのみのホストのユーザがＮＣＰのみの非ＳＭＴＰホストにユーザへ
メッセージを送ることを考えてください。
1) Use the local mail composition program to prepare the message.
Address the message to the recipient at his or her host. Tell
the composition program to queue the message.
1) ローカルなメール構成プログラムをメッセージを準備するために使っ
てください。彼あるいは彼女のホストをメッセージの宛先にしてく
ださい。メッセージを待ち行列に入れように構成プログラムに示し
てください。
2) The background mailer-daemon finds the queued message. It
checks the destination host name in a table to find the
internet address. Instead it finds that the destination host
is a NCP-only host. The mailer-daemon then checks a list of
mail RELAY hosts and selects one. It send the message to the
selected mail RELAY host using the SMTP procedure.
2) バックグラウンドメーラー・デーモンは待ち行列に入れられたメッ
セージを発見します。デーモンはインターネットアドレスを見い
だすためにテーブルで宛先ホスト名をチェックします。アドレスの
代わりに、デーモンは宛先ホストがＮＣＰのみのホストであると
見出します。メーラー・デーモンはメール中継ホストのリストを
チェックして、１つを選択します。デーモンはＳＭＴＰ手順を使っ
てメッセージを選ばれたメール中継ホストに送ります。
3) The mail RELAY host accepts the message for relaying. It
checks the destination host name and discovers that it is a
NCP-only non-SMTP host. The mail RELAY host then sends the
message to the destination using the old FTP/NCP mail
procedure.
3) メール中継ホストは中継するためにメッセージを受け入れます。
中継ホストは宛先ホスト名をチェックし、宛先がＮＣＰのみの
非ＳＭＴＰホストであることを見いだします。メール中継ホスト
は古いＦＴＰ／ＮＣＰメール手順を使って宛先にメッセージを
送ります。
+---------+ +---------+ +---------+
| | SMTP | | FTP | |
| Source |<-------->| Relay |<-------->| Dest. |
| Host | TCP | Host | NCP | Host |
+---------+ +---------+ +---------+
Suppose a user on a NCP-only non-SMTP host wishes to send a message
to a user on an TCP-only host. Suppose the destination user is
"Smith" and the host is "ABC-X".
ＮＣＰのみの非ＳＭＴＰホストのユーザがＴＣＰのみのホストのユーザへの
メッセージを送ることを考えてください。宛先ユーザが"Smith"で、ホスト
が"ABC-X"と考えてください。
1) Use the local mail composition program to prepare the message.
Address the message to "Smith.ABC-X@FORWARDER". Tell the
composition program to queue the message.
1) ローカルなメール構成プログラムをメッセージを準備するために使っ
てください。メッセージの宛先を"Smith.ABC-X@FORWARDER"にして
ください。メッセージを待ち行列に入れるように構成プログラムに
示してください。
2) The background mailer-daemon finds my queued message. It
sends the message to host FORWARDER using the old FTP/NCP mail
procedure.
2) バックグラウンドメーラー・デーモンは待ち行列に入れられたメッ
セージを発見します。デーモンは古いＦＴＰ／ＮＣＰメール手順を
使ってメッセージをホストFORWARDERに送ります。
3) The special forwarder host converts the "user name" supplied
by the FTP/NCP mail procedure (in the MAIL or MLFL command) to
"Smith@ABC-X" (in the SMTP RCTP command) and queues the
message to be processed by the SMTP mailer-daemon program on
this same host. No conversion of the mailbox addresses in
made in thr message header or body.
3) 特別な転送ホスト(forwarder)はＦＴＰ／ＮＣＰメール手順で（MAIL
あるいはMLFLコマンドで）供給された"ユーザ名"を（SMTP RCTPコマ
ンドの）"Smith@ABC-X"に変換し、によって供給された「ユーザ名」
を「Smith@ABC-X」に換えて、同じホストの上のＳＭＴＰメーラー・
デーモンプログラムによって処理されるようにメッセージを待ち
行列に入れます。メッセージヘッダやボディーに作られたメールボッ
クスアドレスの変換はなしです。
4) The SMTP mailer-daemon program on the forwarder host finds
this queued message and checks the destination host name in a
table to find the internet address. It finds the destination
address and send the mail using the SMTP procedure.
4) 転送ホストにのＳＭＴＰメーラー・デーモンプログラムはこの待ち
行列に入れられたメッセージを見いだして、インターネットアドレ
スを発見するためにテーブルの宛先ホスト名をチェックします。
デーモンは宛先アドレスを見いだします、そしてＳＭＴＰ手順を
使ってメールを送ってください。
+---------+ +---------+ +---------+
| | FTP | | SMTP | |
| Source |<-------->|Forwarder|<-------->| Dest. |
| Host | NCP | Host | TCP | Host |
+---------+ +---------+ +---------+
APPENDIX D. IP/TCP Implementation Status
付録Ｄ。 ＩＰ／ＴＣＰ実装状態
Please note that the information in this section may become quickly
dated. Current information on the status of IP and TCP
implementations can be obtained from the file
<INTERNET-NOTEBOOK>TCP-IP-STATUS.TXT on ISIF.
この章の情報が速く時代遅れになるかもしれないことに注意してください。
ＩＰとＴＣＰ実装の状態に関する最新情報とはISIFのファイル
<INTERNET-NOTEBOOK>TCP-IP-STATUS.TXTで得ることができます。
BBN C70 UNIX
Date: 18 Nov 1981
From: Rob Gurwitz <gurwitz at BBN-RSM>
The C/70 processor is a BBN-designed system with a native
instruction set oriented toward executing the C language. It
supports UNIX Version 7 and provides for user processes with a
20-bit address space. The TCP/IP implementation for the C/70 was
ported from the BBN VAX TCP/IP, and shares all of its features.
C/70プロセッサはＣ言語を実行することに向けられたネイティブの命令
セットを持ったBBNによって設計されたシステムです。これはUNIX７版を
サポートして、２０ビットのアドレス空間でユーザ処理を提供します。
C/70のTCP/IP実装はBBN VAX TCP/IPから提供されました、そしてその
機能のすべてを共有します。
This version of TCP/IP is running experimentally at BBN, but is
still under development. Performance tuning is underway, to make
it more compatible with the C/70's memory management system.
TCP/IPのこのバージョンは実験的にBBNで動いています、しかしまだ開発
下にあります。C/70のメモリ管理システムと互換性があるように
パフォーマンス調整が進行中です。
BBN GATEWAYS
Date: 19 Nov 1981
From: Alan Sheltzer <sheltzer at BBN-UNIX>
In an effort to provide improved service in the gateways
controlled by BBN, a new gateway implementation written in
macro-11 instead of BCPL is being developed. The macro-11 gateway
will provide users with internet service that is functionally
equivalent to that provided by the current BCPL gateways with some
performance improvements.
BBNによってコントロールされたゲートウェイで改善されたサービスを提供
しようとする努力で、BCPLの代わりにmacro-11で書かれた新しいゲート
ウェイ実装が開発されています。macro-11ゲートウェイは現在のBCPL
ゲートウェイによって提供されたものと機能上等しいインターネット
サービスを若干パフォーマンスを改良してユーザに提供するでしょう。
ARPANET/SATNET gateway at BBN (10.3.0.40),
ARPANET/SATNET gateway at NDRE (10.3.0.41),
Comsat DCN Net/SATNET gateway at COMSAT (4.0.0.39),
SATNET/UCL Net/RSRE Net gateway at UCL (4.0.0.60),
PR Net/RCC Net gateway at BBN (3.0.0.62),
PR Net/ARPANET gateways at SRI (10.3.0.51, 10.1.0.51),
PR Net/ARPANET gateway at Ft. Bragg (10.0.0.38).
BBN H316 and C/30 TAC
Date: 18 November 1981
From: Bob Hinden <Hinden@BBN-UNIX>
The Terminal Access Controller (TAC) is user Telnet host that
supports TCP/IP and NCP host to host protocols. It runs in 32K
H-316 and 64K C/30 computers. It supports up to 63 terminal
ports. It connects to a network via an 1822 host interface.
ターミナルアクセスコントローラー（TAC）はホストプロトコルに
ＴＣＰ／ＩＰとＮＣＰホストをサポートするユーザＴｅｌｎｅｔホスト
です。これは32K H-316と64K C/30コンピュータで走ります。これは最
高６３の末端ポートをサポートします。これは１８２２のホストインタ
フェースによってネットワークに接続します。
For more information on the TAC's design, see IEN-166.
もっと多くのTACの設計に関する情報はIEN-166を見てください。
BBN HP-3000
Date: 14 May 1981
From: Jack Sax <sax@BBN-UNIX>
The HP3000 TCP code is in its final testing stages. The code
includes under the MPE IV operating system as a special high
priority process. It is not a part of the operating system kernel
because MPE IV has no kernel. The protocol process includes TCP,
IP, 1822 and a new protocol called HDH which allows 1822 messages
to be sent over HDLC links. The protocol process has about 8k
bytes of code and at least 20k bytes of data depending on the
number of buffers allocated.
HP3000のＴＣＰコードはその最終のテスト段階にあります。コードは
MPE IVオペレーティングシステム下で特別な高優先プロセスです。
MPE IVがカーネルを持っていないので、これはオペレーティング・シス
テムカーネルの一部ではありません。プロトコル処理はＴＣＰとＩＰと
１８２２を含みます、そしてＨＤＨと呼ばれる新しいプロトコルが
１８２２メッセージをＨＤＬＣリンク上に送ることを可能にします。プ
ロトコル処理は約８Ｋバイトのコードと割り当てられたバッファに依存
して少なくとも２０Ｋバイトのデータを持っています。
In addition to the TCP the HP3000 has user and server TELNET as
well as user FTP. A server FTP may be added later.
ＴＣＰに加えて、HP3000はユーザとサーバのＴＥＬＮＥＴとユーザの
ＦＴＰを持っています。サーバＦＴＰが後で加えられるかもしれません。
A complete description of the implementation software can be found
in IEN-167.
実装ソフトウェアの完全な記述がIEN-167にあります。
BBN PDP-11 UNIX
Date: 14 May 1981
From: Jack Haverty <haverty@BBN-UNIX>
This TCP implementation was written in C. It runs as a user
process in version 6 UNIX, with modifications added by BBN for
network access. It supports user and server Telnet.
このＴＣＰ実装はＣで書かれました。これはネットワークアクセスのた
めにBBNによって加えられた修正で、UNIX６版のユーザープロセスとし
て作動します。これはユーザとサーバのＴｅｌｎｅｔをサポートします。
This implementation was done under contract to DCEC. It is
installed currently on several PDP-11/70s and PDP-11/44s. Contact
Ed Cain at DCEC <cain@EDN-UNIX> for details of further
development.
この実装はDCECとの契約の下でされました。これは現在いくつかの
PDP-11/70とPDP-11/44に設置されます。これ以上の開発の詳細について
はDCECのエド・カイン<cain@EDN-UNIX>と連絡を取ってください。
BBN TENEX & TOPS20
Date: 23 Nov 1981
From: Charles Lynn <CLynn@BBNA>
TCP4 and IP4 are available for use with the TENEX operating system
running on a Digital KA10 processor with BBN pager. TCP4 and IP4
are also available as part of TOPS20 Release 3A and Release 4 for
the Digital KL10 and KL20 processors.
BBN呼び出し器を持つデジタルKA10プロセッサ上で走るTENEXオペレー
ティング・システムで、TCP4とIP4は利用可能です。デジタルKL10と
KL20プロセッサのためのTOPS20リリース3Aとリリース４の一部として
TCP4とIP4は同じく利用可能です。
Above the IP layer, there are two Internet protocols within the
monitor itself (TCP4 and GGP). In addition up to eight (actually
a monitor assembly parameter) protocols may be implemented by
user-mode programs via the "Internet User Queue" interface. The
GGP or Gateway-Gateway Protocol is used to receive advice from
Internet Gateways in order to control message flow. The GGP code
is in the process of being changed and the ICMP protocol is being
added.
ＩＰ層上に、モニタを含む２つのインターネット・プロトコルがありま
す（TCP4とGGP）。加えて、「インターネットユーザキュー」インター
フェースにより、８つ（実際はモニターアセンプリパラメータ）までの
プロトコルがユーザーモードプログラムとして実装されます。GGPあるい
はゲートウェイゲートウェイプロトコルがメッセージ流れをコントロール
するためにインターネットゲートウェイから助言を受け取るために使われ
ます。GGPコードは変更中で、ＩＣＭＰプロトコルが加えられています。
TCP4 is the other monitor-supplied protocol and it has two types
of connections -- normal data connections and "TCP Virtual
Terminal" (TVT) connections. The former are used for bulk data
transfers while the latter provide terminal access for remote
terminals.
TCP4は他のモニターによって供給されたプロトコルです、そしてそれは
２種類の接続−通常のデータ接続と「ＴＣＰ仮想端末」（TVT）接続−を
持っています。前者は大量データ転送のために使われ、後者が遠隔端末の
端末アクセスを提供します。
Note that TVTs use the standard ("New") TELNET protocol. This is
identical to that used on the ARPANET with NCP and in fact, is
largely implemented by the same code.
TVTが標準の（「新しい」）ＴＥＬＮＥＴプロトコルを使うことに注意し
てください。これは実際はARPANETのＮＣＰで使われたのと同じで、主に
同じコードで実行されます。
Performance improvements, support for the new address formats, and
User and Server FTP processes above the TCP layer are under
development.
性能の改良と、新しいアドレスフォーマットのサポートと、ＴＣＰ層の上
のユーザとサーバＦＴＰ処理が開発下にあります。
BBN VAX UNIX
Date: 18 Nov 1981
From: Rob Gurwitz <gurwitz at BBN-RSM>
The VAX TCP/IP implementation is written in C for Berkeley 4.1BSD
UNIX, and runs in the UNIX kernel. It has been run on VAX 11/780s
and 750s at several sites, and is due to be generally available in
early 1982.
VAX TCP/IP実装はバークレー4.1BSD UNIXのためにＣでに書かれていま
す、そしてUNIXカーネル上で動作します。これはいくつかのサイトで
VAX 11/780と750上で動いています、そして１９８２年の早期に入手可
能になっています。
The implementation conforms to the TCP and IP specifications (RFC
791, 793). The implementation supports the new extended internet
address formats, and both GGP and ICMP. It also supports multiple
network access protocols and device drivers. Aside from ARPANET
1822 and the ACC LH/DH-11 driver, experimental drivers have also
been developed for ETHERNET. There are user interfaces for
accessing the IP and local network access layers independent of
the TCP.
実装はＴＣＰとＩＰ仕様（ＲＦＣ７９１、７９３）に従います。実装は
新しい拡張されたインターネットアドレスフォーマットとＧＧＰとＩＣ
ＭＰの両方をサポートします。これは同じく多数のネットワークアクセス
プロトコルとデバイス・ドライバをサポートします。ARPANET 1822とACC
LH/DH-11ドライバは別として、実験的なドライバもイーサネットのため
に開発されました。ＴＣＰと独立に、ＩＰとローカルネットワークアクセ
スレイヤにアクセスする、ユーザインタフェースがあります。
Higher level protocol services include user and server TELNET,
MTP, and FTP, implemented as user level programs. There are also
tools available for monitoring and recording network traffic for
debugging purposes.
上位レベルプロトコルサービスには、ユーザレベルプログラムとして実装
されている、ユーザとサーバのTELNETとＭＴＰとＦＴＰを含みます。同じ
くデバッグ目的でネットワークトラフィックをモニタして記録することに
利用可能なツールがあります。
Continuing development includes performance enhancements. The
implementation is described in IEN-168.
性能向上の開発が継続しています。 実装はIEN-168で記述されます。
COMSAT
Date: 30 Apr 1980
From: Dave Mills <Mills@ISIE>
The TCP/IP implementation here runs in an LSI-11 with a homegrown
operating system compatible in most respects to RT-11. Besides the
TCP/IP levels the system includes many of the common high-level
protocols used in the ARPANET community, such as TELNET, FTP and
XNET.
TCP/IP実装はRT-11にほぼ互換性があるLSI-11上の自家製のオペレー
ティング・システムで動作します。システムはTCP/IPレベルのほかに
TELNETとＦＴＰとXNETのような、ARPANET共同体で使われた共通の上
位プロトコルの多くを含みます。
DCEC PDP-11 UNIX
Date: 23 Nov 1981
From: Ed Cain <cain@EDN-UNIX>
This TCP/IP/ICMP implementation runs as a user process in version
6 UNIX, with modifications obtained from BBN for network access.
IP reassembles fragments into datagrams, but has no separate IP
user interface. TCP supports user and server Telnet, echo,
discard, internet mail, and a file transfer service. ICMP
generates replies to Echo Requests, and sends Source-Quench when
reassembly buffers are full.
このTCP/IP/ICMP実装は、BNNのネットワークアクセスのためのものの
修正で、第６版UNIXで、ユーザープロセスとして作動します。ＩＰは
データグラムの破片を組み立てますが、ＩＰ分解のユーザインタフェー
スを持っていません。ＴＣＰはユーザとサーバのTelnet、エコー、廃棄、
インターネットメールとファイル転送サービスをサポートします。ＩＣ
ＭＰはエコー要請への返答を生成し、組み立てバッファが満杯のとき、
送信元抑制を送ります。
Hardware - PDP-11/70 and PDP-11/45 running UNIX version 6, with
BBN IPC additions. Software - written in C, requiring 25K
instruction space, 20K data space. Supports 10 connections.
ハードウェア−BBN IPC込みでUNIX第６版を走らせているPDP-11/70と
PDP-11/45。ソフトウェア−Ｃで書かれました、25Kの命令空間と、20K
のデータ空間が必要です。１０の接続をサポートします。
DTI VAX
Date: 15 May 1981
From: Gary Grossman <grg@DTI)>
Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS
VAX/VMSのためのデジタル技術社（DTI）ＩＰ / ＴＣＰ
The following describes the IP and TCP implementation that DTI
plans to begin marketing in 4th Quarter 1981 as part of its
VAX/VMS network software package.
次は、DTIがVAX/VMネットワークソフトウェアパッケージの一部とし
て、１９８１年第４四半期に売り込みを計画するＩＰとＴＣＰ実装の
記述です。
Hardware: VAX-11/780 or /750. Operating System: DEC standard
VAX/VMS Release 2.0 and above. Implementation Language: Mostly
C, with some MACRO. Connections supported: Maximum of 64.
ハードウェア：VAX-11/780又は/750。オペレーティング・システム：
ＤＥＣスタンダードVAX/VMリリース２.０以上。実装言語：主にＣ、
いくらかのマクロ。サポートされた接続：最大６４。
User level protocols available: TELNET, FTP, and MTP will be
available. (The NFE version uses AUTODIN II protocols.)
利用可能なユーザーレベルプロトコル：TELNET、FTPとMTPが利用可能
であるでしょう。（NFE版はAUTODIN IIプロトコルを使います。）
MIT MULTICS
Date: 13 May 1981
From: Dave Clark <Clark@MIT-Multics>
Multics TCP/IP is implemented in PL/1 for the HISI 68/80. It has
been in experimental operation for about 18 months; it can be
distributed informally as soon as certain modifications to the
system are released by Honeywell. The TCP and IP package are
currently being tuned for performance, especially high throughput
data transfer.
Multics TCP/IPはHISI 68/80のPL/1に実装されます。これはおよそ
１８カ月間実験的運用でした；システムへの特定の原稿はハネウェル
によってリリースされるとすぐに、非公式に配布できます。ＴＣＰとＩＰ
パッケージは現在、性能、特に高いスループットデータ転送のために調整
されています。
Higher level services include user and server telnet, and a full
function MTP mail forwarding package.
上位レベルサービスはユーザとサーバのtelnetと完全機能のMTPメール
転送パッケージを含みます。
The TCP and IP contain good logging and debugging facilities,
which have proved useful in the checkout of other implementations.
Please contact us for further information.
ＴＣＰとＩＰは良いログとデバッギング能力を含みます、そしてそれは
他の実装の点検で有用と分かりました。これ以上の情報は我々に連絡を
取ってください。
SRI LSI-11
Date: 15 May 1981
From: Jim Mathis <mathis.tscb@Sri-Unix>
The IP/TCP implementation for the Packet Radio terminal interface
unit is intended to run on an LSI-11 under the MOS real-time
operating system. The TCP is written in MACRO-11 assembler
language. The IP is currently written in assembler language; but
is being converted into C. There are no plans to convert the TCP
from assembler into C.
パケット無線端末インタフェースユニットのためのＩＰ/ＴＣＰ実装は
MOSリアルタイムオペレーティング・システム下のLSI-11上で走らせる
ように意図されます。ＴＣＰはMACRO-11アセンブラ言語で書かれます。
ＩＰは現在アセンブラ言語で書かれます；しかしＣに変換されています。
ＴＣＰをアセンブラからＣへ変換する計画がありません。
The TCP implements the full specification. The TCP appears to be
functionally compatible with all other major implementations. In
particular, it is used on a daily basis to provide communications
between users on the Ft. Bragg PRNET and ISID on the ARPANET.
ＴＣＰは完全仕様を実行します。ＴＣＰは機能上すべての他の主要な実
装と両立できるように思われます。特に、これは日単位でARPANETの
Ft. Bragg PRNETとISIDのユーザ間のコミュニケーションを提供するために
使われます。
The IP implementation is reasonably complete, providing
fragmentation and reassembly; routing to the first gateway; and a
complete host-side GGP process.
ＩＰ実装は、分割と組み立ての；最初のゲートウェイへの経路指定；完全
なホストサイドGGPプロセスの提供が適度に完全です。
A measurement collection mechanism is currently under development
to collect TCP and IP statistics and deliver them to a measurement
host for data reduction.
現在ＴＣＰとＩＰ統計値を集める測定収集メカニズムが開発中で、データ
縮小のために測定ホストにこれらを配達します。
UCLA IBM
Date: 13 May 1981
From: Bob Braden <Braden@ISIA>
Hardware: IBM 360 or 370, with a "Santa Barbara" interface to the
IMP.
ハードウェア：IMPへの"Santa Barbara"インタフェースを持つ、
ＩＢＭ３６０あるいは３７０。
Operating System: OS/MVS with ACF/VTAM. An OS/MVT version is
also available. The UCLA NCP operates as a user job, with its own
internal multiprogramming and resource management mechanisms.
オペレーティング・システム： ACF/VTAM又はOS/MVS。OS/MVT版が
同じく利用可能です。UCLA NCPはそれ自身の内部の多重プログラミング
とリソース管理メカニズムを持ち、ユーザージョブとして稼働します。
Implementation Language: BAL (IBM's macro assembly language)
実装言語：BAL（ＩＢＭのマクロアセンプリ言語）
User-Level Protocols Available: User and Server Telnet
ユーザーレベル利用可能なプロトコル：ユーザとサーバTelnet