[要約] RFC 7969は、ネットワークトポロジに基づいてDHCP設定をカスタマイズするためのガイドラインです。その目的は、ネットワークの効率性と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 7969 Nominum, Inc.
Category: Informational T. Mrugalski
ISSN: 2070-1721 ISC
October 2016
Customizing DHCP Configuration on the Basis of Network Topology
ネットワークトポロジに基づくDHCP構成のカスタマイズ
Abstract
概要
DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.
DHCPサーバーは、DHCPベースの仕様で説明されている以上の重要な機能を提供するように長年にわたって進化してきました。この機能の1つの側面は、コンテキスト固有の構成情報のサポートです。このメモは、いくつかのそのような機能を説明し、それらの操作を説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc7969.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7969で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Client's Location by DHCP Servers . . . . . . . . 3
3.1. DHCPv4-Specific Behavior . . . . . . . . . . . . . . . . 7
3.2. DHCPv6-Specific Behavior . . . . . . . . . . . . . . . . 7
4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 10
5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 12
6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 12
7. Regional Configuration Example . . . . . . . . . . . . . . . 13
8. Multiple Subnets on the Same Link . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications describe how addresses can be allocated to clients based on network topology information provided by the DHCP relay infrastructure. Address allocation decisions are integral to the allocation of addresses and prefixes in DHCP.
DHCPv4 [RFC2131]およびDHCPv6 [RFC3315]プロトコル仕様は、DHCPリレーインフラストラクチャによって提供されるネットワークトポロジ情報に基づいて、クライアントにアドレスを割り当てる方法を記述しています。アドレス割り当ての決定は、DHCPでのアドレスとプレフィックスの割り当てに不可欠です。
The DHCP protocol also describes mechanisms for provisioning devices with additional configuration information, for example, DNS [RFC1034] server addresses, default DNS search domains, and similar information.
DHCPプロトコルは、DNS [RFC1034]サーバーアドレス、デフォルトのDNS検索ドメイン、および同様の情報など、追加の構成情報でデバイスをプロビジョニングするためのメカニズムについても説明しています。
Although it was the intent of the authors of these specifications that DHCP servers would provision devices with configuration information appropriate to each device's location on the network, this practice was never documented, much less described in detail.
DHCPサーバーがネットワーク上の各デバイスの場所に適した構成情報をデバイスにプロビジョニングすることは、これらの仕様の作成者の意図でしたが、この方法は文書化されておらず、詳細はあまり説明されていません。
Existing DHCP server implementations do in fact provide such capabilities; the goal of this document is to describe those capabilities for the benefit of both operators and protocol designers who may wish to use DHCP as a means for configuring their own services but may not be aware of the capabilities provided by most modern DHCP servers.
既存のDHCPサーバーの実装は実際にそのような機能を提供します。このドキュメントの目的は、独自のサービスを構成する手段としてDHCPを使用したいが、ほとんどの最新のDHCPサーバーが提供する機能を認識していない可能性があるオペレーターとプロトコル設計者の両方のために、これらの機能について説明することです。
o CPE device: Customer Premise Equipment device. Typically a router belonging to the customer that connects directly to the provider link.
o CPEデバイス：Customer Premise Equipmentデバイス。通常、プロバイダーリンクに直接接続する顧客に属するルーター。
o DHCP, DHCPv4, and DHCPv6: DHCP refers to the Dynamic Host Configuration Protocol in general and applies to both DHCPv4 and DHCPv6. The terms DHCPv4 and DHCPv6 are used in contexts where it is necessary to avoid ambiguity and explain differences.
o DHCP、DHCPv4、およびDHCPv6：DHCPは一般に動的ホスト構成プロトコルを指し、DHCPv4とDHCPv6の両方に適用されます。 DHCPv4およびDHCPv6という用語は、あいまいさを避けて違いを説明する必要があるコンテキストで使用されます。
o PE router: Provider Edge router. The provider router closest to the customer.
o PEルーター：プロバイダーエッジルーター。カスタマーに最も近いプロバイダールータ。
o Routable IP address: An IP address with a scope of use wider than the local link.
o ルーティング可能なIPアドレス：使用範囲がローカルリンクよりも広いIPアドレス。
o Shared subnet: A case where two or more subnets of the same protocol family are available on the same link. 'Shared subnet' terminology is typically used in Unix environments. It is typically called 'multinet' in the Windows environment. The administrative configuration inside a Microsoft DHCP server is called 'DHCP Superscope'.
o 共有サブネット：同じプロトコルファミリの2つ以上のサブネットが同じリンクで使用できる場合。 「共有サブネット」という用語は、通常、UNIX環境で使用されます。通常、Windows環境では「マルチネット」と呼ばれます。 Microsoft DHCPサーバー内の管理構成は、「DHCPスーパースコープ」と呼ばれます。
o Link or local link: A layer 2 network link, as defined in Section 1.2 of [RFC3297].
o リンクまたはローカルリンク：[RFC3297]のセクション1.2で定義されているレイヤー2ネットワークリンク。
o Link subset: A portion of a link containing a subset of all the connection points on that link, which may be used to finely determine the physical location of a set of clients or may be used to determine topology to a finer degree of detail than the set of all locations at which that particular link is available. The smallest link subset is a single link attachment point, for example, a port on a layer 2 switch.
o リンクサブセット：そのリンク上のすべての接続ポイントのサブセットを含むリンクの一部。これは、クライアントのセットの物理的な場所を詳細に決定するために使用したり、トポロジよりも詳細なトポロジを決定するために使用したりできます特定のリンクが利用できるすべての場所のセット。最小のリンクサブセットは、単一のリンク接続ポイント、たとえば、レイヤー2スイッチのポートです。
Figure 1 illustrates a small hierarchy of network links with Link D serving as a backbone to which the DHCP server is attached.
図1は、リンクDがDHCPサーバーが接続されているバックボーンとして機能するネットワークリンクの小さな階層を示しています。
Figure 2 illustrates a more complex case. Although some of its aspects are unlikely to be seen in actual production networks, they are beneficial for explaining finer aspects of the DHCP protocols. Note that some nodes act as routers (which forward all IP traffic) and some are relay agents (i.e., they run DHCP-specific software that forwards only DHCP traffic).
図2は、より複雑なケースを示しています。実際の実稼働ネットワークでは見られない側面もありますが、DHCPプロトコルの細かい側面を説明するのに役立ちます。一部のノードはルーターとして機能し（すべてのIPトラフィックを転送します）、一部のノードはリレーエージェントです（つまり、DHCPトラフィックのみを転送するDHCP固有のソフトウェアを実行します）。
Link A Link B
|===+===========| |===========+======|
| |
| |
+---+---+ +---+---+
| relay | | relay |
| A | | B |
+---+---+ +---+---+
| |
| Link C |
|===+==========+=================+======|
|
|
+----+---+ +--------+
| router | | DHCP |
| A | | Server |
+----+---+ +----+---+
| |
| |
| Link D |
|==============+=================+======|
|
|
+----+---+
| router |
| B |
+----+---+
|
|
|===+==========+=================+======|
| Link E |
| |
+---+---+ +---+---+
| relay | | relay |
| C | | D |
+---+---+ +---+---+
| |
| |
|===+===========| |===========+======|
Link F Link G
Figure 1: A Simple Network with a Small Hierarchy of Links
図1：リンクの小さな階層を持つ単純なネットワーク
Link A Link B Link H
|===+==========| |=========+======| |======+======|
| | |
| | |
+---+---+ +---+---+ +---+---+
| relay | | relay | | relay |
| A | | B | | G |
+---+---+ +---+---+ +---+---+
| | |
| Link C | | Link J
|===+==========+==============+======| |======+======|
| |
| |
+----+---+ +--------+ +---+---+
| router | | DHCP | | relay |
| A | | Server | | F |
+----+---+ +----+---+ +---+---+
| | |
| | |
| Link D | |
|==============+=========+=======+=============+======|
| |
| |
+----+---+ +---+---+
| router | | relay |
| B | | E |
+----+---+ +---+---+
| |
| |
|===+==========+=========+=======+======|
| Link E |
| |
+---+---+ +---+---+
| relay | | relay |
| C | | D |
+---+---+ +---+---+
| |
| |
|===+===========| |===========+======|
Link F Link G
Figure 2: Complex Network
図2：複雑なネットワーク
These diagrams allow us to represent a variety of different network configurations and illustrate how existing DHCP servers can provide configuration information customized to the particular location from which a client is making its request.
これらの図により、さまざまな異なるネットワーク構成を表すことができ、既存のDHCPサーバーがクライアントが要求を行う特定の場所にカスタマイズされた構成情報をどのように提供できるかを示します。
It is important to understand the background of how DHCP works when considering those diagrams. It is assumed that the DHCP clients may not have routable IP addresses when they are attempting to obtain configuration information.
これらの図を検討する場合は、DHCPの動作の背景を理解することが重要です。 DHCPクライアントは、構成情報を取得しようとしているときに、ルーティング可能なIPアドレスを持たない可能性があると想定されています。
The reason for making this assumption is that one of the functions of DHCP is to bootstrap the DHCP client's IP address configuration. If the client does not yet have an IP address configured, it cannot route packets to an off-link DHCP server; therefore, some kind of relay mechanism is required.
この仮定を行う理由は、DHCPの機能の1つがDHCPクライアントのIPアドレス構成をブートストラップすることであるからです。クライアントにまだIPアドレスが構成されていない場合、クライアントはパケットをオフリンクDHCPサーバーにルーティングできません。したがって、何らかのリレーメカニズムが必要です。
The details of how packet delivery between clients and servers works are different between DHCPv4 and DHCPv6, but the essence is the same: whether or not the client actually has an IP configuration, it generally communicates with the DHCP server by sending its requests to a DHCP relay agent on the local link; this relay agent, which has a routable IP address, then forwards the DHCP requests to the DHCP server (directly or via other relays). In later stages of the configuration, when the client has acquired an address and certain conditions are met, it is possible for the client to send packets directly to the server, thus bypassing the relays. The conditions for such behavior are different for DHCPv4 and DHCPv6 and are discussed in Sections 3.1 and 3.2.
クライアントとサーバー間のパケット配信の仕組みの詳細はDHCPv4とDHCPv6で異なりますが、本質は同じです。クライアントが実際にIP構成を持っているかどうかに関係なく、クライアントは通常、要求をDHCPに送信してDHCPサーバーと通信します。ローカルリンク上のリレーエージェント。ルーティング可能なIPアドレスを持つこのリレーエージェントは、DHCP要求を（直接または他のリレーを介して）DHCPサーバーに転送します。構成の後半の段階で、クライアントがアドレスを取得し、特定の条件が満たされると、クライアントがサーバーに直接パケットを送信して、リレーをバイパスすることができます。このような動作の条件はDHCPv4とDHCPv6では異なり、セクション3.1と3.2で説明します。
To determine the client's point of attachment and link-specific configuration, the server typically uses the client-facing IP address of the relay agent. In some cases, the server may use the routable IP address of the client if the client has the routable IP address assigned to its interface and it is transmitted in the DHCP message. The server is then able to determine the client's point of attachment and select the appropriate subnet- or link-specific configuration.
クライアントの接続ポイントとリンク固有の構成を決定するために、サーバーは通常、リレーエージェントのクライアント側IPアドレスを使用します。場合によっては、クライアントにルーティング可能なIPアドレスがインターフェイスに割り当てられており、DHCPメッセージで送信される場合、サーバーはクライアントのルーティング可能なIPアドレスを使用することがあります。その後、サーバーはクライアントの接続ポイントを決定し、適切なサブネットまたはリンク固有の構成を選択できます。
Sometimes it is useful for the relay agents to provide additional information about the topology. A number of extensions have been defined for this purpose. The specifics are different, but the core principle remains the same: the relay agent knows exactly where the original request came from, so it provides an identifier that will help the server to choose appropriate address pool and configuration parameters. Examples of such options are mentioned in the following sections.
リレーエージェントがトポロジに関する追加情報を提供すると便利な場合があります。この目的のために、いくつかの拡張機能が定義されています。詳細は異なりますが、基本的な原則は同じです。リレーエージェントは元のリクエストの送信元を正確に把握しているため、サーバーが適切なアドレスプールと構成パラメータを選択するのに役立つ識別子を提供します。このようなオプションの例については、次のセクションで説明します。
Finally, clients may be connected to the same link as the server, so no relay agents are required. In such cases, the DHCPv4 server typically uses the IPv4 address assigned to the network interface over which the transmission was received to select an appropriate subnet. This is more complicated for DHCPv6, as the DHCPv6 server is not required to have any globally unique addresses. In such cases, additional configuration information may need to be required. Some servers allow indicating that a given subnet is directly reachable over a specific local network interface.
最後に、クライアントはサーバーと同じリンクに接続できるため、リレーエージェントは必要ありません。このような場合、DHCPv4サーバーは通常、送信が受信されたネットワークインターフェイスに割り当てられたIPv4アドレスを使用して、適切なサブネットを選択します。 DHCPv6サーバーはグローバルに一意のアドレスを持つ必要がないため、これはDHCPv6の場合はさらに複雑です。このような場合、追加の構成情報が必要になることがあります。一部のサーバーでは、特定のローカルネットワークインターフェイスを介して特定のサブネットに直接到達できることを示すことができます。
In some cases in DHCPv4, when a DHCPv4 client has a routable IPv4 address, the message is unicast to the DHCPv4 server rather than going through a relay agent. Examples of such transmissions are renewal (DHCPREQUEST) and address release (DHCPRELEASE).
DHCPv4の一部のケースでは、DHCPv4クライアントがルーティング可能なIPv4アドレスを持っている場合、メッセージはリレーエージェントを経由するのではなく、DHCPv4サーバーにユニキャストされます。そのような送信の例は、更新（DHCPREQUEST）とアドレス解放（DHCPRELEASE）です。
The relay agent that receives the client's message sets the giaddr field to the address of the network interface the message was received on. The relay agent may insert a relay agent option [RFC3046].
クライアントのメッセージを受信するリレーエージェントは、メッセージが受信されたネットワークインターフェイスのアドレスにgiaddrフィールドを設定します。リレーエージェントは、リレーエージェントオプション[RFC3046]を挿入できます。
There are several options defined that are useful for subnet selection in DHCPv4. [RFC3527] defines the Link Selection sub-option that is inserted by a relay agent. This option is particularly useful when the relay agent needs to specify the subnet/link on which a DHCPv4 client resides, which is different from an IP address that can be used to communicate with the relay agent. The Virtual Subnet Selection (VSS) sub-option, specified in [RFC6607], can also be added by a relay agent to specify information in a VPN environment. In certain cases, it is useful for the client itself to specify the Virtual Subnet Selection option, e.g., when there are no relay agents involved during the VPN setup process.
DHCPv4でのサブネット選択に役立ついくつかのオプションが定義されています。 [RFC3527]は、リレーエージェントによって挿入されるリンク選択サブオプションを定義します。このオプションは、リレーエージェントがDHCPv4クライアントが存在するサブネット/リンクを指定する必要がある場合に特に役立ちます。これは、リレーエージェントとの通信に使用できるIPアドレスとは異なります。 [RFC6607]で指定されている仮想サブネット選択（VSS）サブオプションは、VPN環境で情報を指定するためにリレーエージェントによって追加することもできます。たとえば、VPNセットアッププロセス中にリレーエージェントが関与していない場合など、クライアント自体が仮想サブネットの選択オプションを指定すると便利な場合があります。
Another option that may influence the subnet selection is the IPv4 Subnet Selection option, defined in [RFC3011], which allows the client to explicitly request allocation from a given subnet.
サブネットの選択に影響を与える可能性のある別のオプションは、[RFC3011]で定義されているIPv4サブネット選択オプションです。これにより、クライアントは特定のサブネットからの割り当てを明示的に要求できます。
In DHCPv6, unicast communication is possible in cases where the server is configured with a Server Unicast option (see Section 22.12 in [RFC3315]) and clients are able to take advantage of it. In such cases, once a client is assigned a (presumably global) address, it is able to contact the server directly, bypassing any relays. It should be noted that such a mode is completely controllable by administrators in DHCPv6. (They may simply choose to not configure the Server Unicast option, thus forcing clients to always send their messages via relay agents in every case).
DHCPv6では、サーバーにサーバーユニキャストオプション（[RFC3315]のセクション22.12を参照）が構成されていて、クライアントがそれを利用できる場合に、ユニキャスト通信が可能です。このような場合、クライアントに（おそらくグローバル）アドレスが割り当てられると、リレーをバイパスしてサーバーに直接接続できます。 DHCPv6では、このようなモードは管理者が完全に制御できることに注意してください。 （サーバーユニキャストオプションを設定しないように選択することもあるので、クライアントは常に、常にリレーエージェント経由でメッセージを送信する必要があります）。
The DHCPv6 protocol [RFC3315] defines two core mechanisms that allow a server to distinguish which link the relay agent is connected to. The first mechanism is the link-address field in the Relay-forward and Relay-reply messages. The link-address field uniquely identifies the link and should not be mistaken for a link-local address. In normal circumstances, this is the solution that is easiest to maintain, as existing address assignments can be used and no additional administrative actions (like assigning dedicated identifiers for each relay agent, making sure they are unique, and maintaining a list of such identifiers) are needed. It requires, however, for the relay agent to have an address with a scope larger than link-local configured on its client-facing interface.
DHCPv6プロトコル[RFC3315]は、リレーエージェントが接続されているリンクをサーバーが区別できるようにする2つのコアメカニズムを定義しています。最初のメカニズムは、Relay-forwardおよびRelay-replyメッセージのリンクアドレスフィールドです。リンクアドレスフィールドはリンクを一意に識別し、リンクローカルアドレスと間違えないでください。通常の状況では、これは、既存のアドレス割り当てを使用でき、追加の管理アクション（各リレーエージェントに専用の識別子を割り当て、それらが一意であることを確認し、そのような識別子のリストを維持するなど）がないため、維持が最も簡単なソリューションです。必要です。ただし、リレーエージェントは、クライアント側のインターフェイスで構成されたリンクローカルよりも大きなスコープを持つアドレスを持つ必要があります。
The second mechanism uses an Interface-ID option (see Section 22.18 of [RFC3315]) inserted by the relay agent, which identifies the link that the client is connected to. This mechanism may be used when the relay agent does not have a globally unique address or Unique Local Address (ULA) [RFC4193] configured on its client-facing interface, thus making the first mechanism not feasible. If the interface-id is unique within an administrative domain, the interface-id value may be used to select the appropriate subnet. As there is no guarantee for the uniqueness ([RFC3315] only mandates the interface-id to be unique within a single relay agent context), it is up to the administrator to check whether the relay agents deployed use unique interface-id values. If the interface-id values are not unique, the Interface-ID option cannot be used to determine the client's point of attachment.
2番目のメカニズムでは、リレーエージェントによって挿入されたInterface-IDオプション（[RFC3315]のセクション22.18を参照）を使用して、クライアントが接続されているリンクを識別します。このメカニズムは、リレーエージェントのクライアント側のインターフェイスにグローバルに一意のアドレスまたは一意のローカルアドレス（ULA）[RFC4193]が構成されていない場合に使用される可能性があるため、最初のメカニズムは実現できません。 interface-idが管理ドメイン内で一意である場合、interface-id値を使用して適切なサブネットを選択できます。一意性は保証されないため（[RFC3315]は、インターフェースIDが単一のリレーエージェントコンテキスト内で一意であることのみを義務付けています）、展開されたリレーエージェントが一意のインターフェースID値を使用するかどうかを確認するのは管理者の責任です。 interface-id値が一意でない場合、Interface-IDオプションを使用してクライアントの接続ポイントを決定することはできません。
It should be noted that Relay-forward and Relay-reply messages are exchanged between relays and servers only. Clients are never exposed to those messages. Also, servers never receive Relay-reply messages. Relay agents must be able to process both Relay-forward (sending an already relayed message further towards the server when there is more than one relay agent in a chain) and Relay-reply (sending back the response towards the client when there is more than one relay agent in a chain).
リレー転送メッセージとリレー応答メッセージは、リレーとサーバーの間でのみ交換されることに注意してください。クライアントがこれらのメッセージにさらされることはありません。また、サーバーはリレー応答メッセージを受信しません。リレーエージェントは、リレー転送（チェーンに複数のリレーエージェントが存在する場合は既にリレーされたメッセージをサーバーに向けて送信する）とリレー応答（クライアントに複数の場合はクライアントに応答を送信する）の両方を処理できる必要があります。チェーン内の1つのリレーエージェント）。
For completeness, we also mention an uncommon but valid case where relay agents use a link-local address in the link-address field in relayed Relay-forward messages. This may happen if the relay agent doesn't have any address with a larger scope on the interface connected to that specific link. Even though link-local addresses cannot be automatically used to associate the relay agent with a given link, with additional configuration information, the server may still be able to select the proper link.
完全を期すために、リレーエージェントがリレーされたリレー転送メッセージのリンクアドレスフィールドにリンクローカルアドレスを使用する、珍しいが有効なケースについても説明します。これは、その特定のリンクに接続されているインターフェース上に、より広いスコープを持つアドレスがリレーエージェントにない場合に発生する可能性があります。リンクローカルアドレスを使用してリレーエージェントを特定のリンクに関連付けることはできませんが、追加の構成情報を使用すると、サーバーは適切なリンクを選択できる場合があります。
This requires that the DHCP server has a way of associating a particular link-local address with a particular link. The network administrator can then explicitly configure the DHCP server to recognize that the particular link-address field in a relay message refers to that link.
これには、DHCPサーバーが特定のリンクローカルアドレスを特定のリンクに関連付ける方法が必要です。ネットワーク管理者は、リレーメッセージの特定のリンクアドレスフィールドがそのリンクを参照していることを認識するように、DHCPサーバーを明示的に構成できます。
There are two ways that this can work. One is that the DHCP server can provide a mechanism that explicitly associates the link-local address with a link. In this case, the network administrator simply determines the link-local address of the relay agent on a particular link, which we are presuming to be stable, and configures an association between that address and the link.
これが機能する方法は2つあります。 1つは、DHCPサーバーがリンクローカルアドレスをリンクに明示的に関連付けるメカニズムを提供できることです。この場合、ネットワーク管理者は、安定していると推定される特定のリンク上のリレーエージェントのリンクローカルアドレスを決定し、そのアドレスとリンク間の関連付けを構成します。
If the DHCP server doesn't explicitly provide such a mechanism, it may still provide a "shared subnet" mechanism (see Section 8). If it does, the shared subnet mechanism can be used to explicitly associate a link-local address with a link. To do this, the network administrator creates a shared subnet association for the link, if one does not already exist. The network administrator then configures a /128 subnet that contains just the link-local address of the relay agent. The administrator then adds this new /128 to the shared subnet. Now, when a DHCP message comes in with that link-layer address in the link-address field, the correct shared network will be selected.
DHCPサーバーがそのようなメカニズムを明示的に提供しない場合でも、「共有サブネット」メカニズムを提供する可能性があります（セクション8を参照）。その場合、共有サブネットメカニズムを使用して、リンクローカルアドレスをリンクに明示的に関連付けることができます。これを行うために、ネットワーク管理者はリンクの共有サブネットアソシエーションを作成します（まだ存在しない場合）。次に、ネットワーク管理者は、リレーエージェントのリンクローカルアドレスのみを含む/ 128サブネットを構成します。次に、管理者はこの新しい/ 128を共有サブネットに追加します。これで、リンクアドレスフィールドにそのリンク層アドレスが含まれるDHCPメッセージが届くと、正しい共有ネットワークが選択されます。
DHCPv6 also has support for more finely grained link identification using Lightweight DHCPv6 Relay Agents (LDRAs) [RFC6221]. In this case, the link-address field is set to an unspecified address (::), but the DHCPv6 server also receives an Interface-ID option from the relay agent that can be used to more precisely identify the client's location on the network. It is possible to mix LDRA and regular relay agents in the same network. See Sections 7.2 and 7.3 in [RFC6221] for detailed examples.
DHCPv6は、軽量DHCPv6リレーエージェント（LDRA）[RFC6221]を使用して、よりきめ細かいリンク識別もサポートしています。この場合、リンクアドレスフィールドは未指定のアドレス（：:)に設定されますが、DHCPv6サーバーは、ネットワーク上のクライアントの場所をより正確に識別するために使用できるリレーエージェントからインターフェイスIDオプションも受け取ります。同じネットワーク内でLDRAと通常のリレーエージェントを混在させることができます。詳細な例については、[RFC6221]のセクション7.2および7.3を参照してください。
What this means in practice is that the DHCP server has sufficient information in all cases to pinpoint the link to which the client is connected. In some cases, it may additionally be possible to pinpoint the particular link subset to which the client is connected.
これが実際に意味することは、クライアントが接続されているリンクを正確に特定するのに十分な情報がDHCPサーバーにあるということです。場合によっては、クライアントが接続されている特定のリンクサブセットを特定することも可能です。
In all cases, then, the DHCPv6 server will have a link-identifying IP address, and in some cases, it may also have a link-specific identifier (e.g., the Interface-ID option or the Link Address option defined in Section 5 of [RFC6977]). It should be noted that the link-specific identifier is unique only within the scope of the link-identifying IP address. For example, the link-specific identifier of "eth0" assigned to a relay agent using IPv6 address 2001:db8::1 is distinct from an "eth0" identifier used by a different relay agent with address 2001:db8::2.
すべての場合において、DHCPv6サーバーはリンクを識別するIPアドレスを持ち、場合によっては、リンク固有の識別子（例：のセクション5で定義されたインターフェイスIDオプションまたはリンクアドレスオプション）を持つこともあります。 [RFC6977]）。リンク固有の識別子は、リンクを識別するIPアドレスの範囲内でのみ一意であることに注意してください。たとえば、IPv6アドレス2001：db8 :: 1を使用してリレーエージェントに割り当てられたリンク固有の識別子「eth0」は、アドレス2001：db8 :: 2を持つ別のリレーエージェントによって使用される「eth0」識別子とは異なります。
It is also possible for link-specific identifiers to be nested so that the actual identifier that identifies the specific link subset is an aggregate of two or more identifiers sent by a set of LDRAs in a chain; in general, this functions exactly as if a single identifier were received from a single LDRA, so we do not treat it specially in the discussion below, but sites that use chained LDRA configurations will need to be aware of this when configuring their DHCPv6 servers.
リンク固有の識別子をネストして、特定のリンクサブセットを識別する実際の識別子が、チェーン内のLDRAのセットによって送信された2つ以上の識別子の集合になるようにすることもできます。一般に、これは単一のIDが単一のLDRAから受信されたかのように機能するため、以下の説明では特別に扱いませんが、チェーンされたLDRA構成を使用するサイトは、DHCPv6サーバーを構成するときにこれを認識する必要があります。
The Virtual Subnet Selection options, present in DHCPv4, are also defined for DHCPv6. The use case is the same as in DHCPv4: the relay agent inserts VSS options that can help the server to select the appropriate subnet with its address pool and associated configuration options. See [RFC6607] for details.
DHCPv4にある仮想サブネット選択オプションは、DHCPv6にも定義されています。使用例はDHCPv4と同じです。リレーエージェントは、サーバーがアドレスプールと関連する構成オプションを使用して適切なサブネットを選択するのに役立つVSSオプションを挿入します。詳細については、[RFC6607]を参照してください。
Consider Figure 1 in the context of a simple subnetted network. In this network, there are four leaf subnets on which DHCP clients will be configured: Links A, B, F, and G. Relays A, B, C, and D in this example are represented in the diagram as IP routers with an embedded relay function, because this is a very typical configuration, but the relay function can also be provided in a separate node on each link.
単純なサブネット化ネットワークのコンテキストで図1を検討してください。このネットワークには、DHCPクライアントが構成される4つのリーフサブネットがあります。リンクA、B、F、およびGです。この例のリレーA、B、C、およびDは、組み込みのIPルーターとして図に表されていますこれは非常に典型的な構成であるため、リレー機能ですが、リレー機能は各リンクの個別のノードに提供することもできます。
In a simple network like this, there may be no need for link-specific configuration in DHCPv6, since local routing information is delivered through router advertisements. However, in IPv4, it is very typical to configure the default route using DHCP; in this case, the default route will be different on each link. In order to accomplish this, the DHCP server will need link-specific configuration for the default route.
このような単純なネットワークでは、ローカルルーティング情報はルーターアドバタイズメントを通じて配信されるため、DHCPv6でリンク固有の構成を行う必要がない場合があります。ただし、IPv4では、DHCPを使用してデフォルトルートを設定するのが非常に一般的です。この場合、デフォルトルートはリンクごとに異なります。これを実現するために、DHCPサーバーはデフォルトルートのリンク固有の構成を必要とします。
To illustrate, we will use an example from a hypothetical DHCP server that uses a simple JSON notation [RFC7159] for configuration. Although we know of no DHCP server that uses this specific syntax, most modern DHCP servers provide similar functionality.
説明のために、設定に単純なJSON表記[RFC7159]を使用する架空のDHCPサーバーの例を使用します。この特定の構文を使用するDHCPサーバーはありませんが、最近のほとんどのDHCPサーバーは同様の機能を提供しています。
{
"prefixes": {
"192.0.2.0/26": {
"options": {
"routers": ["192.0.2.1"]
},
"on-link": ["A"]
},
"192.0.2.64/26": {
"options": {
"routers": ["192.0.2.65"]
},
"on-link": ["B"]
},
"192.0.2.128/26": {
"options": {
"routers": ["192.0.2.129"]
},
"on-link": ["F"]
},
"192.0.2.192/26": {
"options": {
"routers": ["192.0.2.193"]
},
"on-link": ["G"]
}
}
}
Figure 3: Configuration Example
図3：構成例
In Figure 3, we see a configuration example for this scenario: a set of prefixes, each of which has a set of options and a list of links for which it is on-link. We have defined one option for each prefix: a routers option. This option contains a list of values; each list only has one value, and that value is the IP address of the router specific to the prefix.
図3に、このシナリオの構成例を示します。一連のプレフィックスには、それぞれに一連のオプションと、リンク上にあるリンクのリストがあります。プレフィックスごとに1つのオプション、ルーターオプションを定義しました。このオプションには値のリストが含まれています。各リストには値が1つだけあり、その値はプレフィックスに固有のルーターのIPアドレスです。
When the DHCP server receives a request, it searches the list of prefixes for one that encloses the link-identifying IP address provided by the client or relay agent. The DHCP server then examines the options list associated with that prefix and returns those options to the client.
DHCPサーバーは要求を受信すると、クライアントまたはリレーエージェントによって提供されたリンクを識別するIPアドレスを含むプレフィックスのリストを検索します。 DHCPサーバーは、そのプレフィックスに関連付けられたオプションリストを調べ、それらのオプションをクライアントに返します。
So, for example, a client connected to Link A in the example would have a link-identifying IP address within the 192.0.2.0/26 prefix, so the DHCP server would match it to that prefix. Based on the configuration, the DHCP server would then return a routers option containing a single IP address: 192.0.2.1. A client on Link F would have a link-identifying address in the 192.0.2.128/26 prefix and would receive a routers option containing the IP address 192.0.2.129.
したがって、たとえば、例のリンクAに接続されたクライアントは、192.0.2.0 / 26プレフィックス内にリンクを識別するIPアドレスを持っているため、DHCPサーバーはそのプレフィックスと一致します。 DHCPサーバーは、構成に基づいて、単一のIPアドレス192.0.2.1を含むルーターオプションを返します。リンクF上のクライアントは、192.0.2.128 / 26プレフィックスにリンク識別アドレスを持ち、IPアドレス192.0.2.129を含むルーターオプションを受け取ります。
A relay agent is DHCP software that may be run on any IP node. Although it is typically run on a router, this is by no means required by the DHCP protocol. The relay agent is simply a service that operates on a link, receiving link-local multicasts (IPv6) or broadcasts (IPv4) and relaying them, using IP routing, to a DHCP server. As long as the relay has an IP address on the link and a default route or a more specific route through which it can reach a DHCP server, it need not be a router or even have multiple interfaces.
リレーエージェントは、任意のIPノードで実行できるDHCPソフトウェアです。通常はルーター上で実行されますが、これはDHCPプロトコルが必要とするものではありません。リレーエージェントは、リンク上で動作し、リンクローカルマルチキャスト（IPv6）またはブロードキャスト（IPv4）を受信し、IPルーティングを使用してDHCPサーバーに中継するサービスです。リレーのIPアドレスがリンク上にあり、DHCPサーバーに到達できるデフォルトルートまたはより具体的なルートである限り、リレーはルーターである必要はなく、複数のインターフェイスを持つ必要もありません。
A relay agent can be run on a host connected to two links. That case is presented in Figure 2. There is router B that is connected to Links D and E. At the same time, there is also a host that is connected to the same links. The relay agent software is running on that host. That is uncommon but is a valid configuration.
リレーエージェントは、2つのリンクに接続されたホスト上で実行できます。そのケースを図2に示します。リンクDおよびEに接続されているルーターBがあります。同時に、同じリンクに接続されているホストもあります。リレーエージェントソフトウェアがそのホストで実行されています。これは一般的ではありませんが、有効な構成です。
Let's observe another case, shown in Figure 2. Note that in this configuration, the clients connected to Link G will send their requests to relay D, which will forward its packets directly to the DHCP server. That is typical but not the only possible configuration. It is possible to configure relay agent D to forward client messages to relay E, which in turn will send them to the DHCP server. This configuration is sometimes referred to as "cascaded relay agents".
図2に示す別のケースを見てみましょう。この構成では、リンクGに接続されたクライアントが要求をリレーDに送信し、リレーDがパケットを直接DHCPサーバーに転送します。これが一般的ですが、可能な構成はこれだけではありません。クライアントメッセージをリレーEに転送するようにリレーエージェントDを構成することが可能です。リレーEは、メッセージをDHCPサーバーに送信します。この構成は、「カスケードリレーエージェント」と呼ばれることもあります。
Note that the relaying mechanism works differently in DHCPv4 and in DHCPv6. In DHCPv4, only the first relay is able to set the giaddr field in the DHCPv4 packet. Any following relays that receive that packet will not change it as the server needs giaddr information from the first relay (i.e., the closest to the client). The server will send the response back to the giaddr address, which is the address of the first relay agent that saw the client's message. That means that the client messages travel on a different path than the server's responses. A message from a client connected to Link G will pass through relay D, then through relay E, to reach the server. A response message will be sent from the server to relay D via router B, and relay D will send it to the client on Link G.
リレーメカニズムは、DHCPv4とDHCPv6では動作が異なることに注意してください。 DHCPv4では、最初のリレーのみがDHCPv4パケットのgiaddrフィールドを設定できます。サーバーは最初のリレー（つまり、クライアントに最も近いリレー）からのgiaddr情報を必要とするため、そのパケットを受信する後続のリレーはパケットを変更しません。サーバーは、クライアントのメッセージを見た最初のリレーエージェントのアドレスであるgiaddrアドレスに応答を送信します。つまり、クライアントメッセージはサーバーの応答とは異なるパスを移動します。リンクGに接続されたクライアントからのメッセージは、リレーDを通過し、次にリレーEを通過してサーバーに到達します。サーバーからルーターB経由でリレーDに応答メッセージが送信され、リレーDがリンクGでクライアントに送信します。
Relaying in DHCPv6 is more structured. Each relay agent encapsulates a packet that is destined to the server and sends it towards the server. Depending on the configuration, that can be a server's unicast address, a multicast address, or the next relay agent address. The next relay repeats the encapsulation process. Although the resulting packet is more complex (may have up to 32 levels of encapsulation if the packet traveled through 32 relays), every relay may insert its own options, and it is clear which relay agent inserted which option.
DHCPv6でのリレーはより構造化されています。各リレーエージェントは、サーバー宛のパケットをカプセル化し、サーバーに送信します。構成に応じて、サーバーのユニキャストアドレス、マルチキャストアドレス、または次のリレーエージェントアドレスになります。次のリレーは、カプセル化プロセスを繰り返します。結果のパケットはより複雑ですが（パケットが32のリレーを通過する場合、最大32レベルのカプセル化が可能です）、すべてのリレーが独自のオプションを挿入する可能性があり、どのリレーエージェントがどのオプションを挿入したかは明らかです。
In the Figure 2 example, Link C is a regional backbone for an ISP. Link E is also a regional backbone for that ISP. Relays A, B, C, and D are PE routers, and Links A, B, F, and G are actually link aggregators with individual layer 2 circuits to each customer -- for example, the relays might be Digital Subscriber Line Access Multiplexers (DSLAMs) or cable head-end systems. At each customer site, we assume there is a single CPE device attached to the link.
図2の例では、リンクCはISPのリージョナルバックボーンです。リンクEは、そのISPのリージョナルバックボーンでもあります。リレーA、B、C、およびDはPEルーターであり、リンクA、B、F、およびGは実際には、個々のレイヤー2回路を持つアグリゲーターを各顧客にリンクしています-たとえば、リレーはデジタル加入者回線アクセスマルチプレクサー（ DSLAM）またはケーブルヘッドエンドシステム。各顧客サイトでは、リンクに接続された単一のCPEデバイスがあると想定しています。
We further assume that Links A, B, F, and G are each addressed by a single prefix, although it would be equally valid for each CPE device to be numbered on a separate prefix.
さらに、リンクA、B、F、およびGはそれぞれ1つのプレフィックスでアドレス指定されていると想定していますが、各CPEデバイスが別々のプレフィックスで番号付けされることも同様に有効です。
In a real-world deployment, there would likely be many more than two PE routers connected to each regional backbone; we have kept the number small for simplicity.
実際の展開では、各地域のバックボーンに接続されているPEルーターが3つ以上ある可能性があります。簡単にするために、この数は小さくしています。
In the example presented in Figure 4, the goal is to configure all the devices within a region with server addresses local to that region, so that service traffic does not have to be routed between regions unnecessarily.
図4に示す例の目的は、リージョン内のすべてのデバイスに、そのリージョンにローカルなサーバーアドレスを設定することです。これにより、サービストラフィックをリージョン間で不必要にルーティングする必要がなくなります。
{
"prefixes": {
"2001:db8::/40": {
"on-link": ["A"]
},
"2001:db8:100::/40": {
"on-link": ["B"]
},
"2001:db8:200::/40": {
"on-link": ["F"]
},
"2001:db8:300::/40": {
"on-link": ["G"]
}
},
"links": {
"A": {"region": "omashu"},
"B": {"region": "omashu"},
"F": {"region": "gaoling"},
"G": {"region": "gaoling"}
},
"regions": {
"omashu": {
"options": {
"SIP Server": ["sip.omashu.example.org"],
"DNS Recursive Name Server": ["dns1.omashu.example.org",
"dns2.omashu.example.org"]
}
},
"gaoling": {
"options": {
"SIP Server": ["sip.gaoling.example.org"],
"DNS Recursive Name Server": ["dns1.gaoling.example.org",
"dns2.gaoling.example.org"]
}
}
}
}
Figure 4: Regional Configuration Example
図4：地域構成の例
In this example, when a request comes in to the DHCPv6 server with a link-identifying IP address in the 2001:db8::/40 prefix, it is identified as being on Link A. The DHCPv6 server then looks on the list of links to see what region the client is in. Link A is identified as being in omashu. The DHCPv6 server then looks up omashu in the set of regions and discovers a list of region-specific options.
この例では、要求が2001：db8 :: / 40プレフィックスのリンク識別IPアドレスでDHCPv6サーバーに入ると、リンクAにあると識別されます。DHCPv6サーバーは、リンクのリストを調べますリンクAはオマシュにあると識別されます。 DHCPv6サーバーは、リージョンのセットでomashuを検索し、リージョン固有のオプションのリストを検出します。
The DHCPv6 server then resolves the domain names listed in the options and sends a SIP Server option containing the IP addresses that the resolver returned for sip.omashu.example.org and a DNS Recursive Name Server option containing the IP addresses returned by the resolver for dns1.omashu.example.org and dns2.omashu.example.org. Depending on the server capability and configuration, it may cache resolved responses for a specific period of time, repeat queries every time, or even keep the response until reconfiguration or shutdown. For more detailed discussion, see Section 7 of [RFC7227].
DHCPv6サーバーは、オプションにリストされているドメイン名を解決し、リゾルバーがsip.omashu.example.orgに対して返したIPアドレスを含むSIPサーバーオプションと、リゾルバーが返したIPアドレスを含むDNS再帰ネームサーバーオプションを送信します。 dns1.omashu.example.orgおよびdns2.omashu.example.org。サーバーの機能と構成に応じて、解決された応答を特定の期間キャッシュしたり、毎回クエリを繰り返したり、再構成またはシャットダウンするまで応答を保持したりすることもあります。詳細については、[RFC7227]のセクション7をご覧ください。
Similarly, if the DHCPv6 server receives a request from a DHCPv6 client where the link-identifying IP address is contained by the prefix 2001:db8:300::/40, then the DHCPv6 server identifies the client as being connected to Link G. The DHCPv6 server then identifies Link G as being in the gaoling region and returns the SIP Server and DNS Recursive Name Server options specific to that region.
同様に、DHCPv6サーバーがリンク識別IPアドレスがプレフィックス2001：db8：300 :: / 40に含まれているDHCPv6クライアントから要求を受信した場合、DHCPv6サーバーはクライアントがリンクGに接続されていると識別します。 DHCPv6サーバーはリンクGをgaolingリージョンにあると識別し、そのリージョンに固有のSIPサーバーおよびDNS再帰ネームサーバーオプションを返します。
As with the previous example, the exact configuration syntax and structure shown above does not precisely match what existing DHCPv6 servers do, but the behavior illustrated in this example can be accomplished with most existing modern DHCPv6 servers.
前の例と同様に、上記の正確な構成構文と構造は既存のDHCPv6サーバーの動作と正確には一致しませんが、この例に示されている動作は、ほとんどの既存のDHCPv6サーバーで実現できます。
There are scenarios where there is more than one subnet from the same protocol family (i.e., two or more IPv4 subnets or two or more IPv6 subnets) configured on the same link. Such a configuration is often referred to as 'shared subnets' in Unix environments or 'multinet' in Microsoft terminology.
同じプロトコルファミリからの複数のサブネット（つまり、2つ以上のIPv4サブネットまたは2つ以上のIPv6サブネット）が同じリンク上に構成されているシナリオがあります。このような構成は、Unix環境では「共有サブネット」またはMicrosoft用語では「マルチネット」と呼ばれることがよくあります。
The most frequently mentioned use case is a network renumbering where some services are migrated to the new addressing scheme, but some aren't yet.
最も頻繁に言及される使用例は、一部のサービスが新しいアドレッシングスキームに移行されるネットワーク再番号付けですが、一部はまだ移行されていません。
A second example is expanding the allocation space. In DHCPv4 and for DHCPv6 Prefix Delegation, there could be cases where multiple subnets are needed, because a single subnet may be too small to accommodate the client population.
2番目の例は、割り当てスペースの拡張です。 DHCPv4およびDHCPv6プレフィックス委任では、単一のサブネットが小さすぎてクライアントの人口を収容できない場合があるため、複数のサブネットが必要になる場合があります。
The third use case covers allocating addresses (or delegation prefixes) that are not the same as topological information. For example, the link-address is on prefix X, and the addresses to be assigned are on prefix Y. This could be based on differentiating information (i.e., whether the device is a CPE or cable modem in the Data Over Cable Service Interface Specification (DOCSIS)) or just because the link-address/giaddr is different from the actual allocation space.
3番目の使用例では、トポロジー情報と同じではないアドレス（または委任プレフィックス）の割り当てについて説明します。たとえば、リンクアドレスはプレフィックスXにあり、割り当てられるアドレスはプレフィックスYにあります。これは、差別化情報に基づいている可能性があります（つまり、デバイスがデータオーバーケーブルサービスインターフェイス仕様のCPEであるかケーブルモデムであるか） （DOCSIS））またはlink-address / giaddrが実際の割り当てスペースと異なるからです。
The fourth use case is a cable network, where cable modems and the devices connected behind them are connected to the same layer 2 link. However, operators want the cable modems and user devices to get addresses from distinct address spaces, so users couldn't easily access their modems' management interfaces.
4番目の使用例はケーブルネットワークで、ケーブルモデムとその背後に接続されているデバイスが同じレイヤ2リンクに接続されています。ただし、オペレーターはケーブルモデムとユーザーデバイスが個別のアドレススペースからアドレスを取得することを望んでいるため、ユーザーはモデムの管理インターフェイスに簡単にアクセスできませんでした。
To support such a configuration, additional differentiating information is required. Many DHCP server implementations offer a feature that is typically called "client classification". The server segregates incoming packets into one or more classes based on certain packet characteristics, e.g., the presence or value of certain options or even a match between existing options. Servers require additional information to handle such configuration, as they cannot use the topographical property of the relay addresses alone to properly choose a subnet. Exact details of such an operation are not part of the DHCPv4 or DHCPv6 protocols and are implementation dependent.
このような構成をサポートするには、追加の識別情報が必要です。多くのDHCPサーバー実装は、通常「クライアント分類」と呼ばれる機能を提供します。サーバーは、特定のオプションの存在や値、既存のオプション間の一致など、特定のパケット特性に基づいて、着信パケットを1つ以上のクラスに分離します。サーバーは、リレーアドレスのみのトポロジプロパティを使用してサブネットを適切に選択できないため、このような構成を処理するには追加情報が必要です。そのような操作の正確な詳細は、DHCPv4またはDHCPv6プロトコルの一部ではなく、実装に依存します。
This document explains existing practice with respect to the use of Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host Configuration Protocol Version 6 [RFC3315]. The security considerations for these protocols are described in their specifications and in related documents that extend these protocols.
このドキュメントでは、動的ホスト構成プロトコル[RFC2131]と動的ホスト構成プロトコルバージョン6 [RFC3315]の使用に関する既存の方法について説明します。これらのプロトコルのセキュリティに関する考慮事項は、仕様およびこれらのプロトコルを拡張する関連ドキュメントに記載されています。
The mechanisms described in this document could possibly be exploited by an attacker to misrepresent its point of attachment in the network. This would cause the server to assign addresses, prefixes, and other configuration options, which can be considered a leak of information. In particular, this could be used as a preliminary stage of an attack when the DHCP server leaks information about available services in parts of the network the attacker does not have access to.
このドキュメントで説明されているメカニズムは、攻撃者によって悪用されて、ネットワーク内の接続ポイントを偽装する可能性があります。これにより、サーバーはアドレス、プレフィックス、およびその他の構成オプションを割り当てます。これらは情報の漏えいと見なすことができます。特に、これは、攻撃者がアクセスできないネットワークの一部で利用可能なサービスに関する情報がDHCPサーバーから漏洩した場合に、攻撃の予備段階として使用される可能性があります。
There are several ways that such an attack can be prevented. First, it is a common practice to filter DHCP traffic passing to clients within a particular administrative domain from outside of that domain, and also to filter DHCP traffic to clients outside of a particular administrative domain from within that domain. Second, the DHCP servers can be configured to not respond to traffic that is coming from unknown subnets (i.e., those subnets the server is not configured to serve). Third, some relays provide the ability to reject messages that do not fit expected characteristics. For example, the Cable Modem Termination System (CMTS) acting as a DHCP relay detects if the Media Access Control (MAC) address specified in chaddr in incoming DHCP messages matches the MAC address of the cable modem it came from and can alter its behavior accordingly. Also, relay agents and servers that are connected to clients directly can reject traffic that looks as if it has passed a relay (this could indicate the client is attempting to spoof a relay, possibly to inject forged relay options).
このような攻撃を防ぐ方法はいくつかあります。最初に、特定の管理ドメイン内のクライアントに渡されるDHCPトラフィックをそのドメイン外からフィルタリングし、特定の管理ドメイン外のクライアントへのDHCPトラフィックをそのドメイン内からフィルタリングすることも一般的な方法です。 2番目に、DHCPサーバーは、不明なサブネット（つまり、サーバーが機能するように構成されていないサブネット）からのトラフィックに応答しないように構成できます。 3番目に、一部のリレーは、期待される特性に適合しないメッセージを拒否する機能を提供します。たとえば、DHCPリレーとして機能するケーブルモデムターミネーションシステム（CMTS）は、着信DHCPメッセージのchaddrで指定されたメディアアクセス制御（MAC）アドレスが、元のケーブルモデムのMACアドレスと一致するかどうかを検出し、それに応じてその動作を変更できます。 。また、クライアントに直接接続されているリレーエージェントとサーバーは、リレーを通過したかのように見えるトラフィックを拒否できます（これは、クライアントがリレーを偽装しようとしている可能性があり、偽造されたリレーオプションを挿入している可能性があります）。
There are a number of general DHCP recommendations that should be considered in all DHCP deployments. While not strictly related to the mechanisms described in this document, they may be useful in certain deployment scenarios. [RFC7819] and [RFC7824] provide an analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If those are of concern, [RFC7844] offers mitigation steps.
すべてのDHCP展開で検討する必要がある一般的なDHCP推奨事項がいくつかあります。このドキュメントで説明されているメカニズムに厳密には関係していませんが、特定の展開シナリオで役立つ場合があります。 [RFC7819]と[RFC7824]は、それぞれDHCPv4とDHCPv6のプライバシー問題の分析を提供します。それらが懸念される場合、[RFC7844]は緩和ステップを提供します。
Current DHCPv4 and DHCPv6 standards lack strong cryptographic protection. There is an ongoing effort in the DHC working group to address this. [SECURE-DHCPv6] attempts to provide a mechanism for strong authentication and encryption between DHCPv6 clients and servers. [SECURITY-MESSAGES] attempts to improve security of exchanges between DHCP relay agents and servers.
現在のDHCPv4およびDHCPv6標準には、強力な暗号保護がありません。 DHCワーキンググループでは、これに対処するための継続的な取り組みがあります。 [SECURE-DHCPv6]は、DHCPv6クライアントとサーバー間の強力な認証と暗号化のメカニズムを提供しようとします。 [SECURITY-MESSAGES]は、DHCPリレーエージェントとサーバー間の交換のセキュリティを改善しようとします。
Another possible attack vector is to set up a rogue DHCP server and provide clients with false information, either as a denial of service or to execute a man-in-the-middle type of attack. This can be mitigated by deploying DHCPv6-Shield [RFC7610].
別の可能な攻撃方法は、不正なDHCPサーバーをセットアップし、サービス拒否として、または中間者タイプの攻撃を実行して、クライアントに誤った情報を提供することです。これは、DHCPv6-Shield [RFC7610]を導入することで軽減できます。
Finally, there is an ongoing effort to update the DHCPv6 specification, which is currently 13 years old. Sections 21 ("Security Considerations") and 22 ("Privacy Considerations") of [DHCPv6bis] contain more recent analysis of the security and privacy considerations.
最後に、現在13年前のDHCPv6仕様を更新するための継続的な取り組みがあります。 [DHCPv6bis]のセクション21（「セキュリティに関する考慮事項」）および22（「プライバシーに関する考慮事項」）には、セキュリティおよびプライバシーに関する考慮事項のより最近の分析が含まれています。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[DHCPv6bis] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Work in Progress, draft-ietf-dhc-rfc3315bis-05, June 2016.
[DHCPv6bis] Mrugalski、T.、Siodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T。、およびT. Winters、「IPv6の動的ホスト構成プロトコル（DHCPv6）bis "、Work in Progress、draft-ietf-dhc-rfc3315bis-05、2016年6月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", RFC 3011, DOI 10.17487/RFC3011, November 2000, <http://www.rfc-editor.org/info/rfc3011>.
[RFC3011]ウォーターズ、G。、「DHCPのIPv4サブネット選択オプション」、RFC 3011、DOI 10.17487 / RFC3011、2000年11月、<http://www.rfc-editor.org/info/rfc3011>。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, <http://www.rfc-editor.org/info/rfc3046>.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、DOI 10.17487 / RFC3046、2001年1月、<http://www.rfc-editor.org/info/rfc3046>。
[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, DOI 10.17487/RFC3297, July 2002, <http://www.rfc-editor.org/info/rfc3297>.
[RFC3297] Klyne、G.、Iwazaki、R。、およびD. Crocker、「電子メールに基づくメッセージングサービスのコンテンツネゴシエーション」、RFC 3297、DOI 10.17487 / RFC3297、2002年7月、<http：//www.rfc-editor .org / info / rfc3297>。
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April 2003, <http://www.rfc-editor.org/info/rfc3527>.
[RFC3527] Kinnear、K.、Stapp、M.、Johnson、R.、J。Kumarasamy、「DHCPv4のリレーエージェント情報オプションのリンク選択サブオプション」、RFC 3527、DOI 10.17487 / RFC3527、2003年4月、 <http://www.rfc-editor.org/info/rfc3527>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <http://www.rfc-editor.org/info/rfc6221>.
[RFC6221] Miles、D.、Ed。、Ooghe、S.、Dec、W.、Krishnan、S.、and A. Kavanagh、 "Lightweight DHCPv6 Relay Agent"、RFC 6221、DOI 10.17487 / RFC6221、May 2011、< http://www.rfc-editor.org/info/rfc6221>。
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", RFC 6607, DOI 10.17487/RFC6607, April 2012, <http://www.rfc-editor.org/info/rfc6607>.
[RFC6607] Kinnear、K.、Johnson、R。、およびM. Stapp、「DHCPv4およびDHCPv6の仮想サブネット選択オプション」、RFC 6607、DOI 10.17487 / RFC6607、2012年4月、<http：//www.rfc-editor .org / info / rfc6607>。
[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 Reconfiguration from Relay Agents", RFC 6977, DOI 10.17487/RFC6977, July 2013, <http://www.rfc-editor.org/info/rfc6977>.
[RFC6977] Boucadair、M。およびX. Pougnard、「トリガーリレーエージェントからのDHCPv6再構成」、RFC 6977、DOI 10.17487 / RFC6977、2013年7月、<http://www.rfc-editor.org/info/rfc6977>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[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, <http://www.rfc-editor.org/info/rfc7227>.
[RFC7227] Hankins、D.、Mrugalski、T.、Siodelski、M.、Jiang、S。、およびS. Krishnan、「新しいDHCPv6オプションを作成するためのガイドライン」、BCP 187、RFC 7227、DOI 10.17487 / RFC7227、2014年5月、<http://www.rfc-editor.org/info/rfc7227>。
[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, <http://www.rfc-editor.org/info/rfc7610>.
[RFC7610] Gont、F.、Liu、W。、およびG. Van de Velde、「DHCPv6-Shield：Protecting to Rogue DHCPv6 Servers」、BCP 199、RFC 7610、DOI 10.17487 / RFC7610、2015年8月、<http：/ /www.rfc-editor.org/info/rfc7610>。
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, April 2016, <http://www.rfc-editor.org/info/rfc7819>.
[RFC7819] Jiang、S.、Krishnan、S。、およびT. Mrugalski、「DHCPのプライバシーに関する考慮事項」、RFC 7819、DOI 10.17487 / RFC7819、2016年4月、<http://www.rfc-editor.org/info / rfc7819>。
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, <http://www.rfc-editor.org/info/rfc7824>.
[RFC7824]クリシュナン、S.、Mrugalski、T。、およびS. Jiang、「DHCPv6のプライバシーに関する考慮事項」、RFC 7824、DOI 10.17487 / RFC7824、2016年5月、<http://www.rfc-editor.org/info / rfc7824>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<http://www.rfc-editor.org/ info / rfc7844>。
[SECURE-DHCPv6] Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. Zhang, "Secure DHCPv6", Work in Progress, draft-ietf-dhc-sedhcpv6-14, October 2016.
[SECURE-DHCPv6] Jiang、S.、Li、L.、Cui、Y.、Jinmei、T.、Lemon、T。、およびD. Zhang、「Secure DHCPv6」、Work in Progress、draft-ietf-dhc- sedhcpv6-14、2016年10月。
[SECURITY-MESSAGES] Volz, B. and Y. Pal, "Security of Messages Exchanged Between Servers and Relay Agents", Work in Progress, draft-volz-dhc-relay-server-security-02, September 2016.
[SECURITY-MESSAGES] Volz、B。およびY. Pal、「サーバーとリレーエージェント間で交換されるメッセージのセキュリティ」、進行中の作業、draft-volz-dhc-relay-server-security-02、2016年9月。
Acknowledgements
謝辞
Thanks to Dave Thaler for suggesting that even though "everybody knows" how DHCP servers are deployed in the real world, it might be worthwhile to have an IETF document that explains what everybody knows, because in reality not everybody is an expert in how DHCP servers are administered. Thanks to Andre Kostur, Carsten Strotmann, Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-Francois Tremblay, Marcin Siodelski, Bernie Volz, and Yaron Sheffer for their reviews, comments, and feedback.
DHCPサーバーが実際にどのように展開されているかを「誰もが知っている」としても、誰もが知っていることを説明するIETF文書を用意することは価値があるかもしれないと示唆しているDave Thalerに感謝します。投与されます。 Andre Kostur、Carsten Strotmann、Simon Perreault、Jinmei Tatuya、Suresh Krishnan、Qi Sun、Jean-Francois Tremblay、Marcin Siodelski、Bernie Volz、Yaron Shefferのレビュー、コメント、フィードバックに感謝します。
Authors' Addresses
著者のアドレス
Ted Lemon Nominum, Inc. 800 Bridge Parkway, Suite 100 Redwood City, CA 94065 United States of America
Ted Lemon Nominum、Inc. 800 Bridge Parkway、Suite 100 Redwood City、CA 94065アメリカ合衆国
Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 United States of America
Tomek Mrugalski Internet Systems Consortium、Inc. 950 Charter Street Redwood City、CA 94063アメリカ合衆国
Phone: +1-650-423-1345
Email: tomasz.mrugalski@gmail.com