IPv6ヘッダー形式：構造、フィールド、および拡張ヘッダー

IPv6がヘッダーを変更した理由#

IPv4のヘッダーは数十年にわたって有機的に成長しました。オプションが追加され、フィールドが再利用され、最終的には14の異なるフィールド(一部はオプション)を持つ可変長ヘッダーと、ルーターがホップごとに慎重に解析しなければならない複雑な構造になりました。

IPv6は異なるアプローチを取りました：固定長、簡素化、そして高速転送のための最適化です。ベースヘッダーは常に正確に40バイトで、8つの明確に定義されたフィールドがあります。可変長オプションなし、ヘッダーチェックサムなし、メインヘッダーにフラグメンテーションフィールドなしです。

その結果、ルーターがより高速に処理でき、ハードウェアでの実装が容易で、下位互換性を損なうことなく拡張をサポートするヘッダーが生まれました。IPv6ヘッダーを理解することは、なぜこのように構築されているのか、そして設計者がどのようなトレードオフを行ったのかを理解することを意味します。

40バイトのベースヘッダー#

すべてのIPv6パケットは、次の形式で正確に40バイトから始まります：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

固定サイズです。ベースヘッダーにオプションはありません。すべてのルーターは、解析なしで各フィールドの正確な位置を知っています。

8つのフィールド#

ルーターが通常処理する順序で各フィールドを見ていきましょう。

1. Version(バージョン、4ビット)#

IPv6パケットでは常に6です。IPv4パケットでは常に4です。これは、デバイスがワイヤ上でIPv6とIPv4を区別する方法です。

実用的な意味合い： デュアルスタックシステムは、これらの4ビットを最初に見て、残りのパケットを解析する方法を決定します。

Version = 6 (2進数：0110)

シンプルで、不変で、プロトコル識別に不可欠です。

2. Traffic Class(トラフィッククラス、8ビット)#

初期のIPv6仕様では「優先度」と呼ばれていたこのフィールドは、サービス品質(QoS)処理のためにパケットをマークします。IPv4のType of Service(ToS)またはDifferentiated Services Code Point(DSCP)と同じ目的を果たします。

構造：

• ビット0-5： DSCP(Differentiated Services Code Point)
• ビット6-7： ECN(Explicit Congestion Notification)

一般的なDSCP値：

ECNは、パケットをドロップすることなく、ルーターが輻輳を通知できるようにします。最新のTCP実装で、より良い輻輳制御のために使用されます。

例：

Traffic Class = 46 (EF) = 0b10111000
  DSCP = 46 (Expedited Forwarding)
  ECN = 0 (Not ECN-capable)

QoSをサポートするルーターは、このフィールドを調べてパケットを優先順位付けします。VoIPはファイルダウンロードよりも高い優先度を取得します。リアルタイムビデオは電子メールよりも良い扱いを受けます。

3. Flow Label(フローラベル、20ビット)#

IPv6の最も興味深いが活用されていない機能の1つです。フローラベルは、同じフローに属し、同一のルーティング処理を受けるべきパケットを識別します。

目的：

• 上位レイヤーヘッダーを調べることなく、関連するパケットをルーターが識別できるようにする
• 既知のフローのファストパス転送をサポートする
• フローごとのQoSのハンドルを提供する

仕様(RFC 6437)：

• 値0： 特別な処理を必要とするフローの一部ではないパケット
• 値1-0xFFFFF： フロー識別子(送信元によってランダムに選択)
• フロー内のすべてのパケットで一貫している必要がある
• ルーターハッシングを可能にするために疑似ランダムである必要がある

フローを構成するもの：

• 送信元 + 宛先 + フローラベルが一意に識別する
• TCP接続のすべてのパケットが同じフローラベルを使用する可能性がある
• または各ビデオストリームが一意のラベルを取得する可能性がある

実用的な使用法：

多くの実装はフローラベルを0に設定します。なぜなら：

• フローラベルに基づいてハッシュ/転送するために必要なハードウェアは普遍的ではない
• アプリケーションのサポートが限られている
• オプションであり、ゼロでも正常に機能する

