この文書はRFC 801の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                          J. Postel
Request for Comments: 801                                            ISI
                                                           November 1981



                        NCP/TCP TRANSITION PLAN
                        NCP/TCP移行計画


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.
   ARPAが資金援助するコンピュータ・ネットワークの研究がARPANETの開
   発を導きました。ARPANETの導入は1969年9月に始まりました、そして
   通常運用は1971年までに進行しました。ARPANETは少なくとも(今まで)
   10年間使用可能なサービスでした。これはいろいろなコンピュータ研究
   活動を支援し、信頼性が高いサービスを提供していましたが、(今まで)
   これ自身が継続している研究課題であり、この間に際立って進展しました。

   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.
   ARPAがこれまでの数年に、主に異なる基礎の通信技術に基づくコンピュー
   タ・ネットワークの追加の研究、特にデジタルパケット広帯域無線と人工衛
   星がネットワークを後援しました。また、ARPA共同体はローカルネット
   ワーク上で重要な仕事がありました。

   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で使われたホスト
   対ホストに基づくプロトコルが、これらのネットワークで使用するのに不十
   分であることは明確でした。1973年の仕事は、これらすべてのネット
   ワークを越えたホスト対ホストプロトコルの使用から始められました。こ
   の長い努力の結果はインターネット・プロトコル(IP)そして伝送制御
   プロトコル(TCP)です。

   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").
   これらのプロトコルはこれらのネットワークで相互接続したすべてのホス
   トが共通のプロセス間通信環境を共有することを可能にします。相互接続
   ネットワークの集団はARPAインターネットと呼ばれます(時々「カテ
   ネット」と呼ばれます)。

   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.
   国防省は最近すべてのDoDパケットネットワークのDoD広域標準として
   特にインターネットの概念とIPとTCPプロトコルを採択しました、そし
   て今後数年にわたってこの体系に移行するでしょう。すべての新しいDoD
   パケットネットワークはもっぱらこれらのプロトコルを使うでしょう。

   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ホストと他の
   ネットワークのホストの論理的な接続性をARPAインターネットに拡張す
   る時は来ました。

   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.
   いくつかのホストでIP/TCPの実装はすでに完了しました、そしてい
   くつかのサービスの使用ができます。すべてのARPANETホストで何が何で
   も緊急に1982年1月1日に遅れないようにIP/TCPの実装を開始
   するべきです。ARPANETに接続した新しいホストはIP/TCPとTCP
   に基づくサービスを実装するだけであるべきです。いくつかの重要な実装
   問題がこの文書の最後の章で論じられます。

   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.
   すべてのホストが同時にTCPに変換できず、そして一部がIP/TCP
   だけを実装するから、NCPのみのホストとTCPのみのホスト間に一時
   的に通信を提供する必要があるでしょう。これをするために、NCPと
   IP/TCPの両方を実装する特定のホストがリレーホストに指名される
   でしょう。これらのリレーホストはNCPとTCPの両方でTelnet
   とFTPとメールサービスをサポートするでしょう。これらのリレーサー
   ビスは1981年11月から供給が始まり、1982年1月から完全に実
   施されるでしょう。

   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.
   当初は多くのNCPのみのホストと少数のTCPのみのホストがあるで
   しょう、そしてリレーホストの負荷は比較的軽いでしょう。時が経過し、
   変更が進行すると、多くのTCP対応ホストと少ないNCPのみのホスト
   に加えて新しいTCPのみのホストが存在するでしょう。しかし、多分、
   現在の多くのNCPのみのホストがNCP以外にIP/TCPを実装し、
   「二重プロトコル」ホストになるでしょう。それでリレーホストの負荷は
   上昇するでしょうが、全体のトラフィックの主要部分ではないでしょう。

   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.
   目標は1983年1月1日までにNCPからIP/TCPへ完全な切替を実施
   することです。

      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/TCPの実装はそれぞれのホストの組織の仕事です。この
      実装の仕事は1982年1月1日から始まらなくてはなりません。

      IP:

         This is specified in RFCs 791 and 792.  Implementations exist
         for several machines and operating systems.  (See Appendix D.)
         これは791と792のRFCで指定されます。いくつかのマシンと
         オペレーティング・システムの実装が存在します。(付録Dを見て
         ください。)

      TCP:

         This is specified in RFC793.  Implementations exist for several
         machines and operating systems.  (See Appendix D.)
         これはRFC793で指定されます。いくつかのマシンとオペレーティング・
         システムの実装が存在します。(付録Dを見てください。)

   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.
   IP/TCPプロトコルの実装だけでは十分ではありません、同様にこの
   IP/TCPベース上で主要サービスが利用可能に違いありません。主要
   サービスは以下です:Telnet、ファイル転送、メール。

      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.
      ホストに主要サービスを実装することはそれぞれのホスト組織の仕事
      です。これらの実装仕事は1982年1月1日までに始まらなくては
      なりません。

      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.
         これはRFC764で指定されます。それはNCPで使われた
         Telnetに非常に類似しています。主な相違はICPが削除
         され、NCP割り込みがTCPが緊急で、置き換えられることです。

      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.
         これはRFC765で指定されます。これはNCPで使われた
         FTPに非常に類似しています。主な相違は、Telnetの
         変更と、データチャネルが8ビットのバイトに限定され、他の送信
         バイトサイズを使うFTP機能が削除される事です。

      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.
         これはRFC788で指定されます。メールが完全にFTPから
         分離され、別のサーバーによって処理されます。手順は概念的に
         古いFTP/NCPメール手順に類似していますが、詳細は非常に
         異なり、そして追加の機能−特にメール中継と、複数受取人への
         配達−をサポートします。

   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.
   新しい環境で主要サービスを提供する過程で、現在と1983年1月の間、
   新しい環境と古い環境の間を相互接続するための準備があるに違いありませ
   ん。

      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.)
      Telnetでは1つ以上のホストが中継をするでしょう。Telnet
      中継ホストはNCPとTCPの両方の環境でユーザとサーバの両方の
      Telnetを実装するでしょう。異なる環境のホスト間のTelnet
      サービスを必要としているユーザが最初にTelnet中継ホストに接続
      し、次に宛先ホストに接続するでしょう。(付録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.)
      FTPで、1つ以上の中継ホストがあるでしょう。FTP中継ホストが
      NCPとTCPの両方の環境で、ユーザとサーバの両方のTelnetと
      ユーザとサーバの両方のFTPを実装するでしょう。異なる環境のホスト
      の間でFTPサービスを必要としているユーザが最初にTelnetに
      よってFTPリレーホストに接続し、それからファイルの寄贈者ホスト
      からFTP中継ホストにファイルを動かすためにFTP使い、そして
      最後にFTP中継ホストからファイル引受ホストにファイルを動かす
      ためにFTP使うでしょう。(付録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.)
      メールでは、ホストがRFC788で記述された新しいシンプルメール
      転送プロトコル(SMTP)を実装するでしょう。いくつかのプロトコル
      環境間でメールを中継をSMTP手順は供給します。TCPのみのホスト
      はSMTPを使えば十分でしょう。SMTPを使うように修正されていな
      いNCPのみのホストは、特別な転送ホストでメールを中継するために、
      特別な構文「user.host@forwarder」を使うかもしれません。いくつかの
      メールリレーホストはNCPとTCP環境の間でSMTP手順によって
      メールを中継するでしょう、そして少なくとも1つの特別な転送ホストが
      提供されるでしょう。(付録Cを見てください。)

