3.15. Configuration Payload (設定ペイロード)

Configuration payload は本書で CP と表し, IKE ピア間で設定情報を交換するために用いられる. IRAC が IRAS に内部 IP アドレスを要求し, IRAC が LAN に直接接続している場合に Dynamic Host Configuration Protocol (DHCP) で取得し得る種類のその他の情報を交換するための交換である.

Configuration payload は次のように定義される:

                    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C| RESERVED    |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CFG Type    |                    RESERVED                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Configuration Attributes                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

図 22: Configuration payload 形式

Configuration payload のペイロード種別は 47 である.

CFG Type (1 オクテット) - Configuration Attributes が表す交換の種類. 下表の値は RFC 4306 公開日時点までが最新である. その後追加された値がある可能性がある. 読者は [IKEV2IANA] を参照すべきである.

CFG Type	値
CFG_REQUEST	1
CFG_REPLY	2
CFG_SET	3
CFG_ACK	4

RESERVED (3 オクテット) - 0 を送らなければならず, 受信時には無視しなければならない.
Configuration Attributes (可変長) - Configuration payload 専用の type-length-value (TLV) 構造であり, 下で定義する. 本ペイロードに含まれる Configuration Attribute は 0 個以上でよい.

3.15.1. Configuration Attributes (設定属性)

                    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|         Attribute Type      |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Value                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

図 23: Configuration attribute 形式

Reserved (1 ビット) - 本ビットは 0 でなければならず, 受信時には無視しなければならない.
Attribute Type (15 ビット) - 各 Configuration Attribute Type の一意の識別子.
Length (2 オクテット, 符号なし整数) - 値のオクテット長.
Value (0 以上のオクテット) - 本 Configuration Attribute の可変長値. 以下に属性種別を列挙する.

下表の値は RFC 4306 公開日時点までが最新である (INTERNAL_ADDRESS_EXPIRY と INTERNAL_IP6_NBNS は RFC 5996 で削除済み). その後追加された値がある可能性がある. 読者は [IKEV2IANA] を参照すべきである.

Attribute Type	値	複数値	長さ
INTERNAL_IP4_ADDRESS	1	YES*	0 または 4 オクテット
INTERNAL_IP4_NETMASK	2	NO	0 または 4 オクテット
INTERNAL_IP4_DNS	3	YES	0 または 4 オクテット
INTERNAL_IP4_NBNS	4	YES	0 または 4 オクテット
INTERNAL_IP4_DHCP	6	YES	0 または 4 オクテット
APPLICATION_VERSION	7	NO	0 以上
INTERNAL_IP6_ADDRESS	8	YES*	0 または 17 オクテット
INTERNAL_IP6_DNS	10	YES	0 または 16 オクテット
INTERNAL_IP6_DHCP	12	YES	0 または 16 オクテット
INTERNAL_IP4_SUBNET	13	YES	0 または 8 オクテット
SUPPORTED_ATTRIBUTES	14	NO	2 の倍数
INTERNAL_IP6_SUBNET	15	YES	17 オクテット

* これらの属性は, 複数の値が要求された場合にのみ, 返答で複数値になり得る.

INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - 内部ネットワーク上のアドレスであり, レッドノードアドレスやプライベートアドレスとも呼ばれ, インターネット上のプライベートアドレスであってもよい. 要求メッセージでは, 指定されたアドレスは要求アドレスである (特定アドレスを要求しない場合は長さ 0). 特定アドレスが要求された場合, 以前にそのアドレスで接続があったことを示し, 要求者は再利用を望んでいる可能性が高い. IPv6 では要求者は使用したい下位アドレスオクテットを提供してよい. 複数の内部アドレス属性を要求することで複数の内部アドレスを要求してよい. 応答者は要求された数までしか送ってはならない. INTERNAL_IP6_ADDRESS は 2 フィールドから成る: 第 1 が 16 オクテットの IPv6 アドレス, 第 2 が [ADDRIPV6] で定義される 1 オクテットのプレフィックス長である. 要求されたアドレスは, 当該 IKE SA (または再鍵の後継) が有効な限り有効である. 詳細は第 3.15.3 節.
INTERNAL_IP4_NETMASK - 内部ネットワークのネットマスク. 要求および応答メッセージではネットマスクは 1 つのみ許され (例: 255.255.255.0), INTERNAL_IP4_ADDRESS 属性とのみ併用しなければならない. CFG_REPLY における INTERNAL_IP4_NETMASK は, 同じ情報を含む INTERNAL_IP4_SUBNET (「これらのアドレスへのトラフィックは自分経由で送れ」) とほぼ同義だが, リンク境界も含意する. 例えばクライアントは自アドレスとネットマスクからリンクのブロードキャストアドレスを計算できる. 空の INTERNAL_IP4_NETMASK 属性を CFG_REQUEST に含めてこの情報を要求してよい (ゲートウェイは要求がなくても送ってよい). CFG_REQUEST で本属性に非空の値を入れる意味はなく, 含めてはならない.
INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - ネットワーク内 DNS サーバのアドレスを指定する. 複数の DNS サーバを要求してよい. 応答者は 0 個以上の DNS サーバ属性で応答してよい.
INTERNAL_IP4_NBNS - ネットワーク内 NetBios Name Server (WINS) のアドレスを指定する. 複数の NBNS サーバを要求してよい. 応答者は 0 個以上の NBNS サーバ属性で応答してよい.
INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - ホストに, 内部 DHCP 要求をすべて属性内のアドレスへ送るよう指示する. 複数の DHCP サーバを要求してよい. 応答者は 0 個以上の DHCP サーバ属性で応答してよい.
APPLICATION_VERSION - IPsec ホストのバージョンまたはアプリケーション情報. 印字可能 ASCII 文字列であり, null 終端ではない.
INTERNAL_IP4_SUBNET - 当該エッジデバイスが保護する保護サブネット. 本属性は 2 フィールドから成る: 第 1 が IP アドレス, 第 2 がネットマスク. 複数のサブネットを要求してよい. 応答者は 0 個以上のサブネット属性で応答してよい. 詳細は第 3.15.2 節.
SUPPORTED_ATTRIBUTES - Request 内で用いる場合, 本属性は長さ 0 でなければならず, 応答者にサポートするすべての属性を返すよう問い合わせる. 応答には, 各 2 オクテットの属性識別子の集合を含む属性が含まれる. 長さを 2 (オクテット) で割った値が応答に含まれるサポート属性の個数である.
INTERNAL_IP6_SUBNET - 当該エッジデバイスが保護する保護サブネット. 本属性は 2 フィールドから成る: 第 1 が 16 オクテット IPv6 アドレス, 第 2 が [ADDRIPV6] で定義される 1 オクテットのプレフィックス長. 複数のサブネットを要求してよい. 応答者は 0 個以上のサブネット属性で応答してよい. 詳細は第 3.15.2 節.

本文書は, 実装が応答で実際に何を送るかをどう決めるかについて推奨を行わない. すなわち, 要求 IRAC にどの DNS サーバを返すべきかを IRAS が決める具体的手法は推奨しない.

CFG_REQUEST と CFG_REPLY の組は, IKE エンドポイントがピアから情報を要求することを許す. CFG_REQUEST Configuration payload 内の属性が長さ非 0 なら, その属性への提案とみなされる. CFG_REPLY Configuration payload はその値または新しい値を返してよい. 新しい属性を追加し, 要求された一部を含めないこともしてよい. 認識できないまたはサポートされない属性は要求と応答の両方で無視しなければならない.

CFG_SET と CFG_ACK の組は, IKE エンドポイントがピアへ設定データをプッシュすることを許す. この場合 CFG_SET Configuration payload には, 発起者がピアに変更させたい属性が含まれる. 応答者がいずれかの設定データを受け入れた場合は Configuration payload を返さなければならず, その中には応答者が受け入れた属性を長さ 0 のデータで含めなければならない. 受け入れなかった属性は CFG_ACK Configuration payload にあってはならない. 属性を一つも受け入れなかった場合, 応答者は空の CFG_ACK payload を返すか, CFG_ACK payload のない応答メッセージを返さなければならない. CFG_SET/CFG_ACK 交換の定義済み用途は現状ないが, Vendor ID に基づく拡張と組み合わせて用いられてよい. 本仕様の実装は CFG_SET payload を無視してよい.

3.15.2. INTERNAL_IP4_SUBNET と INTERNAL_IP6_SUBNET の意味

INTERNAL_IP4/6_SUBNET 属性は, 属性を通知するゲートウェイ経由で到達でき, 1 つ以上の別 SA を要する追加サブネットを示し得る. INTERNAL_IP4/6_SUBNET 属性は, どのトラフィックをゲートウェイ経由にすべきかというゲートウェイのポリシーも表し得る; クライアントは, 他のトラフィック (TSr で覆われるが INTERNAL_IP4/6_SUBNET にない) をゲートウェイ経由にするか宛先に直接送るかを選べる. したがって, INTERNAL_IP4/6_SUBNET 属性に列挙されたアドレスへのトラフィックは, 属性を通知するゲートウェイ経由で送るべきである. 当該アドレスを覆う Traffic Selector を持つ既存の子 SA がなければ, 新しい SA を作成する必要がある.

例えば 2 つのサブネット 198.51.100.0/26 と 192.0.2.0/24 があり, クライアントの要求が次を含む場合:

CP(CFG_REQUEST) =
  INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

有効な応答は次のようになり得る (TSr と INTERNAL_IP4_SUBNET が同じ情報を含む):

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
       (0, 0-65535, 192.0.2.0-192.0.2.255))

