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


RFC:  814

                   NAME, ADDRESSES, PORTS, AND ROUTES
                      名前とアドレスとポートと経路
                             David D. Clark
                  MIT Laboratory for Computer Science
               Computer Systems and Communications Group
                               July, 1982

     1.  Introduction
     1.  はじめに

     It has been said that the principal function of an operating system
is to define a number of different names for the same object, so that it
can  busy  itself  keeping  track of the relationship between all of the
different names.  Network protocols  seem  to  have  somewhat  the  same
characteristic.    In  TCP/IP,  there  are  several ways of referring to
things.  At the human visible  interface,  there  are  character  string
"names"  to  identify  networks,  hosts,  and  services.  Host names are
translated into network "addresses", 32-bit  values  that  identify  the
network  to  which  a  host is attached, and the location of the host on
that net.  Service names are translated into a "port identifier",  which
in  TCP  is  a  16-bit  value.    Finally, addresses are translated into
"routes", which are the sequence of steps a packet must  take  to  reach
the  specified  addresses.  Routes show up explicitly in the form of the
internet routing options, and also implicitly in the  address  to  route
translation tables which all hosts and gateways maintain.
     オペレーティング・システムの主な機能は、同じオブジェクトに多くの異
なった名前を定義する事と言われ、それで異なった名前のすべての間の関係を記
録・追跡するのに忙しくなります。ネットワークプロトコルが幾分同じ特徴を持
つように思われます。TCP/IPで、物を参照するいくつかの方法があります。
人間の目に見えるインタフェースにおいて、ネットワークとホストとサービスを
識別するための文字列「名前」があります。ホスト名が32ビットのネットワー
ク「アドレス」に翻訳され、これはホストが接続するネットワークと、そのネッ
ト上のホストの位置を示します。サービス名が「ポート識別子」に変換され、こ
れはTCPで16ビット値です。最終的に、アドレスが「経路」に変換され、こ
れはパケットが指定されたアドレスに着くためにとらなくてはならないステップ
の連続です。経路が明示的にインターネットルーティングオプションのかたちで、
そして暗黙のうちにすべてのホストとゲートウェイが維持する経路翻訳テーブル
に現われます。

     This  RFC  gives  suggestions  and  guidance  for the design of the
tables and algorithms necessary to keep track of these various sorts  of
identifiers inside a host implementation of TCP/IP.
     このRFCはTCP/IPのホスト実装中にこれらの種々種類の識別子を
記録・追跡するために必要なテーブルとアルゴリズムの設計のための提案と指導
を与えます。

     2.  The Scope of the Problem
     2.  問題の範囲

     One  of the first questions one can ask about a naming mechanism is
how many names one can expect to encounter.  In order to answer this, it
is necessary to know something about the expected maximum  size  of  the
internet.  Currently, the internet is fairly small.  It contains no more
than  25  active  networks,  and no more than a few hundred hosts.  This
makes it possible to install tables which exhaustively list all of these
elements.  However, any implementation undertaken now should be based on
an assumption of a much  larger  internet.    The  guidelines  currently
recommended  are  an upper limit of about 1,000 networks.  If we imagine
an average number of 25 hosts per net,  this  would  suggest  a  maximum
number  of 25,000 hosts.  It is quite unclear whether this host estimate
is high or low, but even if it is off by several  factors  of  two,  the
resulting  number  is  still  large enough to suggest that current table
management strategies are unacceptable.  Some fresh techniques  will  be
required to deal with the internet of the future.
     名前メカニズムに対する最初の問題は、いくつの名前に遭遇すると予期す
べきかです。これに答えるために、インターネットの予想される最大の大きさに
ついて何かを知ることが必要です。現在、インターネットはかなり小さいです。
これは25以上のアクティブなネットワークと数百のホスト以上の何も含んでい
ません。これは徹底的にこれらすべての要素をリストアップするテーブルを持つ
ことを可能にします。しかしながら、今開発している実装はは、ずっと大きいイ
ンターネットを仮定すべきです。現在推薦されたガイドラインは上限がおよそ
1,000のネットワークです。もし我々がネットワーク毎に平均25のホスト
数を想像するなら、これは25,000のホストの最大数を提案するでしょう。
このホスト見積もりが高いか低いかは非常に不明確です、しかしたとえこれが数
桁外れるとしても、その結果の数は現在テーブル管理戦略で受け入れ難いことを
示唆するのに十分大きいです。何らかの新しい技術が未来のインターネットを扱
うように要求されるでしょう。

     3.  Names
     3.  名前

     As the previous section suggests, the internet will eventually have
a  sufficient  number  of  names  that a host cannot have a static table
which provides a translation from every name to its associated  address.
There  are  several  reasons  other than sheer size why a host would not
wish to have such a table.  First, with that many names, we  can  expect
names  to  be  added  and deleted at such a rate that an installer might
spend all his time just revising the table.  Second, most of  the  names
will  refer  to  addresses  of  machines with which nothing will ever be
exchanged.  In fact, there may be whole networks with which a particular
host will never have any traffic.
     前の章が示唆するように、インターネットは結局はホストが静的に名前か
