4. HTTP上のIPトンネリング

HTTP上のIPトンネルのネゴシエーションを可能にするために、本書は "connect-ip" HTTPアップグレードトークンを定義する。結果として得られるIPトンネルは、セクション6 で定義された形式のHTTPデータグラムでカプセルプロトコル（[HTTP-DGRAM] のセクション3.2を参照）を使用する。

単一のHTTPストリームに関連付けられたIPトンネルを開始するために、クライアントは "connect-ip" アップグレードトークンを含む要求を発行する。

IPプロキシ要求を送信する際、クライアントはURIテンプレート展開を実行して、要求のパスとクエリを決定しなければならない（SHALL）。セクション3 を参照。

カプセルプロトコルの定義（[HTTP-DGRAM] のセクション3.2を参照）により、IPプロキシ要求はいかなるメッセージコンテンツも運ばない。同様に、成功したIPプロキシ応答もいかなるメッセージコンテンツも運ばない。

HTTP上のIPプロキシは、機密性、完全性、および認証を提供するために、TLSまたはQUIC暗号化、またはその他の同等の暗号化プロトコル上で運用されなければならない（MUST）。

4.1. IPプロキシの処理

IPプロキシ要求を受信すると：

受信者が別のHTTPサーバーを使用するように構成されている場合、要求を他のHTTPサーバーに転送することで仲介者として機能する。要求エンコーディングはバージョンによって異なるため（下記参照）、そのような仲介者が受信に使用したものとは異なるバージョンのHTTPを使用して転送する場合、要求を再エンコードする必要がある場合があることに注意すること。
そうでない場合、受信者はIPプロキシとして機能する。IPプロキシは、IPプロキシ要求を拒否することを選択できる。そうでない場合、要求ヘッダーから再構築したURIからオプションの "target" および "ipproto" 変数を抽出し、それらのパーセントエンコーディングをデコードし、IPトンネルを確立する。

IPプロキシは、デコードされた "target" および "ipproto" 変数がセクション4.6 の要件を満たしているかどうかを検証しなければならない（MUST）。満たしていない場合、IPプロキシは要求を不正な形式として扱わなければならない（MUST）。[HTTP/2] のセクション8.1.1 および [HTTP/3] のセクション4.1.2 を参照。"target" 変数がDNS名である場合、IPプロキシはHTTP要求に応答する前にDNS解決（Aおよび/またはAAAAレコードを介して対応するIPv4および/またはIPv6アドレスを取得するため）を実行しなければならない（MUST）。このプロセス中にエラーが発生した場合、IPプロキシは要求を拒否しなければならず（MUST）、適切なProxy-Statusヘッダーフィールド [PROXY-STATUS] を使用して詳細を送信すべきである（SHOULD）。たとえば、DNS解決がエラーを返した場合、プロキシは [PROXY-STATUS] のセクション2.3.2 の dns_error プロキシエラータイプを使用できる。

IP転送トンネルの有効期間は、IPプロキシ要求ストリームに紐付けられる。IPプロキシは、要求ストリームが開いている間、IP転送トンネルに関連付けられたすべてのIPアドレスとルート割り当てを維持しなければならない（MUST）。IPプロキシは、一定期間の非アクティブ状態のためにトンネルを取り壊すことを選択してもよいが（MAY）、その際、要求ストリームを閉じなければならない（MUST）。

成功したIPプロキシ応答（セクション4.3 および 4.5 で定義）は、IPプロキシがIPトンネルを確立し、IPペイロードをプロキシする意思があることを示す。成功したIPプロキシ応答以外の応答は、要求が失敗したことを示す。したがって、クライアントは要求を中止しなければならない（MUST）。

成功したIPプロキシ応答とともに、IPプロキシはカプセルを送信して、クライアントにアドレスを割り当て、ルートを広告することができる（セクション4.7）。クライアントはまた、ネットワーク間ルーティングのために、IPプロキシにアドレスを割り当て、ルートを広告することもできる。

4.2. HTTP/1.1 要求

HTTP/1.1 [HTTP/1.1] を使用する場合、IPプロキシ要求は以下の要件を満たす：

メソッドは "GET" でなければならない（SHALL）。
要求には、IPプロキシのホストとオプションのポートを含む単一のHostヘッダーフィールドを含めなければならない（SHALL）。
要求には、値が "Upgrade" のConnectionヘッダーフィールドを含めなければならない（SHALL）（[HTTP] のセクション7.6.1 に従い、この要件は大文字と小文字を区別しないことに注意）。
要求には、値が "connect-ip" のUpgradeヘッダーフィールドを含めなければならない（SHALL）。

