[要約] RFC 7341は、IPv6ネットワーク上でIPv4のDHCPを提供するためのプロトコルであり、IPv6上でIPv4のDHCPトラフィックを転送することを目的としています。
Internet Engineering Task Force (IETF) Q. Sun
Request for Comments: 7341 Y. Cui
Category: Standards Track Tsinghua University
ISSN: 2070-1721 M. Siodelski
ISC
S. Krishnan
Ericsson
I. Farrer
Deutsche Telekom AG
August 2014
DHCPv4-over-DHCPv6 (DHCP 4o6) Transport
DHCPv4-over-DHCPv6（DHCP 4o6）トランスポート
Abstract
概要
IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.
ネットワークがIPv6に移行するにつれて、IPv4接続が依然として必要です。サービスプロバイダーへのアップリンクがIPv6のみをサポートしている場合でも、ユーザーはIPv4構成を必要とします。このドキュメントでは、DHCPv6トランスポートを介してDHCPv4メッセージを伝送することにより、IPv6ネットワークでIPv4構成情報を動的に取得するメカニズムについて説明します。この目的のために、2つの新しいDHCPv6メッセージと2つの新しいDHCPv6オプションが定義されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7341.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7341で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 ....................................................3
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. Applicability ...................................................4
5. Architecture Overview ...........................................4
6. New DHCPv6 Messages .............................................6
6.1. Message Types ..............................................6
6.2. Message Formats ............................................6
6.3. DHCPv4-query Message Flags .................................7
6.4. DHCPv4-response Message Flags ..............................7
7. New DHCPv6 Options ..............................................7
7.1. DHCPv4 Message Option Format ...............................7
7.2. DHCP 4o6 Server Address Option Format ......................8
8. Use of the DHCPv4-query Unicast Flag ............................9
9. DHCP 4o6 Client Behavior .......................................10
10. Relay Agent Behavior ..........................................12
11. DHCP 4o6 Server Behavior ......................................12
12. Security Considerations .......................................13
13. IANA Considerations ...........................................14
14. Contributors List .............................................14
15. References ....................................................14
15.1. Normative References .....................................14
15.2. Informative References ...................................15
As the migration towards IPv6 continues, IPv6-only networks will become more prevalent. In such networks, IPv4 connectivity will continue to be provided as a service over IPv6-only networks. In addition to provisioning IPv4 addresses for clients of this service, other IPv4 configuration parameters may also be needed (e.g., addresses of IPv4-only services).
IPv6への移行が続くにつれて、IPv6のみのネットワークがますます普及するようになります。このようなネットワークでは、IPv4接続はIPv6のみのネットワークを介したサービスとして引き続き提供されます。このサービスのクライアントにIPv4アドレスをプロビジョニングすることに加えて、他のIPv4構成パラメーターも必要になる場合があります（IPv4のみのサービスのアドレスなど）。
This document describes a transport mechanism to carry DHCPv4 messages using the DHCPv6 protocol for the dynamic provisioning of IPv4 addresses and other DHCPv4 specific configuration parameters across IPv6-only networks. It leverages the existing DHCPv4 infrastructure, e.g., failover, DNS updates, DHCP Leasequery, etc.
このドキュメントでは、IPv6アドレスを動的にプロビジョニングするためにDHCPv6プロトコルを使用してDHCPv4メッセージを伝送するトランスポートメカニズムと、IPv6のみのネットワーク全体で他のDHCPv4固有の構成パラメータについて説明します。既存のDHCPv4インフラストラクチャを活用します（フェイルオーバー、DNSアップデート、DHCP Leasequeryなど）。
When IPv6 multicast is used to transport DHCP 4o6 messages, another benefit is that the operator can gain information about the underlying IPv6 network to which the DHCP 4o6 client is connected from the DHCPv6 relay agents through which the request has passed.
IPv4マルチキャストを使用してDHCP 4o6メッセージを転送する場合、もう1つの利点は、オペレーターが、要求が通過したDHCPv6リレーエージェントから、DHCP 4o6クライアントが接続されている基本的なIPv6ネットワークに関する情報を取得できることです。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
CPE: Customer Premises Equipment (also known as Customer Provided Equipment), which provides access for devices connected to a Local Area Network (LAN), typically at the customer's site/home, to the Internet Service Provider's (ISP's) network.
CPE：Customer Premises Equipment（別名Customer Provided Equipment）。これは、ローカルエリアネットワーク（LAN）に接続されたデバイス（通常は顧客のサイト/ホーム）からインターネットサービスプロバイダー（ISP）のネットワークへのアクセスを提供します。
DHCP 4o6 client (or client): A DHCP client supporting both the DHCPv6 protocol [RFC3315] as well as the DHCPv4 over DHCPv6 protocol described in this document. Such a client is capable of requesting IPv6 configuration using DHCPv6 and IPv4 configuration using DHCPv4 over DHCPv6.
DHCP 4o6クライアント（またはクライアント）：DHCPv6プロトコル[RFC3315]と、このドキュメントで説明されているDHCPv4 over DHCPv6プロトコルの両方をサポートするDHCPクライアント。このようなクライアントは、DHCPv6を使用してIPv6構成を要求し、DHCPv6 over DHCPv4を使用してIPv4構成を要求できます。
DHCP 4o6 server (or server): A DHCP server that is capable of processing DHCPv4 packets encapsulated in the DHCPv4 Message option (defined below).
DHCP 4o6サーバー（またはサーバー）：DHCPv4メッセージオプション（以下で定義）にカプセル化されたDHCPv4パケットを処理できるDHCPサーバー。
DHCPv4 over DHCPv6: A protocol (described in this document) used to carry DHCPv4 messages in the payload of DHCPv6 messages.
DHCPv6 over DHCPv6：DHCPv6メッセージのペイロードでDHCPv4メッセージを伝送するために使用されるプロトコル（このドキュメントで説明）。
The mechanism described in this document is not universally applicable. This is intended as a special-purpose mechanism that will be implemented on nodes that must obtain IPv4 configuration information using DHCPv4 in specific environments where native DHCPv4 is not available. Such nodes are expected to follow the advice in Section 9; nodes that do not require this functionality are expected not to implement it, or not to enable it by default. This mechanism may be enabled using an administrative control, or it may be enabled automatically in accordance with the needs of some dual-stack transition mechanism such as [LW4OVER6]. Such mechanisms are beyond the scope of this document.
このドキュメントで説明されているメカニズムは、普遍的に適用できるわけではありません。これは、ネイティブDHCPv4が使用できない特定の環境でDHCPv4を使用してIPv4構成情報を取得する必要があるノードに実装される特別な目的のメカニズムとして意図されています。そのようなノードは、セクション9のアドバイスに従うことが期待されます。この機能を必要としないノードは、それを実装しないか、デフォルトで有効にしないことが期待されます。このメカニズムは、管理コントロールを使用して有効にすることも、[LW4OVER6]などのいくつかのデュアルスタック移行メカニズムのニーズに応じて自動的に有効にすることもできます。このようなメカニズムは、このドキュメントの範囲を超えています。
The architecture described here addresses a typical use case, where a DHCP client's uplink supports IPv6 only and the Service Provider's network supports IPv6 and limited IPv4 services. In this scenario, the client can only use the IPv6 network to access IPv4 services, so IPv4 services must be configured using IPv6 as the underlying network protocol.
ここで説明するアーキテクチャは、DHCPクライアントのアップリンクがIPv6のみをサポートし、サービスプロバイダーのネットワークがIPv6および限定されたIPv4サービスをサポートする一般的な使用例に対応しています。このシナリオでは、クライアントはIPv6ネットワークのみを使用してIPv4サービスにアクセスできるため、IPv4サービスは、基礎となるネットワークプロトコルとしてIPv6を使用して構成する必要があります。
Although the purpose of this document is to address the problem of communication between the DHCPv4 client and the DHCPv4 server, the mechanism that it describes does not restrict the transported messages types to DHCPv4 only. As the DHCPv4 message is a special type of BOOTP message, BOOTP messages [RFC951] MAY also be transported using the same mechanism.
このドキュメントの目的はDHCPv4クライアントとDHCPv4サーバー間の通信の問題に対処することですが、それが説明するメカニズムは、転送されるメッセージタイプをDHCPv4のみに制限しません。 DHCPv4メッセージは特殊なタイプのBOOTPメッセージであるため、BOOTPメッセージ[RFC951]も同じメカニズムを使用して転送できます。
DHCP clients may be running on CPE devices, end hosts, or any other device that supports the DHCP-client function. This document uses the CPE as an example for describing the mechanism. This does not preclude any end host, or other device requiring IPv4 configuration, from implementing DHCPv4 over DHCPv6 in the future.
DHCPクライアントは、CPEデバイス、エンドホスト、またはDHCPクライアント機能をサポートするその他のデバイスで実行されている可能性があります。このドキュメントでは、メカニズムを説明するための例としてCPEを使用します。これにより、エンドホスト、またはIPv4構成を必要とするその他のデバイスがDHCPv6 over DHCPv6を将来実装することを妨げることはありません。
This mechanism works by carrying DHCPv4 messages encapsulated within the newly defined DHCPv6 messages. The DHCPv6-relay encapsulation is used solely to deliver DHCPv4 packets to a DHCPv4-capable server, and does not allocate any IPv6 addresses nor does it provide IPv6-configuration information to the client. Figure 1, below, illustrates one possible deployment architecture of this mechanism.
このメカニズムは、新しく定義されたDHCPv6メッセージ内にカプセル化されたDHCPv4メッセージを運ぶことによって機能します。 DHCPv6-relayカプセル化は、DHCPv4パケットをDHCPv4対応サーバーに配信するためにのみ使用され、IPv6アドレスを割り当てたり、IPv6構成情報をクライアントに提供したりしません。下の図1は、このメカニズムの1つの可能な展開アーキテクチャを示しています。
The DHCP 4o6 client implements a new DHCPv6 message called DHCPv4-query, which carries a DHCPv4 message encapsulated in the new DHCPv4 Message option. The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents or directly to the DHCP 4o6 server.
DHCP 4o6クライアントは、新しいDHCPv4メッセージオプションにカプセル化されたDHCPv4メッセージを運ぶDHCPv4-queryと呼ばれる新しいDHCPv6メッセージを実装します。 DHCPv6メッセージは、DHCPv6リレーエージェントを介して、または直接DHCP 4o6サーバーに送信できます。
The server replies with a new DHCPv6 message called DHCPv4-response, which carries the DHCPv4 message from the server, encapsulated in the DHCPv4 Message option.
サーバーは、サーバーからのDHCPv4メッセージを運ぶDHCPv4応答と呼ばれる新しいDHCPv6メッセージで応答し、DHCPv4メッセージオプションにカプセル化されます。
_____________ _____________
/ \ / \
| | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP 4o6 | Network | DHCPv6 | Network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
\_____________/ \_____________/
Figure 1: Architecture Overview
図1：アーキテクチャの概要
Before the client can use DHCPv4 over DHCPv6, it MUST obtain the necessary IPv6 configuration. The client requests the DHCP 4o6 Server Address option from the server by sending the option code in an Option Request option as described in [RFC3315]. If the server responds with the DHCP 4o6 Server Address option, it is an indication to the client to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration. Otherwise, the client MUST NOT use DHCPv4 over DHCPv6 to request IPv4 configuration.
クライアントは、DHCPv6 over DHCPv4を使用する前に、必要なIPv6構成を取得する必要があります。 [RFC3315]で説明されているように、オプション要求オプションでオプションコードを送信することにより、クライアントはサーバーにDHCP 4o6サーバーアドレスオプションを要求します。サーバーがDHCP 4o6サーバーアドレスオプションで応答する場合、それはクライアントにDHCPv6 over DHCPv6を使用してIPv4構成を取得しようとすることを示しています。それ以外の場合、クライアントはIPv4構成を要求するためにDHCPv6ではなくDHCPv4を使用してはなりません（MUST NOT）。
The client obtains the address(es) of the DHCP 4o6 server(s) from the DHCP 4o6 Server Address option and uses it (them) to communicate with the DHCP 4o6 servers as described in Section 9. If the DHCP 4o6 Server Address option contains no addresses (is empty), the client uses the well-known All_DHCP_Relay_Agents_and_Servers multicast address to communicate with the DHCP 4o6 server(s).
クライアントは、DHCP 4o6サーバーのアドレスオプションからDHCP 4o6サーバーのアドレスを取得し、そのアドレスを使用して、セクション9で説明されているようにDHCP 4o6サーバーと通信します。DHCP4o6サーバーアドレスオプションにアドレスがない（空の）場合、クライアントは既知のAll_DHCP_Relay_Agents_and_Serversマルチキャストアドレスを使用してDHCP 4o6サーバーと通信します。
Before applying for an IPv4 address via a DHCPv4-query message, the client must identify a suitable network interface for the address. Once the request is acknowledged by the server, the client can configure the address and other relevant parameters on this interface. The mechanism for determining a suitable interface is out of the scope of the document.
DHCPv4-queryメッセージを介してIPv4アドレスを申請する前に、クライアントはそのアドレスに適したネットワークインターフェイスを識別する必要があります。要求がサーバーによって確認されると、クライアントはこのインターフェイスでアドレスおよびその他の関連パラメーターを構成できます。適切なインターフェースを決定するメカニズムは、ドキュメントの範囲外です。
Two new DHCPv6 messages carry DHCPv4 messages between the client and the server using the DHCPv6 protocol: DHCPv4-query and DHCPv4-response. This section describes the structures of these messages.
2つの新しいDHCPv6メッセージは、DHCPv6プロトコルを使用してクライアントとサーバー間でDHCPv4メッセージを伝達します：DHCPv4-queryとDHCPv4-response。このセクションでは、これらのメッセージの構造について説明します。
DHCPV4-QUERY (20): The DHCP 4o6 client sends a DHCPv4-query message to a DHCP 4o6 server. The DHCPv4 Message option carried by this message contains a DHCPv4 message that the DHCP 4o6 client uses to request IPv4 configuration parameters from the server.
DHCPV4-QUERY（20）：DHCP 4o6クライアントはDHCPv4-queryメッセージをDHCP 4o6サーバーに送信します。このメッセージに含まれるDHCPv4メッセージオプションには、DHCP 4o6クライアントがサーバーからIPv4構成パラメーターを要求するために使用するDHCPv4メッセージが含まれています。
DHCPV4-RESPONSE (21): A DHCP 4o6 server sends a DHCPv4-response message to a DHCP 4o6 client. It contains a DHCPv4 Message option carrying a DHCPv4 message in response to a DHCPv4 message received by the server in the DHCPv4 Message option of the DHCPv4-query message.
DHCPV4-RESPONSE（21）：DHCP 4o6サーバーはDHCPv4-responseメッセージをDHCP 4o6クライアントに送信します。 DHCPv4クエリメッセージのDHCPv4メッセージオプションでサーバーが受信したDHCPv4メッセージに応答してDHCPv4メッセージを運ぶDHCPv4メッセージオプションが含まれています。
Both DHCPv6 messages defined in this document share the following format:
このドキュメントで定義されている両方の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Format of DHCPv4-query and DHCPv4-response Messages
図2：DHCPv4-queryおよびDHCPv4-responseメッセージのフォーマット
msg-type: Identifies the message type. It can be either DHCPV4-QUERY (20) or DHCPV4-RESPONSE (21) corresponding to the contained DHCPv4-query or DHCPv4-response, respectively.
msg-type：メッセージタイプを識別します。含まれているDHCPv4-queryまたはDHCPv4-responseにそれぞれ対応するDHCPV4-QUERY（20）またはDHCPV4-RESPONSE（21）のいずれかです。
flags: Specifies flags providing additional information required by the server to process the DHCPv4 message encapsulated in the DHCPv4-query message, or required by the client to process a DHCPv4 message encapsulated in the DHCPv4-response message.
flags：サーバーがDHCPv4-queryメッセージにカプセル化されたDHCPv4メッセージを処理するために必要な追加情報、またはクライアントがDHCPv4-responseメッセージにカプセル化されたDHCPv4メッセージを処理するために必要な追加情報を提供するフラグを指定します。
options: Options carried by the message. The DHCPv4 Message Option (described in Section 7.1) MUST be carried by the message. Only DHCPv6 options for IPv4 configuration may be included in this field. It MUST NOT contain DHCPv6 options related solely to IPv6, or IPv6-only service configuration.
options：メッセージが運ぶオプション。 DHCPv4メッセージオプション（セクション7.1で説明）は、メッセージによって運ばれる必要があります。このフィールドに含めることができるのは、IPv4構成のDHCPv6オプションのみです。 IPv6のみに関連するDHCPv6オプション、またはIPv6のみのサービス構成を含めることはできません。
The "flags" field of the DHCPv4-query is used to carry additional information that may be used by the server to process the encapsulated DHCPv4 message. Currently, only one bit of this field is used. Remaining bits are reserved for the future use. The "flags" field has the following format:
DHCPv4-queryの「フラグ」フィールドは、サーバーがカプセル化されたDHCPv4メッセージを処理するために使用できる追加情報を運ぶために使用されます。現在、このフィールドの1ビットのみが使用されています。残りのビットは将来の使用のために予約されています。 「フラグ」フィールドの形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv4-query Flags Format
図3：DHCPv4クエリフラグの形式
U: Unicast flag. If set to 1, it indicates that the DHCPv4 message encapsulated within the DHCPv4-query message would be sent to a unicast address if it were sent using IPv4. If this flag is set to 0, it indicates that the DHCPv4 message would be sent to the broadcast address if it were sent using IPv4. The usage of the flag is described in detail in Section 8.
U：ユニキャストフラグ。 1に設定されている場合、IPv4を使用して送信された場合、DHCPv4-queryメッセージ内にカプセル化されたDHCPv4メッセージがユニキャストアドレスに送信されることを示します。このフラグが0に設定されている場合、IPv4を使用して送信された場合、DHCPv4メッセージがブロードキャストアドレスに送信されることを示します。フラグの使用法については、セクション8で詳しく説明します。
MBZ: Bits MUST be set to zero when sending and MUST be ignored when receiving.
MBZ：送信時にはビットをゼロに設定し、受信時には無視する必要があります。
This document introduces no flags to be carried in the "flags" field of the DHCPv4-response message. They are all reserved for future use. The DHCP 4o6 server MUST set all bits of this field to 0 and the DHCP 4o6 client MUST ignore the content in this field.
このドキュメントでは、DHCPv4-responseメッセージの「フラグ」フィールドで伝達されるフラグは紹介されていません。それらはすべて将来の使用のために予約されています。 DHCP 4o6サーバーはこのフィールドのすべてのビットを0に設定する必要があり、DHCP 4o6クライアントはこのフィールドの内容を無視する必要があります。
The DHCPv4 Message option carries a DHCPv4 message that is sent by the client or the server. Such messages exclude any IP or UDP headers.
DHCPv4メッセージオプションは、クライアントまたはサーバーによって送信されるDHCPv4メッセージを伝送します。このようなメッセージには、IPまたはUDPヘッダーは含まれません。
The format of the DHCPv4 Message option is:
DHCPv4メッセージオプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCPv4-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DHCPv4 Message Option Format
図4：DHCPv4メッセージオプションの形式
option-code: OPTION_DHCPV4_MSG (87).
オプションコード：OPTION_DHCPV4_MSG（87）。
option-len: Length of the DHCPv4 message.
option-len：DHCPv4メッセージの長さ。
DHCPv4-message: The DHCPv4 message sent by the client or the server. In a DHCPv4-query message, it contains a DHCPv4 message sent by a client. In a DHCPv4-response message, it contains a DHCPv4 message sent by a server in response to a client.
DHCPv4-message：クライアントまたはサーバーによって送信されたDHCPv4メッセージ。 DHCPv4-queryメッセージには、クライアントから送信されたDHCPv4メッセージが含まれます。 DHCPv4応答メッセージには、サーバーがクライアントに応答して送信したDHCPv4メッセージが含まれます。
The DHCP 4o6 Server Address option is sent by a server to a client requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a list of DHCP 4o6 servers' IPv6 addresses that the client should contact to obtain IPv4 configuration. This list may include multicast and unicast addresses. The client sends its requests to all unique addresses carried in this option.
DHCP 4o6サーバーアドレスオプションは、DHCPv6 [RFC3315]を使用してIPv6構成を要求するクライアントにサーバーから送信されます。これは、クライアントがIPv4構成を取得するために接続する必要があるDHCP 4o6サーバーのIPv6アドレスのリストを伝送します。このリストには、マルチキャストアドレスとユニキャストアドレスが含まれる場合があります。クライアントは、このオプションで運ばれるすべての一意のアドレスに要求を送信します。
This option may also carry no IPv6 addresses, which instructs the client to use the All_DHCP_Relay_Agents_and_Servers multicast address as the destination address.
このオプションはIPv6アドレスも伝送しない場合があり、これはAll_DHCP_Relay_Agents_and_Serversマルチキャストアドレスを宛先アドレスとして使用するようにクライアントに指示します。
The presence of this option in the server's response indicates to the client that it should use DHCPv4 over DHCPv6 to obtain IPv4 configuration. If the option is absent, the client MUST NOT enable DHCPv4-over-DHCPv6 functionality.
サーバーの応答にこのオプションが存在することは、IPv4構成を取得するためにDHCPv6ではなくDHCPv4を使用する必要があることをクライアントに示します。このオプションがない場合、クライアントはDHCPv4-over-DHCPv6機能を有効にしてはなりません（MUST NOT）。
The format of the DHCP 4o6 Server Address option is:
DHCP 4o6サーバーアドレスオプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IPv6 Address(es) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCP 4o6 Servers Address Option Format
図5：DHCP 4o6サーバーアドレスオプションの形式
option-code: OPTION_DHCP4_O_DHCP6_SERVER (88).
オプションコード：OPTION_DHCP4_O_DHCP6_SERVER（88）。
option-len: Length of the IPv6 address(es) carried by the option, i.e., multiple of 16 octets. Minimal length of this option is 0.
option-len：オプションによって運ばれるIPv6アドレスの長さ、つまり16オクテットの倍数。このオプションの最小の長さは0です。
IPv6 Address: Zero or more IPv6 addresses of the DHCP 4o6 server(s).
IPv6アドレス：DHCP 4o6サーバーの0個以上のIPv6アドレス。
A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST message to either a broadcast or unicast address depending on its state. For example, a client in the RENEWING state uses a unicast address to contact the DHCPv4 server to renew its lease. A client in the REBINDING state uses a broadcast address.
[RFC2131]に準拠するDHCPv4クライアントは、そのDHCPREQUESTメッセージを、その状態に応じてブロードキャストアドレスまたはユニキャストアドレスのいずれかに送信できます。たとえば、RENEWING状態のクライアントは、ユニキャストアドレスを使用してDHCPv4サーバーに接続し、リースを更新します。 REBINDING状態のクライアントは、ブロードキャストアドレスを使用します。
In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the DHCP 4o6 server. There is no relation between the outer IPv6 address and the inner DHCPv4 message. As a result, the server is unable to determine whether the received DHCPv4 messages should have been sent using broadcast or unicast in IPv4 by checking the IPv6 address.
DHCPv6 over DHCPv4では、IPv6を使用してDHCPv4メッセージをDHCP 4o6サーバーに配信します。外部IPv6アドレスと内部DHCPv4メッセージの間に関係はありません。その結果、サーバーはIPv6アドレスをチェックしても、受信したDHCPv4メッセージがIPv4のブロードキャストまたはユニキャストのどちらを使用して送信されたのかを判断できません。
In order to allow the server to determine the client's state, the Unicast flag is carried in the DHCPv4-query message. The client MUST set this flag to 1 when the DHCPv4 message would have been sent to the unicast address if using DHCPv4 over IPv4. This flag MUST be set to 0 if the DHCPv4 client would have sent the message to the broadcast address in IPv4. The choice whether a given message should be sent to a broadcast or unicast address is made based on the [RFC2131] and its extensions.
サーバーがクライアントの状態を判別できるようにするために、ユニキャストフラグがDHCPv4-queryメッセージに含まれています。 DHCPv4 over IPv4を使用している場合にDHCPv4メッセージがユニキャストアドレスに送信された場合、クライアントはこのフラグを1に設定する必要があります。 DHCPv4クライアントがIPv4のブロードキャストアドレスにメッセージを送信する場合は、このフラグを0に設定する必要があります。特定のメッセージをブロードキャストまたはユニキャストのどちらのアドレスに送信するかは、[RFC2131]とその拡張に基づいて選択されます。
Note: The Unicast flag reflects how the DHCPv4 packet would have been sent; not how the DHCPv6 packet itself is sent.
注：ユニキャストフラグは、DHCPv4パケットが送信された方法を反映しています。 DHCPv6パケット自体の送信方法ではありません。
The client MUST obtain necessary IPv6 configuration from a DHCPv6 server before using DHCPv4 over DHCPv6. The client requests the DHCP 4o6 Server Address option using the Option Request option (ORO) in every Solicit, Request, Renew, Rebind, and Information-request message. If the DHCPv6 server includes the DHCP 4o6 Server Address option in its response, it is an indication that the client can use DHCPv4 over DHCPv6 to obtain the IPv4 configuration (by sending DHCPv4 messages encapsulated in DHCPv4-query messages).
DHCPv6 over DHCPv4を使用する前に、クライアントはDHCPv6サーバーから必要なIPv6構成を取得する必要があります。クライアントは、すべての要請メッセージ、要求メッセージ、更新メッセージ、再バインドメッセージ、および情報要求メッセージで、オプション要求オプション（ORO）を使用してDHCP 4o6サーバーアドレスオプションを要求します。 DHCPv6サーバーの応答にDHCP 4o6サーバーアドレスオプションが含まれている場合、これはクライアントがDHCPv6 over DHCPv6を使用してIPv4構成を取得できることを示しています（DHCPv4クエリメッセージにカプセル化されたDHCPv4メッセージを送信することにより）。
The client MUST NOT use DHCPv4 over DHCPv6 to request IPv4 configuration if the DHCPv6 server does not include the DHCP 4o6 Server Address option. If the IPv6 configuration that contained the DHCP 4o6 Server Address option subsequently expires, or if the renewed IPv6 configuration does not contain the DHCP 4o6 Server Address option, the client MUST stop using DHCPv4 over DHCPv6 to request or renew IPv4 configuration. However, the client continues to request DHCP 4o6 Server Address option in the messages sent to the DHCPv6 server as long as it desires to use DHCPv4 over DHCPv6.
DHCPv6サーバーにDHCP 4o6サーバーアドレスオプションが含まれていない場合、クライアントはDHCPv6 over DHCPv6を使用してIPv4構成を要求してはなりません（MUST NOT）。 DHCP 4o6サーバーアドレスオプションが含まれていたIPv6構成の有効期限が切れた場合、または更新されたIPv6構成にDHCP 4o6サーバーアドレスオプションが含まれていない場合、クライアントはDHCPv6 over DHCPv4を使用してIPv4構成を要求または更新することを停止する必要があります。ただし、クライアントは、DHCPv6 over DHCPv4を使用したい限り、DHCPv6サーバーに送信されるメッセージでDHCP 4o6サーバーアドレスオプションを要求し続けます。
It is possible in a multihomed configuration for there to be more than one DHCPv6 configuration containing a DHCP 4o6 Server Address Option active at the same time. In this case, the configurations are treated as being independent, so that when any such configuration is active, a DHCPv4-over-DHCPv6 function may be enabled for that configuration.
マルチホーム構成では、同時にアクティブなDHCP 4o6サーバーアドレスオプションを含む複数のDHCPv6構成が存在する可能性があります。この場合、構成は独立したものとして扱われるため、そのような構成がアクティブな場合、その構成に対してDHCPv4-over-DHCPv6機能が有効になる可能性があります。
An implementation may also treat such configurations as being exclusive, such that only one is kept active at a time. In this case, the client keeps the same configuration active continuously as long as it is valid. If that configuration becomes invalid but one or more other configurations remain valid, the client activates one of the remaining valid configurations.
実装では、このような構成を排他的として扱い、一度に1つだけがアクティブに保たれるようにすることもできます。この場合、クライアントは、有効である限り、同じ構成を継続的にアクティブに保ちます。その構成が無効になっても、1つ以上の他の構成が有効のままである場合、クライアントは残りの有効な構成の1つをアクティブにします。
Which strategy to follow is dependent on the implementation: keeping multiple configurations active at the same time may provide useful redundancy in some applications but may be needlessly complex in other cases.
どちらの戦略に従うかは、実装によって異なります。複数の構成を同時にアクティブにしておくと、一部のアプリケーションで有用な冗長性が得られる場合がありますが、それ以外の場合は不必要に複雑になる場合があります。
If the client receives the DHCP 4o6 Server Address option and DHCPv4 [RFC2131] is used on the interface over which the DHCPv6 option was received, the client MUST stop using the IPv4 configuration received using DHCPv4 on this interface. The client MAY send a DHCPRELEASE to the DHCPv4 server to relinquish an existing lease as described in Section 4.4.6 of [RFC2131]. The client MUST NOT use DHCPv4 on this interface as long as it receives DHCP 4o6 Server Address option in the messages received from the DHCPv6 server.
クライアントがDHCP 4o6サーバーアドレスオプションを受信し、DHCPv6 [RFC2131]がDHCPv6オプションを受信したインターフェイスで使用されている場合、クライアントは、このインターフェイスでDHCPv4を使用して受信したIPv4構成の使用を停止する必要があります。 [RFC2131]のセクション4.4.6で説明されているように、クライアントはDHCPv4サーバーにDHCPRELEASEを送信して既存のリースを放棄する場合があります（MAY）。 DHCPv6サーバーから受信したメッセージでDHCP 4o6サーバーアドレスオプションを受信する限り、クライアントはこのインターフェイスでDHCPv4を使用してはなりません（MUST NOT）。
If the client receives a DHCP 4o6 Server Address option that contains no IP addresses, i.e., the option is empty, the client MUST send its requests to the All_DHCP_Relay_Agents_and_Servers multicast address. If there is a list of IP addresses in the option, the client SHOULD send requests to each unique address carried by the option.
クライアントがIPアドレスを含まないDHCP 4o6サーバーアドレスオプションを受信した場合、つまりオプションが空の場合、クライアントはAll_DHCP_Relay_Agents_and_Serversマルチキャストアドレスに要求を送信する必要があります。オプションにIPアドレスのリストがある場合、クライアントは、オプションで運ばれる一意の各アドレスにリクエストを送信する必要があります（SHOULD）。
If the client obtained stateless IPv6 configuration by sending an Information-request message to the server, the client MUST follow the rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6 configuration (i.e., list of DHCP 4o6 servers) as well as other configuration data. The client that obtained stateful IPv6 configuration will refresh the status of DHCPv4-over-DHCPv6 function when extending a lifetime of acquired IPv6 address (Renew and Rebind messages).
クライアントが情報要求メッセージをサーバーに送信してステートレスIPv6構成を取得した場合、クライアントは[RFC4242]のルールに従って、DHCPv4-over-DHCPv6構成（つまり、DHCP 4o6サーバーのリスト）を定期的に更新する必要があります。その他の構成データ。ステートフルIPv6構成を取得したクライアントは、取得したIPv6アドレスの有効期間を延長するときに、DHCPv4-over-DHCPv6機能のステータスを更新します（メッセージの更新と再バインド）。
The client MUST employ an IPv6 address of an appropriate scope from which to source the DHCPv4-query message. When the client sends a DHCPv4-query message to the multicast address, it MUST use a link-local address as the source address as described in [RFC3315]. When the client sends a DHCPv4-query message using unicast, the source address MUST be an address of appropriate scope, acquired in advance.
クライアントは、DHCPv4-queryメッセージのソースとなる適切なスコープのIPv6アドレスを使用する必要があります。 [RFC3315]で説明されているように、クライアントがDHCPv4クエリメッセージをマルチキャストアドレスに送信する場合、リンクローカルアドレスを送信元アドレスとして使用する必要があります。クライアントがユニキャストを使用してDHCPv4クエリメッセージを送信する場合、送信元アドレスは、事前に取得された適切なスコープのアドレスである必要があります。
The client generates a DHCPv4 message and stores it verbatim in the DHCPv4 Message option carried by the DHCPv4-query message. The client MUST put exactly one DHCPv4 Message option into a single DHCPv4-query message. The client MUST NOT request the DHCP 4o6 Server Address option in the DHCPv4-query message.
クライアントはDHCPv4メッセージを生成し、それをそのままDHCPv4クエリメッセージに含まれるDHCPv4メッセージオプションに格納します。クライアントは1つのDHCPv4メッセージオプションを1つのDHCPv4クエリメッセージに入れる必要があります。クライアントは、DHCPv4-queryメッセージのDHCP 4o6サーバーアドレスオプションを要求してはなりません（MUST NOT）。
The client MUST follow the rules defined in Section 8 when setting the Unicast flag based on the DHCPv4 destination.
DHCPv4宛先に基づいてユニキャストフラグを設定する場合、クライアントはセクション8で定義されたルールに従う必要があります。
On receiving a DHCPv4-response message, the client MUST look for the DHCPv4 Message option within this message. If this option is not found, the DHCPv4-response message is discarded. If the DHCPv4 Message option is present, the client extracts the DHCPv4 message it contains and processes it as described in Section 4.4 of [RFC2131].
DHCPv4応答メッセージを受信すると、クライアントはこのメッセージ内でDHCPv4メッセージオプションを探す必要があります。このオプションが見つからない場合、DHCPv4-responseメッセージは破棄されます。 [DHCPv4メッセージ]オプションが存在する場合、クライアントは含まれているDHCPv4メッセージを抽出し、[RFC2131]のセクション4.4で説明されているように処理します。
When dealing with IPv4 configuration, the client MUST follow the normal DHCPv4 retransmission requirements and strategy as specified in Section 4.1 of [RFC2131]. There are no explicit transmission parameters associated with a DHCPv4-query message, as this is governed by the DHCPv4 "state machine" [RFC2131].
IPv4構成を処理する場合、クライアントは[RFC2131]のセクション4.1で指定されている通常のDHCPv4再送信の要件と戦略に従う必要があります。 DHCPv4の "ステートマシン" [RFC2131]によって制御されるため、DHCPv4-queryメッセージに関連付けられた明示的な送信パラメーターはありません。
The client MUST implement [RFC4361] to ensure that the device correctly identifies itself. It MUST send a 'client identifier' option when using DHCPv4 over DHCPv6.
クライアントは、デバイスがそれ自体を正しく識別することを保証するために[RFC4361]を実装する必要があります。 DHCPv6 over DHCPv4を使用する場合は、「クライアント識別子」オプションを送信する必要があります。
When a DHCPv6 relay agent receives a DHCPv4-query message, it may not recognize this message. The unknown message MUST be forwarded as described in [RFC7283].
DHCPv6リレーエージェントがDHCPv4クエリメッセージを受信すると、このメッセージを認識しない場合があります。 [RFC7283]で説明されているように、不明なメッセージを転送する必要があります。
A DHCPv6 relay agent that can recognize DHCP 4o6 messages MAY allow the configuration of a separate set of destination addresses for such messages in addition to the destination addresses used for relaying the other DHCPv6 messages. To implement this function, the relay checks the received DHCPv6 message type and forwards according to the following logic:
DHCP 4o6メッセージを認識できるDHCPv6リレーエージェントは、他のDHCPv6メッセージをリレーするために使用される宛先アドレスに加えて、そのようなメッセージ用に別個の宛先アドレスのセットを構成できる場合があります。この機能を実装するために、リレーは受信したDHCPv6メッセージタイプをチェックし、次のロジックに従って転送します。
1. If the message type is DHCPV4-QUERY, the packet is relayed to the configured DHCP 4o6 Server's address(es) in the form of a normal DHCPv6 packet (i.e., DHCPv6/UDP/IPv6).
1. メッセージタイプがDHCPV4-QUERYの場合、パケットは通常のDHCPv6パケット（つまり、DHCPv6 / UDP / IPv6）の形式で構成済みDHCP 4o6サーバーのアドレスに中継されます。
2. For any other DHCPv6 message type, forward according to section 20 of [RFC3315].
2. その他のDHCPv6メッセージタイプの場合は、[RFC3315]のセクション20に従って転送します。
The above logic only allows for separate relay destinations configured on the relay agent closest to the client (single relay hop). Multiple relaying hops are not considered in the case of separate relay destinations.
上記のロジックでは、クライアントに最も近いリレーエージェント（単一のリレーホップ）で構成された個別のリレー宛先のみが許可されます。複数のリレーホップは、別個のリレー宛先の場合には考慮されません。
When the server receives a DHCPv4-query message from a client, it searches for the DHCPv4 Message option. The server discards a packet without this option. In addition, the server MAY notify an administrator about the receipt of this malformed packet. The mechanism for this notification is out of scope for this document.
サーバーはクライアントからDHCPv4クエリメッセージを受信すると、DHCPv4メッセージオプションを検索します。サーバーは、このオプションのないパケットを破棄します。さらに、サーバーはこの不正なパケットの受信について管理者に通知してもよい（MAY）。この通知のメカニズムは、このドキュメントの範囲外です。
If the server finds a valid DHCPv4 Message option, it extracts the original DHCPv4 message. Since the DHCPv4 message is encapsulated in the DHCPv6 message, it lacks the information that is typically used by the DHCPv4 server, implementing [RFC2131], to make address-allocation decisions, e.g., giaddr for relayed messages and IPv4 address of the interface that the server is using to communicate with a directly connected client. Therefore, the DHCP 4o6 server allocates addresses according to the policies on local address assignment determined by the server administrator. For example, if the DHCPv4-query message has been sent via a relay, the server MAY use the link-address field of the Relay-forward message as a lookup for the IPv4 subnet from which to assign a DHCPv4 address. If the DHCPv4-query message has been sent from a directly connected client, the server MAY use the IPv6 source address of the message to determine the appropriate IPv4 subnet to use for DHCPv4 address assignment.
サーバーは、有効なDHCPv4メッセージオプションを見つけると、元のDHCPv4メッセージを抽出します。 DHCPv4メッセージはDHCPv6メッセージにカプセル化されているため、DHCPv4サーバーが[RFC2131]を実装してアドレス割り当てを決定するために通常使用する情報が不足しています。たとえば、リレーされたメッセージのgiaddrと、サーバーは、直接接続されたクライアントとの通信に使用しています。したがって、DHCP 4o6サーバーは、サーバー管理者が決定したローカルアドレス割り当てのポリシーに従ってアドレスを割り当てます。たとえば、DHCPv4クエリメッセージがリレーを介して送信された場合、サーバーは、リレー転送メッセージのリンクアドレスフィールドを、DHCPv4アドレスを割り当てるIPv4サブネットのルックアップとして使用できます（MAY）。 DHCPv4-queryメッセージが直接接続されたクライアントから送信された場合、サーバーはメッセージのIPv6送信元アドレスを使用して、DHCPv4アドレスの割り当てに使用する適切なIPv4サブネットを決定できます（MAY）。
Alternatively, the server may act as a DHCPv4 relay agent and forward the DHCPv4 packet to a "normal" DHCPv4 server. The details of such a solution have not been considered by the working group; describing that solution is out of scope of this document and is left as future work should the need for it arise.
または、サーバーはDHCPv4リレーエージェントとして機能し、DHCPv4パケットを「通常の」DHCPv4サーバーに転送することもできます。このようなソリューションの詳細は、ワーキンググループでは検討されていません。ソリューションの説明はこのドキュメントの範囲外であり、将来の作業で必要になった場合のために残します。
The server SHOULD use the "flags" field of the DHCPv4-query message to create a response (server to client DHCPv4 message). The use of this field is described in detail in Section 8.
サーバーは、DHCPv4-queryメッセージの「フラグ」フィールドを使用して、応答（サーバーからクライアントのDHCPv4メッセージ）を作成する必要があります（SHOULD）。このフィールドの使用については、セクション8で詳しく説明します。
When an appropriate DHCPv4 response is created, the server places it in the payload of a DHCPv4 Message option, which it puts into the DHCPv4-response message.
適切なDHCPv4応答が作成されると、サーバーはそれをDHCPv4メッセージオプションのペイロードに配置し、DHCPv4応答メッセージに入れます。
If the DHCPv4-query message was received directly by the server, the DHCPv4-response message MUST be unicast from the interface on which the original message was received.
DHCPv4-queryメッセージがサーバーによって直接受信された場合、DHCPv4-responseメッセージは、元のメッセージが受信されたインターフェイスからユニキャストである必要があります。
If the DHCPv4-query message was received in a Relay-forward message, the server creates a Relay-reply message with the DHCPv4-response message in the payload of a Relay Message option, and responds as described in Section 20.3 of [RFC3315].
DHCPv4クエリメッセージがリレー転送メッセージで受信された場合、サーバーはリレーメッセージオプションのペイロードにDHCPv4応答メッセージを含むリレー応答メッセージを作成し、[RFC3315]のセクション20.3の説明に従って応答します。
In this specification, DHCPv4 messages are encapsulated in the newly defined option and messages. This is similar to the handling of the current relay agent messages. In order to bypass firewalls or network authentication gateways, a malicious attacker may leverage this feature to convey other messages using DHCPv6, i.e., use DHCPv6 as a form of encapsulation. However, the potential risk from this is no more severe than that with the current DHCPv4 and DHCPv6 practice.
この仕様では、DHCPv4メッセージは、新しく定義されたオプションとメッセージにカプセル化されます。これは、現在のリレーエージェントメッセージの処理に似ています。ファイアウォールまたはネットワーク認証ゲートウェイをバイパスするために、悪意のある攻撃者はこの機能を利用して、DHCPv6を使用して他のメッセージを伝達する可能性があります。つまり、カプセル化の形式としてDHCPv6を使用します。ただし、これによる潜在的なリスクは、現在のDHCPv4およびDHCPv6のプラクティスの場合よりも深刻ではありません。
It is possible for a rogue server to reply with a DHCP 4o6 Server Address option containing duplicated IPv6 addresses, which could cause an amplification attack. To avoid this, the client MUST check if there are duplicate IPv6 addresses in a DHCP 4o6 Server Address option when receiving one. The client MUST ignore any but the first instance of each address.
不正なサーバーが重複したIPv6アドレスを含むDHCP 4o6サーバーアドレスオプションで応答する可能性があり、増幅攻撃を引き起こす可能性があります。これを回避するために、クライアントは、DHCP 4o6サーバーアドレスオプションを受信したときに、IPv6アドレスが重複していないかどうかを確認する必要があります。クライアントは、各アドレスの最初のインスタンス以外は無視する必要があります。
When considering whether to enable DHCPv4-over-DHCPv6, one important consideration is that when it is enabled, this gives the DHCPv6 server the ability to shut off DHCPv4 traffic, and, consequently, IPv4 traffic, on the interface that is configured to do DHCPv4-over- DHCPv6. For this reason, DHCPv4-over-DHCPv6 should only be enabled in situations where there is a clear trust relationship that eliminates this concern. For instance, a CPE device can safely enable this on its WAN interface, because it is reasonable to assume that an ISP will not accidentally configure DHCPv4 over DHCPv6 service on that link, and that it will be impractical for an attacker to set up a rogue DHCPv6 server in the ISP's network.
DHCPv4-over-DHCPv6を有効にするかどうかを検討する際の重要な考慮事項の1つは、DHCPv4を有効にすると、DHCPv6サーバーがDHCPv4トラフィックを遮断し、その結果、DHCPv4を実行するように構成されているインターフェース上でIPv4トラフィックを遮断できることです。 -over- DHCPv6。このため、DHCPv4-over-DHCPv6は、この問題を排除する明確な信頼関係がある場合にのみ有効にする必要があります。たとえば、ISPがそのリンク上で誤ってDHCPv4 over DHCPv6サービスを構成することはなく、攻撃者が不正をセットアップすることは現実的ではないため、CPEデバイスはWANインターフェイスでこれを安全に有効にできます。 ISPのネットワーク内のDHCPv6サーバー。
IANA has allocated two DHCPv6 option codes for use by OPTION_DHCPV4_MSG (87) and OPTION_DHCP4_O_DHCP6_SERVER (88) from the "Option Codes" table. Also, IANA has allocated two DHCPv6 message type codes for the DHCPV4-QUERY (20) and DHCPV4-RESPONSE (21) from the "Message Types" table of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry. Both tables can be found at <http://www.iana.org/assignments/dhcpv6-parameters/>.
IANAは、「オプションコード」の表から、OPTION_DHCPV4_MSG（87）およびOPTION_DHCP4_O_DHCP6_SERVER（88）で使用する2つのDHCPv6オプションコードを割り当てました。また、IANAは、「IPv6の動的ホスト構成プロトコル（DHCPv6）」レジストリの「メッセージタイプ」表から、DHCPV4-QUERY（20）およびDHCPV4-RESPONSE（21）に2つのDHCPv6メッセージタイプコードを割り当てました。どちらのテーブルも<http://www.iana.org/assignments/dhcpv6-parameters/>にあります。
Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Cong Liu, and Yuchi Chen for their great contributions to the specification.
仕様への多大な貢献に対して、Ted Lemon、Bernie Volz、Tomek Mrugalski、Cong Liu、Yuchi Chenに感謝します。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC3315] Droms, R., 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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4242] Venaas、S.、Chown、T。、およびB. Volz、「IPv6の動的ホスト構成プロトコルの情報更新時間オプション（DHCPv6）」、RFC 4242、2005年11月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361] Lemon、T。およびB. Sommerfeld、「動的ホスト構成プロトコルバージョン4（DHCPv4）のノード固有のクライアント識別子」、RFC 4361、2006年2月。
[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 Messages", RFC 7283, July 2014.
[RFC7283] Cui、Y.、Sun、Q。、およびT. Lemon、「Handling Unknown DHCPv6 Messages」、RFC 7283、2014年7月。
[LW4OVER6] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", Work in Progress, June 2014.
[LW4OVER6] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the DS-Lite Architecture」、Work in Progress 、2014年6月。
[RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951] Croft、B。およびJ. Gilmore、「Bootstrap Protocol」、RFC 951、1985年9月。
Authors' Addresses
著者のアドレス
Qi Sun Tsinghua University Beijing 100084 P.R. China
Q i sun ts inghua大学北京100084 P.R.中国
Phone: +86-10-6278-5822
EMail: sunqi@csnet1.cs.tsinghua.edu.cn
Yong Cui Tsinghua University Beijing 100084 P.R. China
Yong Cu ITS inghuauniversity Beijing 100084 P.R. China
Phone: +86-10-6260-3059
EMail: yong@csnet1.cs.tsinghua.edu.cn
Marcin Siodelski Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
Marcin Siodelski Internet Systems Consortium 950 Charter Street Redwood City、CA 94063 USA
EMail: msiodelski@gmail.com
Suresh Krishnan Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400 Blvd.カナダ、ケベック州マウントロイヤルのデカリータウン
EMail: suresh.krishnan@ericsson.com
Ian Farrer Deutsche Telekom AG CTO-ATI, Landgrabenweg 151 Bonn, NRW 53227 Germany
Ian Farrer Deutsche Telekom AG CTO-ATI、Landgrabenweg 151 Bonn、NRW 53227 Germany
EMail: ian.farrer@telekom.de