らアドレスへの変換をするテーブルでもてないほどの数の名前を持つでしょう。
ホストがこのようなテーブルを持つことが望ましくない大きさ以外のいくつかの
理由があります。最初に、この多くの名前は、設置者が常にテーブルの修正をし
続けないといけないほどの頻度で名前の追加削除が予想されます。第二に、名前
の大部分は機械が通信を行わないアドレスに関するものでしょう。実際、特定の
ホストが通信をしないネットワークがあるかもしれません。

     To  cope  with  this  large  and  somewhat dynamic environment, the
internet is moving from its current position  in  which  a  single  name
table  is  maintained  by  the  NIC  and  distributed to all hosts, to a
distributed approach in which each network (or  group  of  networks)  is
responsible  for maintaining its own names and providing a "name server"
to translate between the names and the addresses in that network.   Each
host   is   assumed   to  store  not  a  complete  set  of  name-address
translations, but only a cache of recently used names.  When a  name  is
provided  by  a  user for translation to an address, the host will first
examine its local cache, and if  the  name  is  not  found  there,  will
communicate  with  an appropriate name server to obtain the information,
which it may then insert into its cache for future reference.
     この広くいくらか動的な環境にうまく対処するために、インターネットは
現在のひとつのNICにより維持される全ホストに配布される名前テーブルから、
それぞれのネットワーク(あるいはネットワークグループ)がそれ自身の名前を
維持しそのネットワークの名前とアドレスの翻訳をするための「ネームサーバ」
を供給することに責任がある分散方式に移行します。それぞれのホストが名前ア
ドレス翻訳の全体を持つのではなく、ただ最近使われた名前のキャッシュだけを
持つと考えられます。アドレスに翻訳するために名前がユーザから供給される時、
ホストは最初にそのローカルなキャッシュを調べるでしょう、そして名前がそこ
になければ、適切なネームサーバと通信して情報を得て、将来の参照に備えて
キャッシュに挿入するかもしれません。

     Unfortunately, the name server mechanism is not totally in place in
the internet yet, so for the moment, it is necessary to continue to  use
the  old  strategy of maintaining a complete table of all names in every
host.  Implementors, however, should structure this table in such a  way
that  it  is  easy  to  convert  later  to  a  name server approach.  In
particular, a reasonable programming strategy would be to make the  name
table  accessible  only  through  a subroutine interface, rather than by
scattering direct references to the table all through the code.  In this
way, it will be possible, at a later date,  to  replace  the  subroutine
with one capable of making calls on remote name servers.
     不幸にも、ネームサーバメカニズムはインターネットでまだ決定されてお
らず、それで差し当たり、すべてのホストですべての名前の完全なテーブルを維
持する古い戦略を使い続けることは必要です。実装者が、しかしながら、後にネー
ムサーバの方式に換えることが容易になる方法でこのテーブルを構造化するべき
です。特に、合理的なプログラム戦略は、コード内にテーブルの直接参照をまき
散らすのではなく、すべてコードで名前テーブルをサブルーチンインタフェース
を通して行うことでしょう。このようにして、サブルーチンを遠隔ネームサーバ
の呼び出しをするものに置き換えることは、後日可能であるでしょう。

     A  problem  which  occasionally arises in the ARPANET today is that
the information in a local host table is out of date, because a host has
moved,  and a revision of the host table has not yet been installed from
the NIC.  In this case, one attempts to connect to a particular host and
discovers an unexpected machine at the address obtained from  the  local
table.    If  a  human is directly observing the connection attempt, the
error  is  usually  detected  immediately.    However,  for   unattended
operations  such as the sending of queued mail, this sort of problem can
lead to a great deal of confusion.
     今日ARPANETで時折起こる問題は、ローカルホストテーブルでの情
報が、ホストの移動しNICからホストテーブルの修正がインストールされてい
ないため、時代遅れであるということです。この場合、特定のホストに接続しよ
うと試みて、ローカルテーブルから得られたアドレスで予期せぬ機械を発見しま
す。もし接続の試みを直接人が観察しているなら、エラーは通常すぐに検出され
ます。しかしながら、待ち行列に入れられたメールを送ることのような、人がい
ないオペレーションで、この種の問題は多くの混乱を導きます。

     The nameserver scheme will only make this problem worse,  if  hosts
cache  locally  the  address associated with names that have been looked
up, because the host has no way of knowing when the address has  changed
and the cache entry should be removed.  To solve this problem, plans are
currently  under  way  to  define  a simple facility by which a host can
query a foreign address to determine what name  is  actually  associated
with  it.    SMTP already defines a verification technique based on this
approach.
     もしホストがいつアドレスが変化しキャッシュを削除すべきか知る方法を
持たずに、単にホストがローカルにに検索された名前とアドレスをキャッシュす
るなら、ネームサーバ案はこの問題を悪化するでしょう。この問題を解くために、
ホストが外部アドレスにその名前が何かを問い合わせる単純な機能を定義する計
画が現在進行中です。SMTPがすでにこのアプローチに基づく検証技術を定義
します。

     4.  Addresses
     4.  アドレス

     The IP layer must know something about addresses.   In  particular,
