創刊号「専用線を引こう！」では低価格専用線を用いてインターネットへ接続する勧めをつらつらと書きました。
今回のテーマはそのインターネットの土台を形成しているTCP/IPネットワークに関して基本中の基本といえる事項について解説しようと思います。
専用線に興味のない方も、これからの時代インターネットに関する知識は持っておいて損はありませんので、よろしければ一度目を通してみてください。

ここでは、インターネット通信技術の根幹を担っているプロトコル「TCP/IP」について簡単に解説します。
まず始めに「プロトコル」と呼ばれる概念に関して一般的な解説を示し、その後でその（実装としての）最大の成功例である「TCP/IP」について解説します。

ネットワークについて勉強した方々はご存知のとおり、その手の教科書では必ずはじめの方で「プロトコル」という専門用語を解説しています。コンピュータネットワークにおいて「プロトコル」とはそれほどまでに重要なものなのですが、如何せん概念的過ぎて勉強しているうちについつい眠くなってしまうことがあります。
しかし、「プロトコル」に関する基本的な知識が無いと効率的なネットワーク管理はできません。やはり管理者としては是非とも（少なくとも基本的なことは）押さえておかなくてはならない知識です。
例えばネットワークにトラブルが発生した場合、その真の問題個所がどこにあるのか...ネットワークカードにあるのかケーブルにあるのかネットワークの基本設定にあるのかユーザアプリケーションの設定にあるのか...これらを特定するにはこの「プロトコル」の知識が欠かせません。
では、「プロトコル（protocol）」とは端的に言って何を指すのでしょうか。
辞書で調べてみます。「[コンピュータ] 通信規約」という説明があります。これから、プロトコルとは「コンピュータやその周辺機器同士が通信を行う上でのルールブック」といった意味だということがわかります。
では通信のルールとはどういったものでしょうか？　どういった事柄を規定しているのでしょうか？
実はプロトコルには、「プロトコルたるものこういったことを規定しなくてはならない」、というような決り事はありません。それゆえ極めて自由度が高く、プロトコルはどれをとっても究極的には１つの地方ルールでしかないということになります。
ただ、究極的には一つの地方言語である英語が、事実上、世界の公式な場でコミュニケーション用言語として「標準」扱いになっているのと同じように、通信プロトコルの世界にも事実上「標準」扱いとなっているものがあります。
それが、インターネットの土台を支える「TCP/IPスイート」と呼ばれるプロトコル群です。「プロトコル」と書かずに「プロトコル群」と書いたのには意味があります。TCP/IPはそれ自身複数のプロトコル階層からなっているのです。
詳しくは次節で解説することにして、ここでは、インターネットを支えている通信ルールは一般にTCP/IPスイートと呼ばれていて、それらは複数のプロトコルから成り立っている、ということだけ理解して下さい。
さて、先に「プロトコルという概念自身には、規定しなければならない事柄などの決り事が無い」と解説しました。がしかし、実はある種の「お手本」と呼ばれるものであれば存在します。国際標準化機構（ISO）が作成した通信モデル「OSI基本参照モデル」がそれです。プロトコルを解説した教科書などでは必ずといって良いほど引き合いにだされているのでご存知の方も多いでしょう。
というわけで以下に「OSI基本参照モデル」のモデル図と概略を示します。

図に記されているとおり、データの送信側は最上位のアプリケーション層に生データを渡します。アプリケーション層はそのデータに自分の担当する処理を施した加工後のデータを下位のプレゼンテーション層に引渡します。プレゼンテーション層ではその渡されたデータに更に自分の担当する処理を施し、下位のセッション層にデータを引き渡します。このようにデータはバケツリレー式に上位の層から下位の層へと処理を施され引き渡されていき、最終的にネットワークへと送出されます。
データの受信側ではこれと逆の流れでデータが処理されます。つまり、物理層がネットワークからデータを受け取り、自身の処理を施した後それをデータリンク層に引渡し、データリンク層は受け取ったデータに自分の処理を施した上で更に上位の層に引渡し、....という具合です。
ところで、上では通信ルールの階層化によるメリットを述べましたが、では階層化を進めていけばどんどん複雑さ・困難さは減少していくのでしょうか？
常識的に考えれば分かるとおり答えは「NO」です。何事もほどほどが重要なのです。
通信ルールの階層化を深くしすぎると、階層間の役割分担があいまいになり、また階層間のやり取りにからむオーバーヘッドが増えてきます。階層化当初のメリットとは逆に、かえって平易さや能率が損なわれてしまうことになりかねないのです。階層化を押し進めすぎると「階層化のパラドックス」とでもいうような現象が起こるわけです。
実は、「OSI基本参照モデル」はお手本とまでされていながら、これを実装して成功したプロトコルが事実上無いという一見おかしな状況にありますが、そうなってしまった大きな理由の一つが「７層というOSI基本参照モデルの階層の多さ」にあるといわれています。まさしく「階層化のパラドックス」です。
OSI基本参照モデルを実装しようという動きはあるにはあったのですが、７層ものプロトコルを取決めるのに多大な時間がかかり、また仮に取決めがうまくいったとしても仕様が細かくなってしまい、忠実に動作するハードウェア・ソフトウェアの作成がうまくいかなかったという背景があったようです。
で、そうこうしているうちに、TCP/IPという「ほどよく」階層化された軽いプロトコルが現れ通信の世界を席巻していったのですが、そのTCP/IPについて次に解説することにします。

まずはじめに、用語について注釈を述べておきます。
上では「TCP/IP」と「TCP/IPスイート」いう言葉を用いましたが、これらはそれぞれ別々のものではなく、ここでの文脈では両者は同じものを指しています。一般にも「TCP/IP」という表現が用いられた場合、多くの場合それは「TCP/IPスイート」のことを指しています。
TCP/IPとは厳密には「TCPプロトコルとIPプロトコル」という意味なわけですからこれは変な感じがするかもしれませんが、現在のインターネットを支えている通信技術がこれら２つのプロトコルを中心としたプロトコル群から成り立っているため、簡略化され単に「TCP/IP」と呼ばれているというわけです。なるべく正確な用語を使いたい方は「TCP/IPスイート」を用いれば良いでしょう。
とにかくここでは、以降、特に断り無くTCP/IPといった場合それはTCP/IPスイートのことを指しているものとします。

ではまず、「TCP/IP」のプロトコル階層を示し、その後それぞれの階層について解説します。

　・SMTP....メール転送プロトコル
　・POP....メール取込みプロトコル
　・HTTP....ハイパーテキスト（ウェブページ）転送プロトコル
　・FTP....ファイル転送プロトコル
　・TELNET....ネットワーク端末プロトコル

・UDP（User Datagram Protocol）
コネクションレス型のプロトコル。ここでのコネクションレス型とは「データの受取り側でデータを受取る準備ができているか」「今送ったデータは無事届いたか」ということを一切確認し合わずにデータを送受信する通信法を指します。
その意味ではUDPは信頼性に欠けるプロトコルだと言えますが、インターネット層によって届けられたデータを単に指定プロセスに引き渡すだけしか行わないので軽く高速に動作するという利点があります。
そのため、以下のような用途で使用されることが多いようです。

�@通信ゲーム	一回のデータ量は少ないがデータの発生量が多く速度が重視される。この場合、データが１つや２つ相手に届かなかったとしてもゲームの進行に対して問題がない。
�Aメッセージ送受信アプリケーション	短いメッセージをお互いやり取りすることによって通信を進めていくアプリケーション。この場合、一定時間内に相手からの返事が無ければデータが届かなかったのだと判断しデータを再送できるので、コネクションレスでも何の問題も無い。

・TCP（Transport Control Protocol）
コネクション型でバイトストリーム型であることを特徴とするプロトコル。ここでのコネクション型とは「データの送信側・受信側でデータをやり取りすることを取り決める」「今送ったデータは無事届いたか」ということを確認し合いながらデータを送受信する通信法を指し、またバイトストリーム型とは「受信側で、データを送信された順序に組み立てることができる」ようデータを送受信する通信法を指します。
UDPでは送信側が一方的にパケットを送りつける動作をしましたが、TCPでは送信側のみならず受信側もパケットを送信します。詳しくは後述しますが、TCPでは「そちらからのパケットを確かに受取った」という旨を送信側に伝える応答パケットを送信するためです。（ここでのパケットの定義に関しては後述）
上記バイトストリーム型の説明に「は？　データは送信した順序で相手に届くんだから、受信した順序でデータを並べれば良いだけなんじゃないの？　何もバイトストリーム型とか気にする必要も無いでしょ？」と思った方はいないでしょうか。確かにたいていの場合はそのとおりなのですが、基本的にインターネットでは送信したパケットが確実に相手に届くという保証はありませんし、また、後の方で触れるように、動的に経路選択が変動しうるため必ずしもデータが送信した順序で相手に届くとも限らないのです。そのため、バイトストリーム型を実現するにはそれなりの仕組みが必要となるわけです。
そこで、TCPでは各パケットのヘッダー部に「シーケンス番号」と呼ばれる通し番号を付与することでこの仕組みを実現しています。（下図参照）ただし、「通し番号」とはいっても、自身が何番目のパケットなのかを表す「パケット数に対する通し番号」ではなく、そのパケットのデータ部分の先頭が送信データの中で何バイト目に当たるのかを表す「データの位置（バイト数）に対する通し番号」である点に注意して下さい。
注意
TCPを自分で実装してみたいという奇特(?)な方のために細かいことを言うと、シーケンス番号の開始番号は必ずしも０とはならず、しかも送受信側それぞれで勝手に決められる点にも注意する必要があります。シーケンス番号の開始番号は、通信を始める前に送受信間でお互いに告知しあうことになっています。

もう既に察しがついたことでしょうが、念の為このシーケンス番号によるバイトストリーム復元方法を説明しますと、それは

�@受信側はまず受取ったパケットの「シーケンス番号」を調べる �Aジグソーパズルを組立てるようにそのデータをシーケンス番号が示す位置に当てはめる �B�Aを繰り返す。 �C最終的に一連のバイトストリームが出来上がる

