IPパケットフォーマット

■ IPv4パケットフォーマット。

  IPのパケットフォーマットは、下記の通りである。
  個々のフィールドについては、以下順番に記述する。

  

■ バージョン番号フィールド。

  IPヘッダの最初の4ビット。
  IPパケットを構成したIPプロトコルのバージョンを表す。
  ここではIPv4なので、4(0x0100)が格納される。

■ ヘッダ長フィールド。Header Length。

  IPヘッダの中の4ビットのフィールド。
  IPヘッダ自身の長さを、32ビットを1単位として表す。
  IPヘッダの長さは、オプションがなければ20バイトだから、
  ふつうは5(0x0101)が格納される。

■ サービスタイプフィールド。

  IPヘッダの中の8ビットのフィールド。
  IPパケットの要求するサービスの特徴を表す。
  ルータはこのフィールドを参照し、
  要求された品質を実現するようにパケットを転送する。

  サービスタイプフィールドの中には、RFC1349により
  3ビットの優先度フィールドと、
  5ビットのTOSフィールドが定義されている。
  ただし、現時点でこの機能は殆ど実装されていない。

  (1) 優先度フィールド。Presedendce。

    サービスタイプフィールドの中の最初の3ビット。
    送信側がIPパケットの重要性を表示するために用いる。
    ふつうはすべて0。値が大きくなるほど重要性が高い。

  (2) TOSフィールド。Type of Servise。

    サービスタイプフィールドの中の後半の5ビット。
    ふつうはすべて0だが、ビットパターンを変えることにより、
    セキュリティを最大にする、スループットを優先する、
    金銭コストを抑えるなどの指定ができる。

  このサービスタイプフィールドは、
  その後RFC2474により再定義された。
  すなわち前半の6ビットがDiffservフィールドとして
  使われることになった。

  (3) Diffservフィールド。Differentiated Services。

    サービスタイプフィールドの最初の6ビット。
    ここにDSCP(Diffservコードポイント)という識別子を格納し、
    トラフィックフロー種別を表示、
    これを利用して優先制御を行なうというもの。

■ 識別子フィールド。Identification。

  IPヘッダの中の16ビットのフィールド。
  各々のIPパケットを識別するために送信側ホストが割り当てた
  ID番号を格納する。

  IPパケットの転送において、転送するパケット長が
  経由する個々のリンクで許容されるMTUを超える場合、
  ホストやルータはMTUの範囲内に収まるように
  IPパケットを複数のパケットに分割する。
  これをフラグメント化と呼ぶ。

  フラグメント化によって分割されたIPパケットは、
  途中のルータや受信側ホストで再構成する必要があるが、
  正しく再構成できるためには、
  個々のフラグメントが元々どのIPパケットの断片なのかが
  識別できなくてはいけない。

  これを実現するために、
  もともとのIPパケットにID番号を記しておくのが、
  識別子フィールドである。

■ フラグフィールド。Flag。

  IPヘッダの中の3ビットのフィールド。
  最初のビットは未使用。2番目のビットで、
  フラグメント化を許可するか否かを指定する。

  また3番目のビットは、
  フラグメント化されている場合に、
  そのフラグメントが元々のIPパケットの途中か末尾かを表す。

■ フラグメントオフセットフィールド。Flagment Offset。

  IPヘッダの中の13ビットのフィールド。
  IPパケットがフラグメント化されている場合に、
  そのフラグメントが何番目のフラグメントなのか、
  という位置を表す。

■ TTLフィールド。Time To Live。

  IPヘッダの中の8ビットのフィールド。
  IPパケットがインターネット上で生存できる最大期間を表す。
  あて先の見つからないIPパケットがネットワーク上を永久に
  循環し続けることを防ぐために設けられている。

  元々は秒数で設定されていたが、
  正確な時間を計測することは困難なため、
  現在ではホップカウントが用いられている。
  デフォルトでは64(秒)を推奨している。

  ルータはIPパケットを受け取り、
  これを転送するごとにTTL値を1づつ減算する。
  そしてTTL=1のパケットを受信したルータは、
  このIPパケットを次のノードに転送することなく、廃棄する。

  同時にルータは、
  タイプ11のICMPメッセージをIPパケットの送信元に返信し、
  IPパケットを廃棄したことを通知する。
  tracertは、これを応用した問診ツールである。

■ プロトコル番号フィールド。

  IPヘッダの中の8ビットのフィールド。
  IPパケットがカプセル化している上位層プロトコルの種類を表す。
  タイプフィールドとも呼ぶ。

  ホストのIPソフトウェアは、
  このプロトコル番号フィールドを参照することにより、
  受け取ったIPパケットのデータ部分を
  どの上位プロトコルに渡せばよいかを判断する。

  実際のプロトコル番号は、IANAが管理しており、
  ふつうは16進数値で表記する。
  例えば、TCPのプロトコル番号は6、UDPは17である。

  +-----------------+------+------+------+------+------+------+
  | 上位プロトコル  | ICMP | IGMP | TCP  | UDP  | IPv6 | OSPF | 
  +-----------------+------+------+------+------+------+------+
  | プロトコル番号  |   1  |   2  |   6  |  17  |  41  |  89  | 
  +-----------------+------+------+------+------+------+------+

■ ヘッダチェックサムフィールド。Header Check-Sum。

  IPヘッダの中の16ビットのフィールド。
  ヘッダだけをCRCでチェックする。
  ペイロード部分はTCPまたはUDPがチェックするので、
  チェックしない。

  ルータはIPパケットを受け取るとTTLを減算するが、
  そうするとチェックサムの値も変わってしまう。
  このためヘッダチェックサムは、ルータごとに照合され、
  また書き換えられる。

■ オプションフィールド。

  IPパケットの配送するときに
  特殊な処理を行なうように指示するフィールド。
  普段はあまり使用されない。

  このフィールドを使用すると、例えば、
  IPパケットの経路をあらかじめ指定したり、
  実際に配送された経路をヘッダの中に記録させたりできる。

■ パディング。

  オプションを使用した場合に、
  ヘッダの長さが32ビットの整数倍にならないことがあるので、
  それを調整して32ビットの整数倍にするためのフィールド。
  ふつうは付加されない。

以上。

[ つづきはこちら ]

2004/03/19 pm