ＬＡＮ技術研究室（ＬＡＮに関心がある人のために情報を提供しているサイト）

ＯＳＩ参照モデルでデータリンク層のすぐ上に位置するのがネットワーク層です。
ＯＳＩ参照モデルについては、プロトコルの基礎をクリックして参照できます。
ネットワーク層のプロトコルとして代表的なものにＩＰ（Internet Protocol）があります。
ＩＰは、インターネットでもＬＡＮでもＩＰパケットが流れているのをよく見かけます。
ネットワーク階層モデルで見て、ＭＡＣフレームの上位に相当するＩＰパケットは以下の図のようになります。

一般的なＩＰヘッダー（オプションなしのケース）

バージョン【４ビット】
ヘッダー長【４ビット】
サービスタイプ【８ビット】
パケット長【１６ビット】
識別子【１６ビット】
フラグ【３ビット】
フラグメント・オフセット【１３ビット】
ＴＴＬ【８ビット】
プロトコル番号【８ビット】
ヘッダー・チェックサム【１６ビット】
送信元ＩＰアドレス【３２ビット】
宛先ＩＰアドレス【３２ビット】
（この後にオプションが続いて少し長くなることがありますが必須ではありません）

• (1) バージョン


このフィールドには、ＩＰのバージョン番号が設定されます。
ＩＰｖ４なら４、ＩＰｖ６なら６が設定されます。


• (2) ヘッダー長


このフィールドには、ＩＰヘッダーのサイズを設定します。
ただし、４ビットしかないフィールドなので、このままなら０〜１５までしか設定できません。
ＩＰヘッダーは、後続のオプションがなくても最低２０オクテットのサイズがあるので、フィールド長が足りません。
そこで、３２ビット（４オクテット）単位で値が設定されています。
従って、最低でも５という値が設定されています。
後続のオプションがある場合でも、６０オクテットまで設定できます。この場合は最大の１５が設定されます。
つまり、実際のＩＰヘッダー長（単位：オクテット）÷４の計算結果がこのフィールドに設定されます。
例えば、最低の２０オクテットのサイズなら、２０÷４＝５となるので、このフィールドには５という値が設定されます。
ヘッダー長のフィールドに関する説明はこれだけですが、情報を表す単位について、ついでに説明しておきます。
情報を表す最低の単位は皆さん御存知だと思いますが、ビットです。
このビットが８ビット集まればバイトです。
これもＬＡＮを学ぼうとしている人ならほとんどの人は御存知でしょう。
このバイトと同じで、８ビット集まった情報で前に出てきたオクテットという単位もあります。
８ビットは、２進数で８桁、１６進数で２桁と覚えておいて下さい。
オクテットは、どちらかというとネットワークで使われることが多いです。
他ではあまり見かけないので、オクテットという単位を初めて知った人もいるかもしれませんが、当サイト（ＬＡＮ技術研究室）ではネットワークに関するサイトなので、バイトを使わずオクテットで統一したいと思います。
また、前述の(1) バージョンや、この(2) ヘッダー長のように、４ビット単位もあります。
これが nibble（ニブル）です。
４ビットで１ニブルと言います。
４ビットは、２進数で４桁、１６進数で１桁と覚えておいて下さい。


• (3) サービスタイプ


このフィールドは、ＴｏＳ（Type of Service）のことでＩＰパケットが示すサービスの質を示します。
ＴｏＳの詳細を以下の表に示しておきます。



サービスタイプの先頭からの相対ビット	各ビットごとの意味	設定する数値とその意味
０〜２	優先度【３ビット】	高い優先度 111 ↑ 110 ｜ 101 ｜ 100 ｜ 011 ｜ 010 ↓ 001 低い優先度 000
３	遅延【１ビット】	０ 通常の遅延 １ 低い遅延
４	スループット（単位時間当たりに処理する量）【１ビット】	０ 通常のスループット １ 高いスループット
５	信頼度【１ビット】	０ 通常の信頼度 １ 高い信頼度
６〜７	予約ビット【２ビット】	２ビットすべて０