という単純な手順によるものです。
実は、シーケンス番号は「バイトストリームの復元」以外にも重要な処理に利用されています。具体的にいうと「受信確認」がそれです。
上図に描かれているように、TCPパケットのヘッダー部には応答番号というフィールドがあります。パケットを相手に送信する際、このフィールドに自分が次に受信するパケットのシーケンス番号（つまりは直近に受信したパケットのシーケンス番号に同パケットのデータ部のバイト数＋１を足し合わせた値）を付与することで、こちらが受信を確認したデータ位置を相手（送信側）に知らせることができます。送信側ではこの応答番号フィールドを監視して、一定時間たっても応答番号が送信したはずのシーケンス番号に達しなかった場合にパケットが届かなかったものとして応答番号以降のパケットを再送するようにします。
この仕組みにより、送信側は送信したデータが無事相手に届いたかを確認することができるのです。
最後に、TCPプロトコルが行うもう一つの重要な処理「フロー制御」について解説します。フロー制御とは簡単に言ってしまうと「通信速度の制御」のことです。
「えっ、通信速度の制御ってハードウェアがするもんじゃないの？　トランスポート層が受け持つ機能じゃないでしょ？」と思った方は鋭いです。確かに、通信速度はその時その時の通信に絡む各機器の性能や回線の混み具合によってクリティカルに決定されるので、そういった意味では基本的に通信速度の制御はハードウェアが行うべきものです。
しかし、よくよく考えてみるとハードウェアだけで通信速度を決定した場合、問題の起こる可能性があることに気付きます。なぜなら、ハードウェアが決定できる通信速度というのは究極的には通信の「最高速度」でしかないからです。ソフトウェアのデータ処理速度が、ハードウェアのデータ処理速度--つまりはデータ転送速度--を下回ってしまう場合に「処理あふれ」という問題が起こってしまうのです。
この問題に対処するため、TCPプロトコルでは「ソフトウェア側の観点から可能な通信速度」を相手側に知らせる機能をもっています。
この機能に使用されるのが上図にも描かれている「ウィンドウサイズ」という情報です。この「ウィンドウサイズ」フィールドには「現在受信側で受信可能なデータサイズ（単位はバイト）」が付与されます。
例えば、通信速度を落としたい場合には、このウィンドウサイズに小さな値（極端には０）をセットすることで送信側に「通信速度（データ送出速度）を下げてください」というメッセージを送ることができるわけです。（ちなみに送信側はウィンドウサイズに０がセットされたパケットを受取ると、受信側からウィンドウサイズに正の値がセットされたパケットが届くまでデータの送出をストップします。）
このようにしてTCPでは「ソフトウェア側からのフロー制御」を実現しています。（勿論、ハードウェア側からのフロー制御というのも存在していますがこれは下位のプロトコルが担当します。）
以上のとおりTCPは高度な機能をもっており、このため現在では多くのネットワークサービス（特にある程度の信頼性が必要なもの）がTCPを利用するようになっています。

・IP（Internet Protocol）
これは名前からも分かるとおり、インターネットを成り立たせる上で最も根幹の部分を担っているプロトコルです。パケットの構成を概略で以下に示します。

IPが行う重要な仕事には、大きく以下の２種類があります。

�@ルーティング（経路選択） 　送られてきたIPパケットのヘッダー部に含まれている宛先アドレスをみて、同パケットを次に送り出すべきネットワークを探し出しバケツリレー式に最終目的地までパケットを転送していく機能のことをルーティングと呼びます。 これがないと、通信は単一ネットワーク上のマシン同士でしか成り立たなくなってしまいます。隣り合うネットワークであってもパケットを転送し合うことができないからです。 複数のネットワーク間で通信が成り立つためには、ネットワーク同士の接続点にあるマシン（ゲートウェイと呼ばれます）で、自身に到達したパケットを「自身に繋がっている別のネットワークに転送すべきか」「転送するとすればどこに転送すれば良いか」判断する必要があります。このためにIPが提供している機能のことをルーティングと呼び、このおかげでインターネットでは世界中に存在する膨大な数のネットワークのどの端末とでも通信ができるわけです。 　この機能を理解するためには前提となる周辺知識がたくさん必要ですので、ここではこれ以上詳しく解説することをやめておきます。代わりに、次章以降で順をおってこれら周辺知識を解説し、最後の章で「ルーティング」について解説することにします。

�Aフラグメンテーション 　各ネットワークには、そのネットワークで伝送することができる最大のパケット長「最大転送単位（MTU）」が設定されており、一般的にそれらはネットワーク毎で異なる値をもっています。 そのため、あるネットワークから送られてきた長いパケットを別のネットワークに転送する際、そのままの長さでは転送できない場合がありえます。その様な場合、IPはパケットのデータ部分を細かく分割して転送するよう動作しますが、この機能のことをフラグメンテーションと呼びます。 　IPパケットのヘッダーには、この機能のための制御情報「フラグメントID」「フラグ」「フラグメントオフセット」が存在します。（上図参照） あるパケットを分割してできた複数のパケットには、同一のフラグメントIDが割当てられています。そしてそれらの位置関係がフラグメントオフセットに与えられます。フラグには、そのパケットが分割されてできたパケット群の最後のパケットかどうかを表すフラグがあてられています。 お気付きのとおり、この辺りの仕組みはTCPの部分で解説した「シーケンス番号によるバイトストリームの復元機能」に似ています。ただし、IPの場合はフラグメントオフセット等を用いたエラー制御や受信確認などは行わない点に注意して下さい。IPはいわゆるコネクションレス型（前述）のプロトコルなのです。

・ICMP（Internet Control Message Protocol）
ICMPはインターネット層に属するプロトコルではありますが、単独ではインターネット層の機能を担うことができない一風変わったプロトコルです。それは、IPプロトコルの機能を利用して自身の処理を行う、いわばIPに寄生しているプロトコルなのです。その意味でトランスポート層のTCP/UDPの関係とは異なります。先に解説したとおり、TCPとUDPはお互いに独立したプロトコルで依存関係を持ちませんでした。
ではICMPはIPにとって悪玉寄生虫なのかというとそうではありません。下で解説するとおり、ICMPはIPが仕事をやりやすいようにいろいろと地ならしをしてくれるIPにとって非常にありがたい存在なのです。
つまり、IPとICMPの関係は、人間と善玉腸内細菌の関係に似ていると言えます。
ICMPの重要な機能には以下のものがあります。

�@フロー制御 　TCPのところで「ウィンドウ」というのを解説しましたが、そこでは「それはソフトウェア側の視点からのフロー制御」だという話しをしました。またその際、ハードウェア側の視点からのフロー制御は（トランスポート層よりも）下位層で行われるとも述べました。 　こう話しを進めると察しがつくとおり、ICMPの行うこのフロー制御こそが、まさしくその「ハードウェア側の視点からのフロー制御」です。ICMPがこのフロー制御を行ってくれているため、IPはハードウェア上の伝送速度に気を使わずパケットの転送に専念できるのです。

�A宛先ホストが見つからない場合の通知 　パケットがゲートウェイにより次々とネットワークを転送されていく過程で、最終的に目的のホストが見つからないことが分かった場合に、ICMPは送信元に「宛先ホストに到達できませんでした」旨のメッセージを送信します。

�Bルーティング（伝送経路）の再設定 　一般に、インターネットではネットワークが網目状に接続されているため相手先に至るまでの経路（道順）が複数ありえます。それら複数の経路の内どれを選択するかは、普通は送信元ではなくパケットを中継するゲートウェイが決定します。 たいていの場合は、一度経路が決まるとずっとその経路を通ってパケットがやり取りされるのですが、何かしらの理由、例えば経路途中のあるネットワークが過負荷状態になってきた、などにより該当ゲートウェイが経路を別のゲートウェイ経由に変更して欲しいと１つ手前のゲートウェイに連絡したい場合があります。 そのような場合に、ゲートウェイはICMPを利用して経路の変更依頼を１つ手前のゲートウェイに送信します。

�C相手先の動作確認 　あるホストが動作中か（正確にはIPパケットを送受信可能か）知るため、ICMPではエコーメッセージを相手先ホストに送信できます。相手先ホストでは同メッセージを受信すると送信元へ返答メッセージを送信します。返答メッセージが返ってくると、そのホストのIPが動作していると判断できます。 　PINGコマンドはICMPのこの機能を利用しています。

ミニ解説：　当特集での「パケット」の定義 細かいことを言うと「パケット」とはUDPプロトコルが取り扱うデータブロックのことなのですが、一般的にはインターネット層、つまりはIPプロトコルが使用するデータブロックのことを指して使用する場合が多いようです。 ここで念の為解説しておきますと、データブロックとはそのプロトコルが取り扱うデータ単位のことで、一般に上位層から渡されたデータそのもの（あるいはそれを分割したもの）にプロトコルが利用する制御情報を加えたものを指します。 したがいまして、本来はUDPやIP以外が取り扱うデータブロックのことをパケットと呼ぶべきではないのでしょうが、通信ネットワークの入門書籍にはこの辺りの区別を行わず、プロトコルが扱うデータブロックのことを全て「パケット」と呼んでいるものが見受けられます。これは恐らく、初学者がそのような細かい点にとらわれ全体像を理解する妨げになることを防ぐためであろうと思われますが、当特集でもこれに倣いインターネット層より上位のどのプロトコルが扱うデータブロックのことも「パケット」と呼ぶことにしました。 というわけですので、当特集では一口にパケットといっても、対象としているプロトコルが違えば指し示しているデータブロックの形式や階層が違う点に注意して下さい。それは単に「そのプロトコルが扱うデータブロック」のことを言っているに過ぎないということです。 一応、初学者以外の方のため、厳密な意味でのデータブロックの名称も以下に示しておきます。このように、正確にはプロトコルや階層毎にデータブロックの名称が異なるということを覚えておいて下さい。

ミニ解説：　プロトコル間でのパケットの受け渡し TCP/IPにおいて、プロトコル間を受け渡されていく過程でパケットが変化していく様子を下図に表します。 図を見て分かるとおり、各プロトコルでのパケットの基本的な形は「ヘッダ部＋データ部」となっています。 このうちヘッダ部には、TCPやIPの解説にて触れましたとおり、そのプロトコルがデータを処理する上で必要とする各種制御情報が収められています。IPでの送信者アドレスや宛先アドレス、TCPでのシーケンス番号、等がそれです。 では、データ部には何が収められているのでしょうか？　データ部、という名前から察するに、最上位のアプリケーションが処理するデータが収められていると思われたりしないでしょうか？ 実は、その推測は半分当たっているのですが半分外れています。確かに、最上位のアプリケーションが処理するデータが含まれてはいるのですが、それだけではないのです。 ヘッダ部の説明をもう一度読み返してみてください。 「そのプロトコルがデータを処理する上で必要とする各種制御情報が収められています。」 この「そのプロトコルが...」の部分に注目して下さい。 ......そうです、ヘッダ部には「そのプロトコルが使用する」情報しか含まれていないのです。上位層のプロトコルが使用する情報は含まれていないのです。 つまり、データ部にはこの「上位プロトコルが使用する」制御情報が最終アプリケーションが使用するデータと共に収められているのです。 ここで「はて？」となった方はいないでしょうか。「じゃあ、下位プロトコルが使用する制御情報はどこにいったの？」と... 答えは簡単です。そんなもの不要だから切り捨てたのです。「どこにいったの？」という問いかけ自体が不要なのです。 もともとプロトコル階層は通信の手順を階層化して作られたため、「あるプロトコル層に固有の情報は、それ以外の層では不必要である」というところがミソです。 上図をもう一度見て下さい。各層は、上位層からデータ（上位層でのヘッダ＋データ）を受取ると、それに自分の層が使用する制御情報をヘッダとして付与し、そうしてできたヘッダ＋データを一つ下の層へと引き渡していきます。これはデータの送信側での動作に相当します。 逆に下位層からデータを受取った場合は、先頭にくっついている自分のヘッダ情報を利用して自身の処理を行い、上位層では不要な自身のヘッダ部分を切り離してデータ部（上位層にとってはヘッダ＋データ）のみを上位層へと引き渡していきます。これはデータの受信側での動作に相当します。 以上でプロトコル間で受け渡されるパケットの様子を理解できたかと思いますが、次の点には注意して下さい。 上図ではあたかも各プロトコル層での１パケットが下位層でも１パケットに変形されていくかのように見えますが、IPのフラグメンテーションやTCPのシーケンス番号に見られるように、必ずしも上位層のパケット数と自身の層でのパケット数は同じではないということを忘れないで下さい。一般的には、上位層パケット数と下位層パケット数は１対多の関係になります。 上図はあくまでもプロトコル間でのヘッダ部-データ部の関係を表した概略図だということです。