when  a datagram is being sent out from a host, the IP layer must decide
where to send it on the immediately  connected  network,  based  on  the
internet address.  Mechanically, the IP first tests the internet address
to  see  whether  the network number of the recipient is the same as the
network number of the sender.  If so, the packet can be sent directly to
the final recipient.  If not, the datagram must be sent to a gateway for
further forwarding.  In this latter case,  a  second  decision  must  be
made, as there may be more than one gateway available on the immediately
attached network.
     IPレイヤはアドレスについて何かを知っていなくてはなりません。特に、
データグラムがホストから送られている時、IPレイヤは、インターネットアド
レスに基づいていて、直接接続されたネットワーク上のどこにそれを送るべきか
決めなくてはなりません。機械的に、IPは受信ネットワーク番号が送信者のネッ
トワーク番号と同じであるかどうか見るために、最初にインターネットアドレス
をテストします。もしそうであるなら、パケットは直接最終受信者に送ることが
できます。もしそうでなければ、データグラムは以降おの転送のためにゲートウェ
イに送られなくてはなりません。この後の場合、直接接続するネットワーク上に
利用可能な複数のゲートウェイがあるかもしれないから、瞬間的な決断がされな
くてはなりません。

     When  the  internet address format was first specified, 8 bits were
reserved  to  identify  the  network.     Early   implementations   thus
implemented  the  above  algorithm by means of a table with 256 entries,
one for each possible net, that specified the gateway of choice for that
net, with a special case entry for those nets  to  which  the  host  was
immediately connected.  Such tables were sometimes statically filled in,
which caused confusion and malfunctions when gateways and networks moved
(or crashed).
     インターネットアドレスフォーマットが最初に指定された時、8ビットが
ネットワークを識別するために予約されました。初期の実装はそれで上記のアル
ゴリズムを、それぞれのネットワークのゲートウェイを指定する256個の要素
を持つテーブルで実装しました、ホストが接続しているネットは特別な場合の要
素です。このようなテーブルは時々静的に記入され、そしてゲートウェイとネッ
トワークが変わると混乱と故障(あるいは停止)を起こしました。

     The  current  definition  of  the  internet  address provides three
different options for network numbering, with the  goal  of  allowing  a
very  large  number of networks to be part of the internet.  Thus, it is
no longer possible to imagine having an exhaustive  table  to  select  a
gateway  for any foreign net.  Again, current implementations must use a
strategy based on a local cache of  routing  information  for  addresses
currently being used.
     インターネットアドレスの現在の定義は、多数のネットワークがインター
ネットに参加できるように、ネットワーク番号に3つの異なる選択を供給します。
それで、どんな外のネットワークのためのゲートウェイを選択するために徹底的
なテーブルを持つと想像することは可能ではありません。現在の実装は、現在使
われているアドレスのために、ルーティング情報のローカルキャッシュに基づい
た作戦を使わなくてはなりません。

     The  recommended  strategy  for  address to route translation is as
follows.    When  the  IP  layer  receives  an  outbound  datagram   for
transmission,  it  extracts  the  network  number  from  the destination
address, and queries its local table to determine  whether  it  knows  a
suitable  gateway to which to send the datagram.  If it does, the job is
done.    (But  see  RFC  816  on  Fault  Isolation  and  Recovery,   for
recommendations  on  how  to  deal  with  the  possible  failure  of the
gateway.)  If there is no such entry in the local table, then select any
accessible  gateway at random, insert that as an entry in the table, and
use it to send the packet.  Either the guess will be right or wrong.  If
it is wrong, the gateway to which the packet was  sent  will  return  an
ICMP  redirect message to report that there is a better gateway to reach
the net in question.  The arrival  of  this  redirect  should  cause  an
update of the local table.
     アドレスから経路への翻訳の推薦された戦略は次の通りです。IPレイヤ
が送信のために外行きのデータグラムを受け取る時、宛先アドレスからネットワー
ク番号を抽出し、そしてデータグラムを送る適当なゲートウェイを知っているか
どうか決定するためにそのローカルテーブルに問い合わせます。もしあれば仕事
をします。(どのようにゲートウェイ障害を扱うかの推薦について、RFC816
の障害隔離と回復を見てください)。もしローカルテーブルにこのような項目が
ないなら、ランダムにアクセス可能なゲートウェイを選択し、テーブルのその項
目を挿入し、パケットを送るためにそれを使います。推測は正しいか間違ってる
かです。もし間違っているなら、パケットが送られたゲートウェイはあて先ネッ
トに届くもっと良いゲートウェイがあると報告するICMPリダイレクトメッセー
ジを返すでしょう。このリダイレクトの到着はローカルテーブルの更新を起こす
べきです。

     The  number  of  entries in the local table should be determined by
the maximum number of active connections which this particular host  can
support  at  any  one  time.  For a large time sharing system, one might
imagine a table with 100 or more entries.  For a personal computer being
used to support a single user telnet connection,  only  one  address  to
gateway association need be maintained at once.
     ローカルテーブルの項目の数は、この特定のホストが一度にサポートでき