しかし、正しく使用すると、フローラベルは次を可能にします：

• ECMP(Equal Cost Multi-Path)ルート間の負荷分散
• フローごとのトラフィックエンジニアリング
• ハードウェアファストパス転送

フローラベルの設定例(Linux)：

# 自動フローラベルを有効にする
sysctl -w net.ipv6.auto_flowlabels=1
 
# フローラベルは5タプルハッシュに基づいて設定される

Linuxは、有効になっているときにTCP接続のフローラベルを自動的に生成し、送信元/宛先アドレスとポートのハッシュを使用します。

4. Payload Length(ペイロード長、16ビット)#

40バイトのベースヘッダーを除く、パケットペイロードのバイト単位の長さです。

範囲： 0〜65,535バイト

重要な詳細：

• 拡張ヘッダー(ある場合)と上位レイヤーデータを含む
• ベース40バイトのIPv6ヘッダーは含まない
• 最大値65,535は、最大パケットサイズが65,575バイト(65,535 + 40)であることを意味する

特殊なケース：ジャンボグラム

65,535バイトより大きいパケットの場合、ペイロード長は0に設定され、ジャンボグラムオプションを持つホップバイホップ拡張ヘッダーが実際の長さ(最大4,294,967,295バイト)を運びます。

ジャンボグラムはまれです。通常、10 Gbps以上のリンク上のジャンボフレームサポートを持つ特殊な高性能ネットワークで使用されます。

例：

Payload Length = 1440バイト
  40バイトのIPv6ヘッダー(カウントされない)
  1440バイトのペイロード(TCPヘッダー + データ)
  合計パケット = 1480バイト

5. Next Header(次ヘッダー、8ビット)#

IPv6ヘッダーの直後に続くヘッダーのタイプを識別します。これが拡張ヘッダーと上位レイヤープロトコルが指定される方法です。

一般的な値：

チェーニングの仕組み：

各拡張ヘッダーは独自の次ヘッダーフィールドを含み、チェーンを形成します：

IPv6 Header (Next Header = 0)
  -> Hop-by-Hop Options (Next Header = 43)
    -> Routing Header (Next Header = 6)
      -> TCP Header
        -> Data

受信ホストは、トランスポートプロトコル(TCP/UDP)またはデータに到達するまで、順番にヘッダーを処理します。

拡張ヘッダーなしの例：

Next Header = 6 (TCP)
  IPv6ヘッダーの直後にTCPヘッダー

拡張ヘッダーありの例：

Next Header = 44 (Fragment)
  IPv6ヘッダーの後にフラグメントヘッダー(Next Header = 6)
    フラグメントヘッダーの後にTCPヘッダー

6. Hop Limit(ホップ制限、8ビット)#

パケットが破棄される前に残っているルーターホップの数です。各ルーターはこれを1ずつ減らします。0に達すると、ルーターはパケットをドロップし、ICMPv6 Time Exceededメッセージを送信します。

範囲： 0-255

これはIPv6のIPv4のTTL(Time To Live)フィールドに相当しますが、名前がより正確です—時間ではなくホップをカウントします。

一般的な初期値：

異なる値がフィンガープリンティングにとって重要な理由：

受信パケットのホップ制限を見ることで、送信元のOSを推測できます：

受信ホップ制限：56
  56 + 8ホップ = 64(おそらくLinux/BSD)
 
受信ホップ制限：117
  117 + 11ホップ = 128(おそらくWindows)

TracerouteはHop Limitを使用：

Tracerouteは、ホップ制限値を増分させたパケットを送信することで機能します：

• ホップ制限1：最初のルーターがTime Exceededで応答
• ホップ制限2：2番目のルーターがTime Exceededで応答
• ホップ制限3：3番目のルーターがTime Exceededで応答
• ...宛先に到達するまで

セキュリティ上の考慮事項：

