[要約] RFC 6422は、リレーサーバが提供するDHCPオプションに関する仕様です。その目的は、DHCPリレーサーバがネットワーク上のクライアントに対して追加の情報を提供するための方法を定義することです。
Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 6422 Nominum
Updates: 3315 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 December 2011
Relay-Supplied DHCP Options
リレーサプライDHCPオプション
Abstract
概要
DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.
DHCPV6リレーエージェントは、DHCPV6クライアントと直接通信できません。ただし、場合によっては、リレーエージェントは、DHCPV6クライアントに役立つ情報をいくつか所有しています。このドキュメントでは、DHCPV6リレーエージェントがそのような情報をDHCPV6サーバーに提供できるメカニズムについて説明します。これにより、この情報をDHCPクライアントに渡すことができます。
This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients.
このドキュメントは、リレーエージェントがクライアントにリレーしてリレーしているときにリレーエージェントがカプセル化ペイロードのコンテンツを変更しないという暗黙の要件を明示することにより、RFC 3315（DHCPV6）を更新します。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6422.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6422で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
2. Protocol Summary ................................................3
3. Encoding ........................................................3
4. RSOO-Enabled Options ............................................4
5. DHCP Relay Agent Behavior .......................................4
6. DHCP Server Behavior ............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
The DHCPv6 specification [RFC3315] allows DHCP relay agents to forward DHCPv6 messages between clients and servers that are not on the same IPv6 link. In some cases, the DHCP relay agent has information not available to the DHCP server that would be useful to provide to a DHCP client. For example, the DHCP client may need to learn the EAP Re-authentication Protocol (ERP) local domain name [RFC6440] for use in EAP re-authentication [RFC5296], which is known to the relay agent but not the server.
DHCPV6仕様[RFC3315]により、DHCPリレーエージェントは、同じIPv6リンクにないクライアントとサーバー間でDHCPV6メッセージを転送できます。場合によっては、DHCPリレーエージェントには、DHCPクライアントに提供するのに役立つDHCPサーバーが利用できない情報があります。たとえば、DHCPクライアントは、EAP再認証[RFC5296]で使用するために、リレーエージェントではないがサーバーではなく使用するために、EAP再認証プロトコル（ERP）ローカルドメイン名[RFC6440]を学習する必要がある場合があります。
The DHCPv6 protocol specification does not provide a mechanism whereby the relay agent can provide options to the client. This document extends DHCP with a mechanism that allows DHCP relay agents to propose options for the server to send to DHCP clients.
DHCPV6プロトコル仕様は、リレーエージェントがクライアントにオプションを提供できるメカニズムを提供しません。このドキュメントは、DHCPリレーエージェントがサーバーがDHCPクライアントに送信できるオプションを提案できるメカニズムを備えたDHCPを拡張します。
This document is not intended to provide a general mechanism for storing client configuration information in the relay agent. Rather, it is intended to address specific use cases where only the relay agent has information needed by the client. This extension is not applicable to DHCP options in general, but rather provided as a mechanism for new specifications that require this functionality.
このドキュメントは、リレーエージェントにクライアント構成情報を保存するための一般的なメカニズムを提供することを目的としていません。むしろ、リレーエージェントのみがクライアントが必要とする情報を持っている特定のユースケースに対処することを目的としています。この拡張機能は、一般的にDHCPオプションには適用されませんが、この機能を必要とする新しい仕様のメカニズムとして提供されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The following terms and acronyms are used in this document:
このドキュメントでは、次の用語と頭字語が使用されています。
o DHCP: Dynamic Host Configuration Protocol Version 6 [RFC3315]
o DHCP：ダイナミックホスト構成プロトコルバージョン6 [RFC3315]
o RSOO: Relay-Supplied Options option
o RSOO：リレーサプライオプションオプション
DHCP clients do not support a mechanism for receiving options from relay agents -- the relay agent is required to deliver the payload from the DHCP server to the DHCP client without changing it. In order for the DHCP relay agent to provide options to the client, it sends those options to the DHCP server, encapsulated in an RSOO. The DHCP server can then choose to place those options in the response it sends to the client.
DHCPクライアントは、リレーエージェントからオプションを受信するメカニズムをサポートしていません。リレーエージェントは、DHCPサーバーからDHCPクライアントにペイロードを変更せずに配信する必要があります。DHCPリレーエージェントがクライアントにオプションを提供するために、RSOOにカプセル化されたDHCPサーバーにそれらのオプションを送信します。DHCPサーバーは、クライアントに送信する応答にこれらのオプションを配置することを選択できます。
In order to supply options for the DHCP server to send to the client, the relay agent sends an RSOO in the Relay-Forward message. This option encapsulates whatever options the relay agent wishes to provide to the DHCPv6 server.
DHCPサーバーがクライアントに送信するオプションを提供するために、リレーエージェントはリレーフォワードメッセージでRSOOを送信します。このオプションは、リレーエージェントがDHCPV6サーバーに提供したいオプションをすべてカプセル化します。
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_RSOO | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options...
+-+-+-+-+-+-+-+-+-+-+-+
OPTION_RSOO
option_rsoo
Relay-Supplied Options code (66).
リレーサプライオプションコード（66）。
option-length
オプション長
Length of the RSOO.
RSOOの長さ。
options
オプション
One or more DHCPv6 options.
1つ以上のDHCPV6オプション。
The RSOO MUST NOT contain any option that is not specifically called out as an RSOO-enabled option. Specifications that describe RSOO-enabled options MUST reference this specification, and MUST state that the option they define is RSOO-enabled. No DHCP option specified prior to the issuance of this specification is RSOO-enabled.
RSOOには、RSOO対応オプションとして具体的に呼び出されないオプションが含まれてはなりません。RSOO対応オプションを記述する仕様は、この仕様を参照する必要があり、定義するオプションはRSOO対応であると述べる必要があります。この仕様の発行前に指定されたDHCPオプションはRSOO対応です。
A current list of RSOO-enabled options can be found in the list titled "Options Permitted in the Relay-Supplied Options Option" maintained at http://www.iana.org/.
RSOO対応オプションの現在のリストは、http://www.iana.org/に維持されている「リレーサプリドオプションオプションで許可されているオプション」というタイトルのリストにあります。
DHCP option specifications that define RSOO-enabled options MUST add text similar to the following to their IANA Considerations section; "random relay option" should be replaced with the name of the option being defined in the specification:
RSOO対応オプションを定義するDHCPオプション仕様は、IANAの考慮事項セクションに次のようなテキストを追加する必要があります。「ランダムリレーオプション」は、仕様で定義されているオプションの名前に置き換える必要があります。
We request that IANA add the name "random relay option" to the registry titled "Options Permitted in the Relay-Supplied Options Option" maintained at http://www.iana.org/.
iANAは、http://www.iana.org/に維持されている「リレーサプライオプションオプションで許可されているオプション」というタイトルのレジストリに「ランダムリレーオプション」という名前を追加することを要求します。
Relay agents MAY include an RSOO in the option payload of a Relay-Forward message being sent toward a DHCP server. When relaying the payload of Relay-Reply messages toward clients, relay agents MUST NOT modify the payload.
リレーエージェントには、DHCPサーバーに送信されるリレーフォワードメッセージのオプションペイロードにRSOOを含めることができます。クライアントに対するリレー対応メッセージのペイロードをリレーする場合、リレーエージェントはペイロードを変更してはなりません。
Relay agents MUST NOT send non-RSOO-enabled options in the Relay-Supplied Options option.
リレーエージェントは、リレーサプライオプションオプションで非RSOO対応オプションを送信してはなりません。
In order to allow network administrators to control the flow of RSOO options onto the network, relay agents that implement the Relay-Supplied Options option need to have a configuration parameter that determines whether or not they will relay Relay-Forward messages containing RSOOs.
ネットワーク管理者がネットワークへのRSOOオプションのフローを制御できるようにするために、リレーサプライオプションオプションオプションを実装するリレーエージェントには、RSOOを含むリレーフォワードメッセージがリレーするかどうかを決定する構成パラメーターが必要です。
Relay agents that have this configuration parameter and that are configured to disable forwarding of a Relay-Forward message containing an RSOO MUST silently discard any such message.
この構成パラメーターを持ち、RSOOを含むリレーフォワードメッセージの転送を無効にするように構成されているリレーエージェントは、そのようなメッセージを静かに破棄する必要があります。
Implementations that can be configured in this way MUST examine all Relay-Forward encapsulations, not just the outer encapsulation.
この方法で構成できる実装は、外側のカプセル化だけでなく、すべてのリレーフォワードカプセルを調べる必要があります。
DHCP servers that implement this protocol specification MUST examine each option contained in an RSOO to see if it is an RSOO-enabled option. DHCP servers MUST silently discard any option contained in an RSOO that is not RSOO-enabled. DHCP server implementations SHOULD have an administrator-configurable list of RSOO-enabled options, so that new RSOO-enabled options do not require software to be updated.
このプロトコル仕様を実装するDHCPサーバーは、RSOOに含まれる各オプションをRSOO対応オプションであるかどうかを確認する必要があります。DHCPサーバーは、RSOO対応ではないRSOOに含まれるオプションを静かに破棄する必要があります。DHCPサーバーの実装には、新しいRSOO対応オプションではソフトウェアを更新する必要がないように、RSOO対応オプションの管理者構成可能なリストが必要です。
DHCP servers normally construct a list of options that are candidates to send to the DHCP client, and then construct the DHCP packet according to Section 17.2.2 of the DHCPv6 specification [RFC3315].
DHCPサーバーは通常、DHCPクライアントに送信する候補であるオプションのリストを作成し、DHCPV6仕様[RFC3315]のセクション17.2.2に従ってDHCPパケットを構築します。
If the server implementing this protocol specification receives an RSOO, it SHOULD add any options that appear in the RSOO for which it has no internal candidate to the list of options that are candidates to send to the DHCP client. The server SHOULD discard any options that appear in the RSOO for which it already has one or more candidates.
このプロトコル仕様を実装するサーバーがRSOOを受信した場合、RSOOに表示されるオプションを追加する必要があります。このオプションは、DHCPクライアントに送信する候補であるオプションのリストに内部候補がないものです。サーバーは、RSOOに表示されるオプションを破棄する必要があります。
Aside from the addition of options from the RSOO, the DHCP server should then construct a DHCP packet as it normally would, and transmit it to the DHCP client as described in [RFC3315].
RSOOからのオプションの追加は別として、DHCPサーバーは通常どおりDHCPパケットを構築し、[RFC3315]で説明されているようにDHCPクライアントに送信する必要があります。
DHCP servers may receive multiply-nested Relay-Forward messages containing conflicting values for options contained in RSOOs in these messages.
DHCPサーバーは、これらのメッセージにRSOOに含まれるオプションの矛盾する値を含む、複数のネストされたリレーフォワードメッセージを受信する場合があります。
When such a conflict exists, the DHCP server MUST choose no more than one of these options to forward to the client. The DHCP server MUST NOT forward more than one of these options to the client.
このような競合が存在する場合、DHCPサーバーは、クライアントに転送するためにこれらのオプションの1つ以上を選択する必要があります。DHCPサーバーは、これらのオプションの2つ以上をクライアントに転送してはなりません。
By default, the DHCP server MUST choose the innermost value -- the value supplied by the relay agent closest to the DHCP client -- to forward to the DHCP client.
デフォルトでは、DHCPサーバーは、DHCPクライアントに転送するために、DHCPクライアントに最も近いリレーエージェントによって提供される値（最小値）を選択する必要があります。
DHCP server implementations MAY provide other heuristics for choosing which one of a set of such conflicting options to forward to the client, as long as the specified behavior is the default behavior.
DHCPサーバーの実装は、指定された動作がデフォルトの動作である限り、クライアントに転送するためのこのような競合するオプションのセットの1つを選択するための他のヒューリスティックを提供する場合があります。
This document provides a mechanism whereby a relay agent can inject options into the response the DHCP server sends to the DHCP client. In currently known use cases -- for example, the ERP Local Domain Option [RFC6440] -- RSOO-enabled options are options that will only ever originate on a relay agent, and do not make sense when originating on a DHCP server.
このドキュメントは、リレーエージェントがDHCPサーバーがDHCPクライアントに送信する応答にオプションを挿入できるメカニズムを提供します。現在既知のユースケースでは、たとえば、ERPローカルドメインオプション[RFC6440] - RSOO対応オプションは、リレーエージェントにのみ発生するオプションであり、DHCPサーバーで発信する場合は意味がありません。
In the event that some new RSOO-enabled option is specified that can originate from either the server or the relay agent, this should be addressed in the Security Considerations section of the document that specifies the use of that option.
サーバーまたはリレーエージェントのいずれかから発生する新しいRSOO対応オプションが指定されている場合、これは、そのオプションの使用を指定するドキュメントのセキュリティに関する考慮事項セクションでアドレス指定する必要があります。
In some environments, there is an interface on one side of which is the client, and zero or more routers, and on the other side of which is a network managed by a monolithic or effectively monolithic administrative entity. Nodes and routers on the client side of the interface are not controlled by this entity, and are considered "untrusted". Nodes and routers on the network side of this interface are considered trusted.
一部の環境では、その片側にクライアントとゼロ以上のルーターがあり、反対側にはモノリシックまたは効果的にモノリシックな行政機関によって管理されるネットワークがあります。インターフェイスのクライアント側のノードとルーターは、このエンティティによって制御されず、「信頼されていない」と見なされます。このインターフェイスのネットワーク側のノードとルーターは、信頼されていると見なされます。
It is possible for a malicious node acting as a relay agent on the untrusted side of this interface to supply an RSOO containing one or more RSOO-enabled options that would override the same option or options that were provided by a relay agent on the trusted side of the interface.
このインターフェイスの信頼されていない側面にリレーエージェントとして機能する悪意のあるノードが、信頼できる側面のリレーエージェントによって提供された同じオプションまたはオプションをオーバーライドする1つ以上のRSOO対応オプションを含むRSOOを提供する可能性がありますインターフェイスの。
In environments where this is a possibility, network administrators are advised to use relay agents that are capable of dropping Relay-Forward messages containing the RSOO, and are advised to configure those relay agents to drop such messages.
これが可能な環境では、ネットワーク管理者は、RSOOを含むリレーフォワードメッセージを削除できるリレーエージェントを使用することをお勧めし、そのようなメッセージをドロップするようにそれらのリレーエージェントを構成することをお勧めします。
Note, however, that this will only be effective if the message from the DHCP server to the DHCP client is authenticated as specified in Section 21 of [RFC3315], or using some similar mechanism. Without this authentication, the malicious node on the untrusted portion of the network can simply modify the DHCP server's response in transit back to the DHCP client, and there is no way for the client to detect that this has happened.
ただし、これは、DHCPサーバーからDHCPクライアントへのメッセージが[RFC3315]のセクション21で指定されているように認証されている場合、または同様のメカニズムを使用している場合にのみ有効になることに注意してください。この認証がなければ、ネットワークの信頼されていない部分の悪意のあるノードは、DHCPクライアントへのトランジットでのDHCPサーバーの応答を単純に変更できます。クライアントがこれが起こったことを検出する方法はありません。
IANA has assigned one new DHCPv6 option code from the registry of DHCP Option Codes maintained at http://www.iana.org/. The option code 66 (OPTION_RSOO) has been assigned to the Relay-Supplied Options option.
IANAは、http://www.iana.org/に維持されているDHCPオプションコードのレジストリから1つの新しいDHCPV6オプションコードを割り当てました。オプションコード66（option_rSOO）は、リレーサプリドオプションオプションに割り当てられています。
IANA has created a new registry on the same assignments page, titled "Options Permitted in the Relay-Supplied Options Option". This registry will enumerate the set of all code points from the DHCP Option Codes table for options that may appear in the RSOO. Options may be added to this list after IETF Review [RFC5226]. When adding options to the list, please ensure that the description for the code added matches the description in the DHCP Option Codes table for that code. Option codes that have not been requested to be added according to the stated procedure should not be mentioned at all in the table, and should not be listed as "reserved" or "unassigned".
IANAは、「リレーサプライオプションオプションで許可されているオプション」というタイトルの同じ割り当てページに新しいレジストリを作成しました。このレジストリは、RSOOに表示される可能性のあるオプションのDHCPオプションコードテーブルからすべてのコードポイントのセットを列挙します。IETFレビュー[RFC5226]の後、オプションをこのリストに追加できます。リストにオプションを追加するときは、追加されたコードの説明が、そのコードのDHCPオプションコードテーブルの説明と一致することを確認してください。指定された手順に従って追加されるように要求されていないオプションコードは、表にまったく言及されるべきではなく、「予約されていない」または「割り当てされていない」とリストされるべきではありません。
IETF Review should include careful consideration of the security implications of allowing a relay agent to provide a value for the option being considered for addition to this registry. In the case where an IETF working group chartered to review DHCP protocol extensions exists, it is not sufficient for some other working group to review the registry addition.
IETFレビューには、リレーエージェントがこのレジストリへの追加のために検討されているオプションの価値を提供できるようにすることのセキュリティへの影響を慎重に検討する必要があります。IETFワーキンググループがDHCPプロトコル拡張をレビューするためにチャーターした場合、他のワーキンググループがレジストリの追加をレビューするだけでは不十分です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296] Narayanan、V。およびL. Dondeti、「EAP再認証プロトコル（ERP）のEAP拡張」、RFC 5296、2008年8月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440] Zorn、G.、Wu、Q.、およびY. Wang、「EAP再認証プロトコル（ERP）ローカルドメイン名DHCPV6オプション」、RFC 6440、2011年12月。
Authors' Addresses
著者のアドレス
Ted Lemon Nominum 2000 Seaport Blvd. Redwood City, CA 94063 USA
Ted Lemon Nominum 2000 Seaport Blvd.カリフォルニア州レッドウッドシティ94063米国
Phone: +1 650 381 6000
EMail: mellon@nominum.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Qin Wu Huawei Technologies Co.、Ltd。101 Software Avenue、Yuhua District Nanjing、Jiangsu 210012 China
Phone: +86-25-56623633
EMail: sunseawq@huawei.com