通信というものを行うには何は無くともまず「通信相手」を特定する必要があります。この「通信相手」としては、例えば「西宮市産所町の権兵衛さん」というような、対象が単数となる場合もあれば、「西宮市の皆さん」というような、対象が複数となる場合もあります。
TCP/IPにおける通信でも同様に通信相手を特定してやる必要があります。ではTCP/IPにおいて相手を特定するにはどういった方法があるのでしょうか？
基本的にTCP/IPの世界では「IPアドレス」と呼ばれる４バイト（32ビット）の数値により通信相手が特定されます。しかしながら、IPアドレスはあまりに機械的なため、人間が利用するにお世辞にも便利だとは言えないという欠点を持っています。
そこで、「ホスト名」と呼ばれるネットワークの階層を反映した文字列による通信相手の特定方法が登場しました。
この章では、通信相手の特定に利用されるこの「IPアドレス／ホスト名」に関して解説し、その後でハードウェアレベルの特定法「物理アドレス」に関して簡単にまとめることにします。

IPアドレスとはTCP/IPネットワークでの住所を指す32ビット（４バイト）の数値で、IPプロトコルによって定義されています。一般に、192.168.24.6というような１バイトづつの数値を４つ並べる方法で表現されます。
IPアドレスはネットワーク上での住所だと書きましたが、しかし、IPアドレスは単にネットワーク上の端末を区別するだけの値ではありません。それは、対象となる端末がどのネットワークに属しているかという情報も持っているのです。郵便の住所で「大阪府寝屋川市なんちゃら町？丁目？番地」と書けば、それが大阪府に属していることも表わしているのと同じようなことです。
複数のネットワーク間でパケットを交換し合うために最も重要な機能である「ルーティング」も、IPアドレスに含まれているこのネットワーク情報を基に処理されています。
ただし、ここでIPアドレス（ただし非ネットワークのもの）に関して勘違いしやすい非常に重要な注意点を指摘しておきます。
それは「IPアドレスが特定しているものは何か」ということに関してです。
上でも使用した、郵便での住所の比喩から、IPアドレスは特定の端末に１つだけ割当てられるものと理解されがちです。しかし実際はそうではありません。IPアドレスは特定の端末に複数割当てられることが多々あるのです。（プライベートアドレスと呼ばれる自由に使用できる同一のIPアドレスも存在しますが、これについては後で解説します。）
これは一体どういうことでしょうか？
実は、IPアドレスはネットワークと端末とのインターフェイス（接点）に割当てられるものなのです。端末そのものに割当てられるものではないのです。
例えば、会社のパソコンが社内LANにつながっていて、かつ同パソコンからプロバイダ経由（つまりはダイアルアップ接続）でインターネットにも接続できるような場合、その端末には２つのIPアドレスが割当てられることになります。なぜなら、そのパソコンにはLANというネットワークとの接点と、モデムを経由したプロバイダのネットワークとの接点が存在するからです。
しかしながら、「え？　自分のコンピュータはそういう形で利用しているけど、IPアドレスは１つしか設定したことないですよ」という方も多いのではないでしょうか。
実は、それはもう１つのIPアドレスが自動的に割当/設定されるため、わざわざユーザが自ら設定する必要が無いのでしていない、というだけのことなのです。
具体的にそれを確かめて見ましょう。
ただし、ここで解説に当たっては以下の環境を想定します。これらはLAN接続していてかつダイアルアップ接続が可能な端末では一般的な設定だと思われます。

・LANカードによりLANに繋がっている
・モデムを使用してダイアルアップ接続できる
・LANではDHCPを使用しないで固定IPアドレスを設定している
・ダイアルアップ接続ではDHCPを使用している
・OSは Microsoft Windows9X

これを見ると、この端末にはネットワークへのインターフェイスが「PPP Adapter」と「Fast Ethernet PCI Adapter」の２つあることが分かります。
しかし、PPP Adapter（ダイアルアップアダプターのこと）にはこの段階ではIPアドレスが割当てられていません。今はダイアルアップ接続をしていないためこのようになっているのです。
これに対して、Fast Ethernet PCI Adapter（LANカードのこと）にはIPアドレスが既に割当てられています。しかもそれは以前自分（あるいは前の持ち主）で設定したIPアドレスになっているはずです。
これらの点を確認できたら、今度はダイアルアップ接続をした状態で「MS-DOSプロンプト」を起動させて先と同様のコマンドを実行して下さい。

C:\WINDOWS＞ipconfig /All /Batch C:\IP2.TXT

すると今度は、C:\IP2.TXT が以下のような記述に変わったのを見て取れるはずです。

#### IP2.TXT #### 　...　...　...　... 　...　...　...　... 0 Ethernet アダプタ : 　　　　　説明 . . . . . . . . : PPP Adapter. 　　　　　物理アドレス. . . . . . : 44-45-53-54-00-00 　　　　　DHCP 有効. . . . . . . . : はい 　　　　　IP アドレス. . . . . . . . . : 202.213.147.52 　　　　　サブネット マスク . . . . . . . . : 255.255.255.0 　　　　　デフォルト ゲートウェイ . . . . . . : 202.213.147.52 　　　　　DHCP サーバー . . . . . . . . : 255.255.255.255 　...　...　...　... 　...　...　...　... 1 Ethernet アダプタ : 　　　　　説明 . . . . . . . . : Fast Ethernet PCI Adapter 　　　　　物理アドレス. . . . . . : 00-00-F4-5A-39-F9 　　　　　DHCP 有効. . . . . . . . : いいえ 　　　　　IP アドレス. . . . . . . . . : 192.168.10.2 　　　　　サブネット マスク . . . . . . . . : 255.255.255.0 　　　　　デフォルト ゲートウェイ . . . . . . : 192.168.10.254 　...　...　...　... 　...　...　...　...

まず、この端末に存在するネットワークインターフェイスは「PPP Adapter」と「Fast Ethernet PCI Adapter」の２つでIP1.TXTから変化がないことが分かります。
Fast Ethernet PCI Adapterの各情報はIP1.TXTと変化がありません。しかし先程と違って、PPP AdapterにはIPアドレス等に身に覚えのない各種情報が割当てられています。今はダイアルアップ接続をしている最中のためこのようになっているのです。IPアドレス等が身に覚えのない値に設定されていたのは、ダイアルアップ接続をした際にDHCPによりIPアドレスが自動設定されたためです。
このように、たとえ自分で設定したIPアドレスの数とネットワークインターフェイスの数が一致しなくても、それは単にDHCPなどにより自動的に設定されているだけで、「IPアドレスはネットワークインターフェイス毎に割り当てられる」という原理に反しているわけではありません。
さて、先に「IPアドレスにはそれがどのネットワークに属しているのかを表す情報も含まれている」と書きました。
では次に、その「ネットワーク情報」がIPアドレスの中にどのように組み込まれているのかを見ていくことにします。
郵便の住所の場合は、住所自身に「都道府県、市町村、丁、番地」というような情報を直接含めることで地域情報（通信でのネットワーク情報に相当）を住所に組み込んでいます。この方式の場合、地域情報がそのエリアの複雑さにしたがって階層化（都道府県レベルや市町村レベル等）されるため、どんなにややこしい場所でも地域情報の階層を追っていくことでたやすくその場所を特定できるという利点があります。
インターネット黎明期のIPアドレスでは、以下に示すアドレスクラスを用いてそれぞれのネットワークを区別していました。
これによると、IPアドレスはネットワーク部とホスト部という２つの部分に分離でき、ネットワーク部の長さは１バイト、２バイト、３バイトのいずれかであることが分かります。
なお、ネットワーク部とは「ネットワークを識別する数値」を意味し、ホスト部とは「同ネットワーク内での端末を識別する数値」のことを意味します。

�@クラスA

10進法表記 　Ａ.Ｂ.Ｃ.Ｄ　　　ただし、Ａ＜128 2進法表記 　0??? ???? . ???? ???? . ???? ???? . ???? ???? 　赤字 --- ネットワーク部　　　　　緑字 --- ホスト部

　１バイト目が127以下のもの（先頭ビットが0）で、先頭バイトがネットワーク部、後ろ３バイトがホスト部となる。したがって、このクラスに属するネットワーク数は2^7（=127）個で、各ネットワークには2^24（=16,777,216）個ものIPアドレスが割当てられる。

�AクラスB

10進法表記 　Ａ.Ｂ.Ｃ.Ｄ　　　ただし、127 ＜ Ａ＜ 192 2進法表記 　10?? ???? . ???? ???? . ???? ???? . ???? ???? 　赤字 --- ネットワーク部　　　　　緑字 --- ホスト部

　１バイト目が128以上191以下のもの（先頭２ビットが10）で、先頭２バイトがネットワーク部、後ろ２バイトがホスト部となる。したがって、このクラスに属するネットワーク数は2^14（=16,384）個で、各ネットワークには2^16（=65,536）個ものIPアドレスが割当てられる。

�BクラスC

10進法表記 　Ａ.Ｂ.Ｃ.Ｄ　　　ただし、191 ＜ Ａ＜ 224 2進法表記 　110? ???? . ???? ???? . ???? ???? . ???? ???? 　赤字 --- ネットワーク部　　　　　緑字 --- ホスト部

　１バイト目が192以上223以下のもの（先頭３ビットが110）で、先頭３バイトがネットワーク部、後ろ１バイトがホスト部となる。したがって、このクラスに属するネットワーク数は2^21（=2,097,152）個で、各ネットワークには2^8（=256）個のIPアドレスが割当てられる。

�CクラスD

　１バイト目が224以上239以下のもの（先頭４ビットが1110）で、マルチキャストアドレスと呼ばれる。これは特定の端末を指すのではなく、特定のアプリケーションを共有するコンピュータのグループを指す。
　このクラスにはネットワーク部という概念がない。

�DクラスE

　１バイト目が240以上のもの（先頭４ビットが1111）で、これは将来のために予約されている。したがって、インターネットで使用することはできない。
　このクラスにはネットワーク部という概念がない。