Milestones
マイルストーン
----------

   First Internet Service                                        already
   最初のインターネットサービス                                  完了

      A few hosts are TCP-capable and use TCP-based services.
      少数のホストがTCP対応であり、TCPベースのサービスを使います。

   First TCP-only Host                                           already
   最初のTCPのみのホスト                                      完了

      The first TCP-only host begins use of TCP-based services.
      最初のTCPのみのホストはTCPベースのサービスの使用を始めます。

   Telnet and FTP Relay Service                                  already
   TelnetとFTP中継サービス                              完了

      Special relay accounts are available to qualified users with a
      demonstrated need for the Telnet or FTP relay service.
      TelnnetあるいはFTP中継サービスの実行に必要な特別な
      中継アカウントは、資格を持つユーザに入手可能です。

   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.
      原型MTP(RFC780)を使う特別なメール中継サービスが実装
      されています、そしてメールが、TCPのみのホストからNCPのみ
      のホストまで中継されますが、逆はそうではありません。このサービ
      スはSMTPサービスで置き換えられるでしょう。

   Last NCP Conversion Begins                                     Jan 82
   NCP変更の開始の最後                                 1982年1月

      The last NCP-only host begins conversion to TCP.
      最後のNCPのみのホストがTCPへの変更を始めます。

   Mail Relay Service                                             Jan 82
   メール中継サービス                                     1982年1月

      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.
      SMTP(RFC788)メールサービスが稼働し始めます、そして
      少なくとも1つのメール中継ホストが動作します、そして少なくとも
      1つの特別な転送者がNCPのみのホストからTCPのみのホストへ
      のメール接続性の提供のために動作します。

   Normal Internet Service                                        Jul 82
   通常のインターネットサービス                           1982年7月

      Most hosts are TCP-capable and use TCP-based services.
      たいていのホストがTCP対応になり、TCPベースのサービスを使
      います。

   Last NCP Conversion Completed                                  Nov 82
   最後のNCPの変更完了                               1982年11月

      The last NCP-only host completes conversion to TCP.
      最後のNCPのみのホストがTCPへの変更を完了します。

   Full Internet Service                                          Jan 83
   完全インターネットサービス                             1983年1月

      All hosts are TCP-capable and use TCP-based services.  NCP is
      removed from service, relay services end, all services are
      TCP-based.
      すべてのホストはTCP対応となり、TCPベースのサービスを使い
      ます。NCPはサービスを中止し、中継サービスが終わります、すべて
      のサービスはTCPベースです。

