3. DHCPv4-over-DHCPv6 Relay Agent (4o6RA)
この節では DHCPv4 over DHCPv6 with Relay Agent support の RFC 原文を保持し, relay behavior, topology-discovery diagrams, deployment notes, security considerations, IANA status を含めます.
3. DHCPv4-over-DHCPv6 Relay Agent (4o6RA)
This document assumes a network where IPv4-only hosts are connected
to a network that supports IPv6 and limited IPv4 services.
To address such a network setup, this document extends DHCPv6 Relay
Agents with DHCPv4 over DHCPv6, as shown in Figure 1.
.-----------. .-----------.
| | | |
+--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+
| DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server |
| | | with 4o6RA | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
'-----------' '-----------'
Figure 1: Architecture Example with Legacy DHCP Client
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.
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.
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]).
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.
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.
Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE
messages MUST handle them as specified in Section 6 of [RFC6221].
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.
3.1. Intermediate Relays
Intermediate relays shall behave according to Section 10 of
[RFC7341].
3.2. 4o6RA and Topology Discovery
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.
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.
Topology discovery as described in [RFC7969] differs between IPv4 and
IPv6 as follows:
* 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.
* 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.
In Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs)
[RFC6221] can be used.
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.
Then, topology information for the given IP address can be obtained
from the DHCPv6 server and used for configuration or other purposes.
[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.
.-----------------. .-------------------------.
| L2 Network | | IPv6 Network |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 |
| Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server |
| | | | | Agent | | Agent | | |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| | | |
'-----------------' '-------------------------'
Figure 2: Broken Topology Information
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].
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.
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.
.-----------------. .------------------------.
| 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
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".
.-----------.
| L2 Network |
+--------+-+ +-+------+----------+
| DHCP | | 4o6 | DHCP 4o6 |
| Client +---------+ Relay + Server |
| on CPE | | Agent | |
+--------+-+ +-+------+----------+
| |
'-----------'
Figure 4: Topology Information Preserved by 4o6 Relay Agent in
DHCP Server