• (4) パケット長


このフィールドには、ＩＰパケット全体のサイズが設定されます。
このフィールドの長さが１６ビットもあるので、前述のヘッダー長とは異なり、オクテット単位の数値になります。
最大で65535オクテットまでの数値が設定できます。


• (5) 識別子


このフィールドは、送信したい全体のデータを複数のＩＰパケットに分割して送信する必要がある時に使用されます。
分割された一つ一つのＩＰパケットを識別するために一意の値が送信元によって設定されます。


• (6) フラグ


この３ビットのフラグ・フィールドに関しては、ＲＦＣ７９１に記載されています。
ＲＦＣ７９１も含めてＲＦＣの詳細は、以下のサイトで御覧下さい。

IETF RFC Page
JPNIC RFC-JP（社団法人：日本ネットワークインフォメーションセンター）
ＲＦＣ７９１（英文）【IETF RFC Page】

この３ビットのフラグ・フィールドが示す意味は以下の表の通りです。



相対ビット	各ビットごとの意味	設定する数値が０の場合	設定する数値が１の場合
０	予約ビット	０に設定しておく
１	ＤＦ（Don't Fragmentの略：断片化禁止フラグ）	ＩＰパケットの分割が可能	ＩＰパケットの分割不可
２	ＭＦ（More Fragmentの略：断片化継続フラグ）	最後の断片	後続断片あり



• (7) フラグメント・オフセット


Ｆｒａｇｍｅｎｔ（フラグメント）は断片を意味しています。
断片化されたＩＰパケットが、全体のデータの内、先頭からの相対的な位置を示す数値が６４ビット（８オクテット）単位で設定されます。
従って、このフラグメント・オフセットのフィールドに設定されている値を８倍した値が、全体のデータの先頭からの位置になります。
結果的にこの数値は、このフィールドを含むＩＰパケットが、最後の断片までの間のどの位置にあるデータなのかを示しています。


• (8) ＴＴＬ

ＴＴＬは、Time To Liveの略で、ＩＰパケットの有効時間というか、生存時間というか、ＩＰパケットの寿命のことを示します。
ＴＴＬは、ルーターを通過するたびに１ずつ減らすように決められています。
また、ＴＴＬのデフォルト値が６４と決まっています。
ＴＴＬに関しては、ＲＦＣ１７００に記載されています。
ＲＦＣ１７００も含めてＲＦＣの詳細は、以下のサイトで御覧下さい。

ＲＦＣ１７００（英文）【IETF RFC Page】
IETF RFC Page
JPNIC RFC-JP（社団法人：日本ネットワークインフォメーションセンター）

ＴＴＬの数値は、中継するルーターの数または秒数で指定され、ＩＰパケットがインターネットの中で生存できる最大の数または最大時間を示していて、この値が０になるとそのＩＰパケットは破棄されます。
秒数として指定する場合の最大値は２５５秒ですが、ＴＴＬの値を最大秒数で実装する例はほとんどないようです。


• (9) プロトコル番号


このフィールドには、ＩＰより上位層のプロトコルに対応した番号が設定されます。
以下の表に代表的なプロトコルに対応した番号と示しておきます。



プロトコル番号（１０進数表示）	プロトコル	説明
１	ＩＣＭＰ	主に通信状態をチェックするのに役立つプロトコル
２	ＩＧＭＰ	ホストのマルチキャスト・グループ情報のルーターへの通知
６	ＴＣＰ	複雑な伝送制御手順があり、信頼性が高い通信を行える最も良く利用されるプロトコル
17	ＵＤＰ	ポート番号を使用してお互いを認識できる程度しかできないデータグラム通信だけのプロトコル
41	ＩＰｖ６	ＩＰｖ４の３２ビットアドレス空間を１２８ビットにまで拡張した次世代ＩＰ
47	ＧＲＥ	ＶＰＮのＰＰＴＰというプロトコルと関係するプロトコル
89	ＯＳＰＦ	大規模ネットワーク向け動的ルーティングプロトコル



