5.3. Tunnel Header Field Descriptions (トンネルヘッダフィールドの説明)
5.3. Tunnel Header Field Descriptions (トンネルヘッダフィールドの説明)
Inner Header (IH, 内部ヘッダ): 内部ヘッダは, 送信元ホストから発信されたデータグラム上のヘッダです。送信元と宛先 IP アドレスは EID です [RFC0791] [RFC2460]。
Outer Header (OH, 外部ヘッダ): 外部ヘッダは, ITR によって前置される新しいヘッダです。アドレスフィールドには, 入口ルータの EID-to-RLOC キャッシュから取得された RLOC が含まれます。IP プロトコル番号は [RFC0768] の「UDP (17)」です。Flags フィールドの Don't Fragment (DF) ビットの設定は, セクション 5.4.1 と 5.4.2 にリストされているルールに従います。
UDP Header (UDP ヘッダ): UDP ヘッダは, パケットをカプセル化するときに ITR によって選択された送信元ポートを含みます。内部ヘッダの 5 タプルに基づいて送信元ポートを選択するために使用されるハッシュアルゴリズムの詳細については, セクション 6.5 を参照してください。宛先ポートは, IANA によって割り当てられたウェルノウンポート値 4341 に設定しなければなりません。
UDP Checksum (UDP Checksum フィールド): ITR は, IPv4 [RFC0768] または IPv6 カプセル化 [UDP-TUNNELS] [UDP-ZERO] の転送時に, UDP Checksum フィールドをゼロとして送信すべきです。ETR が UDP チェックサムがゼロのパケットを受信した場合, ETR はカプセル化解除のためにそのパケットを受け入れなければなりません。ITR が UDP チェックサムに非ゼロ値を転送する場合, そのフィールドに正しく計算された値を送信しなければなりません。ETR が UDP チェックサムが非ゼロのパケットを受信した場合, チェックサム値を検証することを選択できます。このような検証を実行することを選択し, 検証が失敗した場合, パケットを静かにドロップしなければなりません。ETR が検証を実行しないことを選択するか, 検証が成功した場合, カプセル化解除のためにパケットを受け入れなければなりません。LISP を含むすべてのトンネリングプロトコルの UDP チェックサム処理は, IETF 内で活発に議論されています。議論が結論に達したとき, より広範な議論の結果と一致するように LISP に必要な変更が加えられます。
UDP Length (UDP Length フィールド): IPv4 カプセル化パケットの場合, UDP Length フィールドは, 内部 IPv4 Total Length に UDP と LISP ヘッダ長の合計を加えたものに設定されます。IPv6 カプセル化パケットの場合, UDP Length フィールドは, 内部 IPv6 Payload Length, IPv6 ヘッダサイズ (40 オクテット), および UDP と LISP ヘッダサイズの合計です。
N: N ビットは nonce-present ビットです。このビットが 1 に設定されている場合, LISP ヘッダの最初の 32 ビットの下位 24 ビットに Nonce が含まれます。詳細についてはセクション 6.3.1 を参照してください。N ビットと V ビットを同じパケットで両方設定してはなりません。両方が設定されている場合, カプセル化解除 ETR は Nonce/Map-Version フィールドに Nonce 値が存在するものとして扱わなければなりません。
L: L ビットは Locator-Status-Bits フィールドの有効化ビットです。このビットが 1 に設定されている場合, LISP ヘッダの 2 番目の 32 ビットの Locator-Status-Bits が使用されています。
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: E ビットは echo-nonce-request ビットです。N ビットが 0 の場合, このビットは無視されなければならず, 意味を持ちません。N ビットが 1 でこのビットが 1 の場合, ITR は, ITR が ETR でもあるときに, LISP カプセル化パケットが返されるときに Nonce フィールドの nonce 値をエコーバックすることを要求します。詳細についてはセクション 6.3.1 を参照してください。
V: V ビットは Map-Version present ビットです。このビットが 1 に設定されている場合, N ビットは 0 でなければなりません。詳細についてはセクション 6.6.3 を参照してください。このビットは, この例で LISP ヘッダが次のようにエンコードされることを示します:
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: I ビットは Instance ID ビットです。詳細についてはセクション 5.5 を参照してください。このビットが 1 に設定されている場合, Locator-Status-Bits フィールドは 8 ビットに縮小され, 上位 24 ビットが Instance ID として使用されます。L ビットが 0 の場合, 下位 8 ビットはゼロとして送信され, 受信時に無視されます。LISP ヘッダ形式は次のとおりです:
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: flags フィールドは 3 ビットで, 将来のフラグ用に予約されています。送信時にゼロに設定しなければならず, 受信時に無視しなければなりません。
LISP Nonce: LISP Nonce フィールドは 24 ビット値で, N ビットが 1 に設定されているときに ITR によってランダムに生成されます。Nonce 生成アルゴリズムは実装の詳細ですが, 異なる宛先に送信するときに異なる nonce を生成することが要求されます。ただし, 同じ宛先に対しては一定期間同じ nonce を使用できます。E ビットが 1 に設定されている場合, nonce はパケットが返されるときにピアによって nonce 値をエコーバックすることを要求するためにも使用されます。E ビットがクリアされているが N ビットが設定されている場合, リモート ITR は以前に要求された echo-nonce をエコーバックするか, ランダムな nonce を提供します。詳細についてはセクション 6.3.1 を参照してください。
LISP Locator-Status-Bits (LSB): L ビットも設定されている場合, LISP ヘッダの Locator-Status-Bits フィールドは ITR によって設定され, 送信元サイト内の Locator の up/down ステータスを ETR に示します。Map-Reply の各 RLOC には, 0 から n-1 の序数値が割り当てられます (マッピングエントリに n 個の RLOCs があります)。Locator-Status-Bits は, フィールドの最下位ビットから 0 から n-1 として番号付けされます。I ビットが 0 の場合, フィールドは 32 ビットで, I ビットが 1 の場合, フィールドは 8 ビットです。Locator-Status-Bit が 1 に設定されている場合, ITR は, そのビット序数に関連付けられた RLOC が up 状態にあることを ETR に示します。ITR が同じサイトの ETR のステータスをどのように決定するかの詳細については, セクション 6.3 を参照してください。サイトに複数の EID-Prefix があり, それによって複数のマッピング (それぞれ異なる Locator-Set を持つ可能性がある) が生成される場合, カプセル化パケットの Locator-Status-Bits 設定は, 内部ヘッダの送信元 EID アドレスと一致する EID-Prefix のマッピングを反映しなければなりません。エニーキャスト Locator の LSB が 1 に設定されている場合, そのアドレスを持つ少なくとも 1 つの RLOC が存在し, ETR は up と見なされます。
ITR/PITR カプセル化を実行する場合:
o 外部ヘッダの Time to Live フィールド (IPv6 の場合は Hop Limit フィールド) は, 内部ヘッダの Time to Live フィールドからコピーされるべきです。
o 外部ヘッダの Type of Service フィールド (IPv6 の場合は Traffic Class フィールド) は, 内部ヘッダの Type of Service フィールドからコピーされるべきです (1 つの例外があります, 以下を参照)。
ETR/PETR カプセル化解除を実行する場合:
o 外部ヘッダの Time to Live 値が内部ヘッダの Time to Live 値よりも小さい場合, 内部ヘッダの Time to Live フィールド (IPv6 の場合は Hop Limit フィールド) は, 外部ヘッダの Time to Live フィールドからコピーされるべきです。このチェックを実行しないと, カプセル化/カプセル化解除ループで内部ヘッダの Time to Live が増加する可能性があります。パケットが ITR または PITR に到達し, 宛先が LISP サイトである場合, 初期カプセル化でもこのチェックが実行されます。
o 内部ヘッダの Type of Service フィールド (IPv6 の場合は Traffic Class フィールド) は, 外部ヘッダの Type of Service フィールドからコピーされるべきです (1 つの例外があります, 以下を参照)。
ETR/PETR が ITR/PITR でもあり, カプセル化解除後に再カプセル化することを選択した場合, 正味の効果は, 新しい外部ヘッダが古い外部ヘッダと同じ Time to Live マイナス 1 を運ぶことになることに注意してください。
Time to Live (TTL) をコピーする目的は 2 つあります: 第一に, ホストがパケットを伝送することを意図した距離を保持すること, 第二に, より重要なことに, 誤った設定により直列トンネルループが存在する場合にループするパケットを抑制することです。traceroute パケットの TTL 例外処理についてはセクション 9.3 を参照してください。
Explicit Congestion Notification (ECN) フィールドは, IPv4 Type of Service フィールドと IPv6 Traffic Class フィールドのビット 6 と 7 を占めます [RFC3168]。輻輳指示の損失を避けるため, ECN フィールドには特別な処理が必要です [RFC3168]。ITR カプセル化は, 2 ビット ECN フィールドを内部ヘッダから外部ヘッダにコピーしなければなりません。再カプセル化は, 2 ビット ECN フィールドを剥がされた外部ヘッダから新しい外部ヘッダにコピーしなければなりません。ECN フィールドに輻輳指示コードポイント (値 11, つまり Congestion Experienced (CE) コードポイント) が含まれている場合, ETR カプセル化解除は, 2 ビット ECN フィールドを剥がされた外部ヘッダから, ETR の外で転送に使用される残存内部ヘッダにコピーしなければなりません。これらの要件は, ECN 対応パケットが LISP トンネルを通過し, トンネルエンドポイント間の輻輳により CE 指示でマークされた場合に CE 指示を保持します。