一部の攻撃は、IDS/IPSシステムに到達する前にパケットが期限切れになるように、低いホップ制限を使用します。ファイアウォールは、インバウンドトラフィックに対して最小ホップ制限値を強制することがあります。

例：

Hop Limit = 64
  ルーター1が受信、63に減らして転送
  ルーター2が受信、62に減らして転送
  ...
  ルーター64が受信、0に減らしてドロップし、ICMPv6 Type 3を送信

7. Source Address(送信元アドレス、128ビット)#

パケットの送信者のIPv6アドレスです。常に128ビット、例外なしです。

形式： 標準IPv6アドレス表記

2001:db8:1234:5678:9abc:def0:1234:5678

特別な考慮事項：

未指定アドレス(::) は特定のケースでのみ有効です：

• 重複アドレス検出(DAD)
• アドレス割り当て前のDHCP要求
• 特定のICMPv6メッセージ

リンクローカルアドレス(fe80::/10) は有効な送信元アドレスですが、ローカルリンク上でのみです。ルーターはリンクローカル送信元を持つパケットを転送しません。

マルチキャストアドレス は決して有効な送信元アドレスではありません。マルチキャスト送信元を持つパケットは直ちにドロップされるべきです。

実用的な問題：送信元アドレスの選択

ホストが複数のIPv6アドレスを持つ場合(SLAAC、DHCPv6、プライバシー拡張で一般的)、どれを送信元として使用するかを選択する必要があります。RFC 6724は選択アルゴリズムを定義し、次を優先します：

1. 宛先と同じアドレススコープ
2. より長い一致プレフィックスを持つアドレス
3. 非推奨ではないアドレス
4. より高い優先度を持つアドレス

8. Destination Address(宛先アドレス、128ビット)#

パケットの意図された受信者のIPv6アドレスです。送信元アドレスと同様に、常に128ビットです。

形式： 標準IPv6アドレス表記

2001:4860:4860::8888

ルーティング決定：

ルーターはこのフィールドを調べて、パケットをどこに転送するかを決定します。NATがアドレスを書き換える可能性があるIPv4とは異なり、IPv6の宛先アドレスは通常、エンドツーエンドで変更されません。

特別なアドレス：

ループバック(::1) は、ワイヤ上のパケットに決して現れてはなりません。::1へのパケットは内部で処理されます。

マルチキャストアドレス(ff00::/8) は、パケットが複数の受信者に配信されるべきであることを示します：

• ff02::1 - ローカルリンク上のすべてのノード
• ff02::2 - ローカルリンク上のすべてのルーター
• ff02::1:ff00:0/104 - 要請ノードマルチキャスト(近隣探索用)

ルーティングヘッダーの変更：

ルーティング拡張ヘッダーが存在する場合、中間ノードは宛先アドレスを異なる方法で処理する可能性がありますが、これはセキュリティ上の懸念から最近のネットワークでは一般的ではありません。

IPv6 vs IPv4ヘッダー比較#

何が変わったかを理解することは、設計決定を評価するのに役立ちます。

削除されたものとその理由#

ヘッダーチェックサム： IPv4ルーターはTTLが変更されるため、ホップごとにチェックサムを再計算します。これは処理オーバーヘッドを追加します。IPv6はこれを排除しました。なぜなら：

• リンク層(イーサネット)には独自のチェックサムがある
• トランスポート層(TCP/UDP)には独自のチェックサムがある
• ルーターはパケットの整合性を検証する必要がない—エンドポイントが行う

ヘッダー長フィールド： IPv4はオプションがヘッダーを可変長にするため、これが必要です。IPv6の固定40バイトヘッダーはこのフィールドを不要にします。

フラグメンテーションフィールド： IPv4はどのルーターでもパケットをフラグメント化できます。IPv6はPath MTU Discoveryを使用して送信元がフラグメンテーションを実行することを要求します。これにより、複雑さがエンドポイントに移動し、ルーターのパフォーマンスが向上します。

オプション： IPv4オプションはほとんど使用されませんが、ルーターに可変長ヘッダーを解析させます。IPv6はオプションを拡張ヘッダーに移動し、ベースヘッダーをシンプルに保ちます。

