[要約] RFC 8910は、DHCPとルーター広告(RAs)におけるキャプティブポータルの識別方法を定義しています。この標準は、ネットワークに接続したデバイスがインターネットアクセスを得る前に認証や利用規約の同意が必要な場合に、自動的にキャプティブポータルを検出し、ユーザーに通知するために使用されます。主に公共のWi-Fiネットワーク、ホテル、空港などで利用されます。
Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 8910 Google
Obsoletes: 7710 E. Kline
Updates: 3679 Loon
Category: Standards Track September 2020
ISSN: 2070-1721
Captive-Portal Identification in DHCP and Router Advertisements (RAs)
DHCPおよびルータ広告（RAS）における非秘密ポータル識別
Abstract
概要
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.
短期間または一時的なインターネットアクセス（コーヒーショップなど）を提供する多くの環境では、キャプティブポータルモードで新しい接続を開始するのが一般的です。これは、ユーザーがキャプティブポータル条件を満たすまでユーザーができることを非常に制限します。
This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.
このドキュメントでは、DHCPv4とDHCPv6オプションと、それらがある種のキャプティブポータル執行機器の背後にあることをクライアントに通知するためのルータ広告（RA）オプションであり、インターネットアクセスを取得するためにキャプティブポータル条件を満たす必要があることを説明します。クライアントがキャプティブポータルを持つ可能性がある問題のすべてに対処するのはフルソリューションではありません。そのようなポータルと対話するための標準化されたアプローチの1つの要素になるように設計されています。この文書は、ネットワーク事業者がキャプティブポータルAPIエンドポイントをホストに伝えることができる方法を定義しているが、キャプティブポータルを満たす特定の方法はこの文書の範囲外である。
This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.
この文書は、DHCPコード点160を使用したRFC 7710を置き換えます。競合のため、このドキュメントは114を指定します。その結果、このドキュメントはRFC 3679も更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8910.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8910で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Notation
2. The Captive-Portal Option
2.1. IPv4 DHCP Option
2.2. IPv6 DHCP Option
2.3. The Captive-Portal IPv6 RA Option
3. Precedence of API URIs
4. IANA Considerations
4.1. Captive Portal Unrestricted Identifier
4.2. BOOTP Vendor Extensions and DHCP Options Code Change
4.3. Update DHCPv6 and IPv6 ND Options Registries
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Changes from RFC 7710
Appendix B. Observations from IETF 106 Network Experiment
Acknowledgements
Authors' Addresses
In many environments, users need to connect to a captive portal device and agree to an Acceptable Use Policy (AUP) and/or provide billing information before they can access the Internet. Regardless of how that mechanism operates, this document provides functionality to allow the client to know when it is behind a captive portal and how to contact it.
多くの環境では、ユーザーはキャプティブポータルデバイスに接続し、インターネットにアクセスする前に、許容可能な使用ポリシー（AUP）および/または請求情報を提供する必要があります。そのメカニズムがどのように動作するかにかかわらず、このドキュメントでは、クライアントがキャプティブポータルの背後にあるときにクライアントがそれに連絡する方法を知ることができる機能を提供します。
In order to present users with the payment or AUP pages, a captive portal enforcement device presently has to intercept the user's connections and redirect the user to a captive portal server, using methods that are very similar to man-in-the-middle (MITM) attacks. As increasing focus is placed on security, and end nodes adopt a more secure stance, these interception techniques will become less effective and/or more intrusive.
支払いまたはAUPページを使用してユーザーを提示するために、現在、マンインザマン（MITM）と非常によく似た方法を使用して、現在のポータル適用デバイスが現在ユーザーの接続を傍受し、ユーザーをキャプティブポータルサーバーにリダイレクトする必要があります。）攻撃。焦点が増えているため、セキュリティ上に置かれ、エンドノードがより安全なスタンスを採用しているため、これらの遮断技術はより効果的でなく、またはより邪魔になるでしょう。
This document describes a DHCPv4 [RFC2131] and DHCPv6 [RFC8415] option (Captive-Portal) and an IPv6 Router Advertisement (RA) [RFC4861] option that informs clients that they are behind a captive portal enforcement device and the API endpoint that the host can contact for more information.
このドキュメントでは、クライアントがキャプティブポータル施行デバイスの背後にあることをクライアントに通知するDHCPv4 [RFC2131]オプション（RFC8415]オプション（RFC4861）オプションと、ホストがホストのAPIエンドポイントについて説明します。より多くの情報に連絡することができます。
This document replaces RFC 7710 [RFC7710], which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates [RFC3679].
このドキュメントは、RFC 7710 [RFC7710]を置き換えます。これは、DHCPコードポイント160を使用しました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The Captive-Portal DHCP/RA Option informs the client that it may be behind a captive portal and provides the URI to access an API as defined by [RFC8908]. This is primarily intended to improve the user experience by showing the user the captive portal information faster and more reliably. Note that, for the foreseeable future, captive portals will still need to implement interception techniques to serve legacy clients, and clients will need to perform probing to detect captive portals; nonetheless, the mechanism provided by this document provides a more reliable and performant way to do so, and is therefore the preferred mechanism for captive portal detection.
CAPTIVE-PORTAL DHCP / RAオプションは、クライアントにキャプティブポータルの背後にある可能性があることをクライアントに通知し、[RFC8908]で定義されているAPIにアクセスするためのURIを提供します。これは主に、キャプティブポータル情報をより迅速かつより確実にユーザーに表示することによって、ユーザーエクスペリエンスを向上させることを目的としています。予測可能な将来のために、キャプティブポータルはレガシクライアントにサービスを提供するための傍受手法を実装する必要があり、クライアントはキャプティブポータルを検出するためのプロービングを実行する必要があります。それにもかかわらず、この文書によって提供されるメカニズムは、より信頼性が高く実績がある方法を提供し、したがって、拘束ポータル検出のための好ましいメカニズムです。
Clients that support the Captive Portal DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST messages. DHCP servers MAY send the Captive Portal option without any explicit request.
Captive Portal DHCPオプションをサポートするクライアントには、DHCPRequestメッセージのパラメータ要求リストにオプションを含める必要があります。DHCPサーバーは、明示的な要求なしでキャプティブポータルオプションを送信することがあります。
In order to support multiple "classes" of clients (e.g., IPv4 only, IPv6 only with DHCPv6 ([RFC8415]), and IPv6 only with RA), the captive network can provision the client with the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, and IPv6 RA). The captive portal operator SHOULD ensure that the URIs provisioned by each method are identical to reduce the chance of operational problems. As the maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, URIs longer than this SHOULD NOT be provisioned by any of the IPv6 options described in this document. In IPv6-only environments, this restriction can be relaxed.
クライアントの複数の「クラス」（IPv4のみ、DHCPv6（[RFC8415]）、およびRAのみのIPv6のみをサポートするために、キャプティブネットワークは複数のメソッドを介してクライアントをURIにプロビジョニングできます（IPv4 DHCP、IPv6 DHCP、およびIPv6 RA）。キャプティブポータル演算子は、各方法によってプロビジョニングされたURIが動作上の問題の可能性を減らすために同じであることを確認する必要があります。IPv4 DHCPで実行できるURIの最大長は255バイトであるため、このドキュメントで説明されているIPv6オプションのいずれかによってプロビジョニングされるべきではありません。IPv6専用環境では、この制限は緩和できます。
In all variants of this option, the URI MUST be that of the captive portal API endpoint ([RFC8908]).
このオプションのすべての変形では、URIはキャプティブポータルAPIエンドポイントのそれでなければなりません（[RFC8908]）。
A captive portal MAY do content negotiation (Section 3.4 of [RFC7231]) and attempt to redirect clients querying without an explicit indication of support for the captive portal API content type (i.e., without application/capport+json listed explicitly anywhere within an Accept header field as described in Section 5.3 of [RFC7231]). In so doing, the captive portal SHOULD redirect the client to the value associated with the "user-portal-url" API key. When performing such content negotiation (Section 3.4 of [RFC7231]), implementors of captive portals need to keep in mind that such responses might be cached, and therefore SHOULD include an appropriate Vary header field (Section 7.1.4 of [RFC7231]) or set the Cache-Control header field in any responses to "private" or a more restrictive value such as "no-store" (Section 5.2.2.3 of [RFC7234]).
キャプティブポータルはコンテンツ交渉（[RFC7231]のセクション3.4）を実行し、キャプティブポータルAPIコンテンツタイプのサポートを明示的に表示せずにクライアントクエリをリダイレクトしようとしました（つまり、Appled / Capport JSONがAcceptヘッダーフィールド内のどこでも明示的にリストされていません。[RFC7231]のセクション5.3に記載されているように）。そのため、キャプティブポータルはクライアントを「user-portal-url」APIキーに関連付けられている値にリダイレクトする必要があります。そのようなコンテンツ交渉を実行するとき（[RFC7231]のセクション3.4）、キャプティブポータルの実装者は、そのような応答がキャッシュされる可能性があることに留意する必要があります。したがって、適切なVARYヘッダーフィールド（[RFC7231]のセクション7.1.4）を含める必要があります。「No-Store」などの「No-Store」などの制限的な値（[RFC7234]のセクション5.2.2.3）への応答にキャッシュコントロールヘッダフィールドを設定します。
The URI SHOULD NOT contain an IP address literal. Exceptions to this might include networks with only one operational IP address family where DNS is either not available or not fully functional until the captive portal has been satisfied. Use of IP Address certificates ([RFC3779]) adds considerations that are out of scope for this document.
URIにはIPアドレスリテラルを含めるべきではありません。これに例外は、DNSが利用できないか、キャプティブポータルが満たされるまで、1つの動作IPアドレスファミリを1つだけ含むネットワークを含み得る。IPアドレス証明書の使用（[RFC3779]）この文書の範囲外の考慮事項を追加します。
Networks with no captive portals may explicitly indicate this condition by using this option with the IANA-assigned URI for this purpose. Clients observing the URI value "urn:ietf:params:capport:unrestricted" may forego time-consuming forms of captive portal detection.
キャプティブポータルを持たないネットワークは、この目的のためにIANAが割り当てられたURIとこのオプションを使用してこの条件を明示的に示すことがあります。クライアントはURI値「URN：IETF：PARAMS：CAPPORT：UNCESTRICTIOND：UNCPORTICTED」が、拘束ポータル検出の時間のかかる形式を前提としている可能性があります。
The format of the IPv4 Captive-Portal DHCP option is shown below.
IPv4キャプティブポータルDHCPオプションの形式を以下に示します。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Len | URI (variable length) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ...URI continued... .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Captive-Portal DHCPv4 Option Format
図1：Portive-Portal DHCPv4オプションフォーマット
Code: The Captive-Portal DHCPv4 Option (114) (one octet).
コード：キャプティブポータルDHCPv4オプション（114）（1オクテット）。
Len: The length (one octet), in octets, of the URI.
Len：URIのオクテット内の長さ（1オクテット）。
URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in [RFC3986]).
URI：ユーザーが接続する必要があるキャプティブポータルAPIエンドポイントのURI（[RFC3986]の規則に従ってエンコードされています）。
See Section 2 of [RFC2132] for more on the format of IPv4 DHCP options.
IPv4 DHCPオプションのフォーマットの詳細については、[RFC2132]のセクション2を参照してください。
Note that the URI parameter is not null terminated.
URIパラメータはNULLで終了しないことに注意してください。
The format of the IPv6 Captive-Portal DHCP option is shown below.
IPv6キャプティブポータルDHCPオプションの形式を以下に示します。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Captive-Portal DHCPv6 Option Format
図2：Portal-Portal DHCPv6オプションフォーマット
option-code: The Captive-Portal DHCPv6 Option (103) (two octets).
option-code：キャプティブポータルDHCPv6オプション（103）（2オクテット）。
option-len: The unsigned 16-bit length, in octets, of the URI.
オプション-LEN：URIのオクテット内の符号なし16ビット長。
URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in [RFC3986]).
URI：ユーザーが接続する必要があるキャプティブポータルAPIエンドポイントのURI（[RFC3986]の規則に従ってエンコードされています）。
See Section 5.7 of [RFC7227] for more examples of DHCP Options with URIs. See Section 21.1 of [RFC8415] for more on the format of IPv6 DHCP options.
URISのDHCPオプションの例については、[RFC7227]のセクション5.7を参照してください。IPv6 DHCPオプションのフォーマットの詳細については、[RFC8415]のセクション21.1を参照してください。
Note that the URI parameter is not null terminated.
URIパラメータはNULLで終了しないことに注意してください。
As the maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, URIs longer than this SHOULD NOT be provisioned via IPv6 DHCP options.
IPv4 DHCPで実行できるURIの最大長は255バイトであるため、URIはこれよりも長いIPv6 DHCPオプションを介してプロビジョニングされるべきではありません。
This section describes the Captive-Portal Router Advertisement option.
このセクションでは、「ポータルルータ広告」オプションについて説明します。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | URI .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Captive-Portal RA Option Format
図3：キャプティブポータルRAオプションフォーマット
Type: 37
タイプ：37
Length: 8-bit unsigned integer. The length of the option (including the Type and Length fields) in units of 8 bytes.
長さ：8ビットの符号なし整数。8バイト単位でオプションの長さ（タイプフィールドと長さフィールドを含む）。
URI: The URI for the captive portal API endpoint to which the user should connect. This MUST be padded with NUL (0x00) to make the total option length (including the Type and Length fields) a multiple of 8 bytes.
URI：ユーザーが接続する必要があるキャプティブポータルAPIエンドポイントのURI。これにはNUL（0x00）で埋められており、合計オプションの長さ（タイプフィールドを含む）を8バイトの倍数にする必要があります。
Note that the URI parameter is not guaranteed to be null terminated.
URIパラメータはNULLで終了することが保証されていないことに注意してください。
As the maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, URIs longer than this SHOULD NOT be provisioned via IPv6 RA options.
IPv4 DHCPで実行できるURIの最大長は255バイトの場合、URIはこれよりも長いため、IPv6 RAオプションを介してプロビジョニングされるべきではありません。
A device may learn about Captive Portal API URIs through more than one of (or indeed all of) the above options. Implementations can select their own precedence order (e.g., prefer one of the IPv6 options before the DHCPv4 option, or vice versa, et cetera).
装置は、上記のオプションの1つ（または実際に）のうちの複数の（または実際に）を通じてキャプティブポータルAPI URIについて学ぶことができます。実装は独自の優先順位を選択できます（たとえば、DHCPv4オプションの前にIPv6オプションの1つ、またはその逆のIPv6オプションを好む）。
If the URIs learned via more than one option described in Section 2 are not all identical, this condition should be logged for the device owner or administrator; it is a network configuration error if the learned URIs are not all identical.
セクション2で説明されている複数のオプションを介して学習されたURIがすべて同一ではない場合、この状態はデバイスの所有者または管理者に記録する必要があります。学習されたURIがすべて同一ではない場合は、ネットワーク構成エラーです。
IANA has registered a new IETF URN protocol parameter ([RFC3553]). IANA has also reallocated two DHCPv4 option codes (see Appendix B for background) and updated the references for previously registered DHCPv6 and IPv6 ND options.
IANAは新しいIETF URNプロトコルパラメータを登録しました（[RFC3553]）。IANAは2つのDHCPv4オプションコード（バックグラウンド用の付録Bを参照）を再割り当てし、以前に登録されたDHCPv6とIPv6 NDオプションの参照を更新しました。
IANA has registered a new entry in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry defined in [RFC3553]:
IANAは、[RFC3553]で定義されている「登録プロトコルパラメータ識別子」レジストリを「IETF URNサブネームスペース」に登録しました。
Registered Parameter Identifier: capport:unrestricted Reference: RFC 8910 IANA Registry Reference: RFC 8910
登録されたパラメータ識別子：Capport：無制限リファレンス：RFC 8910 IANAレジストリリファレンス：RFC 8910
Only one value is defined (see URN above). No hierarchy is defined and, therefore, no sub-namespace registrations are possible.
1つの値が定義されています（上記のURNを参照）。階層は定義されておらず、したがって、サブネームスペース登録は可能ではありません。
IANA has updated the "BOOTP Vendor Extensions and DHCP Options" registry (https://www.iana.org/assignments/bootp-dhcp-parameters) as follows.
IANAは、次のように「Bootp Vendor ExtensionsとDHCPオプション」レジストリ（https://www.iana.org/ashignments/bootp-dhcp-parameters）を更新しました。
Tag: 114 Name: DHCP Captive-Portal Data Length: N Meaning: DHCP Captive-Portal Reference: RFC 8910
タグ：114名前：DHCPキャプティブポータルデータ長：N意味：DHCPキャプティブポータルリファレンス：RFC 8910
Tag: 160 Name: Unassigned Data Length: Meaning: Previously assigned by [RFC7710]; known to also be used by Polycom. Reference: [RFC7710] RFC 8910
タグ：160名前：未割り当てデータ長：意味：以前に[RFC7710]によって割り当てられました。Polycomによっても使用されることが知られています。参照：[RFC7710] RFC 8910
IANA has updated the DHCPv6 (103 - DHCP Captive-Portal) and IPv6 ND (37 - DHCP Captive-Portal) options previously registered in [RFC7710] to reference this document.
このドキュメントを参照するために、[RFC7710]に以前に登録されていたDHCPv6（103 - DHCPキャプティブポータル）およびIPv6 ND（37 - DHCPキャプティブポータル）オプションを更新しました。
By removing or reducing the need for captive portals to perform MITM hijacking, this mechanism improves security by making the portal and its actions visible, rather than hidden, and reduces the likelihood that users will disable useful security safeguards like DNSSEC validation, VPNs, etc. in order to interact with the captive portal. In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, credentials, etc. By handing out a URI that is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious.
キャプティブポータルがMITMハイジャックを実行するための必要性を削除または減らすことによって、このメカニズムは隠されたよりもむしろポータルとそのアクションを表示することによってセキュリティを向上させ、ユーザーがDNSSEC検証、VPNなどのような有用なセキュリティ保護を無効にする可能性を減らすことができます。キャプティブポータルと対話するために。さらに、システムはキャプティブポータルの背後にあることを知っているので、TLSで保護されているURIを取り出すことで、Captive Portal演算子がユーザーを安心させることを試みることができます。キャプティブポータルは悪意のあるものではありません。
Clients processing these options SHOULD validate that the option's contents conform to the validation requirements for URIs, including those described in [RFC3986].
クライアントの処理これらのオプションは、オプションの内容が[RFC3986]で説明されているものを含む、URIの検証要件に準拠していることを検証する必要があります。
Each of the options described in this document is presented to a node using the same protocols used to provision other information critical to the node's successful configuration on a network. The security considerations applicable to each of these provisioning mechanisms also apply when the node is attempting to learn the information conveyed in these options. In the absence of security measures like RA-Guard ([RFC6105], [RFC7113]) or DHCPv6-Shield [RFC7610], an attacker could inject, modify, or block DHCP messages or RAs.
この文書で説明されている各オプションは、ネットワーク上でノードの成功した構成に重要な他の情報をプロビジョニングするために使用される同じプロトコルを使用しているノードに提示されています。これらのプロビジョニングメカニズムに適用可能なセキュリティ上の考慮事項は、ノードがこれらのオプションで伝達された情報を学習しようとしているときにも適用されます。RA-Guard（[RFC6105]、[RFC7113]）またはDHCPV6シールド[RFC7610]のようなセキュリティ対策がない場合、攻撃者はDHCPメッセージまたはRASを注入、変更、またはブロックすることができます。
An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of the attacker's choosing. An attacker with this capability could simply list themselves as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more capabilities, but because this document removes the need for interception, the attacker may have an easier time performing the attack.
DHCPメッセージまたはRASを注入する機能を持つ攻撃者は、この文書のオプションを含めることができ、ユーザーに攻撃者が選択したアドレスに連絡することを強制することができます。この機能を持つ攻撃者は単にデフォルトのゲートウェイとして一覧表示できます（そして、すべての被害者のトラフィックを傍受させる）。これは著しくより多くの機能を提供していませんが、この文書は傍受の必要性を除去するため、攻撃者は攻撃をより簡単にする可能性があります。
However, as the operating systems and application(s) that make use of this information know that they are connecting to a captive portal device (as opposed to intercepted connections where the OS/ application may not know that they are connecting to a captive portal or hostile device), they can render the page in a sandboxed environment and take other precautions such as clearly labeling the page as untrusted. The means of sandboxing and a user interface presenting this information is not covered in this document; by its nature, it is implementation specific and best left to the application and user interface designers.
ただし、この情報を利用するオペレーティングシステムやアプリケーションとして、それらがキャプティブポータルデバイスに接続していることを知っている（OS /アプリケーションがそれらが拘束ポータルに接続していることがわからない場合があります。敵対的な装置）、それらはサンドボックス化された環境でページをレンダリングし、ページを明確にラベル付けされているなどの他の注意を取ります。この情報を提示するサンドボックスとユーザインタフェースの手段は、この文書ではカバーされていません。その性質によって、それはアプリケーションとユーザーインターフェイスデザイナーに特有の実装であり、残りのものです。
Devices and systems that automatically connect to an open network could potentially be tracked using the techniques described in this document (forcing the user to continually resatisfy the Captive Portal conditions or exposing their browser fingerprint). However, similar tracking can already be performed with the presently common captive portal mechanisms, so this technique does not give the attackers more capabilities.
オープンネットワークに自動的に接続する機器およびシステムは、この文書に記載されている技術を使用して潜在的に追跡される可能性があります（ユーザーが継続的に拘束されたポータル条件を継続的に再扱い、ブラウザの指紋を露出させること）。しかしながら、類似の追跡は現在一般的な捕獲ポータルメカニズムを用いて既に実行されているので、この技術は攻撃者により多くの機能を与えない。
Captive portals are increasingly hijacking TLS connections to force browsers to talk to the portal. Providing the portal's URI via a DHCP or RA option is a cleaner technique, and reduces user expectations of being hijacked; this may improve security by making users more reluctant to accept TLS hijacking, which can be performed from beyond the network associated with the captive portal.
キャプティブポータルは、ブラウザをポータルと話すためにTLS接続をハイジャックしています。DHCPまたはRAオプションを介してポータルのURIを提供することは、クリーナーなテクニックであり、ハイジャックされているというユーザーの期待を軽減します。これは、ユーザがTLSハイジャックを受け入れることをより消極的にすることによってセキュリティを向上させることができ、これはキャプティブポータルに関連するネットワークを超えて実行することができる。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] DROMS、R.、「動的ホスト構成プロトコル」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https：//www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S.およびR.ROMS、「DHCPオプションおよびBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<https：//www.rfc-editor.org/info/rfc2132>。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T.、およびG。Klyne、「登録プロトコルパラメータのIETF URNサブネームスペース」、BCP 73、RFC 3553、DOI 10.17487 / RFC3553、2003年6月、<https://www.rfc-editor.org/info/rfc3553>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7227]ハンキン、D.、Mrugalski、T.、Sodelski、M.、Jiang、S.、およびS.クリシュナン、「新しいDHCPv6のオプションを作成するためのガイドライン」、BCP 187、RFC 7227、DOI 10.17487 / RFC7227、2014年5月<https：//www.rfc-editor.org/info/rfc7227>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Field、R.、Ed。、Nottingham、M.、Ed。、J.Reschke、Ed。、「ハイパーテキスト転送プロトコル（HTTP / 1.1）：キャッシング」、RFC 7234、DOI 10.17487 / RFC7234、2014年6月<https://www.rfc-editor.org/info/rfc7234>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC3679] Droms, R., "Unused Dynamic Host Configuration Protocol (DHCP) Option Codes", RFC 3679, DOI 10.17487/RFC3679, January 2004, <https://www.rfc-editor.org/info/rfc3679>.
[RFC3679] DROMS、R。、「未使用の動的ホスト構成プロトコル（DHCP）オプションコード」、RFC 3679、DOI 10.17487 / RFC3679、2004年1月、<https：//www.rfc-editor.org/info/rfc3679>。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC3779] Lynn、C、Kent、S.、K. SEO、「IPアドレスのX.509拡張機能」、RFC 3779、DOI 10.17487 / RFC3779、2004年6月、<https：//www.rfc-editor.org/info/rfc3779>。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <https://www.rfc-editor.org/info/rfc6105>.
[RFC6105] Levy-Abningoli、E.、Van de Velde、G.、Popviciu、C.、およびJ.Mohacsi、「IPv6ルータ広告ガード」、RFC 6105、DOI 10.17487 / RFC6105、2011年2月、<https：//www.rfc-editor.org/info/rfc6105>。
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, <https://www.rfc-editor.org/info/rfc7113>.
[RFC7113] Gont、F.、「IPv6ルータ広告ガード（RA-Guard）の実装アドバイス」、RFC 7113、DOI 10.17487 / RFC7113、2014年2月、<https：//www.rfc-editor.org/info/rfc7113>。
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>.
[RFC7610] Gont、F.、Liu、W.およびG. van de Velde、 "DHCPV6-Shield：Rogue DHCPV6サーバーから保護する"、BCP 199、RFC 7610、DOI 10.17487 / RFC7610、2015年8月、<https：//www.rfc-editor.org/info/rfc7610>。
[RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, "Captive-Portal Identification Using DHCP or Router Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, December 2015, <https://www.rfc-editor.org/info/rfc7710>.
[RFC7710] kumari、W.、Gudmundsson、O.、Ebersman、P.、およびS. Sheng、「DHCPまたはルーター広告を使用したキャプティブポータル識別（RAS）」、RFC 7710、DOI 10.17487 / RFC7710、2015年12月、<https://www.rfc-editor.org/info/rfc7710>。
[RFC8908] Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API", RFC 8908, DOI 10.17487/RFC8908, September 2020, <https://www.rfc-editor.org/info/rfc8908>.
[RFC8908] Pouly、T.、ED。D. Thakore、Ed。、「Captive Portal API」、RFC 8908、DOI 10.17487 / RFC8908、2020年9月、<https：//www.rfc-editor.org/info/rfc8908>。
This document incorporates the following changes from [RFC7710].
この文書には、[RFC7710]から次のような変更が含まれています。
1. Clarified that IP string literals are NOT RECOMMENDED.
1. IP文字列リテラルが推奨されていないことを明確にしました。
2. Clarified that the option URI MUST be that of the captive portal API endpoint.
2. オプションURIがキャプティブポータルAPIエンドポイントのオプションURIでなければならないことを明確にしました。
3. Clarified that captive portals MAY do content negotiation.
3. キャプティブポータルがコンテンツ交渉をする可能性があることを明確にしました。
4. Added text about Captive Portal API URI precedence in the event of a network configuration error.
4. ネットワーク構成エラーが発生した場合に、Captive Portal API URIの優先順位に関するテキストを追加しました。
5. Added urn:ietf:params:capport:unrestricted URN.
5. 追加されたurn：ietf：params：capport：無制限のURN。
6. Noted that the DHCPv4 Option Code changed from 160 to 114.
6. DHCPv4オプションコードは160から114に変更されたことに注意してください。
During IETF 106 in Singapore, an experiment (https://tickets.meeting.ietf.org/wiki/IETF106network#Experiments) enabling clients compatible with the Captive Portal API to discover a venue-info-url (see experiment description (https://tickets.meeting.ietf.org/wiki/CAPPORT) for more detail) revealed that some Polycom devices on the same network made use of DHCPv4 option code 160 for other purposes (https://community.polycom.com/t5/VoIP-SIP-Phones/DHCP-Standardization-160-vs-66/td-p/72577).
シンガポールのIETF 106の間、実験（https://tickets.meeting.ietf.org/wiki/ietf106network#実験）を有効にすると、Captive Portal APIと互換性のあるクライアントがentive-info-urlを発見することを可能にする（実験説明（HTTPS：//tickets.meeting.ietf.org/wiki/capport）詳細については、同じネットワーク上の一部のPolycomデバイスが他の目的のためにDHCPv4オプションコード160を使用したことを明らかにしました（https：//community.polycom.com/t5/VoIP-SIP-PHONES / DHCP標準化-160-VS-66 / TD-P / 72577）。
The presence of DHCPv4 Option code 160 holding a value indicating the Captive Portal API URL caused these devices to not function as desired. For this reason, IANA has deprecated option code 160 and allocated a different value to be used for the Captive Portal API URL.
DHCPv4オプションコード160の存在は、キャプティブポータルAPI URLを示す値を保持しているため、これらのデバイスが必要に応じて機能しないことが原因となります。このため、IANAは廃止予定のオプションコード160を有し、キャプティブポータルAPI URLに使用される異なる値を割り当てました。
Acknowledgements
謝辞
This document is a -bis of RFC 7710. Thanks to all of the original authors (Warren Kumari, Olafur Gudmundsson, Paul Ebersman, and Steve Sheng) and original contributors.
この文書はRFC 7710の-BISです。オリジナルの著者（Warren Kumari、Olafur Gudmundsson、Paul Ebersman、Steve Sheng）とオリジナルの貢献者のおかげです。
Also thanks to the CAPPORT WG for all of the discussion and improvements, including contributions and review from Joe Clarke, Lorenzo Colitti, Dave Dolson, Hans Kuhn, Kyle Larose, Clemens Schimpe, Martin Thomson, Michael Richardson, Remi Nguyen Van, Subash Tirupachur Comerica, Bernie Volz, and Tommy Pauly.
また、Joe Clarke、Lorenzo Colitti、Dave Dolson、Kyle Larse、Martin Thomson、Michael Richardson、Michael Richardson、Michael Richardson、Micha Lichardson、Michael Schimpe、Martin Thomson、Subast Tirupachur Comerica、Remi Nguyen Van、Remi Ngyen Van、Remi Ngyen Van、Remi Ngyen Van、Remi Ngyen Van、Subash Tirupachur Comerica、Remi Ngyen Van、Subash Tirupachur Comerica、Subash Tirupachur Comerica、Subash Tirupachur Comerica、Bernie Volz、そしてトミーポーリー。
Authors' Addresses
著者の住所
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari Google 1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net
Erik Kline Loon 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Erik Kline Loon 1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国
Email: ek@loon.com