• (10) ヘッダー・チェックサム


このフィールドには、ＩＰヘッダーのみをチェックするチェックサムが設定されます。
前述のように、断片化されたＩＰパケットが届くことがあるので、ＩＰパケットのヘッダー・チェックサムの場合、ＩＰヘッダーに続くデータまでチェックすることはできません。
従って、ＩＰパケットに含まれるヘッダー・チェックサムでは、ＩＰヘッダーしかチェックしません。
チェックサムとは、簡易的な誤り検出方法の一つで、データを一定の長さで分割し、分割した塊ごとのデータを数値とみなして、その合計を計算した値を言います。
ＩＰパケットのヘッダー・チェックサムでは、以下のようなアルゴリズム（算法）になり、このアルゴリズムに基づいてプログラムが計算を行います。

まず、データを１６ビットごとの塊に分割します。
この場合のデータは、ＩＰヘッダーになります。
そして、それぞれの塊を数値とみなし、すべての数値を加算します。
この計算で桁溢れした場合は、桁溢れした分の数値を分離して加算結果に加算すると、また１６ビットの数値になります。
この部分の計算を１の補数和と言います。
その後で、すべてのビットを反転し、ヘッダー・チェックサムのフィールドに設定します。
ここまでは、送信側のプログラムが行います。
今度は受信側のプログラムは、以下のように受信したＩＰヘッダーを検証します。

受信側では、送信側と同じようにＩＰヘッダーを１６ビットごとの塊に分割します。
そして、それぞれの塊を数値とみなし、すべての数値を加算します。
その中には、送信側のプログラムで設定したヘッダー・チェックサムも含まれています。
この加算で桁溢れした場合は、桁溢れした分の数値を分離して加算結果に加算すると、１６ビット分の１６進数でＦＦＦＦになれば通信中のエラーがなかったことを示します。
受信側ではこのように検証します。

ところで、前述の「１の補数とは何ぞや？」と思った方は、以下の項目をクリックすると参照できます。

１の補数と２の補数の計算方法について

また、１の補数和と、実際のＩＰパケットに含まれるヘッダー・チェックサムの計算方法に関して、以下の項目をクリックすると参照できます。

チェックサムの具体的な計算方法の紹介

ヘッダー・チェックサムに関しては、ＲＦＣ１０７１に記載されています。
ＲＦＣ１０７１も含めてＲＦＣの詳細は、以下のサイトで御覧下さい。

IETF RFC Page
JPNIC RFC-JP（社団法人：日本ネットワークインフォメーションセンター）
ＲＦＣ１０７１（英文）【IETF RFC Page】

また、内容を保証できませんが、ＲＦＣ１０７１の日本語訳が以下のサイトにあります。

RFC1071 インターネットチェックサムの計算


• (11) 送信元ＩＰアドレス


送信元を示すＩＰアドレスがこのフィールドに設定されます。
ＩＰアドレスは、一般に以下のような表記をし、特定の宛先を表します。

192.168.0.1

ＩＰアドレスに関する詳細は、ＩＰアドレスについてという項目で解説します。