この方式ではネットワークは階層化されて理解されず、全てのネットワークはお互いに対等な関係にありました。例えば、ネットワークAがネットワークBの中に完全に含まれていたとしても、その階層関係はIPアドレスからは分からなかったのです。
インターネットが形成され始めた頃は接続されるネットワークの数も少なくこれで特に問題はなかったのですが、その後のインターネットの急速な拡大に伴って「ルータの負荷が無視できないほどに増大する」という現象が起き始めました。これは、IPアドレスにネットワークの階層情報が無いため、ルータが使用する「ルーティングテーブル」がインターネットに接続されるネットワーク数の増加に伴ってどんどん肥大していかざるを得ないために起こったものでした。（ルーティングテーブルについては４章で詳しく解説します。とりあえずここではそういうものだと思って読み進めて下さい。）
また、この方式では各ネットワークに割当てられるIPアドレス数が、そのネットワークが実際に使用するIPアドレス数に依らず上述のとおりアドレスクラスによって決定されてしまうため、インターネットに接続される中小規模のネットワークが増加するにしたがって「IPアドレスの枯渇」という別の問題も引き起こし始めました。
これは、一番小さなクラスCのネットワークですらIPアドレスが256個も割り当てられてしまうため、そのネットワークの規模によっては使われないIPアドレスが大量に発生してしまうためです。IPアドレスは４バイトとその大きさが決まっているため、「使われないIPアドレスの発生」はすなわち全体として「IPアドレスの枯渇」を引き起こすというわけです。
そこで、IPアドレスのネットワーク部を調節して割当てIPアドレス数を節約し、かつネットワークの階層関係をも表現することができる新しい技術が開発されました。この新しい技術は、基本的にはアドレスクラスの代わりに「ネットマスク」というビット単位のマスクを用いることでネットワーク部の長さを調節できるようにするという技術です。（下図）

IPアドレス 　213.128.23.53 ネットマスク 　255.255.240.0 2進法表記 　11111111　　11111111　　11110000　　00000000　<--- ネットマスクは 255.255.240.0 　11010101　　10000000　　00010111　　00110101　<--- IPアドレスは 213.128.23.53 　<----- ネットワーク部 -----><--- ホスト部 --> ネットマスクを２進表記にした場合に１が立っている部分をネットワーク部 ０が立っている部分をホスト部とする

そのため、この新しい方法ではネットワーク及び端末の登録時に使用するIP情報を若干拡張する必要がでてきました。なぜなら、従来のアドレスクラスによる方法では、IPアドレスの先頭バイトからネットワーク部の長さが確定できたのですが、この新たな技術ではIPアドレスだけではネットワーク部の長さが確定できないため、IPアドレスそのものと共にそのネットワーク部を特定するネットマスクの情報も指定しなければならなくなったためです。
そこで、最近では端末やネットワークのIP情報を登録する際に、必ずIPアドレスと共にネットマスクも登録するようになっています。この辺りのことは、最近パソコンのネットワーク設定を自力でしたほとんどの方が経験しているのではないでしょうか。
ちなみに、前述のIP1.TXTやIP2.TXTにも「サブネットマスク」という形でこれを見てとれます。
このように登録IP情報が拡張されたため、自身のIPアドレス表記法も以下のような形に拡張されました。

例）ネットマスクが28ビット長の場合 　　IP...213.128.23.148/28 あるいは 　　IP...213.128.23.248　　ネットマスク...255.255.255.240

では次に、このネットマスクを用いたネットワークの階層化の例を見てみることにします。

この図では、まず外部ネットワークとしてネットワークXがあり、そこにネットマスク長が24ビットのネットワークAが接続されていて、そのネットワークAには更にネットマスク長が28ビットのネットワークB、Cが接続されている、という様子が表わされています。
この場合、図から「ネットワークAは、ネットワークBとCを内部に含んでいる」という階層構造を確かめられますが、実はIP情報からもその階層構造を確認できます。以下でこれを確かめてみます。
例えば、ネットワークBに含まれるIPアドレス「213.128.23.248」はネットワークAのネットマスク「255.255.255.0」と論理積をとると「213.128.23.0」となりネットワークAのIPアドレスに等しくなります。また同様に、ネットワークCに含まれるIPアドレス「213.128.23.230」もネットワークAのネットマスク「255.255.255.0」と論理積をとると「213.128.23.0」となりネットワークAのIPアドレスに等しくなります。
そしてこれは、ネットワークB、Cに属するどのアドレスを用いても同じ結果となります。
あるネットワークのネットマスクと論理積をとったものがそのネットワーク部と等しくなるアドレスはそのネットワークに属していると判断できるため、結局ネットワークB、CはネットワークAに属していることが分かります。
逆に、ネットワークAに含まれているIPアドレスの中には、ネットワークB、Cのネットマスクと論理積をとってもネットワークB、CのIPアドレスに等しくならないものが存在します（例えば「213.128.23.126」）。これは、とりもなおさずネットワークAがネットワークBやCには属していない、ということを表しています。
以上より、「ネットワークAはネットワークB及びネットワークCを内部に含んでいる」という階層構造を確認することができました。
４章でルーティングに関して解説をしますが、そこではネットマスクのこの機能によりルータの負荷が減ることを解説します。
最後に、従来のアドレスマスクによる方式では、上記のようなネットワークの階層化ができなかった、という点に注意して下さい。

ミニ解説：　プライベートアドレス 基本的にIPアドレスは世界中で重複してはならないため、NIC（Network Information Center）と呼ばれる機関がその割当てを管理しています。したがって、自分のネットワーク及びその端末に、勝手にIPアドレスを割当てることは許されず、必ずNICから割当てられたIPアドレスのみを使用しなくてはなりません。 ところが、条件付ながら「勝手に」割当てることが許されているIPアドレス群があります。それらは「プライベートアドレス」と呼ばれ、以下の条件の下で自由に使用することができます。 使用の条件 　ローカルに閉じたネットワーク内でのみ流通するアドレスとしてならば自由に使用して良い。つまり、インターネットにそのアドレス情報（プライベートアドレス）が流れるような位置のネットワークで使用してはならない。 この条件を満たすネットワークであれば、以下に示すプライベートアドレスを自由に使用して構わないのですが、この条件を満たすネットワークとは具体的にはどのようなネットワークでしょうか。 プライベートアドレス： 　10.0.0.0 〜 10.255.255.255 　172.16.0.0 〜 172.31.255.255 　192.168.0.0 〜 192.168.255.255 外部のネットワークから完全に独立した（物理的に独立した）ネットワークは勿論上記条件を満たしていますが、インターネットと物理的に繋がっているネットワークではどうでしょうか？ インターネットに繋がっている端末同士が通信する場合、必ずお互いのIPアドレスをパケットに含めなくてはならないことを前章で解説しましたが、これから考えるとインターネットと物理的に接続されたネットワークは上記条件を満たせないように思えます。 確かにほとんどの場合そうなのですが、実はあるテクニックを使用すればインターネットと物理的に繋がっているネットワークでも上記条件をクリアすることが可能となります。 それは、一言でいってしまうと「代理のテクニック」です。以下の図を見てください。 ネットワークXはインターネットに繋がっているとします。この場合、ネットワークBはインターネットに物理的に繋がっている位置関係にあります。 したがって、もしネットワークBの端末がインターネットのどこかの端末に直接アクセスした場合、必ずネットワークBの端末のIPアドレスがインターネット側に漏れてしまうので、ネットワークBではプライベートアドレスを使用することはできません。 ところが、もし、ルータR2がネットワークBの端末の代理を常にしてくれるとしたらどうでしょうか。つまり、ネットワークBの端末Pがインターネットのある端末Qにアクセスしたい場合に、P自身ではなくてR2がQにアクセスし、その通信内容をR2がPに転送するようにした場合はどうかということです。 実はこの場合、ネットワークBはプライベートアドレスを使用できることになります。なぜなら、インターネット側にはPのIPアドレスが一切流れないからです。Qと通信しているのはPではなく、あくまでもR2だからです。インターネット側にはR2のIPアドレス（213.128.23.1）しか流れないのです。勿論、Q自身にも通信相手が実はPであるとは分かりません。Qから見た場合、自分はR2と通信しているとしか認識できないためです。 このテクニックは「IPマスカレード」あるいは「NAT」と呼ばれます。このテクニックを用いれば、プライベートアドレスをインターネットと物理的に接続されれているネットワークでも使用できるようになります。 また、これにより１つのIPアドレス（非プライベートアドレス）を仮想的に複数の端末に割当てたような効果を与えることができます。

上で見たようにIPアドレスはただの数値であるため、人間にとっては非常に理解しづらいものとなっています。勿論、それはコンピュータにとっては理解しやすいものなのですが、「通信相手は226.210.3.102だ」などと言われても人間には何のことやらよくわからないでしょう。
そこで、人間が理解しやすい文字列をIPアドレスにいわば「別名」として割当てる方法が生み出されました。この割当てられた別名のことを「ホスト名」と呼びます。ホスト名はIPアドレスに対して与えられるため、IPアドレスと同じく世界中で重複は許されません。
この「ホスト名」は、一般にFQDN（Fully Qualified Domain Name）と呼ばれる郵便の住所に似た表記法で表されます。FQDNは端末やネットワークの位置を管理組織レベルで階層化し、それらを「.(ピリオド)」で区切って並べることで表現されます。
例えば、「www.nari-kobo.co.jp」というような記述があったとします。これは「日本（jp）の株式会社（co）で也工房（nari-kobo）という会社のウェブサーバ（www）」を表している、といった具合です。
このようにFQDNでは、その端末やネットワークを管理する組織の識別子を階層の浅い方から順に並べていきます。
ちなみに、先の例での「www」の部分を「短いホスト名」、「nari-kobo.co.jp」の部分を「ドメイン名」と呼びます。特定の端末を表す階層の部分を「短いホスト名」、それ以下の部分を「ドメイン名」と呼ぶわけです。
このように、ホスト名による表記はIPアドレスよりも（人間にとって）理解しやすいという特徴をもっているため、現在のインターネットでは非常に良く使用されています。ユーザが直接IPアドレスを指定してネットワークサービス（HTTPやFTP）を利用することなどほとんどないと言っても過言ではありません。
しかし、ここで注意しなくてはならないのは、ホスト名はIPアドレスと異なり必ず設定しなければならないものではない、ということです。ホスト名はいわばアドレス指定のオプションとして準備されているだけのものなのです。現在のインターネットサービスのほとんどが、通信相手の指定方法としてホスト名を利用していますが、それはユーザの利便性を考えてそうしている、というだけのことなのです。
また、もう１つ注意しなくてはならない重要なことがあります。
それは、「パケットはホスト名ではルーティングされない」ということです。
前章でIPに関して解説したことを思い出してください。データを転送するのはIPの仕事でした。IPは何を基にデータを転送したかというとそれはIPアドレスでした。TCP/IPネットワークでは、パケット転送の基本はあくまでもIPアドレスなのです。
では、ホスト名による通信はどのような仕組みで実現しているのでしょうか。
実はその場合、まずホスト名を何かしらの方法でIPアドレスに変換しそのIPアドレスを用いて通常の方法で通信を行う、という処理がシステムの裏側で行われているのです。パケットの転送はIPが行うわけですから、通信はやはりIPが理解できるIPアドレスを導出してから行われるというわけです。
この「ホスト名を何かしらの方法でIPアドレスに変換」する処理のことを「名前解決」と呼び、その方法にはいくつかの種類があります。これについては次章で詳しく解説しますので、ここではこれ以上深入りしないことにしておきます。
注意
　Microsoft Windows系のシステムでは端末を識別するのに「コンピュータ名」というものを使用しますが、これとホスト名とを混同しないようにして下さい。
ホスト名はネットワークインターフェイス（つまりはIPアドレス）に対して与えられますが、コンピュータ名はそれぞれの端末に対して一意に与えられる名称です。したがって、１つの端末にコンピュータ名は１つしか存在できません。この点でコンピュータ名はホスト名と大きく異なります。
　コンピュータ名はNetBIOS名とも呼ばれます。NetBIOSというのはWindowsが標準で使用する通信プロトコルの一種で、TCP/IPスイートに含まれているものではありません。つまり、コンピュータ名は、この「NetBIOS」プロトコル上での端末の住所の表記法だということです。
　また、UNIX系のシステムで「ホスト名」といった場合、上記のIPアドレスに対応したホスト名の他に、端末に対して与えられた名称を指して「ホスト名」という場合がよくあります。（通信に絡まない文脈で使われた場合はまずこちらの意味でしょう。）この場合の「ホスト名」は上記の「コンピュータ名」と同じように、「端末に対して与えられた名称」であって「IPアドレス、つまりはネットワークインターフェイス、に対して与えられた名称」ではない点に注意して下さい。ややこしいですが、それはNetBIOS上の名称でもありませんので、そういう意味でコンピュータ名ともやはり違うという点を誤解しないようにして下さい。
　以下で「ホスト名」といった場合は、特に断らないかぎり「IPアドレスに対応したホスト名」のことを指すものとします。