Documents
文書
---------

   The following RFCs document the protocols to be implemented in the
   new IP/TCP environment:
   次のRFCは新しいIP / TCP環境に実装されるべきプロトコルを
   記述します:

      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
      インターネット・プロトコルハンドブック              1982年1月

      Implementers Hints                                          Jan 82
      実装助言                                            1982年1月

      SDC IP/TCP Specifications                                   Jan 82
      SDC IP/TCP仕様                            1982年1月

      Expanded Host Table                                         Jan 82
      拡張ホストテーブル                                  1982年1月


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.).
      たいていのホストがホストの文字列名を数値アドレスに変換する表を
      持っています。ホストの持つホスト名テーブルに影響を与えるかもし
      れない、この移行の2つの効果があります:(1)もっとずっと多く
      の名前があるでしょう、そして(2)それぞれのホストのプロトコル
      能力(SMTP/TCP、SMTP/NCP、FTP/NCPなど)
      に注意を払う必要があるかもしれません。

      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.
      メーラー・デーモンだけを変え、SMTPサーバを実装することで、
      新しいSMTPメール手順に移行することが可能かもしれませんが、
      しかしあるホストでメール作成プログラムにいくつかの小さい変更
      もしくは全ての変更をする必要があるかもしれません。

      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
   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.
      IPとTCPの継続使用により性能特性とパラメータのより良い理解
      を導くでしょう。実装は性能を改善するための時折の小さい変更を
      予期するべきです。

   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とTCPの実装にある非常に誘惑的な近道があります。誘惑されな
      いでください!  ある者がそうして、捕えられました!  過去の実装で
      修復されなくてはならず、将来の実装で許されないいくつかの欠陥が次
      です:

         IP problems:
        IP問題:

            Some IP implementations did not verify the IP header
            checksum.
            あるIP実装がIPヘッダのチェックサムを検証しませんでした。

            Some IP implementations did not implement fragment
            reassembly.
            あるIP実装が分割パケットの組立てを実行しませんでした。

            Some IP implementations used static and limited routing
            information, and did not make use of the ICMP redirect
            message information.
            あるIP実装が静的で限定された経路指定情報を使い、ICMP
            リダイレクトメッセージ情報を利用しませんでした。

            Some IP implementations did not process options.
            あるIP実装がオプションを処理しませんでした。

            Some IP implementations did not report errors they detected
            in a useful way.
            あるIP実装が有用な方法で検出したエラーを報告しませんでした。

         TCP problems:
         TCP問題:

            Some TCP implementations did not verify the TCP checksum.
            あるTCP実装がTCPチェックサムを検証しませんでした。

            Some TCP implementations did not reorder segments.
            あるTCP実装がセグメントの再要求をしませんでした。

            Some TCP implementations did not protect against silly
            window syndrome.
            あるTCP実装が愚かなウインドウ症候群からの保護をしませんで
            した。

            Some TCP implementations did not report errors they detected
            in a useful way.
            あるTCP実装が有用な方法で検出したエラーを報告しませんでした。

            Some TCP implementations did not process options.
            あるTCP実装がオプションを処理しませんでした。

         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.
      中継サービスの供給は始まりました。中継サービスについて2つの懸
      念があります:(1)信頼性と(2)負荷。

      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.
      負荷は潜在的な問題で、過負荷の中継ホストは不幸なユーザを生むでしょ
      う。これは多くの中継ホストを提供し、負荷を分割し、より良いサービス
      を提供する、もう1つの理由です。

      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.
      このリレー負荷はどれぐらい悪くなり得ますか?  本質的に「二重のプ
      ロトコル」ホストは対象外です(すなわち、中継サービスを必要としま
      せん)。TCPのみのホストの数掛けるNCPのみのホストの数が中継
      負荷の基準であると仮定しましょう。

      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.
      これはNCPのみのホスト(しかしすべてではない)が二重プロトコル
      ホストとなり、この1年間に50の新しいホストが現れ、全ての新しい
      ホストがTCPのみと想定します。

      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.
      もし最初の200のホストがすぐに100のTCPのみと100のNC
      Pのみのホストに分かれるなら、「負荷」は10,000でしょう、そ
      れでホストの大部分が二重のプロトコルホストであるという事実はか
      なり助かります。

      This load measure (NCP hosts times TCP hosts) may over state the
      load significantly.
      この負荷計測(NCPホスト掛けるTCPホスト)は著しく過剰かも
      しれません。

      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
         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.
      既存のゲートウェイの進行中の仕事が1982年の早期にこれらの問題
      の多くを取り扱う能力を提供するであろうことに注意してください。
      1982年の遅くに新しいハードウェアに基づいて改善された能力ゲー
      トウェイを提供するための仕事が同じく進行中です。