るアクティブな接続の最大数によって決定されるべきです。長時間の共有システ
ムで、100以上の項目のテーブルを想像するかもしれません。使われているパー
ソナル・コンピュータが一人のユーザのtelnet接続をサポートするために
は、同時にひとつのアドレスとゲートウェイの関連だけが維持されればよいです。

     The  above strategy actually does not completely solve the problem,
but only pushes it down one level, where the problem then arises of  how
a  new  host,  freshly  arriving  on  the  internet,  finds  all  of its
accessible gateways.  Intentionally, this problem is not  solved  within
the  internetwork  architecture.   The reason is that different networks
have drastically different strategies for allowing a host  to  find  out
about  other  hosts  on  its  immediate  network.    Some  nets permit a
broadcast mechanism.  In this case, a host can send out  a  message  and
expect  an  answer  back  from  all  of the attached gateways.  In other
cases, where a particular network  is  richly  provided  with  tools  to
support  the  internet, there may be a special network mechanism which a
host can invoke to determine where the gateways are.  In other cases, it
may be necessary for an installer to manually provide  the  name  of  at
least  one  accessible  gateway.  Once a host has discovered the name of
one gateway, it can build up a table of all other available gateways, by
keeping track of every gateway that has been reported back to it  in  an
ICMP message.
     上記の戦略は実際には完全に問題を解いていませんが、しかしただ1レベ
ル下がっただけで、そして、インターネットの上に新たに登場したホストが、ア
クセス可能なゲートウェイのすべてを見いだすか、という問題はが生じます。意
図的に、この問題はインターネット体系内で解かれません。ホストに即時にネッ
トワーク上の他のホストを発見することを許すことに対して、理由は異なるネッ
トワークが劇的に異なった作戦を持っているということです。あるネットがブロー
ドキャスト機構を認めます。この場合、ホストがメッセージを送り、そして接続
したゲートウェイのすべてから返事が戻ることを期待できます。他の場合、特定
のネットワークが豊富にインターネットをサポートするツールを提供する場合、
ホストがゲートウェイがどこにあるか決定するために呼び出すことができる特別
なネットワークメカニズムがあるかもしれません。他の場合に、手作業で少なく
とも1つのアクセス可能なゲートウェイの名前を供給することは導入時に必要で
あるかもしれません。ホストが1つのゲートウェイの名前を発見したら、ICM
Pメッセージで報告されたすべてのゲートウェイを記録・追跡することによって、
すべての他の利用可能なゲートウェイのテーブルを増強することができます。

     5.  Advanced Topics in Addressing and Routing
     5.  アドレスとルーティングの進捗トピック

     The  preceding  discussion  describes  the  mechanism required in a
minimal implementation,  an  implementation  intended  only  to  provide
operational  service  access  today to the various networks that make up
the internet.  For any host which will participate in  future  research,
as  contrasted  with  service,  some  additional  features are required.
These features will also be helpful for service hosts if  they  wish  to
obtain access to some of the more exotic networks which will become part
of  the internet over the next few years.  All implementors are urged to
at least provide a structure into which these features  could  be  later
integrated.
     前の議論は、インターネットを構成する種々のネットワークに運用上のサー
ビスアクセスを供給することだけをするように意図された実装、最小実装で必要
とされるメカニズムを記述します。将来の研究に参加するホストでは、サービス
と対比して、ある追加の特徴が必要とされます。これらの特徴は、もし次の数年
にわたってインターネットの一部になるであろういっそうエキゾチックなあるネッ
トワークにアクセスを得ることを望むなら、サービスホストのために同じく助け
になるでしょう。すべての実装者は少なくともこれらの特徴が後で統合化できる
構造体を供給するようしきりに促されます。

     There   are   several  features,  either  already  a  part  of  the
architecture or now under development,  which  are  used  to  modify  or
expand  the  relationships  between addresses and routes.  The IP source
route options allow a host to explicitly direct  a  datagram  through  a
series of gateways to its foreign host.  An alternative form of the ICMP
redirect  packet  has  been  proposed,  which  would  return information
specific to a  particular  destination  host,  not  a  destination  net.
Finally, additional IP options have been proposed to identify particular
routes  within  the internet that are unacceptable.  The difficulty with
implementing these new features  is  that  the  mechanisms  do  not  lie
entirely within the bounds of IP.  All the mechanisms above are designed
to apply to a particular connection, so that their use must be specified
at  the  TCP level.  Thus, the interface between IP and the layers above
it must include mechanisms to allow passing this  information  back  and
forth,  and TCP (or any other protocol at this level, such as UDP), must
be prepared to store this  information.    The  passing  of  information
between IP and TCP is made more complicated by the fact that some of the
information,  in  particular  ICMP packets, may arrive at any time.  The
normal interface envisioned between TCP  and  IP  is  one  across  which
packets  can  be  sent  or received.  The existence of asynchronous ICMP
messages implies that there must be an additional  channel  between  the
two,  unrelated  to the actual sending and receiving of data.  (In fact,
there are many other ICMP messages which arrive asynchronously and which
must be passed from IP  up  to  higher  layers.    See  RFC  816,  Fault
Isolation and Recovery.)
     体系の一部になったるかもしくは開発下のいくつかの機能があり、これら