これらの制限に準拠しないIPプロキシ要求は不正な形式である。そのような不正な形式の要求の受信者は、エラーで応答しなければならず（MUST）、400 (Bad Request) ステータスコードを使用すべきである（SHOULD）。

たとえば、クライアントがURIテンプレート "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" で構成されており、ターゲットまたはプロトコルの制限なしにIP転送トンネルを開きたい場合、以下の要求を送信できる：

GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

図2: HTTP/1.1 要求の例

4.3. HTTP/1.1 応答

サーバーは、以下の要件で応答することにより、成功したIPプロキシ応答を示す：

応答のHTTPステータスコードは 101 (Switching Protocols) でなければならない（SHALL）。
応答には、値が "Upgrade" のConnectionヘッダーフィールドを含めなければならない（SHALL）（[HTTP] のセクション7.6.1 に従い、この要件は大文字と小文字を区別しないことに注意）。
応答には、値が "connect-ip" の単一のUpgradeヘッダーフィールドを含めなければならない（SHALL）。
応答は、カプセルプロトコルを開始するHTTP応答の要件を満たさなければならない（SHALL）。[HTTP-DGRAM] のセクション3.2 を参照。

これらの要件のいずれかが満たされない場合、クライアントはこのプロキシ試行が失敗したとして扱い、接続を閉じなければならない（MUST）。

たとえば、サーバーは次のように応答できる：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

図3: HTTP/1.1 応答の例

4.4. HTTP/2 および HTTP/3 要求

HTTP/2 [HTTP/2] または HTTP/3 [HTTP/3] を使用する場合、IPプロキシ要求はHTTP Extended CONNECTを使用する。これには、[EXT-CONNECT2] および [EXT-CONNECT3] で指定されているように、サーバーがHTTP Settingを送信し、要求が以下の要件を持つHTTP疑似ヘッダーフィールドを使用することが必要である：

:method 疑似ヘッダーフィールドは "CONNECT" でなければならない（SHALL）。
:protocol 疑似ヘッダーフィールドは "connect-ip" でなければならない（SHALL）。
:authority 疑似ヘッダーフィールドには、IPプロキシのオーソリティを含めなければならない（SHALL）。
:path および :scheme 疑似ヘッダーフィールドは空であってはならない（SHALL NOT）。それらの値には、URIテンプレート展開プロセスが完了した後のURIテンプレートからのスキームとパスを含めなければならない（SHALL）。セクション3 を参照。URIテンプレート内の変数は、フルトンネルIPパケット転送の要求や特定のプロキシフローなど、要求のスコープを決定できる。セクション4.6 を参照。

これらの制限に準拠しないIPプロキシ要求は不正な形式である。[HTTP/2] のセクション8.1.1 および [HTTP/3] のセクション4.1.2 を参照。

HEADERS
:method = CONNECT
:protocol = connect-ip
:scheme = https
:path = /.well-known/masque/ip/*/*/
:authority = example.org
capsule-protocol = ?1

図4: HTTP/2 または HTTP/3 要求の例

4.5. HTTP/2 および HTTP/3 応答

サーバーは、以下の要件で応答することにより、成功したIPプロキシ応答を示す：

応答のHTTPステータスコードは 2xx (Successful) の範囲でなければならない（SHALL）。
応答は、カプセルプロトコルを開始するHTTP応答の要件を満たさなければならない（SHALL）。[HTTP-DGRAM] のセクション3.2 を参照。

これらの要件のいずれかが満たされない場合、クライアントはこのプロキシ試行が失敗したとして扱い、要求を中止しなければならない（MUST）。例として、3xx範囲のステータスコードは失敗として扱われ、クライアントに要求を中止させる。

たとえば、サーバーは次のように応答できる：

HEADERS
:status = 200
capsule-protocol = ?1

図5: HTTP/2 または HTTP/3 応答の例

4.6. 要求スコープの制限

ターゲットホストを指定する必要があるUDPプロキシ要求とは異なり、IPプロキシ要求は、エンドポイントが任意のホストに任意のIPパケットを送信することを許可できる。クライアントは、要求にパラメータを追加することで、特定の要求を特定のIPプレフィックスまたはIPプロトコルに制限することを選択できる。IPプロキシが、要求がターゲットプレフィックスまたはプロトコルにスコープされていることを知っている場合、この情報を活用してリソース割り当てを最適化できる。たとえば、IPプロキシは、異なるプレフィックスおよび/または異なるプロトコルにスコープされた2つのIPプロキシ要求に同じパブリックIPアドレスを割り当てることができる。

