第2回 IPv6パケットの構造を知る：Windows管理者のためのIPv6入門（1/2 ページ）

IPv6ではパケットの構造を単純化し、プロトコル処理の高速化やルータの負荷低減なども図っている。IPv6パケットを覗いてみよう。

[打越浩幸，デジタルアドバンテージ]

連載目次

　前回は、IPv6アドレスの基礎と、pingでのIPv6の使用例などについてみてきた。今回はIPv6パケットの構造と実際のパケットの例について解説する。

---

　IPv6は、IPv4よりもアドレス幅が広くなっており、機能も向上しているが、そのパケット構造はよりシンプルになっているのが大きな特徴だ。IPv4のパケットにはさまざまなオプションや将来を見越した機能拡張のための領域などが用意されていたが、長年に渡る運用の結果、ほとんど使われることのない機能や、性能向上のための制約となっている部分などが明らかになってきた。そこでIPv6ではヘッダの内容を整理し、不要なフィールドを廃止すると共に、特にルーティング処理の負荷軽減（パフォーマンスの向上）を目的として、ヘッダ内容を簡素化している。

　比較のために、まずIPv4のIPパケットの構造を見てみよう。

IPv4パケットの構造
IPv4のパケットは、基本的には最小20bytesで、必要に応じてオプションが4bytesずつ追加される。多数のフィールドがあるが、サービス・タイプなどは実際にはほとんど使われていない。

　ヘッダ内の各フィールドの意味は次の通りである。より詳細な機能解説については、連載「基礎から学ぶWindowsネットワーク」の第10回「1．IPパケットの構造」を参照していただきたい。

フィールド	幅	意味
バージョン	4bit	IPv4を表す「0100（2進数表示）」になる
ヘッダ長	4bit	IPv4ヘッダの長さ。先頭から、オプションの最後までの含むサイズ（を4で割った値をセットする）
サービス・タイプ（TOS）	8bit	パケットの優先度などを表すために用意されているが、実際にはほとんど使われていない
データグラム長	16bit	IPv4ヘッダも含む、IPパケット全体の長さ
ID	16bit	フラグメント化されたパケットの識別用番号。パケットをフラグメント化すると、すべて同じIDを持つ。これを元に、元のパケットを識別・復元する
フラグ	3bit	制御用フラグ。フラグメントの存在やフラグメント禁止などを表す
フラグメント・オフセット	13bit	フラグメント化されたパケットにおいて、元のオフセットを表す
TTL	8bit	パケットの寿命を表す数値。ルータを1つ通過するごとに1ずつ減算され、0になるとパケットが破棄される。ルーティングがループになるのを防ぐ
プロトコル番号	8bit	上位プロトコルの番号
ヘッダ・チェックサム	16bit	IPv4ヘッダのチェックサム。TTLが変わると再計算する必要があるので、ルータの負荷は軽くない
送信元IPアドレス	32bit	送信元ノードのIPv4アドレス
あて先IPアドレス	32bit	送信先ノードのIPv4アドレス
IPv4ヘッダの内容

　実際のIPv4パケットでは、このヘッダの直後から複数のオプション・フィールドが続き、最後にデータが付加される。

　これに対してIPv6のIPヘッダの構造は次の通りである。IPv4よりもフィールドの数は減っている。また、ヘッダが「基本」と「拡張」の2種類に分かれている。

IPv6パケットの構造
IPv6ヘッダの基本ヘッダの構造（拡張ヘッダ部分については後述）。基本ヘッダは常にこの40bytesしかない。この直後からいくつかの拡張ヘッダ（オプション）と上位プロトコルのペイロードが続く。IPアドレス部分が長いのでヘッダのトータル・サイズはIPv4のヘッダよりも大きいが、フィールドの数は少ない。

　それぞれのフィールドの意味は次の通りだ。