はアドレスと経路の関係の変更か拡張に使われます。IPソース経路オプション
はホストが明示的に一連のゲートウェイを通してデータグラムを外のホストに向
けることを許します。ICMPリダイレクトパケットの代わりの形式が提案され、
そしてこれは宛先ネットではなく特定の宛先ホストに固有な情報を返すでしょう。
最終的に、追加のIPオプションがインターネットの中の特定の到達できない経
路を識別するために提案されました。これらの新しい機能を実行することでの困
難さはメカニズムがIPの範囲内に完全に入らないということです。すべての上
記のメカニズムは特定の接続に適用するよう意図されます、それでそれらの使用
はTCPレベルにおいて指定されなくてはなりません。それで、IPとその上の
レイヤの間のインタフェースは、この情報を前後に渡す機構を持ち、TCP(あ
るいはUDPのような同レベルの他のプロトコル)はこの情報を保管する準備が
必要です。IPとTCPの間の情報の通過は情報のいくつかが、特定のICMP
パケットで、いつでも到着できるという事実によってより複雑にされます。TC
PとIPの間に想像された標準的なインタフェースは、パケットを送るか受取る
かです。非同期のICMPメッセージの存在は、データを実際に送ったり受け取っ
たりすることと無関係で、2者間に追加のチャネルがあるにことを意味します。
(実際、IPからより高いレイヤまで非同時的に到着すり渡さなければならない
多くの他のICMPメッセージがあります。RFC816のか着ると回復を参照
してください)。

     Source  routes  are  already  in  use  in  the  internet,  and many
implementations will wish to be able to take advantage  of  them.    The
following  sorts  of  usages  should  be permitted.  First, a user, when
initiating a TCP connection, should be able to hand a source route  into
TCP,  which in turn must hand the source route to IP with every outgoing
datagram.  The user might initially obtain the source route by  querying
a  different  sort  of  name  server,  which would return a source route
instead of an address, or the user may have fabricated the source  route
manually.    A  TCP  which  is  listening  for a connection, rather than
attempting to open one, must be prepared to  receive  a  datagram  which
contains  a  IP return route, in which case it must remember this return
route, and use it as a source route on all returning datagrams.
     ソースルートはインターネットですでに使用中で、そして多くの実装がそ
れらを利用することが可能であることを望むでしょう。次の種類の使用は認めら
れるべきです。最初に、ユーザが、TCP接続を始める時、TCPにソースルー
トを渡すことが可能であるべきで、そしてTCPはすべての外向データグラムで
IPにソースルートを渡さなくてはなりません。ユーザは、アドレスの代わりに
ソースルートを返すような異なる種類のネームサーバに問い合わせることで初め
にソースルートを得るかもしれません、あるいはユーザは手作業でソースルート
を造りあげたかもしれません。接続を待つTCPが、1つを開く試みより、IP
返送経路を含むデータグラムを受け取る用意ができているに違いありません、そ
の場合TCPはこの応答経路を覚えていて、そしてすべての返すデータグラムで
これをソースルートとして用いなくてはなりません。

     6.  Ports and Service Identifiers
     6.  ポートとサービス識別子

     The  IP  layer of the architecture contains the address information
which specifies the destination host to  which  the  datagram  is  being
sent.    In  fact, datagrams are not intended just for particular hosts,
but for particular agents within a host,  processes  or  other  entities
that  are  the  actual  source and sink of the data.  IP performs only a
very simple dispatching once the datagram  has  arrived  at  the  target
host,   it   dispatches  it  to  a  particular  protocol.    It  is  the
responsibility of that protocol handler,  for  example  TCP,  to  finish
dispatching  the  datagram  to the particular connection for which it is
destined.    This  next  layer  of  dispatching  is  done  using   "port
identifiers",  which  are  a  part  of  the  header  of the higher level
protocol, and not the IP layer.
     体系のIPレイヤはデータグラムを送る宛先ホストを指定するアドレス情
報を含んでいます。実際、データグラムは特定のホストのためだけを意図せず、
ホスト内の特定のエージェントや、プロセスや、実際のデータの生成元や蓄積元
であるエンティティも意図します。IPは非常に単純な処理を行い、データグラ
ムが目標ホストに到着した途端に特定のプロトコルにそれを送ります。特定の接
続にデータグラムを対応付けるのは、例えばTCPなどのプロトコルハンドラの
責任です。この次のレイヤの対応付けは「ポート識別子」を使ってされ、そして
これはIPレイヤではなく、もっとレベルが高いプロトコルのヘッダの一部です。

     This two-layer dispatching architecture has caused  a  problem  for
certain  implementations.    In  particular,  some  implementations have
wished to put the IP layer within the kernel of  the  operating  system,
and  the  TCP  layer  as  a  user  domain  application  program.  Strict
adherence to this partitioning can lead to grave  performance  problems,
for  the  datagram  must  first  be  dispatched from the kernel to a TCP
process, which then dispatches the datagram  to  its  final  destination
process.   The overhead of scheduling this dispatch process can severely
limit the achievable throughput of the implementation.
     2層の体系はある特定の実装の問題を起こしました。特に、ある実装がI