要求のスコープは、URIテンプレートの "target" および "ipproto" 変数を介してクライアントからIPプロキシに示される。セクション3 を参照。"target" および "ipproto" 変数はどちらもオプションである。含まれていない場合、それらはワイルドカード値 "*" を運ぶと見なされる。

target: 変数 "target" には、クライアントがパケットをプロキシしたい特定のホストのホスト名またはIPプレフィックスが含まれる。"target" 変数が指定されていないか、その値が "*" の場合、クライアントは任意の許可されたホストとの通信を要求している。"target" は、DNS名、IPv6プレフィックス、およびIPv4プレフィックスの使用をサポートする。IPv6スコープアドレス指定ゾーン識別子 [IPv6-ZONE-ID] はサポートされていないことに注意すること。ターゲットがIPプレフィックス（IPアドレスの後にオプションでパーセントエンコードされたスラッシュ、その後にビット単位のプレフィックス長が続く）の場合、要求は単一のIPバージョンのみをサポートする。ターゲットがホスト名の場合、IPプロキシはDNS解決を実行して、クライアントに広告するルートを決定することが期待される。IPプロキシは、要求されたホスト名に対して解決された、IPプロキシがアクセス可能で、IPプロキシが割り当てられたアドレスも送信するアドレスファミリに属するすべてのアドレスのルートを含むROUTE_ADVERTISEMENTカプセルを送信すべきである（SHOULD）。

ipproto: 変数 "ipproto" には、インターネットプロトコル番号が含まれる。"Assigned Internet Protocol Numbers" IANAレジストリ [IANA-PN] の定義リストを参照。存在する場合、クライアントがこの要求に対して特定のIPプロトコルのみをプロキシしたいことを指定する。値が "*" の場合、または変数が含まれていない場合、クライアントは任意のIPプロトコルを使用することを要求している。"ipproto" 変数で示されるIPプロトコルは、HTTPデータグラムで直接送信されるIPヘッダー（最も外側のIPヘッダー）で運ばれる許可された次のヘッダー値を表す。このフィールドの値に関係なく、ICMPトラフィックは常に許可される。

[URI] の用語 IPv6address、IPv4address、および reg-name を使用して、"target" および "ipproto" 変数は、[ABNF] の表記法を使用して、図6の形式に準拠しなければならない（MUST）。さらに：

"target" にIPv6リテラルまたはプレフィックスが含まれる場合、コロン (":") はパーセントエンコードされなければならない（MUST）。たとえば、ターゲットホストが "2001:db8::42" の場合、URIでは "2001%3Adb8%3A%3A42" としてエンコードされる。
存在する場合、"target" 内のIPプレフィックス長の前には、パーセントエンコードされたスラッシュ ("/") が先行しなければならない（SHALL）："%2F"。IPプレフィックス長は、0からIPアドレスのビット長までの10進整数を表さなければならない（MUST）。
"target" にIPプレフィックスが含まれ、プレフィックス長がIPアドレスのビット長よりも厳密に短い場合、プレフィックス長でカバーされないIPアドレスの下位ビットはすべて0に設定されなければならない（MUST）。
"ipproto" は、0から255までの10進整数またはワイルドカード値 "*" を表さなければならない（MUST）。

target = IPv6prefix / IPv4prefix / reg-name / "*"
IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
ipproto = 1*3DIGIT / "*"

図6: URIテンプレート変数の形式

IPプロキシは、クライアントによって提供されたスコープ情報を使用してアクセス制御を実行してもよい（MAY）。つまり、クライアントがスコープに含まれる宛先のいずれかにアクセスすることを許可されていない場合、IPプロキシは要求を直ちに拒否できる。

4.7. カプセル

本書は、エンドポイントがIP構成情報を交換できるようにする複数の新しいカプセルタイプを定義する。両方のエンドポイントは、これらの新しいカプセルをいくつでも送信できる（MAY）。

4.7.1. ADDRESS_ASSIGN カプセル

ADDRESS_ASSIGNカプセル（カプセルタイプ0x01）を使用すると、エンドポイントはピアにIPアドレスまたはプレフィックスのリストを割り当てることができる。すべてのカプセルには、受信者に現在割り当てられているIPプレフィックスの完全なリストが含まれる。これらのアドレスはいずれも、このカプセルの受信者によって発信されたIPパケットの送信元アドレスとして使用できる。

