|
Network Working Group Request for Comments: 2460 Obsoletes: 1883 Category: Standards Track |
S. Deering Cisco R. Hinden Nokia December 1998 |
このドキュメントは、インターネット社会の為のインターネット標準トラックプロトコルを規定しており、改善の為の議論と提案を求めている。このプロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配布は制限されない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
このドキュメントは、ときどき次世代 IP、あるいは IPng と呼ばれるインターネットプロトコルバージョン 6 (IPv6) を規定する。
Table of Contents
1. 導入
2. 用語
3. IPv6 ヘッダ形式
4. IPv6 拡張ヘッダ
4.1 拡張ヘッダの順番
4.2 オプション
4.3 ホップバイホップオプションヘッダ
4.4 ルーティングヘッダ
4.5 フラグメントヘッダ
4.6 宛先オプションヘッダ
4.7 次ヘッダ無し
5. パケットサイズの問題
6. フローラベル
7. トラフィッククラス
8. 上位層プロトコル問題
8.1 上位層チェックサム
8.2 最大パケット生存時間
8.3 最大上位層ペイロード長
8.4 パケット搬送ルーティングヘッダの応答
付録 A フローラベルフィールドの意味と使用方法
付録 B オプションの構成指針
セキュリティの考慮
謝辞
作者のアドレス
参照
RFC-1883 からの変更点
完全なコピーライト宣言
IP バージョン 6 (IPv6) は、IP バージョン 4 (IPv4) [RFC-791] を引き継いで設計されたインターネットプロトコルの新しいバージョンである。IPv4 から IPv6 への変更点は、主に下記のカテゴリに分類される。
・アドレス付け能力の拡張
IPv6 は、アドレス階層のより多くのレベルや、ずっと大きなアドレス付け可能なノード数、アドレスの自動設定の簡素化をサポートするために、IPアドレスのサイズを
32 ビットから
128 ビットに増やす。マルチキャストルーティングの拡張性は、マルチキャストアドレスに「スコープ」フィールドを追加することによって改善される。一つのノードグループのどれかにパケットを送信するために使用する、「エニイキャストアドレス」と呼ばれる新しいアドレスタイプが定義される。
・ヘッダ形式の簡略化
パケット操作の共通処理のコストを減らし、IPv6
ヘッダの帯域コストを制限するために、幾つかの
IPv4 ヘッダフィールドは無くされたか、オプションにされた。
・拡張とオプションのサポート改善
IPヘッダオプションが符号化される方法の変更は、より効率的な転送やオプションの長さ制限の緩和、将来的な新しいオプション導入の柔軟性増加を可能にする。
・フローラベル付け能力
送信側が、例えば非デフォルトサービス品質や「リアルタイム」サービスといった、特別な操作を要求する特定のトラフィック「フロー」に属するパケットのラベル付けを可能にするために、新しい能力が追加される。
・認証と守秘能力
認証、データの完全性、(オプションで)データの機密性サポートの拡張が、IPv6
で規定される。
このドキュメントは、基本的な IPv6 ヘッダと初期定義された IPv6 拡張ヘッダとオプションを規定する。パケットサイズの問題やフローラベルとトラフィック管理のセマンティクス、上位層プロトコルにおける IPv6 の影響についても論じる。IPv6 アドレスの形式とセマンティクスは、別途 [ADDRARCH] で規定される。全ての IPv6 実装が含める必要のある ICMP の IPv6 バージョンは、[ICMPv6] で規定される。
ノード
IPv6 を実装するデバイス。
ルータ
明示的に自分自身にアドレス付けられていない
IPv6 パケットを転送するノード。[以下の注記参照]
ホスト
ルータではないノード。[以下の注記参照]
上位層
IPv6 の直上のプロトコル層。例えば、TCP や UDP 等のトランスポートプロトコルや
ICMP 等の制御プロトコル、OSPF 等のルーティングプロトコル、IPX, AppleTalk,
IPv6 自身等の上にの「トンネル」(すなわちカプセル化)させるインターネット、あるいは下位層プロトコル。
リンク
ノードがリンク層、すなわち IPv6
直下の層で通信できる通信設備や媒体。例えば、イーサネット
(単一またはブリッジ)、PPP リンク、X.25、フレームリレー、ATM ネットワーク、IPv4
や IPv6 自身等の上に「トンネル」させるインターネット (あるいは上位層)
プロトコル。
隣接者
同一リンクに接続されたノード
インタフェース
リンクへのノードの接続
アドレス
一つのインタフェース、あるいはインタフェースのセットのための
IPv6 層識別子。
パケット
IPv6 ヘッダとペイロード。
リンク MTU
最大転送単位、すなわちリンク上で搬送できるオクテット単位の最大パケットサイズ。
パス MTU
送信元ノードと宛先ノード間のパスにおける全てのリンクの最小リンク
MTU。
注記: 一般的ではないが、複数のインタフェースを持つデバイスが、そのインタフェースの幾つかのセット(全て以下)から到着した自身宛てでないパケットを転送したり、他のインタフェースから到着した自身宛てでないパケットを破棄するよう設定することは可能である。そのようなデバイスは、前者の(転送する)インタフェースからパケットを受信し、それ上の隣接者と相互動作する時、ルータの要件に従わなければならない。後者の(転送しない)インタフェースからパケットを受信し、その上の隣接者と相互動作する時、ホストの要件に従わなければならない。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
4 ビットのインターネットプロトコルバージョン番号 = 6。
Traffic Class
8 ビットのトラフィッククラスフィールド。セクション
7 参照。
Flow Label
20 ビットのフローラベル。セクション
6 参照。
Payload Length
16 ビット符号無し整数。IPv6 ペイロードのオクテット単位の長さ、すなわち IPv6
ヘッダに続く残りのパケットの長さである。(存在する如何なる拡張ヘッダ
[セクション 4]
もペイロードの一部と見なされ、長さにカウントされることに注意されたい)。
Next Header
8 ビットのセレクタ。IPv6 ヘッダの直次のヘッダのタイプを識別する。IPv4
のプロトコルフィールド [RFC-1700 等]
と同じ値を使用する。
Hop Limit
8 ビット符号無し整数。パケットを転送する各々のノードで 1 ずつ減算する。もし
Hop Limit が 0 に減算されたら、そのパケットは破棄される。
Source Address
パケットの起動者の 128 ビットアドレス。[ADDRARCH] 参照。
Destination Address
パケットの受信側を意図する 128 ビットアドレス
(もしルーティングヘッダが存在するならば、最終的な受信側ではないかもしれない)。[ADDRARCH]
とセクション 4.4 参照。
IPv6 では、オプションのインターネット層情報は、IPv6 ヘッダとパケット中の上位層ヘッダとの間に置いてもよい別個のヘッダで符号化される。そのような拡張ヘッダは少し存在し、各々異なる次ヘッダ値によって識別される。以下の例で図示されているように、IPv6 パケットは 0、1、あるいはより多くの拡張ヘッダを運んでもよく、先行するヘッダの Next Header フィールドによって識別される。
+---------------+------------------------ | IPv6 ヘッダ | TCP ヘッダ + データ | | | Next Header = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | IPv6 ヘッダ | ルーティング | TCP ヘッダ + データ | | ヘッダ | | Next Header = | Next Header = | | Routing | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv6 ヘッダ | ルーティング | フラグメント | TCP ヘッダ + データ | | ヘッダ | ヘッダ | のフラグメント | Next Header = | Next Header = | Next Header = | | Routing | Fragment | TCP | +---------------+----------------+-----------------+-----------------
一つの例外を除いて、パケットが IPv6 ヘッダの宛先アドレスフィールドで識別されるノード (あるいはマルチキャストではノードの各セット) に到達するまで、拡張ヘッダはパケットの配送パスに属する如何なるノードでもチェック、または処理されない。IPv6 ヘッダの次ヘッダフィールドに基づく通常の非多重化は、最初の拡張ヘッダ、あるいはもし拡張ヘッダが存在しないならば上位層ヘッダを処理するためのモジュールを呼出する。各拡張ヘッダの内容とセマンティクスは、次のヘッダに進めるか否かを決定する。従って拡張ヘッダは、厳密にパケットに現れた順序通りに処理されなければならない。受信側は、例えば特定の種類の拡張ヘッダを調べるためにパケット全体を走査してはならないし、先行する全てのヘッダを処理する前にヘッダを処理してはならない。
前のパラグラフで参照される例外は、ホップバイホップオプションヘッダである。それは、送信元と宛先ノードを含む、パケットの配送パスに属する全てのノードがチェックし処理しなければならない情報を運ぶ。ホップバイホップオプションヘッダが存在する時、IPv6 ヘッダの直後に続かなければならない。それが存在する場合、IPv6 ヘッダの次ヘッダフィールドに 0 の値が指定される
もしヘッダを処理した結果、ノードが次ヘッダに進める必要があるが、現ヘッダの次ヘッダフィールドをノードが認識できないならば、ノードはそのパケットを破棄し、1 (「未知の次ヘッダタイプに遭遇」)の値の ICMP コードを持ち、ICMP ポインタフィールドが元のパケット内の認識できない値のオフセットを含む、ICMP パラメタ問題メッセージをパケットの送信元に送信すべきである。もしノードが IPv6 以外のヘッダで 0 の次ヘッダフィールド値に遭遇したら、同じ動作を実行すべきである。
後続ヘッダに対して 8 オクテット調整を維持するために、各々の拡張ヘッダは 8 オクテット倍数長の整数である。各拡張ヘッダ内の複数オクテットのフィールドは自然な境界で調整、すなわち n オクテット幅のフィールドは、ヘッダの先頭から n オクテット倍の整数で置かれる。n は 1, 2, 4, 8 のどれかである。
IPv6 の完全実装は、以下の拡張ヘッダの実装を含む。
最初の 4 つはこのドキュメントで規定され、最後の 2 つはそれぞれ [RFC-2402] と [RFC-2406] で規定される。
一つ以上の拡張ヘッダが同じパケットで使用される時、それらのヘッダは以下の順番で現れることが推奨される。
注 1: IPv6 宛先アドレスフィールドとルーティングヘッダにリスト化された後続の宛先中に現れる最初の宛先によって処理されるオプション。
注 2: 認証とセキュリティペイロードカプセル化ヘッダの相対順番に関する追加推奨は、[RFC-2406] に記述される。
注 3: パケットの最後の宛先によってのみ処理されるオプション。
大抵 2 回 (ルーティングヘッダの前に 1 回、上位層ヘッダの前に 1 回) 現れるべきである宛先オプションヘッダを除いて、各々の拡張ヘッダは大半 1 回だけ現れるべきである。
もし上位層ヘッダが別の IPv6 ヘッダならば (IPv6 でトンネル化された、あるいは IPv6 にカプセル化された場合)、それ自身の拡張ヘッダが続いてもよく、別個に同じ推奨順序の適用を受ける。
他の拡張ヘッダが定義された場合、上記に一覧化されたヘッダに関するその順序制約が規定されなければならない。
IPv6 ヘッダの直後にのみ現れるよう制限されるホップバイホップオプションヘッダを除いて、IPv6 ノードは拡張ヘッダが同じパケットで如何なる順序でも如何なる回数現れても、受諾し処理を試みなければならない。にもかかわらず、IPv6 パケットの送信元は、以降の規約がその推奨を改訂するまでは上記の推奨順序に固執することが強く忠告される。
現在定義されている拡張ヘッダの二つ、ホップバイホップオプションヘッダと宛先オプションヘッダは、以下の形式の「オプション」を符号化する可変数のタイプ-長さ-値 (TLV: type-length-value) を運ぶ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type
オプションのタイプの 8 ビット符号無し整数。
Opt Data Len
8 ビット符号無し整数。このオプションのオクテット単位のオプションデータフィールドの長さ。
Option Data
可変長フィールド。オプションタイプ特定のデータ。
ヘッダ内のオプションの順序は、ヘッダに現れた順番で厳密に処理しなければならず、受信側は例えばヘッダを特定の種類のオプションを探して走査したり、全ての先行するオプションを処理する前にそのオプションを処理してはならない。
オプションタイプ識別子は、最上位の 2 ビットが IPv6 ノードが認識できないオプションタイプを処理する場合に実行しなければならない動作を指定すように、内部的に符号化される。
00 - このオプションをスキップし、ヘッダの処理を継続する。
01 - パケットを破棄する。
10 - パケットを破棄し、そのパケットの宛先アドレスがマルチキャストアドレスであるないに関わらず、パケットの送信元アドレスに、未知のオプションタイプを指したコード 2 の ICMP パラメタ問題メッセージを送信する。
11 - パケットを破棄し、パケットの宛先アドレスがマルチキャストアドレスでない場合に限り、パケットの送信元アドレスに、未知のオプションタイプを指したコード 2 の ICMP パラメタ問題メッセージを送信する。
オプションタイプの最上位の三つのビットは、オプションのオプションデータがパケットの最終宛先への途中で変更できるか否かを指定する。認証ヘッダがパケット中に存在する時、その如何なるデータも途中で変更してよく、オプションデータフィールド全体は、パケットの認証値を計算、あるいは照合する時に 0 値のオクテットとして扱わなければならない。
0 - オプションデータを途中で変更しない。
1 - オプションデータを途中で変更してもよい。
上で説明されている上位 3 ビットはオプションタイプの一部として扱われ、オプションタイプに無依存ではない。すなわち、ある特定のオプションはオプションタイプの低位 5 ビットだけではなく、8 ビットのオプションタイプ全体によって識別される。
ホップバイホップオプションヘッダと宛先オプションヘッダの両方で、同じオプションタイプ番号空間が使用される。しかし、特定のオプションの規定では、これらの二つのヘッダのうち一つしか使用してはならないと制限するかもしれない。
個々のオプションは、オプションデータフィールド内の複数オクテット値が自然な境界に至ることを保証するために、特定の調整要件を持ってもよい。オプションの調整要件は、xn+y 記法を使用して指定される。それは、オプションタイプがヘッダの開始から x オクテットの整数倍、プラス y オクテットに現れなければならないことを意味する。
2n は、ヘッダの開始から幾つかの 2 オクテットのオフセットを意味する。
8n+2 は、ヘッダの開始から幾つかの 8 オクテットのオフセット、プラス 2 オクテットを意味する。
後続のオプションを調整し、含まれるヘッダを 8 オクテットの倍数長に伸長する必要がある時に使用する、二つのパディングオプションが存在する。これらのパディングオプションは、全ての IPv6 実装が認識できなければならない。
Pad1 オプション (調整要件: 無し)
+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+
注記!: Pad1 オプションの形式は特殊な場合であり、長さや値のフィールドを持たない。
Pad1 オプションは、ヘッダのオプション域にパディングの 1 オクテットを挿入するために使用される。もしパディングに 1 オクテット以上必要ならば、複数の Pad1 オプションではなく、次に説明する PadN オプションを使用すべきである。
PadN オプション (調整要件: 無し)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
PadN オプションは、ヘッダのオプション域に 2 オクテット以上のオクテットを挿入するために使用される。パディングの N オクテットに対し、Opt Data Len フィールドは N-2 の値を含み、オプションデータは N-2 個の 0 値のオクテットから成る。
付録 B は、新しいオプションを設計するための形式化指針を含む。
ホップバイホップオプションヘッダは、パケットの配送パスに属する全てのノードがチェックしなければならないオプション情報を運ぶために使用される。ホップバイホップオプションヘッダは、IPv6 ヘッダ中の 0 の値の次ヘッダによって識別される。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8 ビットのセレクタ。ホップバイホップオプションヘッダの直後に続くヘッダのタイプを識別する。IPv4
のプロトコルフィールド [RFC-1700 等]
と同じ値を使用する。
Hdr Ext Len
8 ビットの符号無し整数。8
オクテット単位のホップバイホップオプションヘッダで、最初の
8 オクテットは含めない。
Options
可変長のフィールドで、ホップバイホップオプションヘッダが完了する長さは、8
オクテットの倍数長の整数である。セクション
4.2 で説明されているように、一つ以上の
TLV で符号化されたオプションを含む。
このドキュメントで定義されたホップバイホップオプションは、セクション 4.2 で規定された Pad1 と PadN オプションだけである。
ルーティングヘッダは、パケットの宛先への道のりで「訪問する」一つ以上の中間ノードをリスト化するために、IPv6 送信元によって使用される。この機能は、「IPv4」の自由な送信元と記録レコードオプションに非常に良く似ている。ルーティングヘッダは、直前のヘッダの 43 の次ヘッダ値によって識別され、以下の形式を持つ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . type-specific data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8 ビットセレクタ。直後に続くルーティングヘッダのヘッダのタイプを識別する。
IPv4 プロトコルフィールド [RFC-1700 等]
と同じ値を使用する。
Hdr Ext Len
8 ビット符号無し整数。8 オクテット単位のルーティングヘッダの長さで、最初の
8 オクテットは含まない。
Routing Type
特定のルーティングヘッダ変形の 8 ビット識別子。
Segments Left
8 ビット符号無し整数。残りの経路セグメントの数、すなわち明示的にリスト化された中間ノードの数は、依然として最終宛先に到達する前に訪問される。
type-specific data
ルーティングタイプによって決定される形式でルーティングヘッダを完結する長さの可変長フィールドは、8
オクテット長の整数倍である。
受信したパケットを処理する間、ノードが未知のルーティングタイプ値を持つルーティングヘッダに遭遇したら、ノードの必要な動作は Segments Left フィールドの値による。下記の通り。
もし Segments Left が 0 ならば、ノードはルーティングヘッダを無視し、ルーティングヘッダの次ヘッダによって識別されるタイプのパケットの次のヘッダに処理を進める。
もし Segments Left が 0 でないならば、ノードはそのパケットを破棄し、未知のルーティングタイプを指すコード 0 の ICMP パラメタ問題メッセージを送信しなければならない。
もし、受信したパケットのルーティングヘッダを処理した後、中間ノードがパケットをリンク MTU がパケットのサイズよりも小さい回線に転送するよう決定したら、そのノードはパケットを破棄して、パケットの送信元アドレスに ICMP パケットサイズ超過メッセージを送信しなければならない。
タイプ 0 のルーティングヘッダは、以下の形式を持つ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type=0| Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[2] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[n] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8 ビットセレクタ。直後に続くルーティングヘッダのヘッダのタイプを識別する。IPv4
プロトコルフィールド [RFC-1700 等]
と同じ値を使用する。
Hdr Ext Len
8 ビット符号無し整数。8 オクテット単位のルーティングヘッダの長さで、最初の
8 オクテットは含まない。タイプ 0 のルーティングヘッダの場合、Hdr Ext Len
はヘッダ中のアドレスの 2 倍の数に等しい。
Routing Type
0.
Segments Left
8 ビット符号無し整数。残りの経路セグメントの数、すなわち明示的にリスト化された中間ノードの数は、依然として最終宛先に到達する前に訪問される。
Reserved
32 ビット予約フィールド。送信時は 0 に初期化され、受信時は無視される。
Address[1..n]
128 ビットアドレスの方向、番号 1 〜 n。
マルチキャストアドレスは、タイプ 0 のルーティングヘッダや、タイプ 0 のルーティングヘッダを運ぶパケットの IPv6 宛先アドレスフィールドに現れてはならない。
ルーティングヘッダは、IPv6 ヘッダの宛先アドレスフィールドで識別されるノードに到達するまでチェック、あるいは処理されない。そのノードで直前のヘッダの次ヘッダフィールドをディスパッチし、ルーティングヘッダモジュールが呼び出される。そして、ルーティングタイプが 0 の場合は、以下のアルゴリズムを実行する。
if Segments Left = 0 {
タイプがルーティングヘッダ中の次ヘッダフィールドによって
識別されるパケットの次ヘッダの処理を進める。
}
else if Hdr Ext Len が奇数 {
Hdr Ext Len フィールドを指すコード 0 の ICMP パラメタ問題
メッセージを、送信元アドレスに送信し、そのパケットを破棄する。
}
else {
Hdr Ext Len を 2 で割ることによってルーティングヘッダ中の
アドレス n を算出する。
if Segments Left が n よりも大きい {
Segments Left フィールドを指すコード 0 の ICMP パラメタ問題
メッセージを、送信元アドレスに送信し、そのパケットを破棄する。
}
else {
Segments Left を 1 減らし、アドレス方向で訪れる次アドレスの
インデクス i を、n から Segments Left を引くことによって算出する。
if Address [i] か IPv6 宛先アドレスがマルチキャストである {
そのパケットを破棄する。
}
else {
IPv6 宛先アドレスとアドレス[i]を入れ替える。
if IPv6 Hop Limit が 1 以下である {
ICMP 時間超過 -- 送信中にホップ制限超過メッセージを
送信元アドレスに送信し、そのパケットを破棄する。
}
else {
Hop Limit を 1 減らす。
新しい宛先に送信するために、そのパケットを IPv6
モジュールに再度渡す。
}
}
}
}
上記アルゴリズムの効果の例として、中間ノード I1, I2, I3 を経由して振り分けさせるためにルーティングヘッダを使用して、宛先ノード D にパケットを送信する送信元ノード S を考える。配送パスの各々のセグメントの関連する IPv6 ヘッダとルーティングヘッダは、以下の通り。
S から I1 までパケット送信時:
Source Address = S Hdr Ext Len = 6
Destination Address = I1 Segments Left = 3
Address[1] = I2
Address[2] = I3
Address[3] = D
I1 から I2 までパケット送信時:
Source Address = S Hdr Ext Len = 6
Destination Address = I2 Segments Left = 2
Address[1] = I1
Address[2] = I3
Address[3] = D
I2 から I3 までパケット送信時:
Source Address = S Hdr Ext Len = 6
Destination Address = I3 Segments Left = 1
Address[1] = I1
Address[2] = I2
Address[3] = D
I3 から D までパケット送信時:
Source Address = S Hdr Ext Len = 6
Destination Address = D Segments Left = 0
Address[1] = I1
Address[2] = I2
Address[3] = I3
フラグメントヘッダは、宛先へのパス MTU に適合するよりも大きいパケットを送信するために、IPv6 送信元によって使用される (注記: IPv4 とは異なり、IPv6 のフラグメント化は送信元ノードでのみ実行され、パケットの配送パス上のルータによっては実行されない。セクション 5 参照)。フラグメントヘッダは、直前のヘッダ中の 44 の値の次ヘッダによって識別され、以下の形式を持つ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8 ビットセレクタ。元のパケットのフラグメント可能部分の初期ヘッダタイプを識別する
(以下に定義)。IPv4 プロトコルフィールド [RFC1700 等]
と同じ値を使用する。
Reserved
8 ビット予約フィールド。転送時に 0 に初期化され、受信時に無視される。
Fragment Offset
13 ビット符号無し整数。このヘッダに続くデータの 8
オクテット単位のオフセットで、元のパケットのフラグメント可能部分の開始から相対である。
Res
2 ビットの予約ヘッダ。送信時に 0 に初期化され、受信時に無視される。
M flag
1 = さらにフラグメント有り、0 = 最終フラグメント。
Identification
32 ビット。以下の説明を参照。
宛先までのパスの MTU には大きすぎるパケットを送信するために、送信元ノードはそのパケットをフラグメントに分割し、各々のフラグメントを別々のパケットとして送信し、受信側で再度組み立てる。
フラグメント化される全てのパケットに対して、送信元ノードは識別子値を生成する。識別子は、同じ送信元アドレスと宛先アドレスを持つ最近 (*) 送信した他の如何なるパケットのものとも異ならなければならない。もしルーティングヘッダが存在するならば、関連する宛先アドレスは最終宛先のものである。
(*) 「最近」はパケットのおおよそ最大生存時間以内を意味し、送信元から宛先への送信時間と同じパケットの組み立てを待つのに費やす時間を含む。しかし、送信元ノードが最大パケット生存時間を知る必要はない。むしろ、パケットをフラグメント化しなければならない毎に加算した単純な 32 ビットの「巻き」回数として識別子値を維持することにより、その要件が適合されると仮定する。ノードで単一のカウンタを維持するか複数のカウンタを維持するかは、すなわち、ノードの有り得る送信元アドレスに対して持つか、活性な (送信元アドレス、宛先アドレス) 組み合わせに対して持つかは、実装の選択である。
最初の大きく、フラグメント化されていないパケットは、「元のパケット」と呼ばれ、図のように二つの部分で構成されるとみなされる。
元のパケット:
+------------------+----------------------//-----------------------+ | フラグメント | フラグメント | | 不可部 | 可能部 | +------------------+----------------------//-----------------------+
フラグメント不可部は、宛先までの途中でノードによって処理されなければならない、IPv6 ヘッダと全ての拡張ヘッダから成る。それは、もし存在するならルーティングヘッダまで、さもなくば、もし存在するならホップバイホップオプションヘッダまで、さもなくば拡張ヘッダまでの全てのヘッダである。
フラグメント可能部は残りのパケットから成る。それは、最終宛先でのみ処理される必要がある拡張ヘッダと上位層ヘッダとデータである。
元のパケットのフラグメント可能部は、各々恐らく最後(最も右)のものを除いて、8 オクテット長の整数倍であるように、フラグメントに分割される。フラグメントは、図のように別個の「フラグメントパケット」で送信される。
元のパケット:
+------------------+--------------+--------------+--//--+--------------+ | フラグメント | 第一 | 第二 | | 最終 | | 不可部 | フラグメント| フラグメント| .... | フラグメント | +------------------+--------------+--------------+--//--+--------------+
フラグメントパケット:
+------------------+------------+--------------+
| フラグメント |フラグメント| 第一 |
| 不可部 |ヘッダ | フラグメント |
+------------------+------------+--------------+
+------------------+------------+--------------+
| フラグメント |フラグメント| 第二 |
| 不可部 |ヘッダ | フラグメント |
+------------------+------------+--------------+
o
o
o
+------------------+------------+--------------+
| フラグメント |フラグメント| 最終 |
| 不可部 |ヘッダ | フラグメント |
+------------------+------------+--------------+
各々のフラグメントパケットは、以下で構成される。
(1) このフラグメントパケットのみの長さを含めるよう (IPv6 ヘッダ自身の長さは除く) 変更された元の IPv6 ヘッダのペイロード長を持つ、元のパケットのフラグメント不可部と、44 に変更されたフラグメント不可部の最終ヘッダの次ヘッダフィールド
(2) フラグメントヘッダは以下を含む。
元のパケットのフラグメント可能部の最初のヘッダを識別する次ヘッダ値
元のパケットのフラグメント可能部の開始から相対の、8 オクテット単位のフラグメントのオフセットを含むフラグメントオフセット。一番目の (「最も左の」) フラグメントのフラグメントオフセットは 0 である。
フラグメントが最後のもの (「最も右」) ならば M フラグ値は 0 であり、さもなくば M フラグ値は 1 である。
識別子値は元のパケットに対して生成される。
(3) フラグメント自身
フラグメントの長さは、結果的にパケットの宛先へのパスの MTU 以内に適合するよう選択しなければならない。
宛先では、フラグメントパケットは以下の図のように、元のフラグメント化されていない形式に組み立てられる。
組み立てられた元のパケット
+------------------+----------------------//-----------------------+ | フラグメント | フラグメント | | 不可部 | 可能部 | +------------------+----------------------//-----------------------+
以下の規則が組み立てに適用される。
元のパケットは同じ送信元アドレス、宛先アドレス、フラグメント識別子を持つフラグメントパケットからのみ組み立てられる。
組み立てられるパケットのフラグメント不可部は、最初のフラグメントパケット (すなわち、フラグメントオフセットが 0 のパケット) のフラグメントヘッダまで (そのヘッダは含めない) の全てのヘッダに、以下の二つの変更を施したものから構成される。
フラグメント不可部の最終ヘッダの次ヘッダフィールドは、フラグメントヘッダの最初のヘッダの次ヘッダフィールドから取得する。
組み立てるパケットのペイロード長は、フラグメント不可部と長さと最終フラグメントのオフセットから算出する。例えば、組み立てられた元のパケットのペイロード長を算出する公式は、
PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last
PL.orig = 組み立てられるパケットのペイロード長。
PL.first = 最初のフラグメントパケットのペイロード長
FL.first =
最初のフラグメントパケットのフラグメントヘッダに続くフラグメントの長さ
FO.last =
最終フラグメントパケットのフラグメントヘッダのフラグメントオフセットフィールド
FL.last = 最終フラグメントパケットのフラグメントヘッダに続くフラグメントの長さ
組み立てられたパケットのフラグメント可能部は、各々のフラグメント中のフラグメントヘッダに続くフラグメントから形成される。各フラグメントの長さは、そのパケットのペイロード長から IPv6 ヘッダとフラグメント自身の間のヘッダの長さを引くことによって算出する。そのフラグメント可能部の相対位置はフラグメントオフセット値から算出する。
フラグメントヘッダは、最終的に組み立てられたパケットには提供されない。
フラグメント化されたパケットを組み立てている時、以下のエラー状態が発生するかもしれない。
もし、最初に到着したパケットのフラグメントの受信から 60 秒以内にパケットの組み立てを完成させるのに不十分なフラグメントを受信したら、そのパケットの組み立ては放棄し、そのパケットとして受信した全てのフラグメントを破棄しなければならない。もし最初のフラグメント (すなわち、0 のフラグメントオフセットを持つもの) を受信していたら、ICMP 時間超過 -- フラグメント組み立て時間超過メッセージを、そのフラグメントの送信元に送信すべきである。
フラグメントパケットのペイロード長フィールドから取得したフラグメントの長さが、8 オクテットの倍数でなく、フラグメントの M フラグが 1 ならば、そのフラグを破棄しなければならず、フラグメントパケットのペイロード長を指すコード 0 の ICMP パラメタ問題メッセージを、フラグメントの送信元に送信すべきである。
フラグメントの長さとオフセットにおいて、フラグメントから組み立てたパケットのペイロード長が 65535 オクテットを超える場合、そのフラグメントは破棄しなければならず、フラグメントパケットのフラグメントオフセットを指すコード 0 の ICMP パラメタ問題メッセージを、フラグメントの送信元に送信すべきである。
以下の状態は発生することは期待されないが、もし起きたらエラーとは見なさない。
同じ元のパケットの異なるフラグメントのフラグメントヘッダの前にある、ヘッダの数と内容は異なってもよい。各フラグメントパケットのフラグメントヘッダの前に存在するヘッダは全て、パケットが到着した時に組み立てのためにフラグメントをキューイングする前に処理される。オフセット 0 のフラグメントパケット中のヘッダだけが、組み立てられるパケット中に保持される。
同じ元のパケットの異なるフラグメントのフラグメントヘッダ中の次ヘッダ値は異なってもよい。オフセット 0 のフラグメントパケットの値のみが、組み立て時に使用される。
宛先オプションヘッダは、パケットの宛先ノードでのみチェックに必要なオプションの情報を運ぶために使用される。宛先オプションヘッダは、ヘッダの直前の 60 の次ヘッダ値によって識別され、以下の形式を持つ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8 ビットセレクタ。宛先オプションヘッダの直後のヘッダタイプを識別する。IPv4
プロトコルフィールド [RFC-1700 等]
と同じ値を使用する。
Hdr Ext Len
8 ビット符号無し整数。8
オクテット単位の宛先オプションヘッダの長さで、最初の 8 オクテットは含まない。
Options
可変長のフィールドで、宛先オプションヘッダが完了する長さは、8
オクテットの倍数長の整数である。セクション 4.2
で説明されているように、一つ以上の TLV で符号化されたオプションを含む。
このドキュメントで定義された唯一の宛先オプションヘッダは、セクション 4.2 に規定されている Pad1 と PadN である。
IPv6 パケット中のオプションの宛先情報を符号化する方法は、二つある。一つは宛先オプションヘッダ中のオプションとして、もう一つは別の拡張ヘッダとして符号化する方法である。フラグメントヘッダと認証ヘッダは、後者のアプローチの例である。どのアプローチを使用できるかは、オプションの情報を理解できない宛先ノードに望まれる動作に依存する。
IPv6 ヘッダか拡張ヘッダ中の次ヘッダフィールド中の値 59 は、次に続くヘッダが存在しないことを示す。もし IPv6 ヘッダのペイロード長が、59 を含む次ヘッダフィールドを持つヘッダの終わりを過ぎてオクテットが存在することを示すならば、そのオクテットを無視しなければならず、もしそのパケットを転送するならば、変更せずに渡さなければならない。
IPv6 は、インターネット内の全てのリンクが 1280 オクテット以上の MTU を持つことを必要とする。一つの断片で 1280 オクテットを運ぶことのできないリンク上では、IPv6 より下の層でリンク特定のフラグメントや組み立てを提供しなければならない。
設定可能な MTU (例えば PPP リンク [RFC-1661]) は、少なくとも 1280 オクテットの MTU を持つよう設定しなければならない。IPv6 層のフラグメント化を受けずに有り得るカプセル化 (例えばトンネル) に適応させるために、1500 オクテットかそれ以上の MTU で設定することが推奨される。
ノードは直接接続された各々のリンクから、リンクの MTU と同じ大きさのパケットを受諾できなければならない。
1280 オクテット以上の MTU を持つパスを検出し利用するために、IPv6 ノードはパス MTU 検出 [RFC-1981] を実装することが強く推奨される。しかし、最小限の IPv6 実装 (例えばブート ROM) は、自身で 1280 オクテット以上の大きさのパケットを送信しないよう単純に制限し、パス MTU 検出の実装を省略してもよい。
パスの MTU よりも大きいパケットを送信するために、ノードはパケットを送信元でフラグメント化し、宛先で組み立てさせるために IPv6 フラグメントヘッダを使用してもよい。しかし、そのようなフラグメントの使用は、測定されたパス MTU (すなわち 1280 オクテットに下がった) に合わせるためにバケットを調整できるアプリケーションでは、推奨されない。
ノードは、組み立て後に 1500 オクテット程の大きさになるフラグメント化されたパケットを受信できなければならない。ノードは、1500 オクテット以上に組み立てられるフラグメント化されたパケットを受諾することは許される。パスの MTU よりも大きいパケットを送信するのに IPv4 フラグメント化に依存している上位層プロトコルやアプリケーションは、宛先がより大きいサイズのパケットを組み立てる能力があるという保証が無ければ、1500 オクテット以上の大きさのパケットを送信すべきでない。
IPv4 宛先に送信される IPv6 パケット (すなわち IPv6 から IPv4 への変換を経験したパケット) に対する応答で、発行元の IPv6 ノードは、1280 以下の次ホップ MTU を通知する ICMP パケットサイズ超過メッセージを受信するかもしれない。その場合、IPv6 ノードは後続のパケットサイズを 1280 以下に減らす必要はないが、IPv6-IPv4 変換ルータが、IPv4 フラグメントで使用するための適切な識別子値を取得できるように、そのパケット中にフラグメントヘッダを含めなければならない。これは、ペイロードが 1232 オクテット (1280 から IPv6 ヘッダの 40 とフラグメントヘッダの 8 を引いた値) に、そして追加の拡張ヘッダが使用されていればさらに小さく減らされなければならないことを意味することに注意されたい。
IPv6 ヘッダの 20 ビットフローラベルフィールドは、例えば、デフォルトでないサービス品質や「リアルタイム」サービスといった、IPv6 ルータで特殊な操作を実行することを要求するパケットを判別するために、送信元で使用してもよい。この IPv6 の面は執筆時点ではまだ実験的であり、インターネットでのフローサポートの要件がより明白になるにつれて変更されている。フローラベルフィールドをサポートしていないホストやルータは、パケットを起動する時そのフィールドを 0 に設定し、パケットを転送する時そのフィールドを変更せず、パケットを受信した時そのフィールドを無視する必要がある。
付録 A は、フローラベルフィールドの現在意図されている意味と使用方法を説明している。
IPv6 ヘッダの 8 ビットトラフィッククラスフィールドは、送信元ノードと転送ルータが IPv6 パケットの異なるクラスや優先度を識別し区別するために使用できる。この規約が書かれた時点では、明示的なフロー設定を使用すること以外によって、IP パケットにおける "差別化されたサービス" の様々な形式を提供するために、IPv4 サービスタイプや優先度ビットを使用した数多くの実験が進行中である。IPv6 ヘッダのトラフィッククラスフィールドは、IPv6 でサポートする同様の機能を可能にすることを意図している。
こうした実験が最終的に、何の種類のトラフィッククラスへの分類が IP パケットで最も有効かについて、同意を導くことが期待される。IPv6 トラフィッククラスのビットに全て、あるいは幾つかのシンタクスとセマンティクスの詳細な定義や、実験かあるいは最終的に標準になるかについては、別のドキュメントで説明されている。
以下の一般要件が、トラフィッククラスフィールドに適用される。
チェックサムの算出に IP ヘッダからのアドレスを含むトランスポートや他の上位層プロトコルは、IPv6 上で使用するために 32 ビット IPv4 アドレスの代わりに 128 ビット IPv6 アドレスを含む修正をしなければならない。特に、以下の図は IPv6 用の TCP と UDP の「擬似ヘッダ」を示す。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upper-Layer Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ICMP の IPv6 バージョン [ICMPv6] は、チェックサム算出に上記の擬似ヘッダを含む。これは、チェックサムに擬似ヘッダを含めない ICMP の IPv4 バージョンからの変更点である。この変更の理由は、配送失敗や ICMP が依存する IPv6 ヘッダのこれらのフィールドの破壊から ICMP を保護することである。それは IPv4 とは異なり、インターネット層チェックサムではカバーされない。ICMP のための擬似ヘッダ中の次ヘッダフィールドは、値 58 を含み、ICMP の IPv6 バージョンを識別する。
IPv4 とは異なり、IPv6 ノードは最大パケット生存時間を強制する必要はない。それは、IPv4 「生存時間」フィールドが IPv6 では「ホップ制限」に名前が変更された理由である。実際、パケット生存時間を制限する要件に適合する IPv4 実装は、たとえ存在してもごくわずかである。そのため、これは実際は変更ではない。パケットの生存時間をインターネット層 (IPv4 か IPv6 のいずれか) に頼る如何なる上位プロトコルも、古いパケットを検出し破棄するメカニズムを自身で提供するためにアップグレードすべきである。
上位層データで利用可能な最大ペイロードサイズを算出する時、上位層プロトコルは、IPv4 ヘッダと比べてより大きい IPv6 ヘッダサイズを考慮に入れなければならない。例えば、IPv4 では TCP の MSS オプションは、最大パケットサイズ (デフォルト値かパス MTU 検出を通じて知る値) から 40 オクテット (IPv4 ヘッダの最小長で 20 オクテットと、TCP ヘッダの最小長で 20 オクテット) を引いて算出される。IPv6 上で TCP を使用する時、IPv6 ヘッダ (拡張ヘッダを持たない IPv6 ヘッダ) の最小長は IPv4 ヘッダの最小長よりより 20 オクテット長いので、最大パケットサイズから 60 を引いて MSS を算出しなければならない。
上位層プロトコルが、ルーティングヘッダを含む受信したパケットに応答して一つ以上のパケットを送信する時、もし受信した送信元アドレスとルーティングヘッダの完全性と信憑性が照合されないならば (例えば、受信したパケット中の認証ヘッダを通じて)、その応答パケットには、ルーティングヘッダを "逆にする" ことによって自動的に引き出されたルーティングヘッダを含んではならない。言い換えると、ルーティングヘッダを生じる受信したパケットの応答として、以下の種類のパケットだけが許される。
フローは、特定の送信元から特定(ユニキャストかマルチキャスト)の宛先に送信され、間に介すルータによる特別な操作を送信元が望むパケットのシーケンスである。特殊な操作の性質は、例えば資源予約プロトコル等の制御プロトコルによってや、例えばホップバイホップオプションといったフローのパケット自身内の情報によってルータに運ばれる。そうした制御プロトコルやオプションの詳細は、このドキュメントの適用外である。
フローに割り当てられないトラフィックだけでなく、送信元から宛先への複数の活性フローが存在してもよい。フローは、送信元アドレスと 0 でないフローラベルの組み合わせによってユニークに識別される。フローに属さないパケットは 0 のフローラベルを運ぶ。
フローラベルは、フローの送信元ノードによってフローに割り当てられる。新しいフローラベルは、1 から 16進数の FFFFF までの範囲で (擬似) ランダムに選択しなければならない。ランダム割当ての目的は、フローラベルフィールドの中で、ルータによるハッシュキーとして使用し、フローに割り当てられた状態を検索するのに適したビットのセットを作成することである。
同じフローに属する全てのパケットは、同じ送信元アドレス、宛先アドレス、フローラベルを持って送信しなければならない。もしそれらのパケットがホップバイホップオプションヘッダを含むならば、同じホップバイホップオプションヘッダの内容を持って (ホップバイホップオプションヘッダの次ヘッダフィールドは除く) 起動しなければならない。もしそれらのパケットがルーティングヘッダを含むならば、全てルーティングヘッダを含むルーティングヘッダまでの全ての拡張ヘッダを持って (ルーティングヘッダの次ヘッダフィールドは除く) 起動しなければならない。ルータや宛先では、これらの条件が満足されているかをチェックすることは許されるが必要ではない。もし違反が検出されたら、フローラベルフィールドの高次オクテット (すなわち IPv6 パケットの中のオフセット 1) を指すコード 0 の ICMP パラメタ問題メッセージによって、送信元に通知すべきである。
フローのパスに従って確立されたフロー制御状態の最大生存時間は、状態確立メカニズムの規約、例えばリソース予約プロトコルやフロー設定ホップバイホップオプション、の一部として規定しなければならない。送信元は、そのフローラベルを使用するために前に確立したフロー制御状態の最大生存時間内に、フローラベルを新しいフローで再使用してはならない。
ノードが (例えば「クラッシュ」の結果で) 停止し再開始する時、生存期間がまだ満了していないかもしれない、以前のフローで使用されたフローラベルを使用しないよう注意しなければならない。これは、キャッシュに渡って思い出せるよう固定記憶装置にフローラベルの利用を記録することによって、あるいは前に確立された可能性のあるフローの最大生存期間が満了するまで、如何なるフローラベルの使用も控えることによって達成してもよい。ノードをリブートする最小時間を知っているならば、フローラベルの割当てを開始する前に必要な待ち時間から、その時間を差し引くことができる。
全ての、あるいは大半のパケットがフローに属する、すなわち 0 でないフローラベルを運ぶ要件はない。この観点は、プロトコル設計者や実装者に他を想定しないことを思い出させるために、ここに記述される。例えば、大半のパケットがフローに属す場合に限りパフォーマンスが適するルータを設計することや、フローに属するパケットにのみ作用するヘッダ圧縮を設計することは賢くない。
この付録は、セクション 4.2 で規定されているホップバイホップオプションヘッダや宛先オプションヘッダで使用される新しいオプションを設計する時のフィールドの構成方法について、幾つかのアドバイスを提供する。これらの指針は、以下の仮定に基づいている。
これらの想定は、オプションのフィールドを配置するのに次のアプローチを提案する: フィールドを最も小さいものから最も大きいものへ順番付け、内部のパディングは付けず、最も大きいフィールドの調整要件 (8 オクテットの最大調整まで) に基づいて、オプション全体の調整要件を引き出す。このアプローチは、以下の例で図示される。
例 1
もしオプション X が二つのデータフィールドを必要とし、一つが
8 オクテット長で、もう一つが 4 オクテット長ならば、以下のように配置される。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8-octet field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
その調整要件は 8n+2 であり、8 オクテットフィールドが、囲むヘッダの開始からの 8 の倍数オフセットで始まることを保証する。この一つのオプションを含む完全なホップバイホップか宛先オプションヘッダは、以下のように見えるだろう。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
例 2
もし、オプション Y が三つのデータフィールドを必要とし、一つが
4 オクテット長で、一つが 2 オクテット長で、一つが 1 オクテット長ならば、以下のように配置される。
+-+-+-+-+-+-+-+-+
| Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-octet field | 2-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
その調整要件は 4n+3 であり、4 オクテットフィールドが、囲むヘッダの開始からの 4 の倍数オフセットで始まることを保証する。この一つのオプションを含む完全なホップバイホップか宛先オプションヘッダは、以下のように見えるだろう。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
例 3
例 1 と 2 のオプション X と Y の両方を含むホップバイホップか宛先オプションヘッダは、最初にどのオプションが現れるかにより、以下の二つの形式の一つを持つ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=4 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 のセキュリティの特徴は、インターネットプロトコルのセキュリティ体系 [RFC-2401] で規定される。
作者は、IPng ワーキンググループ、End-to-End プロトコル研究グループ、大規模なインターネット社会のメンバの多くの有効な提案に対し、多大に感謝する。
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 527 8213
Fax: +1 408 527 8254
EMail: deering@cisco.com
Robert M. Hinden
Nokia
232 Java Drive
Sunnyvale, CA 94089
USA
Phone: +1 408 990-2004
Fax: +1 408 743-5677
EMail: hinden@iprg.nokia.com
[RFC-2401]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[RFC-1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
このメモは、以下の点が RFC-1883 から変更されている。番号は、変更が行われたインターネットドラフトのバージョンを示している。
02) 巨大データグラムと巨大ペイロードオプションへの参照を全て削除 (別のドキュメントに移動)。
02) フローラベルの説明をセクション 6 から (新しい) 付録 A に移動。
02) 付録 A のフローラベルの説明において、フローラベルフィールドのサイズが 24 ビットが 20 ビットに減少したのに伴い、最大フローラベルの値を FFFFFF から FFFFF に修正。
02) 以前の付録 A を付録 B に番号振り替え (文字振り替え ?)。
02) セキュリティの考慮セクションを、この規約と IPsec の規約との間の依存ループを避けるために、言葉を変更。
02) R. Hinden の E-Mail アドレスと会社所属を更新。
01) セクション 3 で、"Class" という名前のフィールドを "Traffic Class" に変更し、サイズを 4 から 8 ビットに増加。フローラベルフィールドのサイズを 24 から 20 ビットに減少。
01) セクション 4.1 で、このメモの 00 バージョンで誤ってひっくり返っていた認証ヘッダと ESP ヘッダの順序を復元。
01) セクション 4.4 で、タイプ 0 のルーティングヘッダから、Strict/Loose Bit Map フィールドと厳密ルーティング機能を削除し、タイプ 0 ルーティングヘッダで運んでもよいアドレス数の制限 (strict/loose bit map のサイズのために、23 個のアドレスに限定された) を除去)。
01) セクション 5 で、最小の IPv6 MTU を 576 から 1280 オクテットに変更し、設定可能な MTU (例えば PPP 回線) を持つ回線は、少なくとも 1500 オクテットの MTU を持つよう設定することの推奨を追加。
01) セクション 5 で、ノードが宛先が組み立てられるバッファサイズを知らずに、1500 オクテット以上に再組み立てられるフラグメント化されたパケットを送信してはならないという要件を削除し、上位層プロトコルかアプリケーションがそうすべきであるという推奨に置き換え。
01) IPv4 パス MTU 検出規約 (RFC-1191) への参照を、IPv6 パス MTU 検出規約 (RFC-1981) への参照に置き換え、パス MTU 検出に関連するセクション 5 の最後の注記を、詳細は現在 RFC-1981 によってカバーされているので削除。
01) セクション 6 で、"便宜的" なフロー設定の規定を削除し、便宜的に確立されたフロー状態の 6 秒の生存時間への参照を全て削除。
01) セクション 7 で、トラフィッククラスフィールドの内部構造と意味の暫定的な説明を削除し、その説明は別のドキュメントで提供される旨を記述。
00) セクション 4 で、"未知の次ヘッダタイプに遭遇" を示す ICMP パラメタ問題メッセージの Code 値を修正。(2 から 1 に変更)
00) セクション 3 のペイロード長フィールドとセクション 4.3 の巨大ペイロード長フィールドの説明で、拡張ヘッダがペイロード長の数に含まれることを明記。
00) セクション 4.1 で、認証ヘッダと ESP ヘッダの順序を交換。(注記: これは誤りであり、この変更はバージョン 01 で取り消された)
00) セクション 4.2 で、オプションはオプションタイプの低次 5 ビットではなく、オプションタイプの全 8 ビットによって識別されることを明記。さらに、同じオプションタイプの番号空間が、ホップバイホップオプションと宛先オプションヘッダで使用される旨を記述。
00) セクション 4.4 で、ルーティングヘッダを処理するノードは、大きすぎて次ホップの回線に合わないパケットの応答として、ICMP パケットサイズ超過メッセージを送信しなければならない (フラグメント化を実行せずに) ことを要求する文を追加。
00) IPv6 優先度フィールドの名前を "クラス" に変更し、セクション 7 の優先度の説明をクラスフィールドの説明に置き換え。さらに、セクション 6 で規定されているように、同じフローの全てのパケットに残さなければならないフィールドのセットから、このフィールドを除外。
00) セクション 8.1 の擬似ヘッダで、"ペイロード長" フィールドの名前が "上位層パケット長" に変更された。それ自身の長さ情報 (非巨大 UDP と同様) を運ぶプロトコルの場合、擬似ヘッダで使用されるのは、IP 層から引き出された長さではなく、上位層から引き出された長さであることを明確化した。
00) セクション 8.4 を追加し、もし受信したルーティングヘッダが認証されていなければ、上位層プロトコルはルーティングヘッダを運ぶ受信パケットに対する応答時に、その応答ヘッダにルーティングヘッダの逆を含めてはならないことを規定。
00) 幾つかのタイポと文法ミスを修正。
00) 作者のコンタクト情報を更新。
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
(このドキュメントと翻訳は全体または一部を、如何なる種類の制限無しで、上記のコピーライト記述を提供し、このパラグラフを全てのコピーや派生作業に含めて、他者へコピーや供給してもよく、コメントしたり、別途説明したり、実装を援助するといった派生作業を準備、コピー、出版、配布してもよい。しかし、このドキュメント自身は、インターネット標準プロセスで定義された手続きに従わなければならず、インターネット標準を開発する目的で必要な場合や、英語以外の言語に翻訳するために必要な場合を除いて、コピーライト記述やインターネット社会、他のインターネット組織への参照等を、如何なる方法でも修正してはならない。
上記で認められた制限された許可は永久的であり、インターネット社会や継承者や割当て者によって無効にされることはないだろう。)
This document and the information contained herein
is provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.