拡張ヘッダーの説明#

拡張ヘッダーは、ベースヘッダーを複雑にすることなく機能を追加するIPv6の方法です。これらはIPv6ヘッダーとトランスポート層(TCP/UDP)の間に表示され、チェーンを形成します。

拡張ヘッダーの仕組み#

各拡張ヘッダーには、チェーン内の次のヘッダーを指す次ヘッダーフィールドが含まれています：

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | Hop-by | NH=43 | Routing| NH=6  | TCP |
| Header |       | -Hop   |       | Header |       |     |
+--------+-------+--------+-------+--------+-------+-----+

ホストは拡張ヘッダーを順番に処理します。ルーターは通常、ホップバイホップオプションのみを処理します。他のヘッダーは宛先でのみ調べられます。

標準拡張ヘッダー#

RFC 8200は、複数の拡張ヘッダーが存在する場合の推奨順序を定義しています：

1. Hop-by-Hop Options(0)
2. Destination Options(ルーティングヘッダーが存在する場合の中間宛先用)
3. Routing(43)
4. Fragment(44)
5. Authentication Header(51)
6. Encapsulating Security Payload(50)
7. Destination Options(60)(最終宛先用)
8. Upper Layer(TCP=6、UDP=17、ICMPv6=58)

Hop-by-Hop Optionsヘッダー(タイプ0)#

パス上のすべてのルーターが調べる必要があるオプションを運びます。

形式：

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

一般的なオプション：

Pad1とPadN： アライメントのためのパディング

Router Alert(タイプ5)： ルーターにパケットをより注意深く調べるよう指示します。MLD(Multicast Listener Discovery)などのプロトコルで使用されます。

Jumbogram(タイプ194)： 65,535バイトより大きいパケット用です。

最初でなければならない： 存在する場合、ホップバイホップオプションはIPv6ヘッダーの直後になければなりません。RFC 8200はこの厳格な順序を要求します。

セキュリティ上の懸念： 多くのルーターは、認識しないホップバイホップヘッダーを持つパケットをドロップするか、大幅にレート制限します。実際には、この拡張ヘッダーは特定のプロトコル(MLD、ジャンボグラム)以外では一般的ではありません。

Routingヘッダー(タイプ43)#

最終宛先に到達する前にパケットが訪問すべき中間ノードを指定します。

形式：

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                     Type-specific data                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ルーティングタイプ：

タイプ0(非推奨)： 元のルーズソースルーティング。セキュリティ問題(増幅攻撃)のためRFC 5095で非推奨になりました。

タイプ2： モバイルIPv6がモバイルノードへのルーティングに使用します。限定的な使用例です。

タイプ3： SRv6のセグメントルーティングヘッダー(SRH)。キャリアネットワークでのトラフィックエンジニアリングとサービスチェーニングの最新の使用例です。

セキュリティ： タイプ0ルーティングヘッダーは、攻撃者が任意のノードを通じてパケットをルーティングし、増幅攻撃を作成することを可能にしました。ほとんどのネットワークはタイプ0をドロップします。タイプ3(SRv6)はより慎重に設計されていますが、パブリックインターネット上ではまだセキュリティ上の懸念があります。

Fragmentヘッダー(タイプ44)#

送信元がパスMTUに対して大きすぎるパケットをフラグメント化するときに使用されます。

形式：

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

フィールド：

• Next Header： フラグメント化されたデータのプロトコル(TCP、UDPなど)
• Fragment Offset： 元のパケットでのこのフラグメントのオフセット(8バイト単位)
• Mフラグ： More Fragments(1 = さらに来る、0 = 最後のフラグメント)
• Identification： 再構成のための一意のID(1つのパケットのすべてのフラグメントで同じ)

フラグメンテーションの仕組み：

1. 送信元が大きなパケットを送信しようとする
2. ICMPv6 Packet Too Bigメッセージを受信する
3. パケットをより小さな部分にフラグメント化する
4. 各部分にフラグメントヘッダーを追加する
5. 宛先が識別フィールドに基づいて再構成する