ADDRESS_ASSIGN Capsule {
  Type (i) = 0x01,
  Length (i),
  Assigned Address (..) ...,
}

図7: ADDRESS_ASSIGN カプセル形式

ADDRESS_ASSIGNカプセルには、0個以上の割り当てられたアドレスのシーケンスが含まれる。

Assigned Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

図8: 割り当てられたアドレスの形式

各割り当てられたアドレスには、以下のフィールドが含まれる：

Request ID: 可変長整数としてエンコードされた要求識別子。このアドレス割り当てがアドレス要求（セクション4.7.2 を参照）への応答である場合、このフィールドには要求内の対応するフィールドの値を含めなければならない（SHALL）。そうでない場合、このフィールドはゼロでなければならない（SHALL）。

IP Version: 符号なし8ビット整数としてエンコードされた、このアドレス割り当てのIPバージョン。4または6でなければならない（MUST）。

IP Address: 割り当てられたIPアドレス。IPバージョンフィールドの値が4の場合、IPアドレスフィールドの長さは32ビットでなければならない（SHALL）。IPバージョンフィールドの値が6の場合、IPアドレスフィールドの長さは128ビットでなければならない（SHALL）。

IP Prefix Length: 割り当てられるプレフィックスを定義するために使用されるIPアドレス内のビット数。符号なし8ビット整数としてエンコードされる。これは、IPアドレスフィールドのビット長以下でなければならない（MUST）。プレフィックス長がIPアドレスの長さと等しい場合、このカプセルの受信者は単一の送信元アドレスからパケットを送信できる。プレフィックス長がIPアドレスの長さより短い場合、このカプセルの受信者はプレフィックス内に収まる任意の送信元アドレスからパケットを送信できる。プレフィックス長がIPアドレスのビット長よりも厳密に短い場合、プレフィックス長でカバーされないIPアドレスフィールドの下位ビットはすべて0に設定されなければならない（MUST）。

受信時にカプセルフィールドのいずれかが不正な形式である場合、カプセルの受信者は [HTTP-DGRAM] のセクション3.3 で定義されているエラー処理手順に従わなければならない（MUST）。

ADDRESS_ASSIGNカプセルに、別のADDRESS_ASSIGNカプセルで以前に送信されたアドレスが含まれていない場合、そのアドレスが削除されたことを示す。ADDRESS_ASSIGNカプセルは空にすることもでき、すべてのアドレスが削除されたことを示す。

HTTPでのIPプロキシの一部の展開では、エンドポイントは、自身のパケットに設定する送信元アドレスを知る前に、ピアによってアドレスを割り当てられる必要がある。たとえば、リモートアクセスVPNのケース（セクション8.1）では、クライアントは使用するアドレスを知るまでIPパケットを送信できない。これらの展開では、アドレス割り当てを期待しているエンドポイントはADDRESS_REQUESTカプセルを送信しなければならない（MUST）。これは、静的アドレスで帯域外で構成されている場合など、エンドポイントがアドレス割り当てを必要としない場合は必要ない。

ADDRESS_ASSIGNカプセルは通常、ADDRESS_REQUESTカプセルへの応答として送信されるが、エンドポイントはADDRESS_ASSIGNカプセルを自発的に送信してもよい（MAY）。

4.7.2. ADDRESS_REQUEST カプセル

ADDRESS_REQUESTカプセル（カプセルタイプ0x02）を使用すると、エンドポイントはピアからのIPアドレスの割り当てを要求できる。カプセルを使用すると、エンドポイントは、割り当てられるアドレスの優先順位をオプションで示すことができる。

ADDRESS_REQUEST Capsule {
  Type (i) = 0x02,
  Length (i),
  Requested Address (..) ...,
}

図9: ADDRESS_REQUEST カプセル形式

ADDRESS_REQUESTカプセルには、1つ以上の要求されたアドレスのシーケンスが含まれる。

Requested Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

図10: 要求されたアドレスの形式

各要求されたアドレスには、以下のフィールドが含まれる：

Request ID: 可変長整数としてエンコードされた要求識別子。これは、この特定のアドレス要求の識別子である。特定のエンドポイントからの各要求は、異なる識別子を運ぶ。要求IDはエンドポイントによって再利用されてはならず（MUST NOT）、ゼロであってはならない（MUST NOT）。