通常このＩＰヘッダーの後にデータが続きます。ただし、上位のプロトコルのヘッダーやデータになることもあります。
プロトコルの階層とパケットの関係は、ちょうどお皿を下から積み上げていくようなイメージになります。
日本ではあまりなじみがありませんが、西洋ではスタックという皿を積み上げておく器具があります。
ちょうどこんな感じなので、プロトコルの階層の集まりをプロトコルスタックと呼びます。
一つ一つのお皿に前述のＩＰヘッダーのようなヘッダーが書かれていて、どんどん積み重ねていきます。
一番下は、ＭＡＣヘッダーが書かれたお皿、その上にＩＰヘッダーが書かれたお皿、その上にＴＣＰヘッダーが書かれたお皿、...というように積み上げてく感じになります。
全部積み上がったら、パケットとしてネットワークに投げてしまいます。
このような説明なら、大変よくわかったと思います。
ＯＳＩ参照モデルでもＴＣＰ／ＩＰ階層モデルでも、ＩＰはレイヤ３のネットワーク層を示します。
聞いたことがあるかもしれませんが、レイヤ３スイッチやルーターはこのネットワーク層で中継する装置を意味します。
なんとなくおわかりになれたとは思いますが、実際にＩＰパケットのデータに含まれるＩＰよりさらに上位プロトコルのヘッダーやデータも含めて詳しくパソコンで見たいという場合は、プロトコルアナライザーと呼ばれるソフトウェアを使って見ることができます。
ＬＡＮを流れるパケットやプロトコルの分析に関しては、後述するネットワークを流れるデータの解析についての基礎知識で解説します。


• (12) 宛先ＩＰアドレス


宛先を示すＩＰアドレスがこのフィールドに設定されます。

• (1) ルーティング機能


ＩＰパケットに含まれる宛先のＩＰアドレスを見て、送るべき経路を選択し、正しい宛先に届いたＩＰパケットを転送します。
中継装置としてのルーターがこの機能を実現するために経路選択を担当します。


• (2) フラグメント機能


ＩＰパケットのサイズがＭＴＵのサイズより大きいと、中継装置や送信元でＩＰパケットのサイズがＭＴＵのサイズ以下になるように分割して、全体のデータのフラグメント（断片）として宛先に送信します。
これがフラグメント機能です。
上記の文中に登場したＭＴＵという用語についてＬＡＮ初心者の方のために説明します。
ＭＴＵとは、Maximum Transmission Unitの略で、１回で送信可能なフレームの最大値のことを言います。
ＯＳＩ参照モデルにおけるデータリンク層では、ネットワーク・インターフェイスごとにフレームの最大長が決まっています。
ネットワーク・インターフェイスとは、パソコンではＬＡＮカードと１対１で対応します。
例えば、今パソコンに１枚しかＬＡＮカードがインストールされていないとします。
この場合、ネットワーク・インターフェイスは１つになります。
このインターフェイスを２つにしたいのなら、ＬＡＮカードをもう一枚増設します。
ところで、現在のＬＡＮではイーサーネット（Ethernet）が主流です。
イーサーネットのフレーム（ＭＡＣフレーム）の最大長は１５００バイトです。
ＥｔｈｅｒｎｅｔII（ＤＩＸ仕様のイーサーネット）の場合、この１５００バイトがＭＴＵとなります。
ＭＴＵはインターフェイスと１対１で対応しています。
インターフェイスごとにそれぞれフレームの最大長があるということです。
ちなみに、イーサーネット以外のに関しては以下の表のようになっています。



代表的なフレーム	ＭＴＵのサイズ（単位：オクテット）
IP over ATM	9180
ＦＤＤＩ	4352
ＰＰＰｏＡまたはケーブルテレビ（ＣＡＴＶ）インターネット ※1	1500
ｘＤＳＬ，ＰＰＰｏＥなど ※2	1492
フレッツＡＤＳＬ ※3	1454
ダイヤルアップ接続 ※4	576



• ※1　ケーブルモデムなどを使用するＣＡＴＶインターネットではＭＴＵを１５００にしますが、若干小さく調整する必要がある場合もあります。



• ※2　ｘＤＳＬやＰＰＰｏＥ以外


ＩＥＥＥ８０２.３仕様のイーサーネットもＭＴＵは１４９２です。
フレッツＡＤＳＬ以外のＡＤＳＬの場合、ＭＴＵは１４９２に設定します。


• ※3　ＰＭＴＵＤブラックホール