APPENDIX A.  Telnet Relay Scenario
付録A. Telnet中継のシナリオ

   Suppose a user at a TCP-only host wishes to use the interactive
   services of an NCP-only service host.
   TCPのみのホストのユーザがNCPのみのサービスホストの対話型の
   サービスを使うことを望むと考えてください。

      1)  Use the local user Telnet program to connect via Telnet/TCP to
          the RELAY host.
      1)  中継ホストにTelnet/TCPで接続するために、ローカルな
          ユーザTelnetプログラムを使ってください。

      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)  Telnet/NCPでサービスホストに接続するために中継
          ホストのユーザTelnetを使ってください。Telnet/
          TCPとTelnet/NCPの両方が中継ホストで利用可能
          ですので、ユーザはどちらがこのステップで使われるはずか選
          択しなくてはなりません。

      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.
   NCPのみのホストのユーザがTCPのみのサービスホストの対話型の
   サービスを使うことを望むと考えてください。

      1)  Use the local user Telnet program to connect via Telnet/NCP to
          the RELAY host.
      1)  Telnet/NCPで中継ホストに接続するためにローカルな
          ユーザTelnetプログラムを使ってください。

      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)  Telnet/NCPでサービスホストに接続するために中継
          ホストのユーザTelnetを使ってください。Telnet
          /TCPとTelnet/NCPの両方が中継ホストで利用
          可能ですから、ユーザはどちらがこのステップで使われるか
          選択しなくてはなりません。

      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