IP Version: 符号なし8ビット整数としてエンコードされた、このアドレス要求のIPバージョン。4または6でなければならない（MUST）。

IP Address: 要求されたIPアドレス。IPバージョンフィールドの値が4の場合、IPアドレスフィールドの長さは32ビットでなければならない（SHALL）。IPバージョンフィールドの値が6の場合、IPアドレスフィールドの長さは128ビットでなければならない（SHALL）。

IP Prefix Length: 符号なし8ビット整数としてエンコードされた、要求されたIPプレフィックスのビット長。これは、IPアドレスフィールドのビット長以下でなければならない（MUST）。プレフィックス長がIPアドレスのビット長よりも厳密に短い場合、プレフィックス長でカバーされないIPアドレスフィールドの下位ビットはすべて0に設定されなければならない（MUST）。

IPアドレスがすべてゼロ（0.0.0.0または::）の場合、これは送信者がそのアドレスファミリのアドレスを要求しているが、特定のアドレスに対する優先順位がないことを示す。そのシナリオでは、プレフィックス長は依然として送信者が要求しているプレフィックス長の優先順位を示す。

ADDRESS_REQUESTカプセルを受信すると、エンドポイントは1つ以上のIPアドレスをピアに割り当て、ADDRESS_ASSIGNカプセルで応答してピアに割り当てを通知すべきである（SHOULD）。各要求されたアドレスについて、ADDRESS_REQUESTカプセルの受信者は、一致する要求IDを持つ割り当てられたアドレスで応答しなければならない（SHALL）。要求されたアドレスが割り当てられた場合、割り当てられたアドレス応答のIPアドレスおよびIPプレフィックス長フィールドは、割り当てられた値に設定されなければならない（SHALL）。要求されたアドレスが割り当てられなかった場合、IPアドレスはすべてゼロでなければならず（SHALL）、IPプレフィックス長は最大長（0.0.0.0/32または::/128）であって、アドレスが割り当てられなかったことを示さなければならない（SHALL）。これらのアドレス拒否は、後続のADDRESS_ASSIGNカプセルに含まれるべきではない（SHOULD NOT）。どの要求IDにも対応しない他の割り当てられたアドレスエントリも、同じADDRESS_ASSIGN応答に含まれる可能性があることに注意すること。

エンドポイントがゼロ個の要求されたアドレスを含むADDRESS_REQUESTカプセルを受信した場合、IPプロキシ要求ストリームを中止しなければならない（MUST）。

要求されたアドレスの順序には意味がないことに注意すること。同様に、要求IDは一意の識別子としてのみ意味があり、優先順位や重要性を伝えるものではない。

4.7.3. ROUTE_ADVERTISEMENT カプセル

ROUTE_ADVERTISEMENTカプセル（カプセルタイプ0x03）を使用すると、エンドポイントは、一連のIPアドレス範囲へのトラフィックをルーティングする意思があることをピアに伝えることができる。これは、送信者が各アドレス範囲への既存のルートを持っていることを示し、ROUTE_ADVERTISEMENTカプセルの受信者がHTTPデータグラムでこれらの範囲のいずれかのIPパケットを送信した場合、カプセルの送信者がそれらを既存のルートに沿って転送することをピアに通知する。アドレス範囲内の任意のアドレスは、このカプセルの受信者によって発信されたIPパケットの宛先アドレスとして使用できる。

ROUTE_ADVERTISEMENT Capsule {
  Type (i) = 0x03,
  Length (i),
  IP Address Range (..) ...,
}

図11: ROUTE_ADVERTISEMENT カプセル形式

ROUTE_ADVERTISEMENTカプセルには、0個以上のIPアドレス範囲のシーケンスが含まれる。

IP Address Range {
  IP Version (8),
  Start IP Address (32..128),
  End IP Address (32..128),
  IP Protocol (8),
}

図12: IPアドレス範囲の形式

各IPアドレス範囲には、以下のフィールドが含まれる：

IP Version: 符号なし8ビット整数としてエンコードされた、この範囲のIPバージョン。4または6でなければならない（MUST）。

Start IP Address および End IP Address: 広告された範囲の包括的な開始および終了IPアドレス。IPバージョンフィールドの値が4の場合、これらのフィールドの長さは32ビットでなければならない（SHALL）。IPバージョンフィールドの値が6の場合、これらのフィールドの長さは128ビットでなければならない（SHALL）。開始IPアドレスは、終了IPアドレス以下でなければならない（MUST）。