TCP/IPネットワークではほとんど意識されることがありませんが、送信先の端末が存在するネットワークでパケットをその端末にまで送る際に使用されるアドレスはIPアドレスではありません。そこで使用されるのは「物理アドレス」と呼ばれる、ネットワークの媒体によってその表記法が異なる、IPアドレスとはまったく別物のアドレス体系です。
これを読んで今までの知識が混乱してしまった方も多いのではないでしょうか。今まで、「パケットの転送はIPが行っていて、IPはパケットの転送をIPアドレスを基にして行う」と何度も書いてきましたし、ちまたの参考書を見てもIPアドレスこそが通信で相手先を指定するものだとひつこいくらいに書かれているので無理もありません。
この事実を始めて聞いたときにあっさり理解できた方は素晴らしい洞察力の持ち主だと思います。僕も、ネットワークに関して勉強を始めた頃にこの話しを聞いて「は?!?!?!?!（頭がパニック）」状態であったのを覚えています。
この事実を正しく理解するためには、何よりも前章のプロトコル階層の話を正しく理解することが必要です。それを踏まえて以下の質問について順に考えていくことにしましょう。

�@ネットワークでパケットを実際に送受信しているものは何でしょうか？ �Aそれを制御しているのはどのプロトコル層に属しているものでしょうか？ �Bそのプロトコルで使用されているパケットはどんな形なのでしょうか？ �Cネットワークを実際に流れるパケットは、どんなパケットでしょうか？

最初の質問「パケットを実際に送受信しているものは何でしょうか？」について考えてみましょう。これには定まった回答はありません。ネットワークの種類によって異なるからです。ただ、最近のネットワークはたいていが「Ethernet（イーサネット）」ですから、おそらく「LANカードとツイストペアケーブル」がその答えとなるでしょう。10BaseTだとか100BaseTXだとかいうキーワードが絡んだ媒体を使用していれば、そのネットワークは「Ethernet（イーサネット）」です。
では次の質問「それを制御しているのはどのプロトコル層に属しているものでしょうか」について考えてみましょう。
前章での話を読み返せば、通信に絡む媒体とそのインターフェイスを制御しているのは「ネットワークアクセス層」であることが分かります。したがって、第２の質問に関する回答は「ネットワークアクセス層」となります。
そして３番目の質問「そのプロトコルで使用されているパケットはどんな形なのでしょうか？」について考えてみましょう。
これも１番目の質問と同様定まった答えはありません。ネットワークアクセス層のプロトコルはネットワークの種類に応じて異なるためパケットの形もネットワークの種類に応じて違ったものとなるからです。
しかしながら、パケットの概略だけはどのプロトコルでも同じだったことを思い出してください。それは「ヘッダー部＋データ部」という形をしていました。そして、そのヘッダー部にはそのプロトコルが使用する各種制御情報が、データ部には上位プロトコルのパケット（あるいはそれを分割したもの）が、格納されているのでした。
最後の質問「ネットワークを実際に流れるパケットは、どんなパケットでしょうか」について考えてみます。その答えは簡単で３番目の質問の答えとまったく同じです。ネットワークアクセス層で取り扱われるパケットこそが実際にネットワークに流れているパケットだからです。「そんなこと分かってるよ」という方も、物理アドレスの話がいまひとつしっくり理解できなかったという場合、本当は最後の質問の答えを深くは理解できていなかったということですので、もう一度その答の意味するところを考えてみて下さい。
どうでしょうか？　何か見えてきましたでしょうか？
そうです！　送受信機器を制御しているのはネットワークアクセス層でIPアドレスが存在するのはインターネット層だ、という点が非常に重要なわけです。
実際にネットワークを流れているパケットはネットワークアクセス層のパケットなのです。IPパケットではありません。実際に送受信を行っているハードウェアを操作しているのはネットワークアクセス層なので、そのレベルではインターネット層が使用するIPアドレスなど使用されていないのです。（IPアドレスはIPプロトコルのみが使用する点を再確認して下さい。）
要するに、IPパケットそのものが直に流れているネットワーク（IPネットワーク）などそもそも存在しないのです。
ではIPアドレスは何のために存在しているのでしょうか？　前章の内容をもう一度注意深く考えてみて下さい。
ネットワークの種類に応じてアドレスの指定方法は異なります。そのため、ハードウェアレベルのアドレスではパケットを異なる種類のネットワークへとうまく転送できません。そこで、ハードウェアレベルの上にハードウェアに依存しないもう一つの統一的なアドレス体系を持ち込んで、その基でネットワーク媒体によるアドレス指定の違いを吸収させた仮想的なネットワークを構築する必要があったのです。そして、その「ハードウェアに依存しないもう一つの統一的なアドレス体系」として使用されているものこそがIPアドレスなのです。IPネットワークとは「ネットワークの違いによるアドレス指定の違いをIPアドレスという統一的なアドレス体系で吸収させて構築された仮想的なネットワーク」のことなのです。
慎重に考えれば当たり前のことなのですが、このようにうっかりIPネットワークを末端に実在するネットワークであるという錯覚を起こしてしまうと、物理アドレスの意味が理解不能になってしまいますので注意して下さい。
物理アドレスの具体例としては、例えばEthernetで使用される「MACアドレス」などがあります。上でも述べたとおり、物理アドレスはネットワークの種類によってその呼び名も表記法も異なります。
最後に、プロトコル階層の違いに起因するIPアドレスと物理アドレスの重要な違いについて触れておきます。
通信を行う場合、ユーザ（あるいはアプリケーション）はIPアドレスを特定しなくてはなりませんでしたが、その場合の「IPアドレス」とは最終目的地（送信先）のIPアドレスのことを指していました。
一方、実際にデータを送受信している通信装置自身は上で述べたとおりIPアドレスではなく物理アドレスで送信先を認識しています。（ミニ解説「ARP」参照） しかも、通信装置はネットワークのノードからノードへのデータ運搬、つまり同一ネットワーク内でのデータ運搬にしか責任を持ちません（ネットワークアクセス層の解説参照）。
これらのことから、データ送信の際に特定する必要がある「物理アドレス」とは、実はデータを次に受取るべきノードのアドレスを指していることが分かります。IPアドレスのような最終目的地（送信先）のものではないのです。したがって、あるパケットのIPアドレスと物理アドレスが異なるホストを表している、ということはざらにあります。（というより、インターネットではその場合の方が多いでしょう）
この点はIPアドレスと物理アドレスの重要な違いですので注意して理解しておいて下さい。

(0)概論

前章で述べたとおり、ホスト名を使用した通信を行うためには、必ず「名前解決」という処理を通してホスト名に対応するIPアドレスを取得する必要があります。
この名前解決の方法には、大きく分けて以下の３つがあります。
�@ブロードキャスト型
　ブロードキャスト型は、同じネットワークの全ての端末に「AさんのIPアドレスはなんですか？」というメッセージを送りつけてそれに答えてもらう、という恐らくは最も分かりやすい方法です。
　これは、ある教室で「A君の電話番号は何番ですか？」と大声で聞くことに似ています。そのような状況では、教室中の皆がその質問を聞くことになってしまいますが、本人がそこにいれば「僕の電話番号は#####番です」と答えてくれるはずです。
ブロードキャスト型の名前解決でもこれと同様のことが行われます。端末A自身がこのメッセージを受取ると「私のIPアドレスは ***.***.***.*** です」という内容の返答メッセージを送信元に送り返してくれるというわけです。
　しかし、この方式には大きな欠点があります。先の例でいえば、もしA君がその教室にいなかった場合返事が返ってこない、という点です。
ブロードキャスト型でも同じく、端末Aが送信元と同じネットワークに存在しない場合、Aは返答メッセージを返しようがないのです。なぜなら、ブロードキャストパケットはルータを越えることができないからです。質問が端末Aの耳に入らなければどうしようもないのです。
　そのため、この方式は同一ネットワーク内でしか有効ではないという欠点をもっていることになります。
�Aファイル参照型
　ファイル参照型は、ホスト名とIPアドレスの対応を記したファイルを端末内に保持しておき、そのファイルを参照することで名前解決を行う方法です。IPアドレスを他の誰かに問い合わせたりしないので高速に名前解決を行える利点があります。
　しかしこの方式の場合、ファイルに情報が記されていないホスト名に関しては名前解決ができません。インターネット中のホストの情報をファイルに収めることなど不可能ですので、実際問題としてある程度規模の小さなネットワーク内でしか使えないといえます。
また、この方法の場合ネットワークの構成に変更が合った場合その変更を全ての端末に反映させる必要があるため、保守管理にかかる労力が通信相手として想定されるネットワークの規模によっては膨大なものとなる危険性があります。
�BDNS型
　上記２つの方法はどちらも、急速に拡大を続けるインターネットの世界で一般的に使用されるには限界がありました。ネットワークが拡大しても、その構成に変更があっても、それらの変化に素早く簡単に対応できる新たな仕組みが必要だったのです。
　そこに登場したのが、「DNS（Domain Name Service）」と呼ばれる分散クライアント・サーバ型の仕組みでした。そして現在では、ほとんどのネットワークでこの方式が採用され、名前解決の主流となっています。
　そのDNSの基本思想は、「各ネットワークのことはそれぞれのネットワーク自身で管理する」というものです。
この方式で名前解決が行われるためには、各ネットワークで、そのネットワークのホスト名・IPアドレス対応表を管理するDNSサーバを立ち上げておく必要があります。そして各端末では「####ってホストのIPアドレスを教えてくれる？」という依頼をDNSサーバに送信し返答させることで名前解決を行います。
　詳しくは後述しますが、問い合わせを受けたDNSサーバが、対象となるホストを管理しているのが自分でないと気付くと、自分よりもそのホストのことを知っているであろうDNSサーバに対し自分にされたのと同じ問い合わせを行う、という動作をします。この動作を繰り返すことで、どんなにネットワークの階層が深いホスト名に対してもそれを管理しているDNSサーバを知ることができるというわけです。
　このように、DNSという仕組みは、インターネット中のDNSサーバで名前解決という仕事を分散させるクライアントサーバ型の仕組みだといえます。ネットワークの構成が変わった場合や、新たなネットワークが加わった場合でも、その影響を受けるのはそれらの端末を管理しているDNSサーバのみに限定できるので、上記�@�Aの方法に比べずっと拡張性に富んだ仕組みだといえます。
　以下では、これらのうち現在名前解決の主流となっている「�BDNS型」の名前解決について詳しく解説することにします。
注意
　DNSはホスト名やネットワーク名のIPアドレスを調べるためだけに利用されているわけではありません。例えば、SMTPサーバが、とあるメールの宛先のメールアドレスをみて、そのメールを受取るべきSMTPサーバのアドレスを調べる場合にも利用されます。
　後日、bindやsendmailの設定を解説する機会があればこのことについて触れる予定でいます。