例：

2000バイトの元のパケット、MTU 1280：

Fragment 1：
  IPv6 Header(40バイト)
  Fragment Header(8バイト)[M=1、Offset=0、ID=12345]
  Data(1232バイト)
  合計：1280バイト
 
Fragment 2：
  IPv6 Header(40バイト)
  Fragment Header(8バイト)[M=0、Offset=154、ID=12345]
  Data(768バイト)
  合計：816バイト

最小MTU： IPv6はすべてのリンクが少なくとも1280バイトをサポートすることを要求します。送信元は、準拠したIPv6ネットワーク上でフラグメンテーションなしで1280バイトのパケットを送信できます。

セキュリティ上の懸念： フラグメンテーションは攻撃を可能にします：

• 重複フラグメント(IDSからペイロードを難読化)
• フラグメントフラッド(再構成リソースを枯渇させる)
• 小さなフラグメント(処理時間を浪費)

多くのファイアウォールは、フラグメント化されたパケットをドロップするか、検査前に再構成します。

Destination Optionsヘッダー(タイプ60)#

宛先ノード専用のオプションを運びます。中間ルーターはそれを処理しません。

形式： ホップバイホップオプションと同じですが、宛先でのみ調べられます。

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         Options                               .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

使用例：

• アライメントのためのパディング
• アプリケーション固有のオプション
• ベースヘッダーを変更せずに将来の拡張

ヘッダーチェーンに2回現れる可能性があります：

1. ルーティングヘッダーの前(中間宛先によって処理される)
2. ESP/AHヘッダーの後(最終宛先によって処理される)

Authentication Header(タイプ51)とESP(タイプ50)#

認証と暗号化を提供するIPsecヘッダーです。

AH(51)： 認証と整合性を提供しますが、機密性は提供しません。ESPが同じことに加えて暗号化もできるため、ほとんど使用されません。

ESP(50)： 機密性、認証、整合性を提供します。VPNと暗号化通信の標準です。

IPsecはヘッダー構造を超えた大きなトピックです。重要なポイント：これらのヘッダーは、後から追加されたIPv4とは異なり、IPv6の設計の一部です。

拡張ヘッダーの処理#

ホストは以下を行う必要があります：

• すべての拡張ヘッダーを順番に処理する
• すべての標準拡張ヘッダーをサポートする
• 次ヘッダー値に従って未知のヘッダーを処理する

ルーターは通常：

• ホップバイホップオプションのみを調べる
• 他の拡張ヘッダーを処理せずに転送する
• セキュリティのために特定のヘッダーをレート制限またはドロップする可能性がある

ファイアウォールの考慮事項：

拡張ヘッダーはファイアウォールを複雑にします。なぜなら：

• トランスポートヘッダー(TCP/UDP)がパケットの深い場所にある可能性がある
• フィルタリングのためにポートを見つけるために、チェーン全体を解析する必要がある
• 攻撃者は複雑なヘッダーチェーンでペイロードを難読化できる

ベストプラクティス：

• 拡張ヘッダーチェーンの長さを制限する
• 非推奨のヘッダー(タイプ0ルーティング)を持つパケットをドロップする
• 検査前にフラグメントを再構成する
• ホップバイホップオプションを持つパケットをレート制限する

なぜチェックサムがないのか？#

IPv4にはルーターがホップごとに再計算しなければならないヘッダーチェックサム(TTLが変更されるため)が含まれています。IPv6はこれを意図的に省略しました。

理由：

1. リンク層はすでにチェックサムを行う： イーサネットにはCRC32があります。Wi-Fiにはチェックサムがあります。最近のリンク層は信頼性があります。

2. トランスポート層のチェックサム： TCPとUDPには、データとヘッダーをカバーするチェックサムが含まれています。エンドツーエンドの検証はとにかく行われます。