IP Protocol: この範囲に送信できるトラフィックのインターネットプロトコル番号。符号なし8ビット整数としてエンコードされる。値が0の場合、すべてのプロトコルが許可される。値が0でない場合、HTTPデータグラムで直接送信されるIPヘッダー（最も外側のIPヘッダー）で運ばれる許可された次のヘッダー値を表す。このフィールドの値に関係なく、ICMPトラフィックは常に許可される。

ROUTE_ADVERTISEMENTカプセルを受信すると、エンドポイントは、ルーティングテーブルにエントリをインストールするなどして、ピアがルーティングする意思があるものに関するローカル状態を更新してもよい（MAY）（ローカルポリシーに従う）。

各ROUTE_ADVERTISEMENTには、アドレス範囲の完全なリストが含まれる。複数のROUTE_ADVERTISEMENTカプセルが一方向に送信される場合、各ROUTE_ADVERTISEMENTカプセルは前のカプセルに取って代わる。言い換えれば、特定のアドレス範囲が前のカプセルに存在していたが、最後に受信したROUTE_ADVERTISEMENTカプセルに含まれていない場合、受信者はその範囲が撤回されたと見なす。

同じIPプロトコルを使用する複数の範囲が重複する場合、一部のルーティングテーブル実装はそれらを拒否する可能性がある。重複を防ぐために、範囲は順序付けられている。これにより、負担が送信者にかかり、受信者による検証がはるかに簡単になる。IPアドレス範囲Aが同じROUTE_ADVERTISEMENTカプセル内でIPアドレス範囲Bの前にある場合、それらは以下の要件に従わなければならない（MUST）：

AのIPバージョンは、BのIPバージョン以下でなければならない（MUST）。
AとBのIPバージョンが等しい場合、AのIPプロトコルはBのIPプロトコル以下でなければならない（MUST）。
AとBのIPバージョンとIPプロトコルが両方とも等しい場合、Aの終了IPアドレスはBの開始IPアドレスよりも厳密に小さくなければならない（MUST）。

エンドポイントがこれらの要件を満たさないROUTE_ADVERTISEMENTカプセルを受信した場合、IPプロキシ要求ストリームを中止しなければならない（MUST）。

IPプロトコルをゼロに設定するとすべてのプロトコルが許可されることを示すため、上記の要件により、一方がIPプロトコルをゼロに設定し、もう一方が非ゼロに設定している場合、2つのルートが重複する可能性がある。エンドポイントは、そのように重複するルートを持つROUTE_ADVERTISEMENTカプセルを送信してはならない（MUST NOT）。この要件の検証はオプションであるが（OPTIONAL）、エンドポイントが違反を検出した場合、IPプロキシ要求ストリームを中止しなければならない（MUST）。

4.8. IPv6拡張ヘッダー

要求スコープ（セクション4.6 を参照）とROUTE_ADVERTISEMENTカプセル（セクション4.7.3 を参照）はどちらもインターネットプロトコル番号を使用する。これらの番号は、上位層（[IPv6] のセクション2 で定義されており、例にはTCPとUDPが含まれる）とIPv6拡張ヘッダー（[IPv6] のセクション4 で定義されており、例にはフラグメントヘッダーとオプションヘッダーが含まれる）の両方を表す。IPプロキシは、拡張ヘッダーに使用されるプロトコル番号へのスコープ要求を拒否してもよい（MAY）。パケットを受信すると、インターネットプロトコル番号によるスコープまたはルーティングをサポートする実装は、拡張チェーンをたどって、スコープルールと照合するための最も外側の非拡張インターネットプロトコル番号を見つけなければならない（MUST）。ROUTE_ADVERTISEMENTカプセルはインターネットプロトコル番号0を使用してすべてのプロトコルが許可されることを示すことに注意すること。これは、ルートをIPv6ホップバイホップオプションヘッダー（[IPv6] のセクション4.3）に制限するものではない。

4.1. IPプロキシの処理​

4.2. HTTP/1.1 要求​

4.3. HTTP/1.1 応答​

4.4. HTTP/2 および HTTP/3 要求​

4.5. HTTP/2 および HTTP/3 応答​

4.6. 要求スコープの制限​

4.7. カプセル​

4.7.1. ADDRESS_ASSIGN カプセル​

4.7.2. ADDRESS_REQUEST カプセル​

4.7.3. ROUTE_ADVERTISEMENT カプセル​

4.8. IPv6拡張ヘッダー​