一般に名前解決といえばホスト名からIPアドレスを取得することを指しますが、これを「正引きの名前解決」と呼びます。これに対して「逆引きの名前解決」というものもありますが、これについては次節で解説することにします。
先に触れたとおり、名前解決は世界中に設置されたDNSサーバが連携しあって処理を行います。連携し合うといっても、やみくもに連携しあっていては名前解決が完了するまでに何時間もかかってしまいます。（世界中には何万台というDNSサーバが存在することを思い出して下さい。）
では、DNSサーバはどのような形で他のDNSサーバと連携し合うのでしょうか。以下で、その動作概要を説明することにしますが、その前に「ホスト名は階層化されたドメイン名から成り立っている」ということを思い出しておいて下さい。例えば「hoge.page.co.jp」といえば「日本（jpドメイン）の会社（coドメイン）である株式会社パゲ（pageドメイン）が所有するhogeというホスト」を表しているということです。

�@	まず、ネットワーク「hana-kobo.co.jp」上のあるホストAが、ネットワーク「nari-kobo.co.jp」上のホストBと通信を行いたいとします。
�A	通信はIPアドレスにより行われるため、ホストAはホストBのIPアドレスを知っていなくてはなりません。
�B	しかし、ホストAはBのIPアドレスを知らず、ホスト名「ftp.nari-kobo.co.jp」のみを知っているとします。 注意 ホストAが何らかの理由でホストBのIPアドレスを知っている場合、例えば以前の通信時にできたキャッシュにホストBとそのIPアドレスの対応データが残っている場合、�C以下の処理は行われずキャッシュされたIPアドレスを用いてすぐに通信が始まります。なお、一般にキャッシュデータは一定時間が経つと削除されるようになっています。
�C	そこで、Aは自分の所属するネットワークのDNSサーバCに「ftp.nari-kobo.co.jpのIPアドレスは何ですか？」と問い合わせをします。（*1） *1.....正確にいうと、問い合わせ先は「自分の所属するネットワークのDNSサーバ」である必要はなく、どこのDNSサーバに対して行っても構いません。が、たいていの場合はプライマリDNSサーバと呼ばれる、最初に問い合わせを行うDNSサーバを自分の所属するネットワークのDNSサーバに設定します。
�D	問い合わせを受けたCは、ホスト名から得られるBのネットワーク名「nari-kobo.co.jp」をチェックし、それが自身の管理するネットワーク「hana-kobo.co.jp」とは異なることを知ります。 注意 もしBがAと同じドメインに属していれば、BのIPアドレスはCが管理しているので、�Cの時点でBの名前解決は完了します。
�E	そこで、Cはルートドメイン（*2）のDNSサーバXに「ftp.nari-kobo.co.jpのIPアドレスは何ですか？」と問い合わせをします。 *2.....jpドメインや com ドメインなど、ホスト名で一番最後に記述されるトップレベルドメインを管理している最上位のドメインのこと。
�F	X自身は「nari-kobo.co.jp」ドメインを管理していないのでそのIPアドレスを答えられません。そこでXは「ftp.nari-kobo.co.jp」のトップレベルドメインでなおかつ自身の管轄ドメインでもある jp ドメインのDNSサーバYのIPアドレスを返しそこに再度問い合わせをするよう促します。
�G	Cはそれを受け、今度はYに「ftp.nari-kobo.co.jpのIPアドレスは何ですか？」と問い合わせをします。
�H	X同様、Yも「nari-kobo.co.jp」ドメインを管理していないのでそのIPアドレスを答えられません。そこでYは「ftp.nari-kobo.co.jp」の2ndレベルドメインでなおかつ自身の管轄ドメインでもある co.jp ドメインのDNSサーバZのIPアドレスを返しそこに再度問い合わせをするよう促します。
�I	Cはそれを受け、今度はZに「ftp.nari-kobo.co.jpのIPアドレスは何ですか？」と問い合わせをします。
�J	しかし今度のZも「nari-kobo.co.jp」ドメインを管理していないのでそのIPアドレスを答えられません。そこでZは「ftp.nari-kobo.co.jp」の3rdレベルドメインでなおかつ自身の管轄ドメインでもある nari-kobo.co.jp ドメインのDNSサーバPのIPアドレスを返しそこに再度問い合わせをするよう促します。
�K	Cはそれを受け、今度はPに「ftp.nari-kobo.co.jpのIPアドレスは何ですか？」と問い合わせをします。
�L	すると、このPはまさしくBが属しているネットワークのDNSサーバなので、ここでついにBのIPアドレスが分かることになります。PはCに「ftp.nari-kobo.co.jpのIPアドレスは###.$$$.%%%.!!!です。」という応答を返します。
�M	BのIPアドレスを取得したCは、そのアドレスをAに返します。
�N	後はAが、取得したIPアドレスを使ってBと通信を開始するだけとなります。

前節で解説した「正引きの名前解決」-- ホスト名からIPアドレスへの変換 -- とは逆に「逆引きの名前解決」-- IPアドレスからホスト名への変換 -- という処理が存在します。
前述のとおり、IPアドレスさえ分かればパケットを通信相手まで届けることが可能なので「正引き」の存在理由は説明するまでも無いのですが、「逆引き」が存在する理由は一体何でしょうか？　IPアドレスが分かっていれば通信に何ら問題は無いはずなのにそれをわざわざホスト名に変更しなくてはならない場面があるのでしょうか？
このような逆引きの名前解決は、セキュリティ上の要請から通信相手の属するドメインを調べたい場面などで必要になります。
例えば、「TELNETサービスをある特定のドメインに属するホストからのみに限定したい」「あるドメインからのアクセスを一切許可したくない」などの場合です。
前述のIPパケットのヘッダー部分を見ると分かるとおり、サーバが受取った通信開始の要求パケットには要求元のIPアドレスが含まれていますがホスト名は含まれていません。したがって、要求元のホストが属するドメインなどの情報は特別な処理（逆引きの名前解決）を行わないかぎり知ることができないのです。
本来、通信を行うにあたっては正引きの名前解決さえ可能であればそれで問題は無いのですが、上記のようなセキュリティポリシーを設定するネットワークが増えてきているため、現在ではDNSサーバを立てる際は必ず正引きと逆引きの両方を設定しなくてはならないようになっています。
では逆引きの名前解決を行う際、DNSサーバはどのように連携し合うのでしょうか。正引きの場合とどこが違うのでしょうか。
結論を言ってしまうと、実は逆引きも正引きと同じメカニズムで動作します。つまり各ドメインを管理するDNSサーバ同士がその階層にしたがって処理を分散し合うというものです。
ここで、「え？　IPアドレスにはドメインという概念は無いのに各ドメインを管理するDNSサーバってどういうこと？」と思った方は鋭いです。ホスト名と違い、IPアドレス自身には元々ドメインという概念は含まれていなかったはずです。
実は、逆引きでも正引きと同じメカニズムが利用できるよう、後で示すようにIPアドレスを（若干無理矢理に）階層化して逆引きの名前解決用に「IPアドレスからみたドメイン」というものを定義しています。それがここでいうドメインです。
ですから、ホスト名でいうところのドメイン（一般的な意味合いでのドメイン）ほどネットワークの論理的な階層関係が存在するわけではありません。以下では、この逆引き用のドメインと正引き用のドメインとを区別するために、逆引き用のドメインのことを「IPドメイン」と呼ぶことにします。
では、IPアドレスがどのようにIPドメインに分割されるのか具体的に見てみることにします。ここでは例としてIPアドレスが「213.128.23.146」となるホストＡ（ホスト名：inetsrv.nari-kobo.co.jp）をとりあげます。（注：当然ながら実在しないホストです）
ホストＡがサブネットマスクによるネットワーク分割を受けていないと仮定すると、この例（ホストA）でのIPドメインは「23.128.213.in-addr.arpa」となります。また、DNSサーバに問い合わせされる際の逆引き用の名称は「146.23.128.213.in-addr.arpa」となります。
つまり、ホストAは「ドメイン23.128.213.in-addr.arpa に属する 146 という名のホスト」として表現されるわけです。こうすれば、正引きも逆引きも同じロジックで名前解決ができそうだと分かってもらえると思います。つまり、最初にルートドメインのDNSサーバに「146.23.128.213.in-addr.arpa のホスト名は何ですか？」と問い合わせ、その返答で得られたarpaドメインのDNSサーバに同じ問い合わせを送り、更にその返答で得られたin-addrドメインのDNSサーバに問い合わせを送り、......という具合です。
ここで示した例のように、逆引き用のドメインではルートドメインの次に来るドメインを「arpa」、更にその次のドメインを「in-addr」とするものとして決めておき、それ以降の階層のドメインとしてIPアドレスを左から順に並べてIPドメインを表現することになっています。（下図参照）

逆引き用の機能を正引き用と別に作らなくて済むという意味で、この逆引きでのドメイン（及び逆引きのホスト名）の定義法は非常に巧妙だといえますが、実は１つ問題があります。少し考えれば分かりますが、ホストAの属するネットワークがサブネット化されていると上の方法ではうまくいかない、少なくとも実用上の問題がでてくるのです。
例えば、先の例でホストAのネットマスクが28ビットであったとします。その場合、ホストAが属するドメイン「nari-kobo.co.jp」のネットワークアドレスは「213.128.23.144/28」ということになります。
そこに、同じくネットマスクが28ビットでIPアドレスが「213.128.23.130」となる別のホストB（ホスト名：www.hana-kobo.co.jp）があったとします。その場合、ホストBが属するドメイン「hana-kobo.co.jp」のネットワークアドレスは「213.128.23.128/28」ということになります。
これらの仮定の基で上記のIPドメイン決定法を用いると、ホストAもホストBもIPドメインが「23.128.213.in-addr.arpa」ということなってしまい、ホストAとホストBの逆引き用の情報を同じDNSサーバで管理しなくてはならないことになってしまいます。ホストAとホストBのドメインは異なりますので、これは運用上問題があります。（理論上は不可能ではありませんが、一般的によそのネットワークの管理まで快く引き受ける管理者はそうそういません。）
そこで、現在ではこの不具合を解決すべくいろいろな方法がそれぞれのネットワークで採用されています。逆にいうと決まった方法が無いということでもありますが、ここでは DION で採用されている方法を紹介することにします。いろいろな方法があるとはいっても、単にIPドメインの命名規則が違う程度で、基本的には同じ作法で処理されていますので「サブネット化された場合の逆引き」の理解には役立つものと思います。
なお、ここでは bind など個別のソフトウェアでの具体的な設定は解説しません。概念的なものに徹することにします。具体的な設定例については後日の特集で解説することにします。

