rfc9928.original.md		rfc9928.md
	---		---
	title: "DHCPv4-over-DHCPv6 with Relay Agent Support"		title: "DHCPv4 over DHCPv6 with Relay Agent Support"
	abbrev: "DHCP 4o6 Relay Agent"		abbrev: "DHCP 4o6 Relay Agent"
	number: 0000		number: 9928
	category: std		category: std
	docname: draft-ietf-dhc-dhcpv4-over-dhcpv6-ra		docname: draft-ietf-dhc-dhcpv4-over-dhcpv6-ra
	submissiontype: IETF		submissiontype: IETF
	number: 0000		date: February 2026
	date: 2025-09
	consensus: true		consensus: true
	ipr: trust200902		ipr: trust200902
			pi: [toc, symrefs, sortrefs]
	v: 3		v: 3
			lang: en
	area: "INT"		area: "INT"
	workgroup: "dhc"		workgroup: "dhc"
	keyword:		keyword:
	- dhcp		- dhcp
	author:		author:
	-		-
	ins: C. Porfiri		ins: C. Porfiri
	name: Claudio Porfiri		name: Claudio Porfiri
	organization: Ericsson		organization: Ericsson
	skipping to change at line 43 ¶		skipping to change at line 44 ¶
	email: jari.arkko@ericsson.com		email: jari.arkko@ericsson.com
	-		-
	ins: M. Kühlewind		ins: M. Kühlewind
	name: Mirja Kühlewind		name: Mirja Kühlewind
	organization: Ericsson		organization: Ericsson
	email: mirja.kuehlewind@ericsson.com		email: mirja.kuehlewind@ericsson.com
	normative:		normative:
	RFC6221:		RFC6221:
	RFC7341:		RFC7341:
	I-D.ietf-dhc-rfc8415bis:		RFC9915:
	informative:		informative:
	RFC0951:		RFC0951:
	RFC1542:		RFC1542:
	RFC2131:		RFC2131:
	RFC2132:		RFC2132:
	RFC7969:		RFC7969:
	--- abstract		--- abstract
	This document describes a mechanism for networks		This document describes a mechanism for networks
	with legacy IPv4-only clients to use services provided by		with legacy IPv4-only clients to use services provided by
	DHCPv4-over-DHCPv6 in a Relay Agent.		DHCPv4 over DHCPv6 in a Relay Agent.
	RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only.		RFC 7341 specifies the use of DHCPv4 over DHCPv6 in the client only.
	This document specifies a RFC7341-based approach that		This document specifies an approach based on RFC 7341 that
	allows a Relay Agent to implement the DHCP 4o6 encapsulation and		allows a Relay Agent to implement the DHCP 4o6 encapsulation and
	decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a		decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a
	DHCPv4 client.		DHCPv4 client.
	--- middle		--- middle
	# Introduction {#introduction}		# Introduction {#introduction}
	{{RFC7341}} describes a transport mechanism for carrying DHCPv4 {{RFC2131}}		{{RFC7341}} describes a transport mechanism for carrying DHCPv4 {{RFC2131}}
	messages using DHCPv6 {{I-D.ietf-dhc-rfc8415bis}} for dynamic provisioning		messages using DHCPv6 {{RFC9915}} for dynamic provisioning
	of IPv4 addresses and other DHCPv4 specific configuration parameters		of IPv4 addresses and other DHCPv4-specific configuration parameters
	across IPv6-only networks. The deployment of {{RFC7341}} requires support in		across IPv6-only networks. The deployment of {{RFC7341}} requires support in
	DHCP clients and at the DHCPv6 server.		DHCP clients and at the DHCPv6 server.
	However, if a client is embedded in a host that only supports IPv4		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		and cannot easily be replaced or updated (which could be due to any
	number of technical or business reasons), this approach does not		number of technical or business reasons), this approach does not
	work.		work.
			<!-- [rfced] Please review the text below. We were unable to find "L3RA" used in
			[draft-ietf-dhc-rfc8415bis] (now published as RFC 9915).
			Original:
			Similarly, the specifications for DHCPv6 Relay Agents such as
			Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] or DHCPv6 Relay Agent
			(L3RA) [draft-ietf-dhc-rfc8415bis] do not foresee the possibility to
			handle legacy DHCPv4, other than implementing DHCP 4o6 in the client.
			-->
	Similarly, the specifications for DHCPv6 Relay Agents such as Lightweight		Similarly, the specifications for DHCPv6 Relay Agents such as Lightweight
	DHCPv6 Relay Agent (LDRA) {{RFC6221}} or DHCPv6 Relay Agent (L3RA)		DHCPv6 Relay Agent (LDRA) {{RFC6221}} or DHCPv6 Relay Agent (L3RA)
	{{I-D.ietf-dhc-rfc8415bis}} do not foresee the possibility to handle legacy DHCPv4,		{{RFC9915}} do not foresee the possibility to handle legacy DHCPv4,
	other than implementing DHCP 4o6 in the client.		other than implementing DHCP 4o6 in the client.
	This document specifies an {{RFC7341}} based solution that can be		This document specifies a solution based on {{RFC7341}} that can be
	implemented in intermediate nodes such as switches or routers,		implemented in intermediate nodes such as switches or routers,
	without putting any requirements on clients. No new protocols or extensions are neede d;		without putting any requirements on clients. No new protocols or extensions are neede d;
	instead, this document specifies a new use case for {{RFC7341}} that allows		instead, this document specifies a new use case for {{RFC7341}} that allows
	a Relay Agent to perform the DHCP 4o6 encapsulation and decapsulation instead of		a Relay Agent to perform the DHCP 4o6 encapsulation and decapsulation instead of
	the client.		the client.
	## Applicability Scope {#applicability}		## Applicability Scope {#applicability}
	The mechanisms described in this document apply to the configuration phase		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		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		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		a DHCP client conformant to {{RFC7341}}, as it is connected to an IPv4-only
	network. But there is a DHCPv6 server that can provide IPv4 addresses by means of		network. However, there is a DHCPv6 server that can provide IPv4 addresses by means o
			f
	the mechanisms specified in {{RFC7341}}.		the mechanisms specified in {{RFC7341}}.
			<!-- [rfced] Section 2:
			a) May we adjust the items in this list to appear in alphabetical order?
			b) May we make these list items consistent as follows?
			Original:
			* DHCP: If not otherwise specified, DHCP refers to DHCPv4 and/or
			DHCPv6.
			* DHCPv4: DHCP as defined in [RFC2131].
			* DHCPv4 over DHCPv6 (or 4o6): The architecture, the procedures, and
			the protocols specified in the DHCPv4-over-DHCPv6 document
			[RFC7341].
			* DHCP Relay Agent: This is a concept in all of the following
			protocols, although the details differ between them: BOOTP
			[RFC951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6
			[draft-ietf-dhc-rfc8415bis].
			* Lightweight DHCPv6 Relay Agent (or LDRA): This is an extension of
			the original DHCPv6 Relay Agent specification, to allow layer-
			2-only devices to perform a Relay Agent function [RFC6221].
			* DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Refers to a Relay Agent
			that implements the 4o6 transport as specified in this document.
			Perhaps:
			DHCP:
			Refers to DHCPv4 and/or DHCPv6 if not otherwise specified.
			DHCPv4:
			Refers to DHCP as defined in [RFC2131].
			DHCPv4 over DHCPv6 (DHCP 4o6):
			Refers to the architecture, the procedures, and the protocols specified in
			the DHCPv4-over-DHCPv6 document [RFC7341].
			(etc.)
			-->
	# Conventions and Definitions		# Conventions and Definitions
	The following terms and acronyms are used in this document:		The following terms and abbreviations are used in this document:
	* DHCP:		{:vspace}
	If not otherwise specified, DHCP refers to DHCPv4 and/or DHCPv6.		DHCP:
			: If not otherwise specified, DHCP refers to DHCPv4 and/or DHCPv6.
	* DHCPv4:		DHCPv4:
	DHCP as defined in {{RFC2131}}.		: DHCP as defined in {{RFC2131}}.
	* DHCPv4 over DHCPv6 (or 4o6):		DHCPv4 over DHCPv6 (DHCP 4o6):
	The architecture, the procedures, and the protocols specified in the		: The architecture, the procedures, and the protocols specified in the
	DHCPv4-over-DHCPv6 document {{RFC7341}}.		DHCPv4-over-DHCPv6 document {{RFC7341}}.
	* DHCP Relay Agent:		DHCP Relay Agent:
	This is a concept in all of the following protocols, although the details differ		: This is a concept in all of the following protocols, although the details differ
	between them: BOOTP {{RFC951}} {{RFC1542}}, DHCPv4		between them: the Bootstrap Protocol (BOOTP) {{RFC0951}} {{RFC1542}}, DHCPv4
	{{RFC2131}} {{RFC2132}}, and DHCPv6 {{I-D.ietf-dhc-rfc8415bis}}.		{{RFC2131}} {{RFC2132}}, and DHCPv6 {{RFC9915}}.
	* Lightweight DHCPv6 Relay Agent (or LDRA):		Lightweight DHCPv6 Relay Agent (LDRA):
	This is an extension of the original DHCPv6 Relay Agent specification, to allow		: This is an extension of the original DHCPv6 Relay Agent specification, to allow
	layer-2-only devices to perform a Relay Agent function {{RFC6221}}.		Layer 2 (L2) only devices to perform a Relay Agent function {{RFC6221}}.
	* DHCPv4 over DHCPv6 Relay Agent (or 4o6RA):		DHCPv4-over-DHCPv6 Relay Agent (4o6RA):
	Refers to a Relay Agent that implements the 4o6		: Refers to a Relay Agent that implements the 4o6
	transport as specified in this document.		transport as specified in this document.
	{::boilerplate bcp14-tagged}		{::boilerplate bcp14-tagged}
	# DHCPv4 over DHCPv6 Relay Agent (4o6RA)		# DHCPv4-over-DHCPv6 Relay Agent (4o6RA)
	This document assumes a network, where IPv4-only hosts are connected		This document assumes a network where IPv4-only hosts are connected
	to a network that supports IPv6 and limited IPv4 services.		to a network that supports IPv6 and limited IPv4 services.
	To address such a network setup, this document extends		To address such a network setup, this document extends
	DHCPv6 Relay Agents with DHCPv4-over-DHCPv6, as shown in {{fig_4o6RA}}.		DHCPv6 Relay Agents with DHCPv4 over DHCPv6, as shown in {{fig_4o6RA}}.
	~~~aasvg		~~~aasvg
	.-----------. .-----------.		.-----------. .-----------.
	| | | |		| | | |
	+--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+		+--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+
	| DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 |		| DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 |
	| Client +---------+ Relay Agent +---------+ Server |		| Client +---------+ Relay Agent +---------+ Server |
	| | | with 4o6RA | | |		| | | with 4o6RA | | |
	+--------+-+ +-+-----------+-+ +-+--------+		+--------+-+ +-+-----------+-+ +-+--------+
	| | | |		| | | |
	'-----------' '-----------'		'-----------' '-----------'
	~~~		~~~
	{: #fig_4o6RA title="Architecture Example with Legacy DHCP Client" artwork-align="cen ter"}		{: #fig_4o6RA title="Architecture Example with Legacy DHCP Client" artwork-align="cen ter"}
	This document specifies the encapsulation		This document specifies the encapsulation
	and decapsulation specified in {{RFC7341}} to be performed in the Relay Agent		and decapsulation specified in {{RFC7341}} to be performed in the Relay Agent
	without requiring any changes on the DHCPv4 client.		without requiring any changes on the DHCPv4 client.
	In this case it is up to the Relay Agent to provide the full DHCP		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		4o6 support, and the legacy DHCPv4 client is not aware that it is being served
	via a DHCP 4o6 service.		via a DHCP 4o6 service.
	As the 4o6RA acts as a DHCP 4o6 client, all prerequisites and configuration		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 4o6 RA.		that apply to the DHCP client in {{Section 5 of RFC7341}} are also applied to the 4o6 RA.
	As the 4o6RA takes the role of the client in respect to {{RFC7341}},		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		it is responsible for determining a suitable interface where it acts as a
	DHCPv6 client, and it is responsible for locating a suitable DHCPv6		DHCPv6 client, and it is responsible for locating a suitable DHCPv6
	server or relay agent and obtain the necessary IPv6 configuration..		server or Relay Agent and obtaining the necessary IPv6 configuration.
	As specified in {{RFC7341}}, the 4o6RA, acting as 4o6 client, therefore has to reques t		As specified in {{RFC7341}}, the 4o6RA, acting as 4o6 client, therefore has to reques t
	the DHCP 4o6 Server Address option from the server by sending the		the DHCP 4o6 Server Address option from the server by sending the
	Option Request option as described in {{I-D.ietf-dhc-rfc8415bis}}		Option Request option as described in {{RFC9915}}
	before it can use the 4o6 transport.		before it can use the 4o6 transport.
	To maintain interoperability with existing DHCPv6 relays and servers,		To maintain interoperability with existing DHCPv6 relays and servers,
	the message format is unchanged from {{I-D.ietf-dhc-rfc8415bis}}. The 4o6RA implement		the message format is unchanged from {{RFC9915}}. The 4o6RA implements
	s		the same message types as a DHCPv6 Relay Agent (see {{Section 6 of RFC7341}}).
	the same message types as a DHCPv6 Relay Agent {{Section 6 of RFC7341}}.
	However, in this specification, the 4o6RA, instead of the client, creates the DHCPV4- QUERY Message		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.		and encapsulates the DHCP request message received from the legacy DHCPv4 client.
	When DHCPV4-RESPONSE Message is received by the 4o6 Relay Agent,		When the DHCPV4-RESPONSE message is received by the 4o6 Relay Agent,
	it looks for the DHCPv4 Message option within this message.		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,		If this option is not found or the DHCPv4-RESPONSE message is not well-formed,
	it MUST be discarded.		it MUST be discarded.
	If the DHCPv4 Message option is present and correct, the 4o6RA MUST extract the DHCPv		If the DHCPv4 message option is present and correct, the 4o6RA MUST extract the DHCPv
	4		4
	message and forward the encapsulated DHCPv4-response to the requesting DHCPv4		message and forward the encapsulated DHCPv4-RESPONSE to the requesting DHCPv4
	client, given that the encapsulated DHCPv4-response is correct and can be		client, given that the encapsulated DHCPv4-RESPONSE is correct and can be
	actually forwarded.		actually forwarded.
	Layer-2 Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages		Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages
	MUST handle them as specified in {{Section 6 of RFC6221}}.		MUST handle them as specified in {{Section 6 of RFC6221}}.
	In any given environment, DHCPv6 servers to which DHCPV4-QUERY		In any given environment, DHCPv6 servers to which DHCPV4-QUERY
	requests are routed are expected to be compliant with 4o6 according		requests are routed are expected to be compliant with 4o6 according
	to {{RFC7341}}. No additional requirements on DHCPv6 servers are set		to {{RFC7341}}. No additional requirements on DHCPv6 servers are set
	by this specification.		by this specification.
	## Intermediate relays		## Intermediate Relays
	Intermediate relays shall behave according to section 10 of {{RFC7341}}.		Intermediate relays shall behave according to {{Section 10 of RFC7341}}.
	## 4o6RA and Topology Discovery {#topology_considerations}		## 4o6RA and Topology Discovery {#topology_considerations}
	In some networks, the configuration of a host may depend on the topology.		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		However, when a new host attaches to a network, it may be unaware
	of the topology and, consequently, how it has to be configured.		of the topology and, consequently, how it has to be configured.
	DHCPv4 {{RFC2131}} and DHCPv6 {{I-D.ietf-dhc-rfc8415bis}} specifications		DHCPv4 {{RFC2131}} and DHCPv6 {{RFC9915}} specifications
	describe how addresses can be allocated to clients based on network		describe how addresses can typically be allocated to clients based on network
	topology information provided by a DHCP relay, typically.		topology information provided by a DHCP relay.
	Address/prefix allocation decisions are integral to the allocation of		Address/prefix allocation decisions are integral to the allocation of
	addresses and prefixes in DHCP, as described in detail		addresses and prefixes in DHCP, as described in detail
	in {{RFC7969}}. This specification aims to guarantee that the 4o6RA does not		in {{RFC7969}}. This specification aims to guarantee that the 4o6RA does not
	break any legacy capability when used for topology discovery.		break any legacy capability when used for topology discovery.
	Topology discovery as described in {{RFC7969}} differs between		Topology discovery as described in {{RFC7969}} differs between
	IPv4 and IPv6:		IPv4 and IPv6 as follows:
	* IPv4:		* IPv4: When using DHCP on IPv4, only the first Relay Agent SHOULD
	when using DHCP on IPv4 only the first Relay Agent SHOULD		set the giaddr field ({{Section 3.1 of RFC7969}}). Thus, in a
	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
	network that has more than one Relay Agent only part of the topology
	is transported via DHCPv4.		is transported via DHCPv4.
	* IPv6:		* IPv6: When using DHCPv6, all Relay Agents SHOULD send
	when using DHCPv6, all Relay Agents SHOULD send		link-address and Interface-ID options that provide
	link-address and Interface-ID options, that provide
	information about the complete path		information about the complete path
	between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server.		between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server.
	In Layer-2 networks, Lightweight DHCPv6 Relay Agents {{RFC6221}}		In Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs) {{RFC6221}}
	can be used.		can be used.
	When provided, the topology information is available at the DHCPv6		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.		server in the form of a sequence of the link-address field and Interface-ID option.
	Then, topology information for the given IP address		Then, topology information for the given IP address
	can be obtained from the DHCPv6 server and used for configuration		can be obtained from the DHCPv6 server and used for configuration
	or other purposes.		or other purposes.
	{{RFC7341}} enables the client to use DHCPv6 for topology discovery		{{RFC7341}} enables the client to use DHCPv6 for topology discovery
	even within a DHCPv4 context, as the DHCPv6 Relay Agent knows		even within a DHCPv4 context, as the DHCPv6 Relay Agent knows
	the interface where the encapsulated DHCP request is received.		the interface where the encapsulated DHCP request is received.
	As shown in {{fig_4o6RA_RA}}, however, the introduction of 4o6 at		However, as shown in {{fig_4o6RA_RA}}, the introduction of 4o6 at
	the edge of the IPv6 network hides the Layer-2 network from the DHCPv6 RA.		the edge of the IPv6 network hides the Layer 2 network from the DHCPv6 RA.
	As such, moving 4o6 to a intermediate node rather than performing it at the client br		As such, moving 4o6 to an intermediate node rather than performing it at the client b
	eaks		reaks
	the topology propagation, as 4o6RA-only solutions does not provide any interface		the topology propagation, as 4o6RA-only solutions do not provide any interface
	information in the encapsulated message.		information in the encapsulated message.
	~~~aasvg		~~~aasvg
	.-----------------. .-------------------------.		.-----------------. .-------------------------.
	| L2 Network | | IPv6 Network |		| L2 Network | | IPv6 Network |
	+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+		+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
	| DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 |		| DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 |
	| Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server |		| Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server |
	| | | | | Agent | | Agent | | |		| | | | | Agent | | Agent | | |
	+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+		+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
	| | | |		| | | |
	'-----------------' '-------------------------'		'-----------------' '-------------------------'
	~~~		~~~
	{: #fig_4o6RA_RA title="Broken topology information" artwork-align="center"}		{: #fig_4o6RA_RA title="Broken Topology Information" artwork-align="center"}
	In order to provide full topology information, it is RECOMMENDED that		In order to provide full topology information, it is RECOMMENDED that
	any implementation of 4o6RA be combined		any implementation of 4o6RA be combined
	with an LDRA implementation {{RFC6221}} in a back-to-back structure, and that the		with an LDRA implementation {{RFC6221}} in a back-to-back structure and that the
	LDRA implementation includes a mechanism to obtain interface information that		LDRA implementation includes a mechanism to obtain interface information that
	can be used to provide the Interface-ID option to outgoing		can be used to provide the Interface-ID option to outgoing
	DHCPV4-QUERY messages, as specified in Section 5.3.2 of {{RFC6221}}.		DHCPV4-QUERY messages, as specified in {{Section 5.3.2 of RFC6221}}.
	The internal mechanisms to exchange interface information,		The internal mechanisms to exchange interface information,
	their format and whether the interface information contains an indication that a 4o6R		their format, and whether the interface information contains an indication that a 4o6
	A		RA
	is involved are out of the scope for this document.		is involved, are out of the scope for this document.
	The resulting architecture is shown in {{fig_4o6LDRA}} where		The resulting architecture is shown in {{fig_4o6LDRA}} where
	the Relay Agent is implementing 4o6RA and LDRA, and has an internal interface to		the Relay Agent is implementing 4o6RA and LDRA and has an internal interface to
	propagate topology information from 4o6RA to LDRA.		propagate topology information from 4o6RA to LDRA.
	~~~aasvg		~~~aasvg
	.-----------------. .------------------------.		.-----------------. .------------------------.
	| L2 Network or | | IPv6 Network |		| L2 Network or | | IPv6 Network |
	| IPv6-only link | | |		| IPv6-Only Link | | |
	+--------+-+ +---------+ +-+---+--+---------+ +------+---+		+--------+-+ +---------+ +-+---+--+---------+ +------+---+
	| DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 |		| DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 |
	| Client +--+ Switch +--+ Relay + RFC6221 +------+ Server |		| Client +--+ Switch +--+ Relay + RFC 6221+------+ Server |
	| | | | | Agent | | | |		| | | | | Agent | | | |
	+--------+-+ +---------+ +-+---+--+---------+ +------+---+		+--------+-+ +---------+ +-+---+--+---------+ +------+---+
	| | | |		| | | |
	'-----------------' '------------------------'		'-----------------' '------------------------'
	~~~		~~~
	{: #fig_4o6LDRA title="Topology information preserved with LDRA" artwork-align="cente r"}		{: #fig_4o6LDRA title="Topology Information Preserved with LDRA" artwork-align="cente r"}
	In a simple case, where the same node hosts the 4o6RA and the DHCP4o6 server,		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 {{fig_4o6RAserver}}.		it might be enough to only use 4o6RA, as shown in {{fig_4o6RAserver}}.
			<!-- [rfced] Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations
			should be expanded upon first use. How and where should "CPE" be expanded as
			it appears in Figure 4?
			Original:
			In a simple case, where the same node hosts the 4o6RA and the DHCP4o6
			server, it might be enough to only use 4o6RA, as shown in Figure 4.
			Perhaps:
			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".
			-->
	~~~aasvg		~~~aasvg
	.-----------.		.-----------.
	| L2 Network |		| L2 Network |
	+--------+-+ +-+------+----------+		+--------+-+ +-+------+----------+
	| DHCP | | 4o6 | DHCP 4o6 |		| DHCP | | 4o6 | DHCP 4o6 |
	| Client +---------+ Relay + Server |		| Client +---------+ Relay + Server |
	| on CPE | | Agent | |		| on CPE | | Agent | |
	+--------+-+ +-+------+----------+		+--------+-+ +-+------+----------+
	| |		| |
	'-----------'		'-----------'
	~~~		~~~
	{: #fig_4o6RAserver title="Topology information preserved by 4o6 Relay Agent in DHCP server" artwork-align="center"}		{: #fig_4o6RAserver title="Topology Information Preserved by 4o6 Relay Agent in DHCP Server" artwork-align="center"}
	# Deployment Considerations		# Deployment Considerations
	As clients are unaware of the presence of 4o6RA, the network		As clients are unaware of the presence of 4o6RA, the network
	deployment needs to ensure that all DHCPv4 broadcast and unicast messages to and		deployment needs to ensure that all DHCPv4 broadcast and unicast messages to and
	from clients are steered via a 4o6RA.		from clients are steered via a 4o6RA.
	This can be achieved by placing the 4o6RA in a central position		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		that can intercept all traffic from the clients or by using Network Address
	Translation (NAT) with the 4o6RA address for unicast messages.		Translation (NAT) with the 4o6RA address for unicast messages.
			<!-- [rfced] Security Considerations:
			a) Would the following adjustment clarify what "the 4o6 DHCP specification"
			refers to?
			b) Please note that we have changed "4o6 DHCP" to "DHCP 4o6" in this
			section for consistency with the rest of the document.
			Original:
			This document does not change anything else in the 4o6 DHCP specification
			and therefore the security considerations of [RFC7341] still apply.
			Perhaps:
			This document does not change anything else in the DHCP 4o6 specification [RFC7341
			];
			therefore, the security considerations of that document still apply.
			-->
	# Security Considerations {#seccons}		# Security Considerations {#seccons}
	This document specifies the applicability of 4o6 DHCP in a scenario where legacy IPv4 clients are		This document specifies the applicability of DHCP 4o6 in a scenario where legacy IPv4 clients are
	connected to 4o6 DHCP Relay Agents that perform the encapsulation and decapsulation. This document		connected to 4o6 DHCP Relay Agents that perform the encapsulation and decapsulation. This document
	does not change anything else in the 4o6 DHCP specification and therefore the		does not change anything else in the DHCP 4o6 specification; therefore, the
	security considerations of {{RFC7341}} still apply.		security considerations of {{RFC7341}} still apply.
	Specifically, since the legacy IPv4 client is not aware of the encapsulation and deca psulation,		Specifically, since the legacy IPv4 client is not aware of the encapsulation and deca psulation,
	it is 4o6RA has to provide the protections that are specficed in the security		4o6RA has to provide the protections that are specified in the security
	considerations in {{Section 12 of RFC7341}}.		considerations in {{Section 12 of RFC7341}}.
	The mechanisms defined here differ from {{RFC7341}} as they allow the DHCP client		The mechanisms defined here differ from {{RFC7341}} as they allow the DHCP client
	to send and receive DHCPv4 messages, whereas in {{RFC7341}} the client		to send and receive DHCPv4 messages, whereas in {{RFC7341}}, the client
	only sends DHCPv6 messages. This makes it possible that in improperly configured		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,		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.		DHCPv4 messages could reach a DHCPv4 server without using the 4o6RA.
	While this can cause erroneous state in both clients and servers		While this can cause erroneous state in both clients and servers
	and potentially even lead to misconfigurations that impact reachability,		and potentially even lead to misconfigurations that impact reachability,
	this is seen as a deployment error rather than a security concern.		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,		Further, even though this mechanism may be used for attacks from within the network,
	this is not a new concern introduced by this specification.		this is not a new concern introduced by this specification.
	More generally, legacy IPv4 clients are not aware of this mechanism, however, even		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		when DHCP 4o6 is used, the client does not have any control about the
	information provided by the Relay agent.		information provided by the Relay Agent.
	As such this change does not raise any additional security concerns.		As such, this change does not raise any additional security concerns.
	# IANA Considerations		# IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	--- back		--- back
	# Example Use Case: Topology Discovery for IPv4-only Radio Unit in 3GPP RAN with Swit		<!-- [rfced] Appendix A: Please review our questions and suggested updates to
	ched Fronthaul {#usecase}		the text below, including the following items:
	In 3GPP mobile network architecture, the User Equipments (UE) are connected		a) Should the abbreviation for "Baseband Units (BB)" be updated to "Baseband Units (B
	via Radio Access Network (RAN). RAN is built up with Baseband Units (BB)		BUs)"
	and Radio Units (RU). Radio Fronthaul Network (FH) connects RU and BB, each of		as seen in the text below? If so, please note that we would also update instances of
	RU and BB is an IP host, they may support IPv4 only, IPv6 only or both		"BB"/"BBs" to "BBU"/"BBUs" accordingly throughout the rest of this section as well.
			b) Should the abbreviation for "Radio Fronthaul Network (FH)" be adjusted for
			clarity?
			Original:
			In 3GPP mobile network architecture, the User Equipments (UE) are
			connected via Radio Access Network (RAN). RAN is built up with
			Baseband Units (BB) and Radio Units (RU). Radio Fronthaul Network
			(FH) connects RU and BB, each of RU and BB is an IP host, they may
			support IPv4 only, IPv6 only or both depending on the vendor and the
			model.
			Perhaps:
			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.
			-->
			# Example Use Case: Topology Discovery for IPv4-Only Radio Unit in 3GPP RAN with Swit
			ched Fronthaul {#usecase}
			In 3GPP mobile network architecture, the User Equipment (UE) is connected
			via Radio Access Network (RAN). RAN is built up with Baseband Units (BBs)
			and Radio Units (RUs). Radio Fronthaul Network (FH) connects RUs and BBs. Each
			RU and BB is an IP host, and they may support IPv4 only, IPv6 only, or both,
	depending on the vendor and the model.		depending on the vendor and the model.
	Each RU is unique as it is tied to a set of antennas, and each antenna		Each RU is unique as it is tied to a set of antennas, and each antenna
	is serving a specific Cell and Sector.		is serving a specific Cell and Sector.
	Each RU is configured by the BB depending on the Cell and Sectors it serves.		Each RU is configured by the BB depending on the Cell and Sectors it serves.
	However, that dependency is only specified by the cabling between RU and antennas.		However, that dependency is only specified by the cabling between RUs and antennas.
	BB can be cabled to RU directly or via a Layer-2 switched network.		BBs can be cabled to RUs directly or via a Layer 2 switched network.
	~~~aasvg		~~~aasvg
	+--------+		+--------+
	| RU2 +-----+		| RU2 +-----+
	| | |		| | |
	+--------+ |		+--------+ |
	|		|
	+--------+ |		+--------+ |
	| RU3 | |		| RU3 | |
	| +--+ | +-----------+		| +--+ | +-----------+
	skipping to change at line 385 ¶		skipping to change at line 509 ¶
	+--------+ +-----| Unit |		+--------+ +-----| Unit |
	| RU4 +--+ +--| |		| RU4 +--+ +--| |
	| | | +-----------+		| | | +-----------+
	+--------+ |		+--------+ |
	|		|
	+--------+ |		+--------+ |
	| RU2 +-----+		| RU2 +-----+
	| |		| |
	+--------+		+--------+
	~~~		~~~
	{: #bb_connected_to_ru title="3GPP RAN where RU are cabled directly to BB" artwork-al ign="center"}		{: #bb_connected_to_ru title="3GPP RAN Where RUs Are Cabled Directly to BB" artwork-a lign="center"}
	In {{bb_connected_to_ru}} BB is directly cabled to a set of RUs, the		In {{bb_connected_to_ru}}, the BB is directly cabled to a set of RUs, and the
	BB can recognize the relationship between RUs and Cell/Sectors		BB can recognize the relationship between RUs and Cell/Sectors
	based on the cabling between the RUs and antennas.		based on the cabling between the RUs and antennas.
	When BBs and RUs are connected via a Layer-2 switched network,		When BBs and RUs are connected via a Layer 2 switched network,
	the added level of complexity requires the BBs to have a deeper		the added level of complexity requires the BBs to have a deeper
	knowledge of the topology in order to properly configure the RUs,		knowledge of the topology in order to properly configure the RUs,
	involving knowledge of all the cabling in the switched network.		involving knowledge of all the cabling in the switched network.
	Examples for switched networks are shown in section 3 of {{RFC7969}}		Examples for switched networks are shown in {{Section 3 of RFC7969}}
	and demonstrate the different levels of complexity.		and demonstrate the different levels of complexity.
	An example of a FH is depicted in {{l2_switched_fh}}.		An example of a FH is depicted in {{l2_switched_fh}}.
	~~~aasvg		~~~aasvg
	+--------+		+--------+
	| RU1 | P1 +-+------+ | |		| RU1 | P1 +-+------+ | |
	| +--------| | L2RA | | +----+------+ |		| +--------| | L2RA | | +----+------+ |
	+--------+ | +------+ | | | L3RA | |		+--------+ | +------+ | | | L3RA | |
	| L2 | +--| +------+ |		| L2 | +--| +------+ |
	+--------+ P2 | switch | | | | |		+--------+ P2 | Switch | | | | |
	| RU2 +--------| #1 +-----| | Router +----|		| RU2 +--------| #1 +-----| | Router +----|
	| | +--------+ | +-----------+ | +---------+		| | +--------+ | +-----------+ | +---------+
	+--------+ | | | |		+--------+ | | | |
	| +--| DHCP |		| +--| DHCP |
	+--------+ | | | Server |		+--------+ | | | Server |
	| RU3 | P1 +-+------+ | | | #1 |		| RU3 | P1 +-+------+ | | | #1 |
	| +--------| | L2RA | | +-----------+ | +---------+		| +--------| | L2RA | | +-----------+ | +---------+
	+--------+ | +------+ | | | |		+--------+ | +------+ | | | |
	| L2 | +--| Baseband | |		| L2 | +--| Baseband | |
	+--------+ P2 | switch | | | Unit | |		+--------+ P2 | Switch | | | Unit | |
	| RU4 +--------| #2 +-----| | +----|		| RU4 +--------| #2 +-----| | +----|
	| | +--------+ | +-----------+ |		| | +--------+ | +-----------+ |
	+--------+ | |		+--------+ | |
	~~~		~~~
	{: #l2_switched_fh title="3GPP RAN with Layer-2 Switched Fronthaul Example" artwork-a lign="center"}		{: #l2_switched_fh title="3GPP RAN with Layer 2 Switched Fronthaul Example" artwork-a lign="center"}
	If IPv6 is used and all RU are capable of DHCPv6 in {{l2_switched_fh}},		If IPv6 is used and all RUs are capable of DHCPv6 in {{l2_switched_fh}},
	DHCP topology knowledge can be used for solving the RU configuration problem.		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		Such solution would use the topology discovery mechanisms described in {{Section 3.2
	of {{RFC7969}}.		of RFC7969}}.
	If RU are capable of IPv4 only but implement a 4o6 client according to {{RFC7341}}, t he same topology discovery mechanisms are applicable.		If RUs are capable of IPv4 only but implement a 4o6 client according to {{RFC7341}}, the same topology discovery mechanisms are applicable.
	If RU are capable of IPV4 only and cannot implement a 4o6 client according to {{RFC73		If RUs are capable of IPv4 only and cannot implement a 4o6 client according to {{RFC7
	41}},		341}},
	the topology discovery mechanisms described in section 3.2		the topology discovery mechanisms described in {{Section 3.2
	of {{RFC7969}} can be used by introducing 4o6RA in the switches as decribed in this d		of RFC7969}} can be used by introducing 4o6RA in the switches as described in this do
	ocument.		cument.
	# Acknowledgments		# Acknowledgments
	{:numbered="false"}		{:numbered="false"}
	The authors would also like to acknowledge interesting discussions in		The authors would like to acknowledge interesting discussions in
	this problem space with Sarah Gannon, Ines Ramadza, and Siddharth Sharma		this problem space with {{{Sarah Gannon}}}, {{{Ines Ramadza}}}, and {{{Siddharth Shar
	as well as reviews and comments provided by Eric Vyncke, Mohamed Boucadair,		ma}}},
	David Lamparter, Michael Richardson, Alan DeKok, Dale Worley, Paul Wouters,		as well as reviews and comments provided by {{{Éric Vyncke}}}, {{{Mohamed Boucadair}}
	Deb Cooley, Erik Kline, Ketan Talaulikar, Mike Bishop and Roman Danyliw.		},
			{{{David Lamparter}}}, {{{Michael Richardson}}}, {{{Alan DeKok}}}, {{{Dale Worley}}},
			{{{Paul Wouters}}},
			{{{Deb Cooley}}}, {{{Erik Kline}}}, {{{Ketan Talaulikar}}}, {{{Mike Bishop}}}, and {{
			{Roman Danyliw}}}.
			<!-- [rfced] Terminology and Abbreviations:
			a) We note that the phrase "4o6" appears a few times by itself throughout this
			document. For consistency and context, should these instances be updated to "DHCP 4o6
			"?
			We have provided a few examples below:
			the 4o6 transport
			are expected to be compliant with 4o6
			the introduction of 4o6 at the edge
			moving 4o6 to a intermediate node
			a 4o6 client
			b) We note the following phrases appear after their abbreviations are
			introduced. For consistency, should these terms (on the left) be updated to
			their abbreviated form (on the right) after first use?
			Expansion -> Abbreviation
			DHCPv4-over-DHCPv6 -> DHCP 4o6
			4o6 Relay Agent -> 4o6RA
			Layer 2 -> L2
			c) FYI - We have added expansions for abbreviations upon first use
			per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
			expansion in the document carefully to ensure correctness.
			Bootstrap Protocol (BOOTP)
			Layer 2 (L2)
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			Note that our script did not flag any words in particular, but this should
			still be reviewed as a best practice. -->
End of changes. 74 change blocks.
	114 lines changed or deleted		240 lines changed or added
This html diff was produced by rfcdiff 1.48.