Pレイヤをオペレーティング・システムのカーネルとして、TCPレイヤをユー
ザードメインアプリケーションプログラムとして置くことを望みました。この分
割の厳密な維持は性能の問題を導きます、なぜならデータグラムは最初にカーネ
ルからTCPプロセスに渡され、TCPプロセスがデータグラムをその最終の宛
先プロセスに渡します。この転送プロセスをスケジューリングするオーバーヘッ
ドはひどく実装の達成可能なスループットを制限します。

     As is discussed in RFC 817, Modularity and Efficiency  in  Protocol
Implementations,  this  particular  separation  between  kernel and user
leads to other performance problems, even ignoring  the  issue  of  port
level  dispatching.   However, there is an acceptable shortcut which can
be taken to move the higher  level  dispatching  function  into  the  IP
layer, if this makes the implementation substantially easier.
     RFC817のプロトコル実装のモジュール性と効率インプリメンテーショ
ンで論じられるように、このカーネルとユーザ間の特定の分離はポートレベルの
対応付けの問題を無視しても他性能問題に導きます。しかしながら、受入れ可能
な手段があります、もしこれで実装が十分に容易になるなら、IP層の中に上位
レベル分析関数を動かすことが出来ます。

     In  principle,  every  higher level protocol could have a different
dispatching  algorithm.    The  reason  for  this  is  discussed  below.
However,  for  the  protocols  involved  in  the  service offering being
implemented today, TCP and UDP, the dispatching algorithm is exactly the
same, and the port field is located in precisely the same place  in  the
header.  Therefore, unless one is interested in participating in further
protocol  research,  there  is only one higher level dispatch algorithm.
This algorithm takes into account the internet  level  foreign  address,
the protocol number, and the local port and foreign port from the higher
level  protocol  header.  This algorithm can be implemented as a sort of
adjunct to the IP layer implementation, as long as no other higher level
protocols are to be implemented.  (Actually, the above statement is only
partially true, in that the UDP dispatch function is subset of  the  TCP
dispatch  function.  UDP dispatch depends only protocol number and local
port.  However, there is an occasion within TCP  when  this  exact  same
subset comes into play, when a process wishes to listen for a connection
from  any  foreign  host.    Thus,  the range of mechanisms necessary to
support TCP dispatch are also sufficient to support  precisely  the  UDP
requirement.)
     原則として、すべての上位レベルプロトコルが異なる配達アルゴリズムを持つ
ことができます。この理由は下記に論じられます。しかしながら、今日実装されてい
るサービス提供に関係しているプロトコル、TCPとUDPで、配達アルゴリズムは
正確に同じで、そしてポートフィールドは正確にヘッダの同じ場所に位置しています。
それ故に、これ以上のプロトコル研究に参加することに興味を持たないなら、ただ1
つだけの上位レベル配達アルゴリズムがあります。このアルゴリズムはインターネッ
トレベルの外のアドレスと、プロトコル番号と、上位レベルヘッダのローカルと外の
ポートを考慮に入れます。このアルゴリズムは、他の上位レベルプロトコルが実装さ
れない限り、IPレイヤ実装の一種の付属物として実装することができます。(実際
に、上記の文は、UDP配達機能がTCP配達機能の下位グループであるという点で、
ただ部分的に本当です。UDP配達はプロトコル番号とローカルポートだけに依存し
ます。しかしながら、TCP内にこの正確に同じ下位グループが活動する機会があり
ます、プロセスが外のホストからの接続を待つときです。それで、TCP配達をサポー
トするために必要なメカニズムは同じく正確にUDP必要条件をサポートすることに
十分です。)

     The decision to remove port level dispatching from IP to the higher
level  protocol  has  been questioned by some implementors.  It has been
argued that if all of the address structure were part of the  IP  layer,
then IP could do all of the packet dispatching function within the host,
which  would  lead  to  a  simpler  modularity.    Three  problems  were
identified with this.  First, not all protocol implementors could  agree
on  the  size  of the port identifier.  TCP selected a fairly short port
identifier, 16 bits, to reduce  header  size.    Other  protocols  being
designed,  however, wanted a larger port identifier, perhaps 32 bits, so
that the port identifier, if  properly  selected,  could  be  considered
probabilistically  unique.    Thus,  constraining  the  port  id  to one
particular IP level mechanism would prevent certain  fruitful  lines  of
research.    Second,  ports  serve  a  special  function  in addition to
datagram delivery:   certain  port  numbers  are  reserved  to  identify
particular services.  Thus, TCP port 23 is the remote login service.  If
ports  were  implemented  at  the  IP level, then the assignment of well
known ports could not be done on a protocol basis, but would have to  be
done  in a centralized manner for all of the IP architecture.  Third, IP
was designed with a very simple layering role:    IP  contained  exactly
those functions that the gateways must understand.  If the port idea had
been  made a part of the IP layer, it would have suggested that gateways
needed to know about ports, which is not the case.
     IPから上位レベルプロトコルまでの配達で、ポートを削除する決定はあ