[サブネット化されている場合の逆引き設定（DIONの場合）]

（題）IPアドレスが 213.128.23.146/28 となるホスト inetsrv.nari-kobo.co.jp の逆引き設定

(i)	ネットマスクが28ビットなので、題のホストの属するネットワークアドレスが「213.128.23.144/28」と分かる。
(ii)	このネットワークアドレスを用いて、題のホストの属するIPドメインを「144h.23.128.213.in-addr.arpa」と定義する。サブネット化を考慮しない場合のIPドメイン「23.128.213.in-addr.arpa」とは異なる点に注意する。
(iii)	したがって、題のホストの逆引きでの名称は「146.144h.23.128.213.in-addr.arpa」と定義/登録される。これは、題のホストが属するIPドメイン「144h.23.128.213.in-addr.arpa」のDNSサーバに登録される。
(iv)	IPドメイン「23.128.213.in-addr.arpa」のDNSサーバに、題のホストが属するIPドメイン「144h.23.128.213.in-addr.arpa」のDNSサーバを登録する。
(v)	IPドメイン「23.128.213.in-addr.arpa」のDNSサーバに、題のホストを別名で登録する。つまり、「146.23.128.213.in-addr.arpa」という名称が「146.144h.23.128.213.in-addr.arpa」の別名であると登録する。

以上が、逆引き用の設定です。ミソとなるのは、最後の「ホストを別名で登録する」ところです。これがどのように働くのかを以下でみることにします。

[サブネット化されている場合の逆引きの流れ（DIONの場合）]

�@	あるホストAがIPアドレス「213.128.23.146」となる端末Bのホスト名を調べたいとします
�A	Aは自身の属するネットワークのDNSサーバCに「146.23.128.213.in-addr.arpa のホスト名は何ですか？」と問い合わせを行います。（Bの逆引き名は最初に解説したロジックにより 146.23.128.213.in-addr.arpa となることに注意）
�B	問い合わせを受けたCは、Bが自身の管理するネットワークに存在しない（と仮定）ことを知ります。
�C	そこで、CはルートドメインのDNSサーバXに「146.23.128.213.in-addr.arpa のホスト名は何ですか？」と問い合わせをします。
�D	Xは「146.23.128.213.in-addr.arpa」のトップレベルドメインでなおかつ自身の管轄ドメインでもある arpa ドメインのDNSサーバYのIPアドレスを返しそこに再度問い合わせをするよう促します。
�E	Cはそれを受け、今度はYに「146.23.128.213.in-addr.arpa のホスト名は何ですか？」と問い合わせをします。
�F	Yは「146.23.128.213.in-addr.arpa」の2ndレベルドメインでなおかつ自身の管轄ドメインでもある in-addr.arpa ドメインのDNSサーバZのIPアドレスを返しそこに再度問い合わせをするよう促します。
�G	このように正引きと同じロジックで問い合わせ先を転々とし、ついに「23.128.213.in-addr.arpa」ドメインのDNSサーバPまで辿りつきます。
�H	そしてCはPに「146.23.128.213.in-addr.arpa のホスト名は何ですか？」と問い合わせをします。
�I	するとPでは、「146.23.128.213.in-addr.arpa」が実は「146.144h.23.128.213.in-addr.arpa」の別名であると登録されていて、またそのドメイン「144h.23.128.213.in-addr.arpa」のDNSサーバQのIPアドレス情報も登録されています。そこでPはそれらの情報をCに返しQに再度問い合わせをするよう促します。
�J	Cはそれを受け、今度はQに「146.144h.23.128.213.in-addr.arpa のホスト名は何ですか？」と問い合わせをします。（146.23.128.213.in-addr.arpa ではない点に注意）
�K	QはまさしくBが属しているネットワークの逆引き用DNSサーバなので、QはCに「146.144h.23.128.213.in-addr.arpa のホスト名は inetsrv.nari-kobo.co.jp です。」という応答を返します。
�L	Bのホスト名を取得したCは、そのホスト名をAに返します。

(0)概論

この章では、ネットワーク間でパケットを転送しあう際に最も重要な「ルーティング」と呼ばれる処理について解説します。ルーティングを日本語で書くと「経路選択」となります。つまりルーティングとは、ルータ（ゲートウェイ）が、あるパケットを別のネットワークに転送しなくてはならない場合にどのネットワークに転送すればよいかを判断する処理だといえます。
ここまで順に読み進めた方にとっては自明のことでしょうが、ルーティングの解説の前に、念の為、パケットを別のネットワークに転送する必要があるかどうか判断する際の基準について解説しておきます。
これは、基本的に「あるIPアドレスとあるネットワークアドレスとの論理積がそのネットワークアドレスに等しい場合、そのIPアドレスで示されるホストはそのネットワークアドレスのネットワークに属している」という原理を基に判断しています。
例えば、IPアドレス「213.128.23.148/28」のホストAが、IPアドレス「213.128.23.152」のホストXと通信したい場合を考えてみます。
まず、ホストAはネットマスクが28ビットであることから自身の属するネットワークのネットワークアドレスが「213.128.23.144」だと知っています。このネットワークアドレスとホストXのIPアドレス「213.128.23.152」の論理積をとると結果は「213.128.23.144」となり、ホストAの属するネットワークアドレスと同じだと分かります。
前述の原理により、この場合ホストXはホストAと同じネットワーク上にあると判断されるため、ホストAはパケットを別のネットワークに転送する必要無しと判断します。

では、上記のホストAがIPアドレス「213.128.23.130」のホストYと通信したい場合はどうでしょうか。
ホストAのネットワークアドレス「213.128.23.144」とホストYのIPアドレス「213.128.23.130」の論理積をとると結果は「213.128.23.128」となります。これはホストAのネットワークアドレス「213.128.23.144」とは異なりますので、ホストYがホストAとは異なるネットワークに存在すると分かります。
したがってこの場合、ホストAはパケットを別のネットワークに転送する必要有りと判断します。

以上が、パケットの他ネットワークへの転送が必要かを判断する際に（暗黙のうちに）送信元で行われている処理です。確認しておいてほしいのは、パケットの転送が必要かを最初に判断するのはルータ（ゲートウェイ）ではなく送信元のホストであるという点です。これは結構勘違いしやすいので注意しておいて下さい。

では、本題のルーティングの解説に入ることにします。
先程の２番目の例のように、別のネットワークへの転送が必要だと判断された場合、送信元で次に行われる処理 -- どのルータ（ゲートウェイ）に転送を依頼すれば良いかの判断 -- こそが「ルーティング（経路選択）」と呼ばれるものです。前述のとおり、インターネットでは各ネットワークが網目状に接続されています。目的地に到達する経路はいくらでも存在するわけです。したがって、これ（経路選択）をしないことには効率的な通信が実現できないのです。

[sugi@inetsrv]# netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.10.0    0.0.0.0         255.255.255.0   U      1500 0          0 eth0
192.168.30.0    192.168.10.254  255.255.255.0   UG     1500 0          0 eth0
213.128.23.144  192.168.10.254  255.255.255.240 UG     2000 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U      3584 0          0 lo

重要な項目について解説します。

つまり、上記ルーティングテーブルの例は以下のことを表していることになります。

�@	ネットワーク「192.168.10.0/24」上のホストと通信する場合は、インターフェイス「eth0」が同ネットワークに直結している（転送不要）のでそこに直接パケットを送り込めば良い。
�A	ネットワーク「192.168.30.0/24」上のホストと通信する場合は、ルータ（IPアドレス：192.168.10.254）にパケットの転送を依頼する必要がある。なお、同ルータへはインターフェイス「eth0」から接続できる。
�B	ネットワーク「213.128.23.144/28」上のホストと通信する場合は、ルータ（IPアドレス：192.168.10.254）にパケットの転送を依頼する必要がある。なお、同ルータへはインターフェイス「eth0」から接続できる。
�C	ネットワーク「127.0.0.0/8」上のホストと通信する場合は、ループバックインターフェイス「lo」にパケットを送り込めば良い。（「127.0.0.1」はループバックアドレスである点に注意）

ルーティング処理はこのようなルーティングテーブルの情報に基づいて行われます。具体的には、

(i)	ルーティングテーブルのDestination・Genmaskを上から順に走査して送信先ホストのIPアドレスが該当するレコードを探し、
(ii)	そのレコードにGatewayが設定されていたら、IfaceからそのGateway宛てにパケットを送る(*1)。（Gatewayは送られてきたパケットをしかるべきネットワークへ転送する。）
(iii)	そのレコードにGatewayが設定されていなければ、Ifaceからその送信先ホスト宛てにパケットを送る(*1)。

*1...

これはインターネット層レベルまででとらえた場合の話し。より正確に（ネットワークアクセス層まで含めて）表現すると「Gatewayや送信先ホストのIPアドレス宛てでパケットを送る前に、ARPなどでそれらの物理アドレスを調べ、Ifaceからその物理アドレス宛てにフレームを送る」ということになります。プロトコルの解説にて注意したとおり、実際に通信を行う際に使用されるアドレス体系は物理アドレスであることを思い出して下さい。IPアドレスはあくまでも仮想的な（つまりは論理上の）ネットワークで使用されるアドレス体系なのです。 なお、ここではルーティングの際の物理アドレス取得法として「ARP」を使用しているように書きましたが、数年前までにネットワークの勉強をした方は「Proxy ARP」と呼ばれる方法を教わったかもしれません。確かにそれはかつて主流の方法だったのですが、今ではあまり使われなくなったため、初学者の混乱を避けるためにもここでは解説しないことにしました。現在では上記のロジックによるルーティング処理が普通になっていることを覚えておいて下さい。「Proxy ARP」について詳しく知りたい方は別の情報ソース（書籍、ウェブ etc）を参照して下さい。