これらの場合 INTERNAL_IP4_SUBNET は実質的に有用な情報を運ばない.

別のあり得る応答は次のとおり:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

この応答は, クライアントはすべてのトラフィックをゲートウェイ経由で送ってよいが, ゲートウェイは INTERNAL_IP4_SUBNET に含まれないトラフィックをクライアントが宛先へ直接送っても (ゲートウェイを経由せずに) 問題ないことを意味する.

2 つのサブネットのトラフィックを別々の SA で運ぶポリシーがゲートウェイにある場合は, 次のような応答がクライアントに, 第 2 サブネットにアクセスするには別 SA が必要であることを示す:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

クライアントの TSr がアドレス空間の一部のみを含む場合も INTERNAL_IP4_SUBNET は有用である. 例えばクライアントが次を要求する場合:

CP(CFG_REQUEST) =
  INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

ゲートウェイの応答は次のようになり得る:

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
  INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

CFG_REQUEST における INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET の意味が不明確なため, CFG_REQUEST では信頼して用いられない.

3.15.3. IPv6 向け Configuration payload

IPv6 の Configuration payload は対応する IPv4 ペイロードに基づき, 「通常の IPv6 のやり方」には完全には従わない. 特に IPv6 ステートレス自動設定やルータ広告メッセージは用いず, 近隣探索も用いない. IKEv2 における IPv6 設定を論じる追加文書 [IPV6CONFIG] がある. 現時点では実験的文書だが, 実装経験が蓄積すれば本文書と同様の標準扱いになることが期待される.

クライアントは INTERNAL_IP6_ADDRESS Configuration payload で IPv6 アドレスを割り当てられ得る. 最小の交換の例:

CP(CFG_REQUEST) =
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

CP(CFG_REPLY) =
  INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

クライアントは CFG_REQUEST で空でない INTERNAL_IP6_ADDRESS 属性を送り, 特定アドレスまたはインタフェース識別子を要求してよい. ゲートウェイはまず指定アドレスが受け入れ可能か確認し, 可能ならそれを返す. アドレスが受け入れられない場合, ゲートウェイはインタフェース識別子を別のプレフィックスと組み合わせて使おうとする; それも失敗すれば別のインタフェース識別子を選ぶ.

INTERNAL_IP6_ADDRESS 属性にはプレフィックス長フィールドも含まれる. CFG_REPLY で用いる場合, IPv4 の INTERNAL_IP4_NETMASK 属性に対応する.

この IPv6 アドレス設定アプローチは比較的単純だが制限もある. IKEv2 で設定した IPsec トンネルは, IPv6 アドレス指定アーキテクチャの意味 [ADDRIPV6] で完全な「インタフェース」ではない. 特にリンクローカルアドレスを必ずしも持たず, それを前提とするプロトコル (例: [MLDV2]) の利用を複雑にし得る.

3.15.4. アドレス割当ての失敗

応答者が Configuration payload の処理中に発起者へ IP アドレスを割り当てようとしてエラーに遭遇した場合, INTERNAL_ADDRESS_FAILURE 通知で応答する. この失敗により初期子 SA を作成できなくても IKE SA は作成される. このエラーが IKE_AUTH 交換内で発生した場合, 子 SA は作成されない. ただしより複雑なエラーケースもある.

応答者が Configuration payload をまったくサポートしない場合, すべての Configuration payload を単に無視してよい. この種の実装は INTERNAL_ADDRESS_FAILURE 通知を決して送らない.

発起者が IP アドレス割当てを必須とする場合, CFG_REPLY のない応答をエラーとみなす.

発起者は, 応答者が Configuration payload をサポートしていてもサポートしない種類のアドレス (IPv4 または IPv6) を要求し得る. この場合応答者はサポートしないアドレス種別を無視し, 要求の残りを通常どおり処理する.

発起者が応答者がサポートする種類のアドレスを複数要求し, 一部 (すべてではない) が失敗した場合, 応答者は成功したアドレスのみを返す. アドレスを一つも割り当てられない場合にのみ INTERNAL_ADDRESS_FAILURE を送る.

発起者がポリシーで必要とする IP アドレスを受け取らない場合, 適切なタイムアウト後に別の INFORMATIONAL 交換で Configuration payload を再試行するために IKE SA を維持してよいし, 別の INFORMATIONAL 交換で Delete payload を送って IKE SA を解体し, 一定のタイムアウト後に最初から IKE SA を再試行してよい. そのタイムアウトは短すぎてはならない (特に IKE SA を最初から開始する場合). これらのエラーはすぐには解消できない可能性があるため, タイムアウトは数分程度が妥当である. 例えば応答者のアドレスプール枯渇は, 他クライアントが切断してプールにエントリが戻るか, 応答者がより大きいアドレスプールに再設定されるまで解消されない可能性が高い.