ＰＭＴＵＤとは、Path Maximum Transmission Unit Discoveryの略で、パス最大転送ユニット・ディスカバリーのことを言います。
ＰＭＴＵＤは、ＭＴＵの値が異なるネットワーク間でも問題なくＩＰパケットの転送が行えるようにした仕組みで、ＩＰパケットを断片化せずに転送します。
ＰＭＴＵＤに関しては、ＲＦＣ１１９１に記載されています。
ＲＦＣ１１９１も含めてＲＦＣの詳細は、以下のサイトで御覧下さい。

IETF RFC Page
JPNIC RFC-JP（社団法人：日本ネットワークインフォメーションセンター）
ＲＦＣ１１９１（英文）【IETF RFC Page】


ところで、ＮＴＴのフレッツＡＤＳＬでは、ＭＴＵの値を１５００に設定すると、一部のＷｅｂサイトのホームページを表示できなくなることがあります。
フレッツＡＤＳＬでは、上の表で示したとおりＭＴＵの値を１４５４に設定しています。
１５００と１４５４を比べてみると、１４５４の方は中途半端で少し小さい数です。
インターネット上には、いたるところにルーターという中継装置があります。
もし、１５００バイトのＩＰパケットを受信すると、これを受け取ったルーターは、ＮＴＴのＩＰネットワーク（ＮＴＴの地域ＩＰ網）に転送する直前で、１５００では大きすぎるので、このＩＰパケットを分割して転送する必要があります。
この分割対象が、あるユーザーがどこかのＷｅｂサーバーのホームページを表示しようとした時に転送されてきたＩＰパケットだったとします。
このＷｅｂサーバーがＩＰパケットを分割できない設定だった場合、「ＩＰパケットを分割できない」という意味のエラーパケットを返そうとします。
ところが、途中に存在するサーバーが、前述のエラーパケットも含めたＩＣＭＰというプロトコルに従って送受信されるパケットを破棄する設定になっていた場合、前述のＷｅｂサーバーからのＩＰパケットだけではなく、前述のエラーパケットも受け取れないことになってしまいます。
ユーザーサイドから見ると、ホームページの情報となるＩＰパケットを受け取れず、エラーの原因を示すエラーパケットも受け取れない状況に陥ります。
この問題の犯人は、前述のルーターというわけではないのですが、あたかもこのルーターが次から次へと来るＩＰパケットをどんどん飲み込んでは捨ててしまっているように思えます。
これは、まるでルーターがＩＰパケットをどんどん吸い込んでは消滅させているイメージを抱くので、宇宙にあるブラックホールと似ていることからＰＭＴＵＤブラックホール（Path Maximum Transmission Unit Discovery Black Hole）と呼ばれています。
ＰＭＴＵＤブラックホールに関しては、ＲＦＣ２９２３に記載されています。
ＲＦＣ２９２３も含めてＲＦＣの詳細は、以下のサイトで御覧下さい。

IETF RFC Page
JPNIC RFC-JP（社団法人：日本ネットワークインフォメーションセンター）
ＲＦＣ２９２３（英文）【IETF RFC Page】

この解決方法として、ホームページを見る方のパソコンでＭＴＵの値を１４５４に設定します。
設定するためのソフトがあります。
Windows®用のソフトを紹介します。


• (1) EditMTU（ＭＴＵ，ＲＷＩＮ簡単設定ツール）


• (2) NetTune

Windows®のレジストリを書き換えることでネットワークの速度を上げられるプログラムです。


ダウンロードしてファイルを解凍したら、すぐＭＴＵの値を変更する前に、Windows®ならＤＯＳプロンプトでｐｉｎｇというコマンドを実行して下さい。
スタートボタンをクリックし、「ファイル名を指定して実行」をクリックし、cmdと入力してOKをクリックすればＤＯＳプロンプトが簡単に出ます。
cmdを入力しなくてもマウスだけでＤＯＳプロンプトを起動することができますが、メニューの階層が深いので面倒くさいです。
ＤＯＳプロンプトのウィンドーが開いたら、以下のように入力し、Enterキーを押して下さい。
ＭａｃＯＳ Ｘでもターミナルというプログラムを実行すれば、以下とまったく同じコマンドを実行できます。