フィールド	幅	意味
バージョン	4bit	IPv6を表す「0110（2進数表示）」になる
トラフィック・クラス	8bit	IPv4のサービス・タイプ（TOS）と同じで、パケット送信時のQoS（Quality of Service）を指定する。パケット送信時の優先度を表す
フロー・ラベル	20bit	マルチキャスト通信などにおいて、通信経路の品質を確保したり、経路を優先的に選択させたりするために使用する。IPv4ヘッダには該当するものはない（IPv4の場合は、より上位のプロトコルと組み合わせて通信路の経路を確保するのが一般的）
ペイロード長	16bit	拡張ヘッダとペイロード・データの合計サイズ。IPv4と異なり、IPv6の基本ヘッダ部分（40bytes）は含まない
ネクスト・ヘッダ	8bit	このIPv6ヘッダに続く、拡張ヘッダや上位プロトコルのタイプ。拡張ヘッダが複数ある場合は、最初の拡張ヘッダのタイプを表す。以後のヘッダは、数珠つなぎで並べる。IPv4のプロトコル・タイプに相当するが、拡張ヘッダもペイロード（上位プロトコルのヘッダとそのデータ）もこのネクスト・ヘッダを使って同様に並べる。詳細は後述
ホップ・リミット	8bit	IPv4のTTLと同じで、通過可能なルータの最大数を制限する。ルータを1つ通過するたびに1ずつ減算される。0になるとパケットは破棄され、送信元に対してICMPv6の「hop limit exceeded in transit」が返信される
送信元IPアドレス	128bit	送信元ノードのIPv6アドレス。128bit幅があるので、16bytes占有する
あて先IPアドレス	128bit	送信先ノードのIPv6アドレス
IPv6基本ヘッダの内容

　IPv4ヘッダと比較すると、以下の点が大きく異なる。

• ヘッダ・チェックサムとIDフィールドが含まれていない
• ヘッダ・サイズが40bytesの固定長になっている
• いくつかのヘッダが基本ヘッダから外され、拡張ヘッダ中へ移行している

　ヘッダ・チェックサムが省略されたのは、主にルータでの負荷を軽減するためである。ルータがパケットをルーティング（フォワード）する場合、ホップ・リミット（IPv4ではTTL）の値を1つ減算する処理を行うが、IPv4の場合はここでチェックサムを再計算する必要があった。さらにIPv4ではヘッダ・サイズが不定長ということもあり、高速処理を必要とするルータ（特に大量のトラフィックを処理する基幹ルータ）にとっては、これは大きな負担であった。この負担を減らして高速化するため、IPv6ではチェックサムを省略したり、固定長の小さなヘッダを採用したりしている。それにイーサネットや無線LAN、光ファイバなど、現在一般的に利用されている通信メディアでは十分に通信の信頼性が高い（エラー・パケットが上位プロトコル・スタックに渡されることはまずない）ので、IPレベルでのチェックサム（IPv4のチェックサムは、イーサネットなどのCRCよりもエラー検出能力は低い）は不要と判断されたからでもある。

　これ以外にも、ルータでのフラグメンテーションの廃止（パケットの分断化は送信元でのみ行う。中継途中のルータでは行わない）、ルータがチェックするべきヘッダの限定（ルータは基本ヘッダと、ごく一部の拡張ヘッダの内容しかチェックしない）などを行い、ルーティング・パフォーマンスの向上を目指している。

ネクスト・ヘッダによる拡張ヘッダ／プロトコルのチェイン

　IPv6では、使用頻度の低いくつかのフィールドは「拡張ヘッダ」部分に格納されることになっている。詳細はすぐ次で述べるが、ルーティングに不要なフィールド（IPv4のIDフィールドなど）を拡張ヘッダとして分離することにより、基本ヘッダ・サイズを抑え、ルーティング処理ではチェックしなくても済むようにしている。

　基本的には次のように、IPv6の基本ヘッダ（40bytes）に続いて、オプションの拡張ヘッダ（複数可）と上位プロトコルのペイロード（例えばUDPのヘッダとそのデータ）が続く。