る実装者で問題にされました。もしアドレス構造体のすべてがIP層の一部なら、
IPはホスト内ですべてのパケットの配達が可能で、より単純なモジュール性に
導くであろうと論じられました。3つの問題がこれと同一視されました。最初に、
すべてのプロトコル実装者がポート識別子の大きさについて合意することができ
たわけではありません。TCPはかなり短いポート識別子、16ビットを、ヘッ
ダサイズを減らすよう選びました。設計されている他のプロトコルは、しかしな
がら、より大きいポート識別子、多分32ビットを欲しました、それでポート識
別子は、もし正確に選択されるなら、確率的にユニークであると思うことができ
ました。それで、ポートIDを1つの特定のIPレベルメカニズムに限定するこ
とは研究可能性を妨げるでしょう。第二に、ポートがデータグラム配達のほかに
特別な機能を果たします:ある特定のポート番号が特定のサービスを識別するた
めに予約されます。それで、TCPポート23はリモートログインサービスです。
もしポートがIPレベルにおいて実装されたなら、機知ポートの割当てはプロト
コル基礎上ですることができず、IP体系のすべてのために中央集権化された方
法でされなければならないでしょう。第三に、IPが非常に単純なレイヤの役割
で設計されました:IPが正確にゲートウェイが理解しなくてはならない機能を
含んでいます。もしポートの考えがIP層の一部にされたなら、それはゲートウェ
イがポートについて知る必要があることを示唆しますが、このような場合はあり
ません。

     There are, of course, other ways  to  avoid  these  problems.    In
particular,  the  "well-known  port" problem can be solved by devising a
second mechanism, distinct from port  dispatching,  to  name  well-known
ports.   Several protocols have settled on the idea of including, in the
packet which sets up a  connection  to  a  particular  service,  a  more
general  service  descriptor,  such  as a character string field.  These
special  packets,  which  are  requesting  connection  to  a  particular
service,  are  routed on arrival to a special server, sometimes called a
"rendezvous server", which  examines  the  service  request,  selects  a
random  port  which  is to be used for this instance of the service, and
then passes the packet along to  the  service  itself  to  commence  the
interaction.
     もちろん、これらの問題を避ける他の方法があります。特に、「既知ポー
ト」問題は、既知ポートを指定するために、ポートの配達と異なる2番目のメカ
ニズムを考案することによって解くことができます。いくつかのプロトコルが、
文字列フィールドのような一般的なサービス記述子を、接続を準備するパケット
に含めるアイデアを採用しました。特定のサービスに接続を求めているこれらの
特別なパケットは、時々「ランデブーサーバ」と呼ばれる特別なサーバに送られ、
そしてサーバはサービスの要求を調べて、このサービスに実際に使われるはずで
ある任意のポートを選び、そして次に対話を開始するサービス自身にパケットを
伝え送ります。

     For  the  internet architecture, this strategy had the serious flaw
that it presumed all protocols would fit into the same service paradigm:
an initial setup phase, which might contain a certain overhead  such  as
indirect routing through a rendezvous server, followed by the packets of
the  interaction  itself,  which  would  flow  directly  to  the process
providing the service.  Unfortunately, not all high level  protocols  in
internet  were  expected to fit this model.  The best example of this is
isolated datagram exchange using UDP.  The simplest exchange in  UDP  is
one process sending a single datagram to another.  Especially on a local
net,  where  the  net  related overhead is very low, this kind of simple
single datagram interchange can be extremely efficient,  with  very  low
overhead  in  the  hosts.  However, since these individual packets would
not be part of an established connection, if  IP  supported  a  strategy
based  on  a  rendezvous  server and service descriptors, every isolated
datagram would have to  be  routed  indirectly  in  the  receiving  host
through  the  rendezvous  server, which would substantially increase the
overhead of processing, and every datagram would have to carry the  full
service  request  field,  which  would  increase  the size of the packet
header.
     インターネット体系で、この戦略はすべてのプロトコルが同じサービスパ
ラダイムに入ると仮定した重大な欠陥を持っていました:初期設定フェーズで、
これはランデブーサーバ経由の間接ルーティングのような何らかのオーバーヘッ
ドをもち、対話の続くパケットでサービスを供給するプロセスに直接流れます。
不幸にも、すべてのインターネットの上位レベルプロトコルがこのモデルに合う
ことを期待されたわけではありません。これの最も良い例はUDPを使う孤立デー
タグラム交換です。UDPでの最も単純な交換はひとつのデータグラムを送る1
つのプロセスです。特にローカルネットで、ネットに関連したオーバーヘッドが
非常に低時に、この種類の単純なひとつのデータグラム交換は、ホストで、非常
に効率的で、非常に低いコストです。しかしながら、これらの個別のパケットが
確立された接続の一部ではないであろうから、もしIPがランデブーサーバとサー
ビス記述子に基づいた作戦をサポートしたなら、すべての孤立データグラムがラ
ンデブーサーバを通る間接的経路を使用し、これは処理のコストを増やし、そし
てすべてのデータグラムが完全なサービス要求フィールドを運ばなければならな
いであろうから、パケットヘッダの大きさを増やすでしょう。

     In general, if a network is intended for "virtual circuit service",
or  things similar to that, then using a special high overhead mechanism
for circuit setup makes sense.  However, current directions in  research
are  leading  away  from  this  class  of  protocol,  so  once again the
architecture  was  designed  not  to   preclude   alternative   protocol
structures.    The  only  rational  position  was  that  the  particular
dispatching strategy used should be part of the  higher  level  protocol
design, not the IP layer.
     一般に、もしネットワークが「仮想回路サービス」、あるいはそれに類似