3. ルーターのパフォーマンス： ホップごとにチェックサムを再計算することは、CPUサイクルを浪費します。高速ルーターは毎秒何十億ものパケットを転送します—チェックサム計算を排除することは役立ちます。

4. エラーはまれ： 最近のネットワークはビットエラー率が低いです。チェックサムは、IPv4が設計された1980年代よりも少ないエラーを捕捉します。

破損についてはどうか？

IPv6ヘッダーでビットが反転した場合：

• 間違った宛先アドレス：パケットが間違った場所に行くか、ドロップされ、TCPが再送信する
• 間違ったホップ制限：パケットが早期または遅延して死ぬ可能性があり、限界的な影響
• 間違った次ヘッダー：宛先がそれを解析できず、TCPが欠落データを検出して再送信する

エンドツーエンド原則は、エンドポイントがエラーを検出して処理すべきだと言います。中間ルーターはただ高速にパケットを転送します。

実用的な意味合い#

ネットワークエンジニア向け#

ファイアウォール設定：

• トランスポートヘッダーを見つけるために拡張ヘッダーチェーンを解析する必要がある
• 悪用を防ぐためにチェーンの深さを制限すべき
• 非推奨のヘッダー(タイプ0ルーティング)をドロップする

パフォーマンスチューニング：

• ヘッダーチェックサムがないことは、ハードウェアでのより高速な転送を意味する
• 固定ヘッダーサイズは、ルーターでのより良いパイプライン処理を可能にする
• 拡張ヘッダーがスローパス処理をトリガーする可能性がある

トラブルシューティング：

• tcpdumpはすべてのヘッダーを表示：tcpdump -i eth0 -vv ip6
• Wiresharkは拡張ヘッダーを明確に解析する
• ドロップを引き起こす予期しない拡張ヘッダーをチェックする

開発者向け#

ソケットプログラミング：

• IPv6ソケットは補助データを介して拡張ヘッダーを受信できる
• アプリケーションが拡張ヘッダーを手動で構築する必要はほとんどない
• OSはフラグメンテーションを自動的に処理する

パケット構築：

• QoS対応アプリケーション(VoIP、ビデオ)のためにトラフィッククラスを設定する
• より良いECMP負荷分散のために自動フローラベル生成を有効にする
• フラグメント化できると仮定しない—PMTUDを適切に使用する

セキュリティ：

• 送信元アドレスを検証する(マルチキャスト送信元を拒否するなど)
• フラグメント化されたパケットを慎重に処理するか拒否する
• ミドルボックスが拡張ヘッダーをドロップする可能性があることに注意する

システム管理者向け#

MTU設定：

• すべてのリンクでMTUが少なくとも1280バイトであることを確認する
• より大きなMTUがパフォーマンスを向上させる(標準1500、ジャンボフレームの場合9000)
• ファイアウォールを通してICMPv6 Packet Too Bigを許可する

QoSセットアップ：

• トラフィッククラスマーキングを尊重するようにルーターを設定する
• アプリケーショントラフィックを適切なDSCP値にマップする
• QoSポリシーが正しく機能することを監視する

IPsec/VPN：

• AHとESPは拡張ヘッダー—ファイアウォールはそれらを許可する必要がある
• IPsecはオーバーヘッドを追加する—MTU計算でこれを考慮する
• トランスポートモード対トンネルモードのヘッダーへの影響を検討する

ツールでヘッダーを調べる#

tcpdump#

IPv6ヘッダーをキャプチャして表示：

# 基本的なIPv6パケットキャプチャ
sudo tcpdump -i eth0 -n ip6
 
# すべてのヘッダーフィールドを表示する詳細出力
sudo tcpdump -i eth0 -vv ip6
 
# 拡張ヘッダーを持つパケットのみを表示
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'
 
# フラグメント化されたパケットをキャプチャ
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

出力例：

12:34:56.789012 IP6 2001:db8::10 > 2001:db8::20: DSTOPT (TCP)
  2001:db8::10.54321 > 2001:db8::20.80: Flags [S], seq 123456789, win 65535
 