という動作をします。
例えば、上の例でIPアドレス「213.128.23.150」のホストと通信をしたい場合、ルーティングテーブルのDestination・Genmaskを順に調べ該当レコードを探すと三行目（�B）のエントリーが送信先IPアドレスに合致することが分かります。更に同レコードのGatewayをみるとIPアドレス「192.168.10.254」のゲートウェイにパケット転送をしてもらう必要があると分かります。結局、このケースでのルーティングは「eth0インターフェイスからそのゲートウェイ宛てにパケットを送り転送してもらう」という動作をすることになります。
なお、ルーティングは送信元ホストだけが行うものではなくゲートウェイ（ルータ）も行いますので、当然ゲートウェイも独自のルーティングテーブルを持っていることになります。そして基本的にゲートウェイも自身のルーティングテーブルを基に上記と同じロジックでパケットを転送します。このようにしてパケットは送信先に到着するまでバケツリレー式に運ばれることになります。
以上のとおりルーティング処理はルーティングテーブルを用いて行われるわけですが、ここで１つ新たな疑問が出てきたことでしょう。「じゃ、ルーティングテーブルはどういうロジックで作成されるんだ？」
実は、ルーティングテーブル作成法は各ネットワークでその管理者が設定することになっています。基本的には手動作成と自動作成の２種類があります。手動作成とは、読んで字のごとくネットワーク管理者が手動でルーティングテーブルを作成する方法を指します。自動作成とは、ゲートウェイ同士を連携させて機械的にルーティングテーブルを作成する方法を指します。一般的に、ルーティングテーブルを自動作成する場合は定期的にその内容を更新するよう設定されます。これらのルーティングテーブル作成方法については詳しくは次節以降で解説することにします。

時間的に変化しないルーティングテーブルを用いてルーティング処理を行うことを「静的ルーティング」と呼びます。手動でルーティングテーブルを設定する場合などが該当します。
Linuxでは route コマンドでルーティングテーブルのエントリを設定できます。routeコマンドのよく使用される書式を以下に示します。（細かい書式については「man route」を参照のこと）
[経路の追加]

route add [-net|-host] target [netmask Nm] [gw Gw] [metric N] [[dev] If]

[経路の削除]

route del [-net|-host] target [gw Gw] [netmask Nm] [metric N] [[dev] If]

[オプションの意味]

-net target をネットワークとする。 -host target をホストとする。 target は、対象のネットワークかホストである。10 進ドット表 記 の IP アドレスか、ホスト名もしくはネットワーク名 を指定可能である。 netmask Nm 追加する経路のネットマスクを記述する。 gw Gw 目的のネットワークもしくはホストへの IP パ ケッ ト は、 ここで記述されたゲートウェイを経由する。 注意: 記述されたゲートウェイは、まず到達可能でなければ な ら ない。これは通常、前もってゲートウェイに静的経路 を設定しなくてはならないということである。もし、 ロ ーカルのインタフェース のアドレスを指定した場合は、 それはパケットが通過すべきインタフェースの決定に 使 用 さ れる。これは BSD の手法にのっとったやり方であ る。 metric M 経路テーブルのメトリック (routed デーモンが使 用 す る) を M に設定する。 dev If 記述されたデバイスに、経路を関連づけることを強制 す る。 通常カーネルは自分自身でデバイスを決定しようと する(すでにある経路とデバイスの記述、経路がどこに追 加 されているかによる) 。一般的なネットワークでは、 これを指定する必要はない。

以上より、前節の例でのルーティングテーブルを作成するには以下のコマンドを発行すればよいことが分かります。

route add -net 192.168.10.0 netmask 255.255.255.0 dev eth0 route add -net 192.168.30.0 netmask 255.255.255.0 gw 192.168.10.254 dev eth0 route add -net 213.128.23.144 netmask 255.255.255.240 gw 192.168.10.254 dev eth0 route add -net 127.0.0.0 netmask 255.0.0.0 dev lo

なお、もしデフォルトルートをIPアドレス「192.168.10.254」のルータに設定する場合は予約語「default」を用いて以下のコマンドを発行します。

route add default gw 192.168.10.254 dev eth0

時間的に内容が更新されていくルーティングテーブルを用いてルーティング処理を行うことを「動的ルーティング」と呼びます。ゲートウェイ同士を連携させてルーティングテーブルを作成する場合は、多くの場合適当な時間間隔でルーティングテーブルを更新するよう設定されているのでたいてい「動的ルーティング」に該当するでしょう。
動的ルーティングの技術は次世代インターネットに絡んで現在でも盛んに研究が進められています。それに深入りすることは「それ行け！リナちゃん」の守備範囲から離れてしまうため、当節では基本的な事柄についてのみ解説することにします。
動的ルーティングではネットワークのセグメント間で最新の経路情報をやり取りする必要があります。そのために使用されるプロトコルを経路制御プロトコルと呼び、それは「内部経路制御プロトコル」「外部経路制御プロトコル」の２つに大別することができます。
「内部経路制御プロトコル」とは、独立した一つのネットワーク（大雑把にいうと、明確な管理主体が存在し管理されているネットワーク）内で使用されるもので、例えば「RIP」「OSPF」と呼ばれるものが代表的です。
それに対し「外部経路制御プロトコル」とは、独立したネットワーク間で経路情報をやり取りするのに使用され、例えば「BGP」と呼ばれるものが代表的です。
以下でここに登場した各プロトコルについて簡単に解説をします。詳しいことは書籍等の情報ソースを参照して下さい。
[内部経路制御プロトコル]

�@RIP（Routing Information Protocol）
UNIX系のネットワークでは最も多く使用されている内部制御プロトコルで中小規模のネットワークに向いています。
RIPでは「ホップ数」と呼ばれる「そこに到達するまでに通過するゲートウェイの数」を基にルーティングテーブルを作成します。このように宛先までの距離（ホップ数）情報だけを基にルーティングテーブルを作成する経路制御プロトコルのことを「距離ベクトルプロトコル」と呼びます。
RIPは具体的には以下のような動作をします。

(i)	起動時、もしくは設定された時間が経過すると経路情報の更新を要求するメッセージをブロードキャストで送出する。
(ii)	RIPに対応したゲートウェイが要求メッセージを受取ると、自身のルーティングテーブルをホップ数と共に返答する。
(iii)	要求を出した端末は、得られた返答メッセージに新たなエントリを見つけるとそれを自身のルーティングテーブルに登録する。その際、該当エントリの「ホップ数」には、返答メッセージ中のホップ数とその返答メッセージを送ってきたゲートウェイまでのホップ数を合計した値を登録する。
(iv)	既に別のゲートウェイから返答された情報を元に同じ宛先のエントリが作成されていた場合は、返答メッセージ中のホップ数と返答メッセージを送ってきたゲートウェイまでのホップ数を合計して、それが現在登録されているホップ数より少なければ新たにそちらの情報を元に(iii)の手順でルーティングテーブル（及びホップ数）を再構築する。
(v)	なお、ホップ数の計算の際その値が15を超えると、その経路は「無限遠の宛先」と認識され無視される。

このようにRIPはシンプルな動作でその分設定も楽なのですが、以下にあげるようないくつかの欠点を持っています。（これらの欠点のためRIPは大規模ネットワークではあまり使われていないのです。）

欠点１

ネットワークが３つ以上のサブネットワークから成る場合に経路の収束が遅い。どこかのサブネットワークがダウンしてもその情報がルーティングテーブルに反映される（該当エントリの削除）までに数分かかってしまう。そのエントリのホップ数が15を超えるまで待たないとエントリが削除されないためである。 これは、RIPではあるネットワークがダウンしたことを知ることができるのはそのネットワークに直接接続されたゲートウェイのみであり、そのためサブネットワークのダウン後もネットワーク内のどこかのゲートウェイのルーティングテーブルにダウンしたサブネットワークへのエントリが残ってしまうことが原因である。詳しいことはここでは割愛するが、この問題は２つ以下のサブネットから成るネットワークでは起こらないという点に注意すれば理解しやすいものと思われる。（分からなければ参考書を見るなり、僕まで質問メールを送るなりして下さい。^-^;）

欠点２

アドレスクラスしか認識しない。つまりRIPはネットマスクによるアドレスクラスのサブネット化を認識しない。

�AOSPF（Open Shortest Path First）
OSPFは上記RIPの欠点を補うことができるプロトコルで大規模ネットワークに向いています。
RIPが隣接するゲートウェイ同士でしか情報をやり取りしないのに対し、OSPFは全てのゲートウェイ同士で直接情報をやり取りします。全てのゲートウェイ同士でメッセージをやり取りすることにより、OSPFではどのゲートウェイの先にどのゲートウェイが接続されているのかを認識できます。つまり、最終的に各ゲートウェイでは自身を起点にしたネットワークの有向グラフを作成することができるわけです。OSPFではそうしてできた有向グラフを基に各経路のコスト計算（「コスト」とはRIPでのホップ数に相当する管理者が独自に設定する値）を行いルーティングテーブルを作成します。このようにネットワーク全体のトポロジーを基にルーティングテーブルを作成する経路制御プロトコルのことを「リンクステートプロトコル」と呼びます。
OSPFでは各ゲートウェイ同士が比較的短い間隔で直接メッセージをやり取りするので、どこかのサブネットワークがダウンするとそれがすぐにネットワーク中に伝わります。そのため上記で指摘したRIPの「欠点1」のような事態が起きません。また、OSPFはサブネット化されたネットワークでも問題なく動作するため上記で指摘したRIPの「欠点2」も起きません。
このようにOSPFはRIPよりも優れたプロトコルだと言えますが、「有向グラフを作成したり処理が重たい」「ネットワーク中に全てのゲートウェイ同士のメッセージが行き交うのでトラフィックが多くなる」などの欠点もあります。
[外部経路制御プロトコル]

�BBGP（Border Gateway Protocol）
BGPは現在のインターネットでの外部経路制御プロトコルで中心的役割を成しているプロトコルです。
BGPは最初に接続が確立されたときにルーティング情報をネットワーク同士でやり取りし、以降は自身のルーティングテーブルの内容に変化があったときにのみその変更内容を送信するよう動作します。ルーティング情報に変更がない場合も自身が稼動中であることを知らせる小さなサイズのメッセージを送信することで、お互いにネットワークのダウンを検知できるようになっています。このように、BGPはトラフィックを最小限に抑えるよう工夫されたプロトコルであると言えます。
BGPはOSPFと同様、ネットワーク同士のトポロジーを認識します。そういう意味ではBGPはリンクステートモデルだと言えます。（とはいえOSPFとBGPは全く別物です。対象となるネットワークが内部のものか外部のものかという根本的な違いがあるからです。また、以下に挙げる点でも大きく異なります。）
BGPに関して注意が必要なのは、「実はBGP自身には外部ネットワークとの間で行う経路制御の方法が全く規定されていない」という点です。これは、「経路制御の方法、つまりはネットワーク同士でやり取りするルーティング情報の項目をあらかじめ外部ネットワークとすり合わせておく必要がある」ということを意味します。上で見たようにOSPFやRIPでは、ルーティング情報をやり取りする際の項目が決まっていましたので、この点はBGPの大きな特徴だと言えます。
そのため、BGPの設定は先に紹介したプロトコルに比べ複雑なものとなります。設定例や更に詳しい解説は割愛しますが、それらの情報が必要な方は書籍等の別の情報ソースを参照するようにして下さい。

最後まで読んでくださった方、ご精読ありがとうございました。
今回は長女（宇咲子）の出産があったため９月中旬を予定していた発行が１ヶ月以上も遅れてしまいました。楽しみにしていてくれた奇特な方には申し訳ありませんでした。
とはいえ、まだまだしばらく（数年？）忙しい日々が続きそうなので発行がどんどん遅れていきそうです（涙）が、これからもよろしくお願いいたします。

ああ、新生児の世話がこれほど大変だとは....