この文書は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.
オペレーティング・システムの主な機能は、同じオブジェクトに多くの異
なった名前を定義する事と言われ、それで異なった名前のすべての間の関係を記
録・追跡するのに忙しくなります。ネットワークプロトコルが幾分同じ特徴を持
つように思われます。ＴＣＰ／ＩＰで、物を参照するいくつかの方法があります。
人間の目に見えるインタフェースにおいて、ネットワークとホストとサービスを
識別するための文字列「名前」があります。ホスト名が３２ビットのネットワー
ク「アドレス」に翻訳され、これはホストが接続するネットワークと、そのネッ
ト上のホストの位置を示します。サービス名が「ポート識別子」に変換され、こ
れはＴＣＰで１６ビット値です。最終的に、アドレスが「経路」に変換され、こ
れはパケットが指定されたアドレスに着くためにとらなくてはならないステップ
の連続です。経路が明示的にインターネットルーティングオプションのかたちで、
そして暗黙のうちにすべてのホストとゲートウェイが維持する経路翻訳テーブル
に現われます。
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.
このＲＦＣはＴＣＰ／ＩＰのホスト実装中にこれらの種々種類の識別子を
記録・追跡するために必要なテーブルとアルゴリズムの設計のための提案と指導
を与えます。
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.
名前メカニズムに対する最初の問題は、いくつの名前に遭遇すると予期す
べきかです。これに答えるために、インターネットの予想される最大の大きさに
ついて何かを知ることが必要です。現在、インターネットはかなり小さいです。
これは２５以上のアクティブなネットワークと数百のホスト以上の何も含んでい
ません。これは徹底的にこれらすべての要素をリストアップするテーブルを持つ
ことを可能にします。しかしながら、今開発している実装はは、ずっと大きいイ
ンターネットを仮定すべきです。現在推薦されたガイドラインは上限がおよそ
１,０００のネットワークです。もし我々がネットワーク毎に平均２５のホスト
数を想像するなら、これは２５,０００のホストの最大数を提案するでしょう。
このホスト見積もりが高いか低いかは非常に不明確です、しかしたとえこれが数
桁外れるとしても、その結果の数は現在テーブル管理戦略で受け入れ難いことを
示唆するのに十分大きいです。何らかの新しい技術が未来のインターネットを扱
うように要求されるでしょう。
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.
この広くいくらか動的な環境にうまく対処するために、インターネットは
現在のひとつのＮＩＣにより維持される全ホストに配布される名前テーブルから、
それぞれのネットワーク（あるいはネットワークグループ）がそれ自身の名前を
維持しそのネットワークの名前とアドレスの翻訳をするための「ネームサーバ」
を供給することに責任がある分散方式に移行します。それぞれのホストが名前ア
ドレス翻訳の全体を持つのではなく、ただ最近使われた名前のキャッシュだけを
持つと考えられます。アドレスに翻訳するために名前がユーザから供給される時、
ホストは最初にそのローカルなキャッシュを調べるでしょう、そして名前がそこ
になければ、適切なネームサーバと通信して情報を得て、将来の参照に備えて
キャッシュに挿入するかもしれません。
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.
今日ＡＲＰＡＮＥＴで時折起こる問題は、ローカルホストテーブルでの情
報が、ホストの移動しＮＩＣからホストテーブルの修正がインストールされてい
ないため、時代遅れであるということです。この場合、特定のホストに接続しよ
うと試みて、ローカルテーブルから得られたアドレスで予期せぬ機械を発見しま
す。もし接続の試みを直接人が観察しているなら、エラーは通常すぐに検出され
ます。しかしながら、待ち行列に入れられたメールを送ることのような、人がい
ないオペレーションで、この種の問題は多くの混乱を導きます。
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.
もしホストがいつアドレスが変化しキャッシュを削除すべきか知る方法を
持たずに、単にホストがローカルにに検索された名前とアドレスをキャッシュす
るなら、ネームサーバ案はこの問題を悪化するでしょう。この問題を解くために、
ホストが外部アドレスにその名前が何かを問い合わせる単純な機能を定義する計
画が現在進行中です。ＳＭＴＰがすでにこのアプローチに基づく検証技術を定義
します。
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.
ＩＰレイヤはアドレスについて何かを知っていなくてはなりません。特に、
データグラムがホストから送られている時、ＩＰレイヤは、インターネットアド
レスに基づいていて、直接接続されたネットワーク上のどこにそれを送るべきか
決めなくてはなりません。機械的に、ＩＰは受信ネットワーク番号が送信者のネッ
トワーク番号と同じであるかどうか見るために、最初にインターネットアドレス
をテストします。もしそうであるなら、パケットは直接最終受信者に送ることが
できます。もしそうでなければ、データグラムは以降おの転送のためにゲートウェ
イに送られなくてはなりません。この後の場合、直接接続するネットワーク上に
利用可能な複数のゲートウェイがあるかもしれないから、瞬間的な決断がされな
くてはなりません。
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).
インターネットアドレスフォーマットが最初に指定された時、８ビットが
ネットワークを識別するために予約されました。初期の実装はそれで上記のアル
ゴリズムを、それぞれのネットワークのゲートウェイを指定する２５６個の要素
を持つテーブルで実装しました、ホストが接続しているネットは特別な場合の要
素です。このようなテーブルは時々静的に記入され、そしてゲートウェイとネッ
トワークが変わると混乱と故障（あるいは停止）を起こしました。
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.
インターネットアドレスの現在の定義は、多数のネットワークがインター
ネットに参加できるように、ネットワーク番号に３つの異なる選択を供給します。
それで、どんな外のネットワークのためのゲートウェイを選択するために徹底的
なテーブルを持つと想像することは可能ではありません。現在の実装は、現在使
われているアドレスのために、ルーティング情報のローカルキャッシュに基づい
た作戦を使わなくてはなりません。
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.
アドレスから経路への翻訳の推薦された戦略は次の通りです。ＩＰレイヤ
が送信のために外行きのデータグラムを受け取る時、宛先アドレスからネットワー
ク番号を抽出し、そしてデータグラムを送る適当なゲートウェイを知っているか
どうか決定するためにそのローカルテーブルに問い合わせます。もしあれば仕事
をします。（どのようにゲートウェイ障害を扱うかの推薦について、ＲＦＣ８１６
の障害隔離と回復を見てください）。もしローカルテーブルにこのような項目が
ないなら、ランダムにアクセス可能なゲートウェイを選択し、テーブルのその項
目を挿入し、パケットを送るためにそれを使います。推測は正しいか間違ってる
かです。もし間違っているなら、パケットが送られたゲートウェイはあて先ネッ
トに届くもっと良いゲートウェイがあると報告するＩＣＭＰリダイレクトメッセー
ジを返すでしょう。このリダイレクトの到着はローカルテーブルの更新を起こす
べきです。
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.
ローカルテーブルの項目の数は、この特定のホストが一度にサポートでき
るアクティブな接続の最大数によって決定されるべきです。長時間の共有システ
ムで、１００以上の項目のテーブルを想像するかもしれません。使われているパー
ソナル・コンピュータが一人のユーザのｔｅｌｎｅｔ接続をサポートするために
は、同時にひとつのアドレスとゲートウェイの関連だけが維持されればよいです。
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.
上記の戦略は実際には完全に問題を解いていませんが、しかしただ１レベ
ル下がっただけで、そして、インターネットの上に新たに登場したホストが、ア
クセス可能なゲートウェイのすべてを見いだすか、という問題はが生じます。意
図的に、この問題はインターネット体系内で解かれません。ホストに即時にネッ
トワーク上の他のホストを発見することを許すことに対して、理由は異なるネッ
トワークが劇的に異なった作戦を持っているということです。あるネットがブロー
ドキャスト機構を認めます。この場合、ホストがメッセージを送り、そして接続
したゲートウェイのすべてから返事が戻ることを期待できます。他の場合、特定
のネットワークが豊富にインターネットをサポートするツールを提供する場合、
ホストがゲートウェイがどこにあるか決定するために呼び出すことができる特別
なネットワークメカニズムがあるかもしれません。他の場合に、手作業で少なく
とも１つのアクセス可能なゲートウェイの名前を供給することは導入時に必要で
あるかもしれません。ホストが１つのゲートウェイの名前を発見したら、ＩＣＭ
Ｐメッセージで報告されたすべてのゲートウェイを記録・追跡することによって、
すべての他の利用可能なゲートウェイのテーブルを増強することができます。
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.)
体系の一部になったるかもしくは開発下のいくつかの機能があり、これら
はアドレスと経路の関係の変更か拡張に使われます。ＩＰソース経路オプション
はホストが明示的に一連のゲートウェイを通してデータグラムを外のホストに向
けることを許します。ＩＣＭＰリダイレクトパケットの代わりの形式が提案され、
そしてこれは宛先ネットではなく特定の宛先ホストに固有な情報を返すでしょう。
最終的に、追加のＩＰオプションがインターネットの中の特定の到達できない経
路を識別するために提案されました。これらの新しい機能を実行することでの困
難さはメカニズムがＩＰの範囲内に完全に入らないということです。すべての上
記のメカニズムは特定の接続に適用するよう意図されます、それでそれらの使用
はＴＣＰレベルにおいて指定されなくてはなりません。それで、ＩＰとその上の
レイヤの間のインタフェースは、この情報を前後に渡す機構を持ち、ＴＣＰ（あ
るいはＵＤＰのような同レベルの他のプロトコル）はこの情報を保管する準備が
必要です。ＩＰとＴＣＰの間の情報の通過は情報のいくつかが、特定のＩＣＭＰ
パケットで、いつでも到着できるという事実によってより複雑にされます。ＴＣ
ＰとＩＰの間に想像された標準的なインタフェースは、パケットを送るか受取る
かです。非同期のＩＣＭＰメッセージの存在は、データを実際に送ったり受け取っ
たりすることと無関係で、２者間に追加のチャネルがあるにことを意味します。
（実際、ＩＰからより高いレイヤまで非同時的に到着すり渡さなければならない
多くの他のＩＣＭＰメッセージがあります。ＲＦＣ８１６のか着ると回復を参照
してください）。
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.
ソースルートはインターネットですでに使用中で、そして多くの実装がそ
れらを利用することが可能であることを望むでしょう。次の種類の使用は認めら
れるべきです。最初に、ユーザが、ＴＣＰ接続を始める時、ＴＣＰにソースルー
トを渡すことが可能であるべきで、そしてＴＣＰはすべての外向データグラムで
ＩＰにソースルートを渡さなくてはなりません。ユーザは、アドレスの代わりに
ソースルートを返すような異なる種類のネームサーバに問い合わせることで初め
にソースルートを得るかもしれません、あるいはユーザは手作業でソースルート
を造りあげたかもしれません。接続を待つＴＣＰが、１つを開く試みより、ＩＰ
返送経路を含むデータグラムを受け取る用意ができているに違いありません、そ
の場合ＴＣＰはこの応答経路を覚えていて、そしてすべての返すデータグラムで
これをソースルートとして用いなくてはなりません。
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.
体系のＩＰレイヤはデータグラムを送る宛先ホストを指定するアドレス情
報を含んでいます。実際、データグラムは特定のホストのためだけを意図せず、
ホスト内の特定のエージェントや、プロセスや、実際のデータの生成元や蓄積元
であるエンティティも意図します。ＩＰは非常に単純な処理を行い、データグラ
ムが目標ホストに到着した途端に特定のプロトコルにそれを送ります。特定の接
続にデータグラムを対応付けるのは、例えばＴＣＰなどのプロトコルハンドラの
責任です。この次のレイヤの対応付けは「ポート識別子」を使ってされ、そして
これはＩＰレイヤではなく、もっとレベルが高いプロトコルのヘッダの一部です。
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.
２層の体系はある特定の実装の問題を起こしました。特に、ある実装がＩ
Ｐレイヤをオペレーティング・システムのカーネルとして、ＴＣＰレイヤをユー
ザードメインアプリケーションプログラムとして置くことを望みました。この分
割の厳密な維持は性能の問題を導きます、なぜならデータグラムは最初にカーネ
ルからＴＣＰプロセスに渡され、ＴＣＰプロセスがデータグラムをその最終の宛
先プロセスに渡します。この転送プロセスをスケジューリングするオーバーヘッ
ドはひどく実装の達成可能なスループットを制限します。
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.
ＲＦＣ８１７のプロトコル実装のモジュール性と効率インプリメンテーショ
ンで論じられるように、このカーネルとユーザ間の特定の分離はポートレベルの
対応付けの問題を無視しても他性能問題に導きます。しかしながら、受入れ可能
な手段があります、もしこれで実装が十分に容易になるなら、ＩＰ層の中に上位
レベル分析関数を動かすことが出来ます。
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.)
原則として、すべての上位レベルプロトコルが異なる配達アルゴリズムを持つ
ことができます。この理由は下記に論じられます。しかしながら、今日実装されてい
るサービス提供に関係しているプロトコル、ＴＣＰとＵＤＰで、配達アルゴリズムは
正確に同じで、そしてポートフィールドは正確にヘッダの同じ場所に位置しています。
それ故に、これ以上のプロトコル研究に参加することに興味を持たないなら、ただ１
つだけの上位レベル配達アルゴリズムがあります。このアルゴリズムはインターネッ
トレベルの外のアドレスと、プロトコル番号と、上位レベルヘッダのローカルと外の
ポートを考慮に入れます。このアルゴリズムは、他の上位レベルプロトコルが実装さ
れない限り、ＩＰレイヤ実装の一種の付属物として実装することができます。（実際
に、上記の文は、ＵＤＰ配達機能がＴＣＰ配達機能の下位グループであるという点で、
ただ部分的に本当です。ＵＤＰ配達はプロトコル番号とローカルポートだけに依存し
ます。しかしながら、ＴＣＰ内にこの正確に同じ下位グループが活動する機会があり
ます、プロセスが外のホストからの接続を待つときです。それで、ＴＣＰ配達をサポー
トするために必要なメカニズムは同じく正確にＵＤＰ必要条件をサポートすることに
十分です。）
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.
ＩＰから上位レベルプロトコルまでの配達で、ポートを削除する決定はあ
る実装者で問題にされました。もしアドレス構造体のすべてがＩＰ層の一部なら、
ＩＰはホスト内ですべてのパケットの配達が可能で、より単純なモジュール性に
導くであろうと論じられました。３つの問題がこれと同一視されました。最初に、
すべてのプロトコル実装者がポート識別子の大きさについて合意することができ
たわけではありません。ＴＣＰはかなり短いポート識別子、１６ビットを、ヘッ
ダサイズを減らすよう選びました。設計されている他のプロトコルは、しかしな
がら、より大きいポート識別子、多分３２ビットを欲しました、それでポート識
別子は、もし正確に選択されるなら、確率的にユニークであると思うことができ
ました。それで、ポートＩＤを１つの特定のＩＰレベルメカニズムに限定するこ
とは研究可能性を妨げるでしょう。第二に、ポートがデータグラム配達のほかに
特別な機能を果たします：ある特定のポート番号が特定のサービスを識別するた
めに予約されます。それで、ＴＣＰポート２３はリモートログインサービスです。
もしポートがＩＰレベルにおいて実装されたなら、機知ポートの割当てはプロト
コル基礎上ですることができず、ＩＰ体系のすべてのために中央集権化された方
法でされなければならないでしょう。第三に、ＩＰが非常に単純なレイヤの役割
で設計されました：ＩＰが正確にゲートウェイが理解しなくてはならない機能を
含んでいます。もしポートの考えがＩＰ層の一部にされたなら、それはゲートウェ
イがポートについて知る必要があることを示唆しますが、このような場合はあり
ません。
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.
もちろん、これらの問題を避ける他の方法があります。特に、「既知ポー
ト」問題は、既知ポートを指定するために、ポートの配達と異なる２番目のメカ
ニズムを考案することによって解くことができます。いくつかのプロトコルが、
文字列フィールドのような一般的なサービス記述子を、接続を準備するパケット
に含めるアイデアを採用しました。特定のサービスに接続を求めているこれらの
特別なパケットは、時々「ランデブーサーバ」と呼ばれる特別なサーバに送られ、
そしてサーバはサービスの要求を調べて、このサービスに実際に使われるはずで
ある任意のポートを選び、そして次に対話を開始するサービス自身にパケットを
伝え送ります。
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.
インターネット体系で、この戦略はすべてのプロトコルが同じサービスパ
ラダイムに入ると仮定した重大な欠陥を持っていました：初期設定フェーズで、
これはランデブーサーバ経由の間接ルーティングのような何らかのオーバーヘッ
ドをもち、対話の続くパケットでサービスを供給するプロセスに直接流れます。
不幸にも、すべてのインターネットの上位レベルプロトコルがこのモデルに合う
ことを期待されたわけではありません。これの最も良い例はＵＤＰを使う孤立デー
タグラム交換です。ＵＤＰでの最も単純な交換はひとつのデータグラムを送る１
つのプロセスです。特にローカルネットで、ネットに関連したオーバーヘッドが
非常に低時に、この種類の単純なひとつのデータグラム交換は、ホストで、非常
に効率的で、非常に低いコストです。しかしながら、これらの個別のパケットが
確立された接続の一部ではないであろうから、もしＩＰがランデブーサーバとサー
ビス記述子に基づいた作戦をサポートしたなら、すべての孤立データグラムがラ
ンデブーサーバを通る間接的経路を使用し、これは処理のコストを増やし、そし
てすべてのデータグラムが完全なサービス要求フィールドを運ばなければならな
いであろうから、パケットヘッダの大きさを増やすでしょう。
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.
一般に、もしネットワークが「仮想回路サービス」、あるいはそれに類似
しているもののために意図されるなら、回路設定のために特別な高いオーバーヘッ
ドメカニズムを使うことは意味をなします。しかしながら、研究での現在の方向
は、この種のプロトコルから離れていっており、それで体系は代わりのプロトコ
ル構造体を妨げないよう意図されました。唯一の合理的な見解は使われた詳細を
対応付ける戦略がもっとレベルが高いプロトコルデザインの一部であるべきであ
り、ＩＰ層ではないということでした。
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.
この回路設定メカニズムについての同じ議論は同じくＩＰアドレス構造体
の設計に当てはまります。多くのプロトコルがすべてのパケットの一部として完
全なアドレスフィールドを伝達します、しかしソースから宛先までの回路設定の
一部として生成される短い識別子を伝達しません。もし完全なアドレスがただ長
い交換の最初のパケットでだけで運ばれる必要があるなら、非常に長いアドレス
フィールドを運ぶことのオーバーヘッドは容易に正当化できます。このような状
況下で、本当に贅沢なアドレスフィールドを作ることができ、そしてこれは想像
可能なほとんどのエンティティのアドレスのために拡大することができます。し
かしながら、この戦略は仮想回路ネット、伝達されているパケットが確立された
シーケンスの一部である場合にだけ有用です、さもなければこの大きい贅沢なア
ドレスはすべてのパケット上で送られなくてはなりません。インターネット体系
上で明示的にこの制限を拒絶したので、すべてのデータグラムで送られるらけの
小さなアドレスフィールドを思い付くことが必要でしたが、一般に前の設定フェー
ズなしで異種ネットを通して正確にデータグラムの経路を決めれば十分でした。
３２ビットのＩＰアドレスは結果として生じた妥協です。明らかにただ３２ビッ
トだけで宇宙で面白いものすべてを扱うには、実質的な量の靴直しを必要としま
す。他方、もしアドレスフィールドがずっとより大きくなっていたなら、ＩＰは
もう１つの批判の可能性があったでしょう、それはヘッダが使い勝手が悪く大き
くなっていたということです。再び、基本的なデザイン決定はプロトコルが新し
く異なる種類のプロトコル体系の研究をサポートする方法で設計されるというこ
とでした。
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.
もっと上位レベルプロセスによって選択されたポートメカニズム上にＩＰ
デザインによって課されたある限定された制限があります。特に、パケットがイ
ンターネット上のどこかで変になる時、問題のパケットはＩＣＭＰパケットの一
部として、エラー表示とともに、返されます。ＩＣＭＰパケットが元のデータグ
ラムのＩＰレイヤと次の６４ビットだけを返します。それで、どのポートから特
定の問題のデータグラムが来たかについて考ることを望む上位レベルプロトコル
が次レベルヘッダの６４ビット内にポート情報を含めることを確実にしなければ
なりません。これは同じく、たいていの場合に、ＩＰ層の一部として、入ってく
る上位ヘッダの最初の６４ビットを取り出して比較するポート識別メカニズムを
想像することが可能であることを意味します。