付録B。  FTP中継シナリオ

   Suppose a user at a TCP-only host wishes copy a file from a NCP-only
   donor host.
   TCPのみのホストのユーザがNCPのみのドナーホストからファイルを
   コピーしたいと考えていると想定します。

      Phase 1:
      第1段階:

         1)  Use the local user Telnet program to connect via Telnet/TCP
             to the RELAY host.
         1) Telnet/TCPで中継ホストに接続するためにローカルな
             ユーザTelnetプログラムを使ってください。

         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)  FTP/NCPでドナー者ホストに接続するために中継ホストの
             ユーザFTPを使ってください。

         4)  FTP login on the donor host using the regular account.
         4)  通常のアカウントを使ってドナーホストにFTPログインします。

         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)  FTPセッションを終わらせて、ドナーホストとの接続を閉じて
             ください。

         7)  Logout of the RELAY host, close the Telnet/TCP connection,
             and quit Telnet on the local host.
         7)  中継ホストからログアウトし、Telnet/TCP接続を閉じ、
             そしてローカルホストのTelnetから抜けてください。

            +---------+          +---------+          +---------+
            |         |  Telnet  |         |   FTP    |         |
            | Local   |<-------->|  Relay  |<-------->| Service |
            |  Host   |   TCP    |   Host  |   NCP    |   Host  |
            +---------+          +---------+          +---------+


      Phase 2:
      第2段階:

         1)  Use the local user FTP to connect via FTP/TCP to the RELAY
             host.
         1)  FTP/TCPで中継ホストに接続するためにローカルなユーザ
             FTPを使ってください。

         2)  FTP login on the RELAY host using the special account for
             the relay service.
         2)  中継サービスの特別アカウントを使って中継ホストにFTP
             ログインします。

         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セッションを終わらせて、そして中継ホストを切ってください。

            +---------+          +---------+
            |         |   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
付録C。  メール中継シナリオ

   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.
   TCPのみのホストのユーザがSMTPを実装したNCPのみのホストのユー
   ザへメッセージを送ることを考えてください。

      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)  バックグラウンドメーラー・デーモンは待ち行列に入れられたメッ
          セージを発見します。デーモンはインターネットアドレスを見いだす
          ためにテーブルの宛先ホスト名をチェックします。アドレスの代わり
          にデーモンは宛先ホストがNCPのみのホストである事を発見します。
          メーラー・デーモンはメール中継ホストのリストをチェック、1つを
          選択します。デーモンはSMTP手順を使ってメッセージを選ばれた
          メール中継ホストに送ります。

      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を実装し
          たNCPのみのホストであることを見いだします。メール中継ホスト
          はSMTP/NCP手順を使って宛先にメッセージを送ります。

         +---------+          +---------+          +---------+
         |         |   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.
   TCPのみのホストのユーザがNCPのみの非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)  バックグラウンドメーラー・デーモンは待ち行列に入れられたメッ
          セージを発見します。デーモンはインターネットアドレスを見い
          だすためにテーブルで宛先ホスト名をチェックします。アドレスの
          代わりに、デーモンは宛先ホストがNCPのみのホストであると
          見出します。メーラー・デーモンはメール中継ホストのリストを
          チェックして、1つを選択します。デーモンはSMTP手順を使っ
          てメッセージを選ばれたメール中継ホストに送ります。

      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)  メール中継ホストは中継するためにメッセージを受け入れます。
          中継ホストは宛先ホスト名をチェックし、宛先がNCPのみの
          非SMTPホストであることを見いだします。メール中継ホスト
          は古いFTP/NCPメール手順を使って宛先にメッセージを
          送ります。

         +---------+          +---------+          +---------+
         |         |   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".
   NCPのみの非SMTPホストのユーザがTCPのみのホストのユーザへの
   メッセージを送ることを考えてください。宛先ユーザが"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)  バックグラウンドメーラー・デーモンは待ち行列に入れられたメッ
          セージを発見します。デーモンは古いFTP/NCPメール手順を
          使ってメッセージをホスト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)はFTP/NCPメール手順で(MAIL
          あるいはMLFLコマンドで)供給された"ユーザ名"を(SMTP RCTPコマ
          ンドの)"Smith@ABC-X"に変換し、によって供給された「ユーザ名」
          を「Smith@ABC-X」に換えて、同じホストの上のSMTPメーラー・
          デーモンプログラムによって処理されるようにメッセージを待ち
          行列に入れます。メッセージヘッダやボディーに作られたメールボッ
          クスアドレスの変換はなしです。

      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)  転送ホストにのSMTPメーラー・デーモンプログラムはこの待ち
          行列に入れられたメッセージを見いだして、インターネットアドレ
          スを発見するためにテーブルの宛先ホスト名をチェックします。
          デーモンは宛先アドレスを見いだします、そしてSMTP手順を
          使ってメールを送ってください。

         +---------+          +---------+          +---------+
         |         |   FTP    |         |   SMTP   |         |
         | Source  |<-------->|Forwarder|<-------->|  Dest.  |
         |  Host   |   NCP    |   Host  |   TCP    |   Host  |
         +---------+          +---------+          +---------+