ping -f -l 1500 xxx.xxx.xxx

xxx.xxx.xxx のところには、インターネットの向こうに存在する見たいホームページがあるＷｅｂサーバーのドメイン名かＩＰアドレスを指定します。
-l は、ＩＣＭＰパケットの長さを指定するｐｉｎｇコマンドのオプションです。
ｐｉｎｇコマンドは、前述のＩＣＭＰを使用してデータを送信しています。
-f は、ＩＰパケットの断片化を禁止するオプションです。
つまり、「ＩＰパケットを分割して送ることはできないよ」ということでこれに従ってｐｉｎｇコマンドはＩＣＭＰパケットを送信します。
このオプションが指定されている時は、前述のＩＰヘッダーの(6) フラグのフィールドで、ＤＦ（Don't Fragmentの略：断片化禁止フラグ）に１を設定してＩＰパケットを送信します。
上記の通りにｐｉｎｇコマンドを実行すると、以下のメッセージが何行か出ると思います。

Packet needs to be fragmented but DF set.

これが出たら、xxx.xxx.xxx のＷｅｂサーバーにＩＣＭＰパケットが届きません。
ＩＰパケットの分割を禁止していて、なおかつ前述のＷｅｂサーバーまでＩＣＭＰパケットが届かなければなりません。
そこで、前述のフリーソフトの出番です。
EditMTUでもNetTuneでもどちらでもかまいません。
これらのツールでＭＴＵの値を１４５４に設定します。
今度は以下のようにｐｉｎｇコマンドを実行してみます。

ping -f -l 1454 xxx.xxx.xxx

稼動中のＷｅｂサーバーなら、今度は以下のようなメッセージが何行か出たと思います。

Reply from xxx.xxx.xxx: bytes=1454〜

xxx.xxx.xxx にはＷｅｂサーバーのＩＰアドレスが表示されていると思います。
これで問題なくブラウザで目的のＷｅｂサーバーのホームページが見れると思います。

ちなみに、NetTuneでは、ＰＭＴＵＤの項目があり、この項目でEnableをクリックしておくと、目的のホストまでのＭＴＵを自動的に見つけようとしてくれます。
また、Macintoshをお使いの方は、ＭＴＵ関連の設定を変更できる以下のツールがあります。

ＭａｃＯＳ９ ：IPNetTuner
ＭａｃＯＳ Ｘ：RMAC

ここまでで、ＩＰというプロトコルの二つの機能についておわかり頂けましたでしょうか。

ところで、ＩＰというプロトコルは、ＩＰパケットを宛先に送り届ける小包配達人のような働きをします。
パケットとは小包のことです。
しかし、この配達人はあまり責任感がある者ではなく、よく確認せずにＩＰパケットを配達してしまいます。
本当に宛先に届いたかどうかのチェックは一切しません。
まるで遠くへ発射した鉄砲玉みたいで、当たったかどうかが不明です。
従って、データ保証はできません。
そのため、正確にデータを送りたい場合は、ネットワーク層より上位層（トランスポート層）にデータ保証を委ねることになります。
そこで、ＴＣＰ（Transmission Control Protocol）というプロトコルの出番になります。
ＴＣＰに関しては、トランスポート層のプロトコルをクリックして参照できます。

ページトップへ
ネットワーク層のプロトコル［メニュー］へ戻る
サイトマップ（ＬＡＮ技術研究室の案内図）
ネットワーク技術用語集へ行く
ＬＡＮ技術研究室のトップページへ

© 2007 Toyozi Masuda All rights reserved.