IPv6の拡張ヘッダの構造

　基本ヘッダの中にネクスト・ヘッダという8bitのフィールドがあるが、これは基本ヘッダの次に続くデータの種類を表している。IPv4ではこれはプロトコル・フィールドと呼ばれ、例えばICMPv4なら1、TCPなら6、UDPなら17といったプロトコル番号がセットされていたが、IPv6では次のデータ・ブロックのタイプを表す。タイプの値そのものはプロトコル番号を拡張したものである。Windows OSならシステム・ドライブの「\Windows\System32\drivers\etc」フォルダにある「protocol」ファイルに記述されている。

IPv6のプロトコル番号
これはWindows 7の\Windows\System32\drivers\etcフォルダにあるprotocolファイルの内容。IPv6のネクスト・ヘッダ・フィールドには <assigned number> 列の数値がセットされる。
（1）Windows XPの同一ファイルと比較すると、この部分がIP6用に追加されている。

　何の拡張ヘッダもなく、例えばTCPをIPv6上で利用しているなら、基本ヘッダ中のネクスト・ヘッダの値は6（tcp）となり、基本ヘッダの直後にはTCPのペイロード（TCPのヘッダとそのデータ）が続く。だがパケットをフラグメント化してさらにICMPを利用していると、44（ipv6-frag）と58（ipv6-icmp）という値を持つ2つの拡張ヘッダとICMPのデータが続く。

　IPv6で利用される拡張ヘッダのタイプは以下の通りである。

タイプ	番号	意味
ホップ・バイ・ホップ・オプション・ヘッダ	0	通常、拡張ヘッダ部分は中継ルータでは関与しないが、このタイプが指定されている場合は、すべてのルータでこのヘッダの内容を処理すること。このヘッダには追加のオプションを格納する
ルーティング・ヘッダ	43	途中で経由する必要のあるノード（ルータ）を列挙する。パケットが通過するルータを限定する、IPv4のソース・ルーティングに相当
フラグメント・ヘッダ	44	フラグメント化（断片化）されたデータが含まれることを示す。IPv6ではフラグメント化は送信元でのみ行い、途中のルータでは行わない。IPv4のヘッダにあったIDフィールド（フラグメント化されたパケットを識別するための番号）は、この拡張ヘッダ中に存在する
ESPヘッダ	50	パケットの暗号化情報。IPv4ではIPやTCPなどとは別に定義されていた暗号化／認証などの機能が、IPv6ではIPレベルで統合されている
AHヘッダ	51	パケットの認証情報（同上）
ICMPv6ヘッダ	58	IPv6用のICMP
ノー・ネクスト・ヘッダ	59	次のヘッダが存在しない、つまりヘッダ・チェインの終了を表す
あて先オプション・ヘッダ・ヘッダ	60	通常、拡張ヘッダ部分は中継ルータでは関与しないが、このタイプが指定されている場合は、あて先のノードと、（ルーティング・ヘッダで指定されている）すべてのルータでこのヘッダの内容を処理すること
（プロトコル番号）	上記以外	指定されたプロトコルのヘッダとそのデータを表す。例えばTCPなら6、UDPなら17などとなる
IPv6のヘッダ・タイプ IPv6の基本ヘッダに入らない（入れる必要性の少ない）フラグやオプション、使用頻度の低いプロトコル・オプションなどは、この拡張ヘッダで対応する。

■更新履歴

【2012/02/03】IPv6のヘッダサイズの説明において、当初公開した記事では、「ヘッダ・サイズが20bytesの固定長になっている」としておりましたが、正しくは「ヘッダ・サイズが40bytesの固定長になっている」でした。また、次ページの画面の説明文中でも、一部40bytesとすべきところを20bytesと記述しておりました。お詫びして訂正させていただきます。

« 前の回へ