APPENDIX D.  IP/TCP Implementation Status
付録D。  IP/TCP実装状態

   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.
   この章の情報が速く時代遅れになるかもしれないことに注意してください。
   IPとTCP実装の状態に関する最新情報とは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プロセッサはC言語を実行することに向けられたネイティブの命令
      セットを持ったBBNによって設計されたシステムです。これはUNIX7版を
      サポートして、20ビットのアドレス空間でユーザ処理を提供します。
      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)はホストプロトコルに
      TCP/IPとNCPホストをサポートするユーザTelnetホスト
      です。これは32K H-316と64K C/30コンピュータで走ります。これは最
      高63の末端ポートをサポートします。これは1822のホストインタ
      フェースによってネットワークに接続します。

      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のTCPコードはその最終のテスト段階にあります。コードは
      MPE IVオペレーティングシステム下で特別な高優先プロセスです。
      MPE IVがカーネルを持っていないので、これはオペレーティング・シス
      テムカーネルの一部ではありません。プロトコル処理はTCPとIPと
      1822を含みます、そしてHDHと呼ばれる新しいプロトコルが
      1822メッセージをHDLCリンク上に送ることを可能にします。プ
      ロトコル処理は約8Kバイトのコードと割り当てられたバッファに依存
      して少なくとも20Kバイトのデータを持っています。

      In addition to the TCP the HP3000 has user and server TELNET as
      well as user FTP.  A server FTP may be added later.
      TCPに加えて、HP3000はユーザとサーバのTELNETとユーザの
      FTPを持っています。サーバFTPが後で加えられるかもしれません。

      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.
      このTCP実装はCで書かれました。これはネットワークアクセスのた
      めにBBNによって加えられた修正で、UNIX6版のユーザープロセスとし
      て作動します。これはユーザとサーバのTelnetをサポートします。

      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とリリース4の一部として
      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.
      IP層上に、モニタを含む2つのインターネット・プロトコルがありま
      す(TCP4とGGP)。加えて、「インターネットユーザキュー」インター
      フェースにより、8つ(実際はモニターアセンプリパラメータ)までの
      プロトコルがユーザーモードプログラムとして実装されます。GGPあるい
      はゲートウェイゲートウェイプロトコルがメッセージ流れをコントロール
      するためにインターネットゲートウェイから助言を受け取るために使われ
      ます。GGPコードは変更中で、ICMPプロトコルが加えられています。

      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は他のモニターによって供給されたプロトコルです、そしてそれは
      2種類の接続−通常のデータ接続と「TCP仮想端末」(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が標準の(「新しい」)TELNETプロトコルを使うことに注意し
      てください。これは実際はARPANETのNCPで使われたのと同じで、主に
      同じコードで実行されます。

      Performance improvements, support for the new address formats, and
      User and Server FTP processes above the TCP layer are under
      development.
      性能の改良と、新しいアドレスフォーマットのサポートと、TCP層の上
      のユーザとサーバFTP処理が開発下にあります。

   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のためにCでに書かれていま
      す、そしてUNIXカーネル上で動作します。これはいくつかのサイトで
      VAX 11/780と750上で動いています、そして1982年の早期に入手可
      能になっています。

      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.
      実装はTCPとIP仕様(RFC791、793)に従います。実装は
      新しい拡張されたインターネットアドレスフォーマットとGGPとIC
      MPの両方をサポートします。これは同じく多数のネットワークアクセス
      プロトコルとデバイス・ドライバをサポートします。ARPANET 1822とACC
       LH/DH-11ドライバは別として、実験的なドライバもイーサネットのため
      に開発されました。TCPと独立に、IPとローカルネットワークアクセ
      スレイヤにアクセスする、ユーザインタフェースがあります。

      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とMTPとFTPを含みます。同じ
      くデバッグ目的でネットワークトラフィックをモニタして記録することに
      利用可能なツールがあります。

      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とFTPと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のネットワークアクセスのためのものの
      修正で、第6版UNIXで、ユーザープロセスとして作動します。IPは
      データグラムの破片を組み立てますが、IP分解のユーザインタフェー
      スを持っていません。TCPはユーザとサーバのTelnet、エコー、廃棄、
      インターネットメールとファイル転送サービスをサポートします。IC
      MPはエコー要請への返答を生成し、組み立てバッファが満杯のとき、
      送信元抑制を送ります。

      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第6版を走らせているPDP-11/70と
      PDP-11/45。ソフトウェア−Cで書かれました、25Kの命令空間と、20K
      のデータ空間が必要です。10の接続をサポートします。

   DTI VAX

      Date:  15 May 1981
      From:  Gary Grossman <grg@DTI)>

      Digital Technology Incorporated (DTI) IP/TCP for VAX/VMS
      VAX/VMSのためのデジタル技術社(DTI)IP / TCP

      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ネットワークソフトウェアパッケージの一部とし
      て、1981年第4四半期に売り込みを計画するIPとTCP実装の
      記述です。

      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。オペレーティング・システム:
      DECスタンダードVAX/VMリリース2.0以上。実装言語:主にC、
      いくらかのマクロ。サポートされた接続:最大64。

      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に実装されます。これはおよそ
      18カ月間実験的運用でした;システムへの特定の原稿はハネウェル
      によってリリースされるとすぐに、非公式に配布できます。TCPとIP
      パッケージは現在、性能、特に高いスループットデータ転送のために調整
      されています。

      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.
      TCPとIPは良いログとデバッギング能力を含みます、そしてそれは
      他の実装の点検で有用と分かりました。これ以上の情報は我々に連絡を
      取ってください。

   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.
      パケット無線端末インタフェースユニットのためのIP/TCP実装は
      MOSリアルタイムオペレーティング・システム下のLSI-11上で走らせる
      ように意図されます。TCPはMACRO-11アセンブラ言語で書かれます。
      IPは現在アセンブラ言語で書かれます;しかしCに変換されています。
      TCPをアセンブラからCへ変換する計画がありません。

      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.
      TCPは完全仕様を実行します。TCPは機能上すべての他の主要な実
      装と両立できるように思われます。特に、これは日単位で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.
      IP実装は、分割と組み立ての;最初のゲートウェイへの経路指定;完全
      なホストサイド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.
      現在TCPとIP統計値を集める測定収集メカニズムが開発中で、データ
      縮小のために測定ホストにこれらを配達します。

   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"インタフェースを持つ、
      IBM360あるいは370。

      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(IBMのマクロアセンプリ言語)

      User-Level Protocols Available:  User and Server Telnet
      ユーザーレベル利用可能なプロトコル:ユーザとサーバTelnet

Japanese translation by Ishida So