しているもののために意図されるなら、回路設定のために特別な高いオーバーヘッ
ドメカニズムを使うことは意味をなします。しかしながら、研究での現在の方向
は、この種のプロトコルから離れていっており、それで体系は代わりのプロトコ
ル構造体を妨げないよう意図されました。唯一の合理的な見解は使われた詳細を
対応付ける戦略がもっとレベルが高いプロトコルデザインの一部であるべきであ
り、IP層ではないということでした。

     This  same  argument about circuit setup mechanisms also applies to
the design of the IP address structure.  Many protocols do not  transmit
a  full  address  field  as  part of every packet, but rather transmit a
short identifier which is created as part of a circuit setup from source
to destination.  If the full address needs to be  carried  in  only  the
first  packet  of  a long exchange, then the overhead of carrying a very
long address field can easily be justified.  Under these  circumstances,
one  can  create  truly extravagant address fields, which are capable of
extending to address almost  any  conceivable  entity.    However,  this
strategy  is  useable  only  in a virtual circuit net, where the packets
being transmitted are part of a  established  sequence,  otherwise  this
large  extravagant  address  must be transported on every packet.  Since
Internet explicitly rejected this restriction on  the  architecture,  it
was  necessary  to come up with an address field that was compact enough
to be sent in every datagram, but general enough to correctly route  the
datagram  through  the  catanet  without a previous setup phase.  The IP
address of 32 bits is the compromise that results.  Clearly it  requires
a  substantial  amount  of shoehorning to address all of the interesting
places in the universe with only 32 bits.  On the other  hand,  had  the
address  field  become  much  bigger,  IP would have been susceptible to
another criticism, which is that the header had grown unworkably  large.
Again, the fundamental design decision was that the protocol be designed
in  such  a way that it supported research in new and different sorts of
protocol architectures.
     この回路設定メカニズムについての同じ議論は同じくIPアドレス構造体
の設計に当てはまります。多くのプロトコルがすべてのパケットの一部として完
全なアドレスフィールドを伝達します、しかしソースから宛先までの回路設定の
一部として生成される短い識別子を伝達しません。もし完全なアドレスがただ長
い交換の最初のパケットでだけで運ばれる必要があるなら、非常に長いアドレス
フィールドを運ぶことのオーバーヘッドは容易に正当化できます。このような状
況下で、本当に贅沢なアドレスフィールドを作ることができ、そしてこれは想像
可能なほとんどのエンティティのアドレスのために拡大することができます。し
かしながら、この戦略は仮想回路ネット、伝達されているパケットが確立された
シーケンスの一部である場合にだけ有用です、さもなければこの大きい贅沢なア
ドレスはすべてのパケット上で送られなくてはなりません。インターネット体系
上で明示的にこの制限を拒絶したので、すべてのデータグラムで送られるらけの
小さなアドレスフィールドを思い付くことが必要でしたが、一般に前の設定フェー
ズなしで異種ネットを通して正確にデータグラムの経路を決めれば十分でした。
32ビットのIPアドレスは結果として生じた妥協です。明らかにただ32ビッ
トだけで宇宙で面白いものすべてを扱うには、実質的な量の靴直しを必要としま
す。他方、もしアドレスフィールドがずっとより大きくなっていたなら、IPは
もう1つの批判の可能性があったでしょう、それはヘッダが使い勝手が悪く大き
くなっていたということです。再び、基本的なデザイン決定はプロトコルが新し
く異なる種類のプロトコル体系の研究をサポートする方法で設計されるというこ
とでした。

     There are some limited restrictions imposed by the IP design on the
port mechanism selected by the higher level  process.    In  particular,
when  a packet goes awry somewhere on the internet, the offending packet
is returned, along with an error indication, as part of an ICMP  packet.
An  ICMP  packet  returns only the IP layer, and the next 64 bits of the
original datagram.  Thus, any higher level protocol which wishes to sort
out from which port a particular offending datagram came must make  sure
that  the  port information is contained within the first 64 bits of the
next level header.  This also means, in most cases, that it is  possible
to  imagine,  as  part  of the IP layer, a port dispatch mechanism which
works by masking and matching on the  first  64  bits  of  the  incoming
higher level header.
     もっと上位レベルプロセスによって選択されたポートメカニズム上にIP
デザインによって課されたある限定された制限があります。特に、パケットがイ
ンターネット上のどこかで変になる時、問題のパケットはICMPパケットの一
部として、エラー表示とともに、返されます。ICMPパケットが元のデータグ
ラムのIPレイヤと次の64ビットだけを返します。それで、どのポートから特
定の問題のデータグラムが来たかについて考ることを望む上位レベルプロトコル
が次レベルヘッダの64ビット内にポート情報を含めることを確実にしなければ
なりません。これは同じく、たいていの場合に、IP層の一部として、入ってく
る上位ヘッダの最初の64ビットを取り出して比較するポート識別メカニズムを
想像することが可能であることを意味します。

Japanese translation by Ishida So