Internet Engineering Task Force (IETF) C. Porfiri
Request for Comments: 9928 Ericsson
Category: Standards Track S. Krishnan
ISSN: 2070-1721 Cisco
J. Arkko
M. Kühlewind
Ericsson
March 2026
This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv4 over DHCPv6 in a Relay Agent. RFC 7341 specifies the use of DHCPv4 over DHCPv6 in the client only. This document specifies an approach based on RFC 7341 that allows a Relay Agent to implement the DHCPv4-over-DHCPv6 encapsulation and decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a DHCPv4 client.
このドキュメントでは、レガシー IPv4 専用クライアントを備えたネットワークが、リレー エージェントで DHCPv6 経由で DHCPv4 によって提供されるサービスを使用するためのメカニズムについて説明します。RFC 7341 では、クライアントのみで DHCPv6 を介した DHCPv4 の使用を指定しています。この文書では、リレー エージェントが DHCPv4 クライアントに代わって DHCPv6 メッセージ内の DHCPv4 メッセージの DHCPv4-over-DHCPv6 カプセル化およびカプセル化解除を実装できるようにする、RFC 7341 に基づくアプローチを指定します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9928.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9928 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Applicability Scope
2. Conventions and Definitions
3. DHCPv4-over-DHCPv6 Relay Agent (4o6RA)
3.1. Intermediate Relays
3.2. 4o6RA and Topology Discovery
4. Deployment Considerations
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Example Use Case: Topology Discovery for IPv4-Only
Radio Unit in 3GPP RAN with Switched Fronthaul
Acknowledgments
Authors' Addresses
[RFC7341] describes a transport mechanism for carrying DHCPv4 [RFC2131] messages using DHCPv6 [RFC9915] for dynamic provisioning of IPv4 addresses and other DHCPv4-specific configuration parameters across IPv6-only networks. The deployment of [RFC7341] requires support in DHCP clients and at the DHCPv6 server. However, if a client is embedded in a host that only supports IPv4 and cannot easily be replaced or updated (which could be due to any number of technical or business reasons), this approach does not work.
[RFC7341] は、IPv6 専用ネットワーク全体での IPv4 アドレスおよびその他の DHCPv4 固有の設定パラメータの動的プロビジョニングのために DHCPv6 [RFC9915] を使用して DHCPv4 [RFC2131] メッセージを伝送するためのトランスポート メカニズムについて説明しています。[RFC7341] の展開には、DHCP クライアントと DHCPv6 サーバーでのサポートが必要です。ただし、クライアントが IPv4 のみをサポートするホストに組み込まれており、簡単に交換または更新できない場合 (技術的またはビジネス上の理由が多数ある可能性があります)、このアプローチは機能しません。
Similarly, the DHCPv6 Relay Agent specification defined in [RFC9915], which also refers to [RFC6221] for the Lightweight DHCPv6 Relay Agent (LDRA) behavior, does not provide any mechanism to handle legacy DHCPv4, except by requiring the client to implement the DHCPv4-over-DHCPv6 encapsulation and decapsulation.
同様に、[RFC9915] で定義されている DHCPv6 リレー エージェント仕様は、Lightweight DHCPv6 Relay Agent (LDRA) の動作に関して [RFC6221] も参照していますが、クライアントに DHCPv4-over-DHCPv6 のカプセル化とカプセル化解除の実装を要求することを除いて、レガシー DHCPv4 を処理するメカニズムを提供していません。
This document specifies a solution based on [RFC7341] that can be implemented in intermediate nodes such as switches or routers, without putting any requirements on clients. No new protocols or extensions are needed; instead, this document specifies a new use case for [RFC7341] that allows a Relay Agent to perform the DHCPv4- over-DHCPv6 encapsulation and decapsulation instead of the client.
この文書は、クライアントに要件を課すことなく、スイッチやルーターなどの中間ノードに実装できる [RFC7341] に基づくソリューションを指定します。新しいプロトコルや拡張機能は必要ありません。代わりに、この文書は、クライアントの代わりにリレー エージェントが DHCPv4 over DHCPv6 のカプセル化とカプセル化解除を実行できるようにする [RFC7341] の新しい使用例を指定します。
The mechanisms described in this document apply to the configuration phase of hosts that need to receive an IPv4 address when a DHCP server for IPv4 [RFC2131] is not reachable directly from the host. Furthermore, the host is unable to implement a DHCP client conformant to [RFC7341], as it is connected to an IPv4-only network. However, there is a DHCPv6 server that can provide IPv4 addresses by means of the mechanisms specified in [RFC7341].
この文書で説明されているメカニズムは、IPv4 [RFC2131] の DHCP サーバーがホストから直接到達できない場合に、IPv4 アドレスを受信する必要があるホストの構成フェーズに適用されます。さらに、ホストは IPv4 専用ネットワークに接続されているため、[RFC7341] に準拠した DHCP クライアントを実装できません。ただし、[RFC7341] で指定されたメカニズムを使用して IPv4 アドレスを提供できる DHCPv6 サーバーがあります。
The following terms and abbreviations are used in this document:
このドキュメントでは次の用語と略語が使用されます。
DHCP:
DHCP:
Refers to DHCPv4 and/or DHCPv6 if not otherwise specified.
特に指定がない場合は、DHCPv4 および/または DHCPv6 を指します。
DHCP Relay Agent:
DHCP リレー エージェント:
Refers to a common concept in all of the following protocols, although the details differ between them: the Bootstrap Protocol (BOOTP) [RFC0951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6 [RFC9915].
詳細はそれらの間で異なりますが、ブートストラップ プロトコル (BOOTP) [RFC0951] [RFC1542]、DHCPv4 [RFC2131] [RFC2132]、および DHCPv6 [RFC9915] のすべてのプロトコルに共通の概念を指します。
DHCPv4:
DHCPv4:
Refers to DHCP as defined in [RFC2131].
[RFC2131] で定義されている DHCP を指します。
DHCPv4 over DHCPv6 (DHCP 4o6):
DHCPv4 over DHCPv6 (DHCP 4o6):
Refers to the architecture, the procedures, and the protocols specified in the DHCPv4-over-DHCPv6 document [RFC7341].
DHCPv4-over-DHCPv6 文書 [RFC7341] で指定されたアーキテクチャ、手順、およびプロトコルを指します。
DHCPv4-over-DHCPv6 Relay Agent (4o6RA):
DHCPv4-over-DHCPv6 リレー エージェント (4o6RA):
Refers to a Relay Agent that implements the DHCP 4o6 transport as specified in this document.
このドキュメントで指定されているように、DHCP 4o6 トランスポートを実装するリレー エージェントを指します。
Layer 3 Relay Agent (L3RA):
レイヤ 3 リレー エージェント (L3RA):
Refers to a DHCP Relay Agent as specified in [RFC9915] that is not a LDRA.
[RFC9915] で指定されている、LDRA ではない DHCP リレー エージェントを指します。
Lightweight DHCPv6 Relay Agent (LDRA):
軽量 DHCPv6 リレー エージェント (LDRA):
Refers to an extension of the original DHCPv6 Relay Agent specification, to allow Layer 2 (L2) only devices to perform a Relay Agent function [RFC6221].
レイヤ 2 (L2) 専用デバイスがリレー エージェント機能 [RFC6221] を実行できるようにする、元の DHCPv6 リレー エージェント仕様の拡張を指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document assumes a network where IPv4-only hosts are connected to a network that supports IPv6 and limited IPv4 services.
このドキュメントでは、IPv4 のみのホストが IPv6 および限定的な IPv4 サービスをサポートするネットワークに接続されているネットワークを想定しています。
To address such a network setup, this document extends DHCPv6 Relay Agents with DHCPv4 over DHCPv6, as shown in Figure 1.
このようなネットワーク設定に対処するために、このドキュメントでは、図 1 に示すように、DHCPv6 リレー エージェントを DHCPv4 over DHCPv6 で拡張します。
.-----------. .-----------.
| | | |
+--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+
| DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server |
| | | with 4o6RA | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
'-----------' '-----------'
Figure 1: Architecture Example with Legacy DHCP Client
図 1: レガシー DHCP クライアントを使用したアーキテクチャの例
This document specifies the encapsulation and decapsulation specified in [RFC7341] to be performed in the Relay Agent without requiring any changes on the DHCPv4 client. In this case, it is up to the Relay Agent to provide the full DHCP 4o6 support, and the legacy DHCPv4 client is not aware that it is being served via a DHCP 4o6 service. As the 4o6RA acts as a DHCP 4o6 client, all prerequisites and configurations that apply to the DHCP client in Section 5 of [RFC7341] are also applied to the 4o6RA.
この文書は、[RFC7341] で指定されているカプセル化とカプセル化解除が、DHCPv4 クライアントでの変更を必要とせずにリレー エージェントで実行されるように指定します。この場合、完全な DHCP 4o6 サポートを提供するのはリレー エージェント次第であり、レガシー DHCPv4 クライアントは、DHCP 4o6 サービスを介してサービスが提供されていることを認識しません。4o6RA は DHCP 4o6 クライアントとして機能するため、[RFC7341] のセクション 5 で DHCP クライアントに適用されるすべての前提条件と設定は 4o6RA にも適用されます。
As the 4o6RA takes the role of the client in respect to [RFC7341], it is responsible for determining a suitable interface where it acts as a DHCPv6 client, and it is responsible for locating a suitable DHCPv6 server or Relay Agent and obtaining the necessary IPv6 configuration. As specified in [RFC7341], the 4o6RA, acting as DHCP 4o6 client, therefore has to request the DHCP 4o6 Server Address option from the server by sending the Option Request option as described in [RFC9915] before it can use the DHCP 4o6 transport.
4o6RA は [RFC7341] に関してクライアントの役割を担うため、DHCPv6 クライアントとして機能する適切なインターフェイスを決定する責任を負い、適切な DHCPv6 サーバーまたはリレー エージェントを見つけて必要な IPv6 設定を取得する責任を負います。[RFC7341] で規定されているように、DHCP 4o6 クライアントとして機能する 4o6RA は、DHCP 4o6 トランスポートを使用する前に、[RFC9915] で説明されているオプション要求オプションを送信して、サーバーから DHCP 4o6 サーバー アドレス オプションを要求する必要があります。
To maintain interoperability with existing DHCPv6 relays and servers, the message format is unchanged from [RFC9915]. The 4o6RA implements the same message types as a DHCPv6 Relay Agent (see Section 6 of [RFC7341]).
既存の DHCPv6 リレーおよびサーバーとの相互運用性を維持するために、メッセージ形式は [RFC9915] から変更されていません。4o6RA は、DHCPv6 リレー エージェントと同じメッセージ タイプを実装します ([RFC7341] のセクション 6 を参照)。
However, in this specification, the 4o6RA, instead of the client, creates the DHCPV4-QUERY message and encapsulates the DHCP request message received from the legacy DHCPv4 client.
ただし、この仕様では、クライアントの代わりに 4o6RA が DHCPV4-QUERY メッセージを作成し、レガシー DHCPv4 クライアントから受信した DHCP 要求メッセージをカプセル化します。
When the DHCPV4-RESPONSE message is received by the DHCP 4o6 Relay Agent, it looks for the DHCPv4 message option within this message. If this option is not found or the DHCPv4-RESPONSE message is not well-formed, it MUST be discarded. If the DHCPv4 message option is present and correct, the 4o6RA MUST extract the DHCPv4 message and forward the encapsulated DHCPv4-RESPONSE to the requesting DHCPv4 client, given that the encapsulated DHCPv4-RESPONSE is correct and can be actually forwarded.
DHCPV4-RESPONSE メッセージが DHCP 4o6 リレー エージェントによって受信されると、このメッセージ内の DHCPv4 メッセージ オプションが検索されます。このオプションが見つからない場合、または DHCPv4-RESPONSE メッセージが整形式でない場合は、破棄しなければなりません (MUST)。DHCPv4 メッセージ オプションが存在し、正しい場合、カプセル化された DHCPv4-RESPONSE が正しく、実際に転送できることを前提として、4o6RA は DHCPv4 メッセージを抽出し、カプセル化された DHCPv4-RESPONSE を要求元の DHCPv4 クライアントに転送しなければなりません (MUST)。
Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages MUST handle them as specified in Section 6 of [RFC6221].
DHCPV4-QUERY または DHCPV4-RESPONSE メッセージを受信するレイヤー 2 (L2) リレー エージェントは、[RFC6221] のセクション 6 に規定されているようにそれらを処理しなければなりません (MUST)。
In any given environment, DHCPv6 servers to which DHCPV4-QUERY requests are routed are expected to be compliant with DHCP 4o6 according to [RFC7341]. No additional requirements on DHCPv6 servers are set by this specification.
どのような環境においても、DHCPV4-QUERY リクエストがルーティングされる DHCPv6 サーバーは、[RFC7341] に従って DHCP 4o6 に準拠していることが期待されます。この仕様では、DHCPv6 サーバーに関する追加の要件は設定されていません。
Intermediate relays shall behave according to Section 10 of [RFC7341].
中間リレーは、[RFC7341] のセクション 10 に従って動作しなければなりません。
In some networks, the configuration of a host may depend on the topology. However, when a new host attaches to a network, it may be unaware of the topology and, consequently, how it has to be configured.
一部のネットワークでは、ホストの構成がトポロジに依存する場合があります。ただし、新しいホストがネットワークに接続するとき、そのホストはトポロジを認識していない可能性があり、その結果、どのように構成する必要があるのかを認識していない可能性があります。
DHCPv4 [RFC2131] and DHCPv6 [RFC9915] specifications describe how addresses can typically be allocated to clients based on network topology information provided by a DHCP relay.
DHCPv4 [RFC2131] および DHCPv6 [RFC9915] の仕様では、DHCP リレーによって提供されるネットワーク トポロジ情報に基づいて、一般的にクライアントにアドレスを割り当てる方法が説明されています。
Address/prefix allocation decisions are integral to the allocation of addresses and prefixes in DHCP, as described in detail in [RFC7969]. This specification aims to guarantee that the 4o6RA does not break any legacy capability when used for topology discovery.
[RFC7969] で詳細に説明されているように、アドレス/プレフィックス割り当ての決定は、DHCP でのアドレスとプレフィックスの割り当てに不可欠です。この仕様は、4o6RA がトポロジ検出に使用されるときに従来の機能を壊さないことを保証することを目的としています。
Topology discovery as described in [RFC7969] differs between IPv4 and IPv6 as follows:
[RFC7969] で説明されているトポロジ検出は、IPv4 と IPv6 で次のように異なります。
* IPv4: When using DHCP on IPv4, only the first Relay Agent SHOULD set the giaddr field (Section 3.1 of [RFC7969]). Thus, in a network that has more than one Relay Agent, only part of the topology is transported via DHCPv4.
* IPv4: IPv4 で DHCP を使用する場合、最初のリレー エージェントのみが giaddr フィールドを設定すべきです ([RFC7969] のセクション 3.1)。したがって、複数のリレー エージェントがあるネットワークでは、トポロジの一部のみが DHCPv4 経由で転送されます。
* IPv6: When using DHCPv6, all Relay Agents SHOULD send link-address and Interface-ID options that provide information about the complete path between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server.
* IPv6: DHCPv6 を使用する場合、すべてのリレー エージェントは、DHCPv6 クライアントと DHCPv6 サーバー間の完全なパスに関する情報を提供するリンク アドレスとインターフェイス ID オプションを DHCPv6 サーバーに送信する必要があります (SHOULD)。
In Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs) [RFC6221] can be used.
レイヤ 2 ネットワークでは、Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] を使用できます。
When provided, the topology information is available at the DHCPv6 server in the form of a sequence of the link-address field and Interface-ID option.
トポロジ情報が提供されると、リンク アドレス フィールドとインターフェイス ID オプションのシーケンスの形式で DHCPv6 サーバーで利用できます。
Then, topology information for the given IP address can be obtained from the DHCPv6 server and used for configuration or other purposes.
その後、指定された IP アドレスのトポロジ情報を DHCPv6 サーバーから取得し、構成やその他の目的に使用できます。
[RFC7341] enables the client to use DHCPv6 for topology discovery even within a DHCPv4 context, as the DHCPv6 Relay Agent knows the interface where the encapsulated DHCP request is received. However, as shown in Figure 2, the introduction of DHCP 4o6 at the edge of the IPv6 network hides the Layer 2 network from the DHCPv6 RA. As such, moving DHCP 4o6 to an intermediate node rather than performing it at the client breaks the topology propagation, as 4o6RA-only solutions do not provide any interface information in the encapsulated message.
[RFC7341] では、DHCPv6 リレー エージェントがカプセル化された DHCP 要求が受信されるインターフェイスを認識しているため、クライアントは DHCPv4 コンテキスト内でもトポロジ検出に DHCPv6 を使用できます。ただし、図 2 に示すように、IPv6 ネットワークのエッジに DHCP 4o6 を導入すると、レイヤー 2 ネットワークが DHCPv6 RA から隠蔽されます。したがって、DHCP 4o6 をクライアントで実行するのではなく中間ノードに移動すると、4o6RA のみのソリューションではカプセル化されたメッセージにインターフェイス情報が提供されないため、トポロジの伝播が中断されます。
.-----------------. .-------------------------.
| L2 Network | | IPv6 Network |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 |
| Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server |
| | | | | Agent | | Agent | | |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| | | |
'-----------------' '-------------------------'
Figure 2: Broken Topology Information
図 2: 壊れたトポロジ情報
In order to provide full topology information, it is RECOMMENDED that any implementation of 4o6RA be combined with an LDRA implementation [RFC6221] in a back-to-back structure and that the LDRA implementation includes a mechanism to obtain interface information that can be used to provide the Interface-ID option to outgoing DHCPV4-QUERY messages, as specified in Section 5.3.2 of [RFC6221].
完全なトポロジ情報を提供するために、4o6RA の実装はバックツーバック構造で LDRA 実装 [RFC6221] と組み合わせることが推奨されます。また、LDRA 実装には、[RFC6221] のセクション 5.3.2 で規定されているように、発信 DHCPV4-QUERY メッセージに Interface-ID オプションを提供するために使用できるインターフェイス情報を取得するメカニズムが含まれることが推奨されます。
The internal mechanisms to exchange interface information, their format, and whether the interface information contains an indication that a 4o6RA is involved, are out of the scope for this document.
インターフェイス情報を交換する内部メカニズム、その形式、およびインターフェイス情報に 4o6RA が関与していることを示す情報が含まれているかどうかについては、このドキュメントの範囲外です。
The resulting architecture is shown in Figure 3 where the Relay Agent is implementing 4o6RA and LDRA and has an internal interface to propagate topology information from 4o6RA to LDRA.
結果として得られるアーキテクチャを図 3 に示します。ここでは、リレー エージェントが 4o6RA と LDRA を実装しており、トポロジ情報を 4o6RA から LDRA に伝播する内部インターフェイスを備えています。
.-----------------. .------------------------.
| L2 Network or | | IPv6 Network |
| IPv6-Only Link | | |
+--------+-+ +---------+ +-+---+--+---------+ +------+---+
| DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 |
| Client +--+ Switch +--+ Relay + RFC 6221+------+ Server |
| | | | | Agent | | | |
+--------+-+ +---------+ +-+---+--+---------+ +------+---+
| | | |
'-----------------' '------------------------'
Figure 3: Topology Information Preserved with LDRA
図 3: LDRA で保存されるトポロジ情報
In a simple case, where the same node hosts the 4o6RA and the DHCP 4o6 server, it might be enough to only use 4o6RA, as shown in Figure 4, where CPE stands for "Customer Premises Equipment".
同じノードが 4o6RA と DHCP 4o6 サーバーをホストする単純なケースでは、図 4 に示すように 4o6RA のみを使用するだけで十分な場合があります。CPE は「Customer Premises Equipment」の略です。
.-----------.
| L2 Network |
+--------+-+ +-+------+----------+
| DHCP | | 4o6 | DHCP 4o6 |
| Client +---------+ Relay + Server |
| on CPE | | Agent | |
+--------+-+ +-+------+----------+
| |
'-----------'
Figure 4: Topology Information Preserved by 4o6 Relay Agent in DHCP Server
図 4: DHCP サーバーの 4o6 リレー エージェントによって保存されるトポロジ情報
As clients are unaware of the presence of 4o6RA, the network deployment needs to ensure that all DHCPv4 broadcast and unicast messages to and from clients are steered via a 4o6RA. This can be achieved by placing the 4o6RA in a central position that can intercept all traffic from the clients or by using Network Address Translation (NAT) with the 4o6RA address for unicast messages.
クライアントは 4o6RA の存在を認識しないため、ネットワーク展開では、クライアントとの間で送受信されるすべての DHCPv4 ブロードキャストおよびユニキャスト メッセージが 4o6RA 経由で誘導されるようにする必要があります。これは、クライアントからのすべてのトラフィックを傍受できる中央の位置に 4o6RA を配置するか、ユニキャスト メッセージの 4o6RA アドレスでネットワーク アドレス変換 (NAT) を使用することによって実現できます。
This document specifies the applicability of DHCP 4o6 in a scenario where legacy IPv4 clients are connected to DHCP 4o6 Relay Agents that perform the encapsulation and decapsulation. This document does not change anything else in the DHCP 4o6 specification [RFC7341]; therefore, the security considerations of that document still apply. Specifically, since the legacy IPv4 client is not aware of the encapsulation and decapsulation, 4o6RA has to provide the protections that are specified in the security considerations in Section 12 of [RFC7341].
この文書では、レガシー IPv4 クライアントがカプセル化とカプセル化解除を実行する DHCP 4o6 リレー エージェントに接続されているシナリオにおける DHCP 4o6 の適用可能性を指定します。この文書は、DHCP 4o6 仕様 [RFC7341] の他の部分を変更するものではありません。したがって、その文書のセキュリティ上の考慮事項が引き続き適用されます。具体的には、レガシー IPv4 クライアントはカプセル化とカプセル化解除を認識しないため、4o6RA は [RFC7341] のセクション 12 のセキュリティ上の考慮事項で指定されている保護を提供する必要があります。
The mechanisms defined here differ from [RFC7341] as they allow the DHCP client to send and receive DHCPv4 messages, whereas in [RFC7341], the client only sends DHCPv6 messages. This makes it possible that in improperly configured networks where the client is located on the same Layer 2 scope of a DHCPv4 server, DHCPv4 messages could reach a DHCPv4 server without using the 4o6RA. While this can cause erroneous state in both clients and servers and potentially even lead to misconfigurations that impact reachability, this is seen as a deployment error rather than a security concern. Further, even though this mechanism may be used for attacks from within the network, this is not a new concern introduced by this specification.
ここで定義されたメカニズムは、DHCP クライアントが DHCPv4 メッセージを送受信できるようにするため、[RFC7341] とは異なります。一方、[RFC7341] では、クライアントは DHCPv6 メッセージのみを送信します。このため、クライアントが DHCPv4 サーバーの同じレイヤ 2 スコープ上にある不適切に構成されたネットワークでは、DHCPv4 メッセージが 4o6RA を使用せずに DHCPv4 サーバーに到達する可能性があります。これにより、クライアントとサーバーの両方で誤った状態が発生し、到達可能性に影響を与える構成ミスにつながる可能性もありますが、これはセキュリティ上の問題ではなく、展開エラーとみなされます。さらに、このメカニズムはネットワーク内からの攻撃に使用される可能性がありますが、これはこの仕様によって新たに導入された問題ではありません。
More generally, legacy IPv4 clients are not aware of this mechanism; however, even when DHCP 4o6 is used, the client does not have any control about the information provided by the Relay Agent. As such, this change does not raise any additional security concerns.
より一般的には、レガシー IPv4 クライアントはこのメカニズムを認識しません。ただし、DHCP 4o6 が使用されている場合でも、クライアントはリレー エージェントによって提供される情報を制御できません。そのため、この変更によって新たなセキュリティ上の懸念が生じることはありません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6221>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
RFC 7341, DOI 10.17487/RFC7341, August 2014,
<https://www.rfc-editor.org/info/rfc7341>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9915] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
January 2026, <https://www.rfc-editor.org/info/rfc9915>.
[RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
DOI 10.17487/RFC0951, September 1985,
<https://www.rfc-editor.org/info/rfc951>.
[RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542,
October 1993, <https://www.rfc-editor.org/info/rfc1542>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
[RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP
Configuration on the Basis of Network Topology", RFC 7969,
DOI 10.17487/RFC7969, October 2016,
<https://www.rfc-editor.org/info/rfc7969>.
In 3GPP mobile network architecture, the User Equipment (UE) is connected via a Radio Access Network (RAN). RAN is built up with Baseband Units (BBUs) and Radio Units (RUs). A radio Fronthaul (FH) network connects RUs and BBUs. Each RU and BBU is an IP host, and they may support IPv4 only, IPv6 only, or both, depending on the vendor and the model. Each RU is unique as it is tied to a set of antennas, and each antenna is serving a specific Cell and Sector. Each RU is configured by the BBU depending on the Cell and Sectors it serves. However, that dependency is only specified by the cabling between RUs and antennas. BBUs can be cabled to RUs directly or via a Layer 2 switched network.
3GPP モバイル ネットワーク アーキテクチャでは、ユーザー機器 (UE) は無線アクセス ネットワーク (RAN) を介して接続されます。RAN は、ベースバンド ユニット (BBU) と無線ユニット (RU) で構築されます。無線フロントホール (FH) ネットワークは、RU と BBU を接続します。各 RU と BBU は IP ホストであり、ベンダーとモデルに応じて、IPv4 のみ、IPv6 のみ、または両方をサポートする場合があります。各 RU はアンテナのセットに関連付けられているため固有であり、各アンテナは特定のセルとセクターにサービスを提供します。各 RU は、サービスを提供するセルとセクターに応じて BBU によって構成されます。ただし、その依存関係は、RU とアンテナ間のケーブル配線によってのみ指定されます。BBU は、RU に直接ケーブル接続することも、レイヤ 2 スイッチ ネットワーク経由で接続することもできます。
+--------+
| RU2 +-----+
| | |
+--------+ |
|
+--------+ |
| RU3 | |
| +--+ | +-----------+
+--------+ | +--+ |
+-----+ Baseband |
| |
+--------+ +-----+ Unit |
| RU4 +--+ +--+ |
| | | +-----------+
+--------+ |
|
+--------+ |
| RU2 +-----+
| |
+--------+
Figure 5: 3GPP RAN Where RUs Are Cabled Directly to BBUs
図 5: RU が BBU に直接ケーブル接続される 3GPP RAN
In Figure 5, the BBU is directly cabled to a set of RUs, and the BBU can recognize the relationship between RUs and Cell/Sectors based on the cabling between the RUs and antennas.
図 5 では、BBU は RU のセットに直接ケーブル接続されており、BBU は RU とアンテナ間のケーブル接続に基づいて RU とセル/セクター間の関係を認識できます。
When BBUs and RUs are connected via a Layer 2 switched network, the added level of complexity requires the BBUs to have a deeper knowledge of the topology in order to properly configure the RUs, involving knowledge of all the cabling in the switched network.
BBU と RU がレイヤ 2 スイッチ ネットワーク経由で接続されている場合、複雑さが増すため、BBU は RU を適切に構成するために、スイッチ ネットワーク内のすべてのケーブル配線に関する知識を含む、トポロジについてのより深い知識を必要とします。
Examples for switched networks are shown in Section 3 of [RFC7969] and demonstrate the different levels of complexity. An example of a FH is depicted in Figure 6.
スイッチドネットワークの例は [RFC7969] のセクション 3 に示されており、さまざまなレベルの複雑さを示しています。FH の例を図 6 に示します。
+--------+
| RU1 | P1 +-+------+ | |
| +--------+ | L2RA | | +----+------+ |
+--------+ | +------+ | | | L3RA | |
| L2 | +--+ +------+ |
+--------+ P2 | Switch | | | | |
| RU2 +--------+ #1 +-----+ | Router +----+
| | +--------+ | +-----------+ | +---------+
+--------+ | | | |
| +--+ DHCP |
+--------+ | | | Server |
| RU3 | P1 +-+------+ | | | #1 |
| +--------+ | L2RA | | +-----------+ | +---------+
+--------+ | +------+ | | | |
| L2 | +--+ Baseband | |
+--------+ P2 | Switch | | | Unit | |
| RU4 +--------+ #2 +-----+ | +----+
| | +--------+ | +-----------+ |
+--------+ | |
Figure 6: 3GPP RAN with Layer 2 Switched Fronthaul Example
図 6: レイヤ 2 スイッチド フロントホールを使用した 3GPP RAN の例
If IPv6 is used and all RUs are capable of DHCPv6 in Figure 6, DHCP topology knowledge can be used for solving the RU configuration problem. Such solution would use the topology discovery mechanisms described in Section 3.2 of [RFC7969].
図 6 で IPv6 が使用され、すべての RU が DHCPv6 に対応している場合、DHCP トポロジの知識を使用して RU 構成の問題を解決できます。このようなソリューションでは、[RFC7969] のセクション 3.2 で説明されているトポロジ検出メカニズムが使用されます。
If RUs are capable of IPv4 only but implement a DHCP 4o6 client according to [RFC7341], the same topology discovery mechanisms are applicable.
RU が IPv4 のみに対応しているが、[RFC7341] に従って DHCP 4o6 クライアントを実装している場合、同じトポロジ検出メカニズムが適用できます。
If RUs are capable of IPv4 only and cannot implement a DHCP 4o6 client according to [RFC7341], the topology discovery mechanisms described in Section 3.2 of [RFC7969] can be used by introducing 4o6RA in the switches as described in this document.
RU が IPv4 のみに対応し、[RFC7341] に従って DHCP 4o6 クライアントを実装できない場合、この文書で説明されているようにスイッチに 4o6RA を導入することで、[RFC7969] のセクション 3.2 で説明されているトポロジ検出メカニズムを使用できます。
The authors would like to acknowledge interesting discussions in this problem space with Sarah Gannon, Ines Ramadza, and Siddharth Sharma, as well as reviews and comments provided by Éric Vyncke, Mohamed Boucadair, David Lamparter, Michael Richardson, Alan DeKok, Dale Worley, Paul Wouters, Deb Cooley, Erik Kline, Ketan Talaulikar, Mike Bishop, and Roman Danyliw.
著者らは、Sarah Gannon、Ines Ramadza、Siddharth Sharma とのこの問題領域における興味深い議論、ならびに Éric Vyncke、Mohamed Boucadair、David Lamparter、Michael Richardson、Alan DeKok、Dale Worley、Paul Wouters、Deb Cooley、Erik Kline、Ketan Talaulikar、Mike Bishop、および Roman Danyliw によって提供されたレビューとコメントに感謝したいと思います。
Claudio Porfiri
Ericsson
Email: claudio.porfiri@ericsson.com
Suresh Krishnan
Cisco
Email: suresh.krishnan@gmail.com
Jari Arkko
Ericsson
Email: jari.arkko@ericsson.com
Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com