4. IPv6 Extension Headers (IPv6拡張ヘッダー)
IPv6では、オプションのインターネット層情報は、パケットのIPv6ヘッダーと上位層ヘッダーの間に配置できる個別のヘッダーにエンコードされます。このような拡張ヘッダー (Extension Headers) は少数存在し、それぞれ異なるNext Header値によって識別されます。
拡張ヘッダーの番号は、IPv4とIPv6が使用する値と同じIANA IPプロトコル番号 [IANA-PN] から取得されます。パケット内のNext Header値のシーケンスを処理する際、拡張ヘッダー [IANA-EH] ではない最初の値は、パケット内の次の項目が対応する上位層ヘッダーであることを示します。上位層ヘッダーが存在しない場合は、特別な「No Next Header」値が使用されます。
以下の例に示すように、IPv6パケットは、ゼロ個、1個、または複数の拡張ヘッダーを運ぶことができ、それぞれ前のヘッダーのNext Headerフィールドによって識別されます:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
拡張ヘッダー（Hop-by-Hop Optionsヘッダーを除く）は、パケットがIPv6ヘッダーのDestination Addressフィールドで識別されるノード（またはマルチキャストの場合はノードのグループ）に到達するまで、パケット配信パス上のいかなるノードによっても処理、挿入、または削除されてはなりません (MUST NOT)。
Hop-by-Hop Optionsヘッダーは、挿入または削除されることはありませんが、パケットがIPv6ヘッダーのDestination Addressフィールドで識別されるノード（またはマルチキャストの場合はノードのグループ）に到達するまで、パケット配信パス上の任意のノードによって検査または処理される可能性があります。Hop-by-Hop Optionsヘッダー（存在する場合）は、IPv6ヘッダーの直後に続かなければなりません (MUST)。その存在は、IPv6ヘッダーのNext Headerフィールドの値ゼロによって示されます。
注意: [RFC2460]では、すべてのノードがHop-by-Hop Optionsヘッダーを検査および処理しなければならない (MUST) とされていましたが、現在では、パケット配信パス上のノードは、明示的にそうするように構成されている場合にのみ、Hop-by-Hop Optionsヘッダーを検査および処理することが期待されています。
宛先ノードでは、IPv6ヘッダーのNext Headerフィールドの通常の逆多重化により、最初の拡張ヘッダーを処理するモジュール、または拡張ヘッダーが存在しない場合は上位層ヘッダーを処理するモジュールが呼び出されます。各拡張ヘッダーの内容とセマンティクスによって、次のヘッダーの処理を続行するかどうかが決定されます。したがって、拡張ヘッダーは、パケット内に出現する順序で厳密に処理されなければなりません (MUST)。たとえば、受信者は、すべての先行するヘッダーを処理する前に、特定のタイプの拡張ヘッダーを探してパケットをスキャンし、そのヘッダーを処理してはなりません (MUST NOT)。
ヘッダーの処理の結果として、宛先ノードが次のヘッダーの処理を続行する必要があるが、現在のヘッダーのNext Header値がそのノードによって認識されない場合、そのノードはパケットを破棄し (SHOULD)、パケットの送信元にICMP Parameter Problemメッセージ（ICMPコード値1「遭遇した認識できないNext Headerタイプ」）を送信すべきです (SHOULD)。ICMPポインターフィールドには、元のパケット内の認識されない値のオフセットが含まれます。ノードがIPv6ヘッダー以外のヘッダーでNext Header値ゼロに遭遇した場合も、同じ動作を取るべきです (SHOULD)。
各拡張ヘッダーの長さは、後続のヘッダーのために8オクテットのアライメントを維持するために、8オクテットの整数倍です。各拡張ヘッダー内のマルチオクテットフィールドは、自然な境界にアライメントされます。つまり、幅がnオクテットのフィールドは、ヘッダーの開始からnオクテットの整数倍の位置に配置されます（n = 1、2、4、または8）。
IPv6の完全な実装には、以下の拡張ヘッダーの実装が含まれます:
- Hop-by-Hop Options (ホップバイホップオプション)
- Fragment (フラグメント)
- Destination Options (宛先オプション)
- Routing (ルーティング)
- Authentication (認証)
- Encapsulating Security Payload (カプセル化セキュリティペイロード)
最初の4つは本文書で規定されています。後の2つは、それぞれ [RFC4302] と [RFC4303] で規定されています。現在のIPv6拡張ヘッダーのリストは [IANA-EH] で確認できます。
4.1 Extension Header Order (拡張ヘッダーの順序)
同じパケットで複数の拡張ヘッダーが使用される場合、これらのヘッダーは以下の順序で出現することが推奨されます (RECOMMENDED):
IPv6 header
Hop-by-Hop Options header
Destination Options header (注1)
Routing header
Fragment header
Authentication header (注2)
Encapsulating Security Payload header (注2)
Destination Options header (注3)
Upper-Layer header
注1: IPv6 Destination Addressフィールドに出現する最初の宛先およびRouting headerにリストされている後続の宛先によって処理されるオプション用。
注2: Authentication headerとEncapsulating Security Payload headerの相対的な順序に関する追加の推奨事項は [RFC4303] に記載されています。
注3: パケットの最終宛先のみによって処理されるオプション用。
各拡張ヘッダーは最大1回出現すべきです (SHOULD)。ただし、Destination Optionsヘッダーは最大2回（Routing headerの前に1回、上位層ヘッダーの前に1回）出現できます (SHOULD)。
上位層ヘッダーが別のIPv6ヘッダー（IPv6-in-IPv6トンネリングまたはカプセル化の場合）である場合、それ自身の拡張ヘッダーが続く可能性があり、これらは個別に同じ順序の推奨事項に従います。
他の拡張ヘッダーが定義されている場合、上記にリストされているヘッダーに対する順序制約を指定しなければなりません (MUST)。
IPv6ノードは、任意の順序で、同じパケット内に任意の回数出現する拡張ヘッダーを受け入れて処理しようと試みなければなりません (MUST)。ただし、Hop-by-Hop Optionsヘッダーは、IPv6ヘッダーの直後に出現することに制限されています。それにもかかわらず、後続の仕様がこの推奨事項を改訂するまで、IPv6パケットの送信元が上記の推奨順序に従うことが強く推奨されます (STRONGLY ADVISED)。
4.2 Options (オプション)
本文書で規定されている2つの現在定義されている拡張ヘッダー（Hop-by-Hop OptionsヘッダーとDestination Optionsヘッダー）は、可変数の「オプション」を運び、これらは以下の形式でType-Length-Value (TLV) エンコードされます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type (オプションタイプ) 8ビット識別子。特定のオプションのタイプ。
Opt Data Len (オプションデータ長) 8ビット符号なし整数。このオプションのOption Dataフィールドの長さ（オクテット単位）。
Option Data (オプションデータ) 可変長フィールド。オプション固有のデータ。
Option Typeフィールドの最上位2ビットは、このオプションのタイプを認識しないIPv6ノードが取るべき動作を指定します:
00 - このオプションをスキップし、処理を続行する
01 - パケットを破棄する
10 - パケットを破棄し、宛先アドレスがマルチキャストアドレスであるかどうかに関係なく、
パケットの送信元アドレスにICMP Parameter Problemコード2メッセージを送信する
11 - パケットを破棄し、宛先アドレスがマルチキャストアドレスでない場合にのみ、
パケットの送信元アドレスにICMP Parameter Problemコード2メッセージを送信する
Option Typeフィールドの3番目に高いビット（ビット2）は、このオプションのデータがパケットの途中で変更される可能性があるかどうかを指定します:
0 - オプションデータは途中で変更されない
1 - オプションデータは途中で変更される可能性がある
個々のオプションは、拡張ヘッダー内のオクテット境界に整列する必要はありません。ただし、拡張ヘッダー全体の長さが8オクテットの整数倍になるように、Pad1またはPadNオプションを使用してパディングが必要です。
4.3 Hop-by-Hop Options Header (ホップバイホップオプションヘッダー)
Hop-by-Hop Optionsヘッダーは、配信パスに沿った各ノードによって検査されるオプション情報を運ぶために使用されます。Hop-by-Hop Optionsヘッダーは、Next Header値0を使用してIPv6ヘッダーで識別されます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8ビットセレクター。このヘッダーの直後に続くヘッダーのタイプを識別します。IPv4 Protocolフィールドと同じ値を使用します [IANA-PN]。
Hdr Ext Len 8ビット符号なし整数。Hop-by-Hop Optionsヘッダーの長さを8オクテット単位で表します（最初の8オクテットは含みません）。
Options 可変長フィールド。長さは、Hdr Ext Lenによって指定されます。1つ以上のTLVエンコードされたオプションが含まれます。
Hop-by-Hop Optionsヘッダー内で現在定義されている唯一のオプションは、Pad1とPadNオプション（セクション4.2で指定）、およびRouter Alert [RFC2711] です。
4.4 Routing Header (ルーティングヘッダー)
Routing Headerは、IPv6送信元ノードによって使用され、パケットが宛先への途中で訪問すべき1つ以上の中間ノードを「ルーティング」するために使用されます。この機能は、IPv4のLoose Source and Record Routeオプションと非常に似ています。Routing Headerは、IPv6ヘッダーまたは別の拡張ヘッダーのNext Header値43を使用して識別されます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8ビットセレクター。このヘッダーの直後に続くヘッダーのタイプを識別します。
Hdr Ext Len 8ビット符号なし整数。Routing Headerの長さを8オクテット単位で表します（最初の8オクテットは含みません）。
Routing Type 8ビット識別子。特定のRouting Headerバリアント。
Segments Left 8ビット符号なし整数。最終宛先に到達する前に明示的にリストされている残りのルートセグメントの数。
type-specific data 可変長フィールド。Routing Typeによって決定される形式。
Routing Typeに対して明示的に他のノードが指定されていない場合、Routing Headerを含むパケットを受信するノードは、Segments Leftがゼロの場合は通常のIPv6転送を実行し、Segments Leftが非ゼロの場合はRFC 5095 [RFC5095] で指定されている手順に従わなければなりません (MUST)。
4.5 Fragment Header (フラグメントヘッダー)
Fragment Headerは、IPv6送信元によって使用され、元の「アンフラグメント可能な」パケットがパス上のMTUよりも大きいデータグラムを送信します。Fragment Headerは、IPv6ヘッダーまたは別の拡張ヘッダーのNext Header値44を使用して識別されます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8ビットセレクター。元のアンフラグメント可能なパケットの「Next Header」値を識別します。
Reserved 8ビット予約フィールド。送信時にゼロに初期化され、受信時に無視されます。
Fragment Offset 13ビット符号なし整数。このフラグメントのデータがアンフラグメント可能な元のパケットの開始からのオフセット（8オクテット単位）。
Res 2ビット予約フィールド。送信時にゼロに初期化され、受信時に無視されます。
M flag 1 = これより多くのフラグメント; 0 = 最後のフラグメント。
Identification 32ビット。元のパケットのすべてのフラグメントを一意に識別するために送信元ノードによって生成されます。
IPv6パケットをフラグメント化するために、送信元ノードは以下の手順を実行します:
-
元のパケットは、「アンフラグメント可能な部分」と「フラグメント可能な部分」に概念的に分割されます。
アンフラグメント可能な部分は、IPv6ヘッダーと、存在する場合は以下のものから構成されます:
- Hop-by-Hop Optionsヘッダー
- Destination Optionsヘッダー（ただし、Routing Headerの後に出現するものは除く）
- Routing Header
フラグメント可能な部分は、アンフラグメント可能な部分に続くパケットの残りの部分から構成されます。
-
フラグメント可能な部分のペイロードは、「フラグメント」と呼ばれる複数のチャンクに分割されます（最後のフラグメントを除く、各フラグメントは8オクテットの整数倍でなければなりません）。
-
各フラグメントに対して、送信元ノードはフラグメントパケットを作成します:
a) アンフラグメント可能な部分は、元のパケットと同一です。ただし、IPv6ヘッダーのPayload Lengthは、フラグメントパケットのペイロード長を反映するように変更されます。
b) Fragment Headerが作成され、Next Headerフィールドは元のパケットのアンフラグメント可能な部分の最後のヘッダーから取得されます。
c) フラグメントが、Fragment Headerに続いて配置されます。
フラグメントの再構成のために、宛先は以下の手順を実行します:
-
同じIdentificationフィールド値を持つすべてのフラグメントを収集します。
-
Fragment Offsetフィールドを使用して、元のアンフラグメント可能なパケットを再構成します。
-
M flagが0のフラグメント（つまり、最後のフラグメント）を使用して、元のパケットの長さを決定します。
重要な注意事項:
-
フラグメント化は、送信元ノードでのみ実行され、中間ノードでは実行されません。
-
IPv6ノードがフラグメント化されたパケットを受信した場合、宛先に到達する前にフラグメントを再構成してはなりません (MUST NOT)。
-
フラグメントの再構成タイムアウトは、最初のフラグメントが到着してから少なくとも60秒でなければなりません (MUST)。
-
フラグメントの再構成中にエラーが発生した場合（タイムアウトまたは重複するフラグメント）、宛先は不完全なパケットを静かに破棄し、送信元にICMP Time Exceededメッセージ（コード1）を送信することができます (MAY)。
4.6 Destination Options Header (宛先オプションヘッダー)
Destination Optionsヘッダーは、パケットの宛先ノードによってのみ検査されるオプション情報を運ぶために使用されます。Destination Optionsヘッダーは、IPv6ヘッダーまたは別の拡張ヘッダーのNext Header値60を使用して識別されます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8ビットセレクター。このヘッダーの直後に続くヘッダーのタイプを識別します。
Hdr Ext Len 8ビット符号なし整数。Destination Optionsヘッダーの長さを8オクテット単位で表します（最初の8オクテットは含みません）。
Options 可変長フィールド。1つ以上のTLVエンコードされたオプションが含まれます。
Destination Optionsヘッダー内で現在定義されているオプションは、Pad1とPadNオプション（セクション4.2で指定）のみです。
4.7 No Next Header (次ヘッダーなし)
値59は「No Next Header」を示し、IPv6ヘッダーまたは任意の拡張ヘッダーのNext Headerフィールドで使用される可能性があります。これは、そのヘッダーの後に何も続かないことを示します。そのヘッダーの後に続くオクテットがある場合、それらのオクテットは無視され、IPv6ヘッダーのPayload Lengthカウントの一部としてルーティング時に伝達されなければなりません (MUST)。
4.8 Defining New Extension Headers and Options (新しい拡張ヘッダーとオプションの定義)
新しい拡張ヘッダーまたはオプションを定義する仕様では、以下を指定しなければなりません (MUST):
- 既存の拡張ヘッダーに対する順序制約
- 認識されない場合のノードの動作
- 変更可能性（途中で変更できるかどうか）
- アライメント要件
- Fragment Headerとの相互作用（該当する場合）