分析：
- 送信元：2001:db8::10、ポート54321
- 宛先：2001:db8::20、ポート80
- 拡張ヘッダー：Destination Options (DSTOPT)
- トランスポート：TCP SYN

Wireshark#

Wiresharkは詳細なヘッダー分析を提供します：

フィルター：

# すべてのIPv6トラフィック
ipv6
 
# 特定の拡張ヘッダーを持つパケット
ipv6.nxt == 0    # Hop-by-Hop
ipv6.nxt == 43   # Routing
ipv6.nxt == 44   # Fragment
ipv6.nxt == 60   # Destination Options
 
# フラグメント化されたパケット
ipv6.fragment
 
# 特定のトラフィッククラス
ipv6.tclass == 46  # Expedited Forwarding

ヘッダー検査：

1. パケット詳細で「Internet Protocol Version 6」を展開する
2. すべての8つのフィールドが明確にラベル付けされている
3. 拡張ヘッダーは別のレイヤーとして表示される
4. フィルタリングのためにフィールドを右クリックする

Scapy (Python)#

IPv6パケットをプログラムで構築および分析：

from scapy.all import *
 
# IPv6パケットを作成
pkt = IPv6(src="2001:db8::10", dst="2001:db8::20", tc=46, fl=12345)
pkt = pkt/TCP(sport=54321, dport=80, flags="S")
 
# パケット構造を表示
pkt.show()
 
# 出力：
# ###[ IPv6 ]###
#   version= 6
#   tc= 46
#   fl= 12345
#   plen= None
#   nh= TCP
#   hlim= 64
#   src= 2001:db8::10
#   dst= 2001:db8::20
# ###[ TCP ]###
#   sport= 54321
#   dport= http
 
# 拡張ヘッダーを追加
pkt = IPv6(dst="2001:db8::20")/IPv6ExtHdrDestOpt()/TCP(dport=80)
pkt.show()

一般的な誤設定#

拡張ヘッダー全体をブロック#

問題： ファイアウォールが拡張ヘッダーを持つすべてのパケットをドロップします。

影響：

• フラグメンテーションが機能しない(タイプ44がブロックされる)
• IPsec VPNが失敗する(タイプ50/51がブロックされる)
• 一部の正当なトラフィックがドロップされる

解決策： 必要なヘッダー(Fragment、AH、ESP)を許可し、非推奨のもの(タイプ0ルーティング)をブロックします。

# iptables：フラグメントを許可、タイプ0ルーティングをドロップ
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

トラフィッククラスを無視#

問題： QoSなしで設定されたルーター、すべてのパケットがベストエフォート処理を受ける。

影響：

• VoIPの品質が低下する
• ビデオストリームがバッファリングする
• 時間に敏感なトラフィックがバルク転送と競合する

解決策： トラフィッククラス/DSCPに基づいてQoSポリシーを設定します。

! Cisco IOSの例
class-map match-any VOICE
  match dscp ef
!
policy-map WAN-QOS
  class VOICE
    priority percent 20
  class class-default
    fair-queue
!
interface GigabitEthernet0/1
  service-policy output WAN-QOS

MTUミスマッチ#

問題： MTU < 1280のリンクまたはICMPv6 Packet Too Bigをブロックするファイアウォール。

影響：

• 接続がハングする
• 大きな転送が失敗する
• PMTUDが機能しない

解決策： すべての場所で最小1280 MTUを確保し、ICMPv6タイプ2を許可します。

# MTUを設定
ip link set dev eth0 mtu 1500
 
# 確認
ip -6 link show eth0
 
# Packet Too Bigを許可
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

関連記事#

• IPv6の基礎 - ヘッダーに入る前に、基本的なIPv6アドレッシングと概念を理解します。
• ICMPv6の説明 - 次ヘッダー値58を使用し、IPv6に不可欠なICMPv6について学びます。
• IPv6ファイアウォール設定 - IPv6ヘッダーと拡張ヘッダーを正しく処理するようにファイアウォールを設定します。

よくある質問#