rfc8987xml2.original.xml		rfc8987.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2119.xml">
	<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4443.xml">
	<!ENTITY RFC4778 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4778.xml">
	<!ENTITY RFC5460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5460.xml">
	<!ENTITY RFC7513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7513.xml">
	<!ENTITY RFC7653 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7653.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	<!ENTITY RFC8213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8213.xml">
	<!ENTITY RFC8415 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8415.xml">
	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="4"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std" docName="draft-ietf-dhc-dhcpv6-pd-relay-requirements-05"
	ipr="trust200902">
	<front>
	<title abbrev="DHCPv6 PD Relay">DHCPv6 Prefix Delegating Relay Requirements</t
	itle>
	<author fullname="Ian Farrer" initials="I" surname="Farrer">
	<organization>Deutsche Telekom AG</organization>
	<address>
	<postal>
	<street>Landgrabenweg 151</street>
	<city>Bonn</city>
	<code>53227</code>
	<country>DE</country>
	</postal>
	<email>ian.farrer@telekom.de</email>
	</address>
	</author>
	<author fullname="Naveen Kottapalli" initials="N" surname="Kottapalli">
	<organization>Benu Networks</organization>
	<address>
	<postal>
	<street>154 Middlesex Turnpike</street>
	<city>Burlington</city>
	<code>01803</code>
	<region>MA</region>
	<country>USA</country>
	</postal>
	<email>nkottapalli@benunets.com</email>
	</address>
	</author>
	<author fullname="Martin Hunek" initials="M" surname="Hunek">
	<organization>Technical University of Liberec</organization>
	<address>
	<postal>
	<street>Studentska 1402/2</street>
	<city>Liberec</city>
	<code>46017</code>
	<country>CZ</country>
	</postal>
	<email>martin.hunek@tul.cz</email>
	</address>
	</author>
	<author fullname="Richard Patterson" initials="R.P." surname="Patterson">
	<organization>Sky UK Ltd</organization>
	<address>
	<postal>
	<street>1 Brick Lane</street>
	<city>London</city>
	<code>E1 6PU</code>
	<country>UK</country>
	</postal>
	<email>richard.patterson@sky.uk</email>
	</address>
	</author>
	<date month="January" year="2021"/>
	<area>Internet</area>		<!-- updated by Chris 01/05/21 -->
	<workgroup>DHC Work Group</workgroup>		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<keyword>Prefix Delegation</keyword>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dhc-dhcpv6-p
	<keyword>DHCPv6 relay</keyword>		d-relay-requirements-05"
	<keyword>Delegating router</keyword>		number="8987" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" ca
	<keyword>Requesting router</keyword>		tegory="std"
	<keyword>Delegating relay</keyword>		consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sor
			tRefs="true"
			version="3">
	<abstract>		<!-- xml2rfc v2v3 conversion 3.5.0 -->
	<t>This document describes operational problems that are known to		<front>
	occur when using DHCPv6 relays with Prefix Delegation. These		<title abbrev="DHCPv6 PD Relay">DHCPv6 Prefix Delegating Relay Requirements<
			/title>
			<seriesInfo name="RFC" value="8987"/>
			<author fullname="Ian Farrer" initials="I." surname="Farrer">
			<organization>Deutsche Telekom AG</organization>
			<address>
			<postal>
			<street>Landgrabenweg 151</street>
			<city>Bonn</city>
			<code>53227</code>
			<country>Germany</country>
			</postal>
			<email>ian.farrer@telekom.de</email>
			</address>
			</author>
			<author fullname="Naveen Kottapalli" initials="N." surname="Kottapalli">
			<organization>Benu Networks</organization>
			<address>
			<postal>
			<street>WeWork Galaxy, 43 Residency Road</street>
			<city>Bangalore</city>
			<code>560025</code>
			<region>Karnataka</region>
			<country>India</country>
			</postal>
			<email>nkottapalli@benunets.com</email>
			</address>
			</author>
			<author fullname="Martin Hunek" initials="M." surname="Hunek">
			<organization>Technical University of Liberec</organization>
			<address>
			<postal>
			<street>Studentska 1402/2</street>
			<city>Liberec</city>
			<code>46017</code>
			<country>Czech Republic</country>
			</postal>
			<email>martin.hunek@tul.cz</email>
			</address>
			</author>
			<author fullname="Richard Patterson" initials="R." surname="Patterson">
			<organization>Sky UK Ltd.</organization>
			<address>
			<postal>
			<street>1 Brick Lane</street>
			<city>London</city>
			<code>E1 6PU</code>
			<country>United Kingdom</country>
			</postal>
			<email>richard.patterson@sky.uk</email>
			</address>
			</author>
			<date month="February" year="2021"/>
			<area>Internet</area>
			<workgroup>DHC Work Group</workgroup>
			<keyword>Prefix Delegation</keyword>
			<keyword>DHCPv6 relay</keyword>
			<keyword>Delegating router</keyword>
			<keyword>Requesting router</keyword>
			<keyword>Delegating relay</keyword>
			<abstract>
			<t>This document describes operational problems that are known to
			occur when using DHCPv6 relays with prefix delegation. These
	problems can prevent successful delegation and result in routing		problems can prevent successful delegation and result in routing
	failures. To address these problems, this document provides		failures. To address these problems, this document provides
	necessary functional requirements for operating DHCPv6 relays with		necessary functional requirements for operating DHCPv6 relays with
	Prefix Delegation.</t>		prefix delegation.</t>
			<t>It is recommended that any network operator using DHCPv6
	<t>It is recommended that any network operator that is using DHCPv6		prefix delegation with relays ensure that these requirements
	prefix delegation with relays should ensure that these requirements
	are followed on their networks.</t>		are followed on their networks.</t>
	</abstract>		</abstract>
	</front>		</front>
			<middle>
	<middle>		<section numbered="true" toc="default">
	<section title="Introduction">		<name>Introduction</name>
	<t>For internet service providers that offer native IPv6 access		<t>For Internet service providers that offer native IPv6 access
	with prefix delegation to their customers, a common deployment		with prefix delegation to their customers, a common deployment
	architecture is to have a DHCPv6 relay agent function located in		architecture is to have a DHCPv6 relay agent function located in
	the ISP's Layer-3 customer edge device and separate, centralized		the ISP's Layer 3 customer edge device and a separate, centralized
	DHCPv6 server infrastructure. <xref target="RFC8415"/> describes		DHCPv6 server infrastructure. <xref target="RFC8415" format="default"/> des
	the functionality of a DHCPv6 relay and Section 19.1.3 mentions		cribes
	this deployment scenario, but does not provide details for all of		the functionality of a DHCPv6 relay, and <xref target="RFC8415" sectionForma
			t="of" section="19.1.3"/> mentions
			this deployment scenario, but it does not provide details for all of
	the functional requirements that the relay needs to fulfill to		the functional requirements that the relay needs to fulfill to
	operate deterministically in this deployment scenario.</t>		operate deterministically in this deployment scenario.</t>
			<t>A DHCPv6 relay agent for prefix delegation is a function commonly
	<t>A DHCPv6 relay agent for prefix delegation is a function commonly
	implemented in routing devices, but implementations vary in		implemented in routing devices, but implementations vary in
	their functionality and client/server inter-working. This can		their functionality and client/server interworking. This can
	result in operational problems such as messages not being forwarded		result in operational problems such as messages not being forwarded
	by the relay or un-reachability of the delegated prefixes. This		by the relay or unreachability of the delegated prefixes. This
	document provides a set of requirements for devices implementing a		document provides a set of requirements for devices implementing a
	relay function for use with prefix delegation.		relay function for use with prefix delegation.
	</t>		</t>
			<t>The mechanisms for a relay to inject routes (including aggregated
	<t>The mechanisms for a relay to inject routes (including aggregated		ones) on its network-facing interface based on prefixes learned
	ones), on its network-facing interface based on prefixes learned		from a server via DHCP prefix delegation (DHCP-PD) are out of scope of the d
	from a server via DHCP-PD are out of scope of the document.</t>		ocument.</t>
			<t>Multi-hop DHCPv6 relaying is not affected. The requirements
	<t>Multi-hop DHCPv6 relaying is not affected. The requirements
	in this document are solely applicable to the DHCP relay agent		in this document are solely applicable to the DHCP relay agent
	co-located with the first-hop router that the DHCPv6 client		co-located with the first-hop router to which the DHCPv6 client
	requesting the prefix is connected to, so no changes to any		requesting the prefix is connected, so no changes to any
	subsequent relays in the path are needed.</t>		subsequent relays in the path are needed.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Terminology">		<name>Terminology</name>
	<section title="General">		<section numbered="true" toc="default">
	<t>This document uses the terminology defined in <xref		<name>General</name>
	target="RFC8415"/>, however, when defining the functional		<t>This document uses the terminology defined in <xref target="RFC8415"
	elements for prefix delegation <xref target="RFC8415"/>, Section		format="default"/>. However, when defining the functional
	4.2 defines the term 'delegating router' as:		elements for prefix delegation, <xref target="RFC8415" sectionFormat="co
	<list style="empty">		mma" section="4.2"/> defines the term "delegating router" as:
	<t>"The router that acts as a DHCP server and responds to		</t>
	requests for delegated prefixes."		<blockquote>The router that acts as a DHCP server and responds to requests for d
	</t>		elegated prefixes.</blockquote>
	</list>		<t>
	This document is concerned with deployment scenarios in which		This document is concerned with deployment scenarios in which
	the DHCPv6 relay and DHCPv6 server functions are separated, so		the DHCPv6 relay and DHCPv6 server functions are separated, so
	the term 'delegating router' is not used. Instead, a new term		the term "delegating router" is not used. Instead, a new term
	is introduced to describe the relaying function:		is introduced to describe the relaying function:
	<list style="hanging" hangIndent="17">		</t>
	<t hangText="Delegating relay">A delegating relay acts as an		<dl newline="true" spacing="normal">
			<dt>Delegating relay:</dt>
			<dd>A delegating relay acts as an
	intermediate device, forwarding DHCPv6 messages containing		intermediate device, forwarding DHCPv6 messages containing
	IA_PD and IAPREFIX options between the client and server. The		IA_PD and IAPREFIX options between the client and server. The
	delegating relay does not implement a DHCPv6 server		delegating relay does not implement a DHCPv6 server
	function. The delegating relay is also responsible for		function. The delegating relay is also responsible for
	routing traffic for the delegated prefixes.		routing traffic for the delegated prefixes.
	</t>		</dd>
	</list>		</dl>
	</t>		<t>Where the term "relay" is used on its own within this document,
			it should be understood to be a delegating relay unless
	<t>Where the term 'relay' is used on its own within this document,
	it should be understood to be a delegating relay, unless
	specifically stated otherwise.		specifically stated otherwise.
	</t>		</t>
			<t>In CableLabs DOCSIS environments, the Cable Modem Termination
	<t>In CableLabs DOCSIS environments, the Cable Modem Termination
	System (CMTS) would be considered a delegating relay with		System (CMTS) would be considered a delegating relay with
	respect to Customer Premises Devices (CPEs)		respect to Customer Premises Devices (CPEs) (<xref target="DOCSIS_3.1"/>
	<xref target="DOCSIS_3.1"/>, Section 5.2.7.2. A Broadband		, Section 5.2.7.2). A Broadband
	Network Gateway (BNG) in a DSL based access network may be a		Network Gateway (BNG) in a DSL-based access network may be a
	delegating relay if it does not implement a local DHCPv6 server		delegating relay if it does not implement a local DHCPv6 server
	function <xref target="TR-092"/>, Section 4.10.		function (<xref target="TR-092"/>, Section 4.10).
	</t>		</t>
			<t><xref target="RFC8415" format="default"/> defines the "DHCP server" (
	<t><xref target="RFC8415"/> defines the 'DHCP server', (or		or
	'server') as:		"server") as:
	<list style="empty">		</t>
	<t>"A node that responds to requests from clients. It may or		<blockquote>A node that responds to requests from clients. It may or
	may not be on the same link as the client(s). Depending on		may not be on the same link as the client(s). Depending on
	its capabilities, if it supports prefix delegation it may		its capabilities, if it supports prefix delegation it may
	also feature the functionality of a delegating router."		also feature the functionality of a delegating router.
	</t>		</blockquote>
	</list>		<t>
	This document serves the deployment cases where a DHCPv6 server		This document serves the deployment cases where a DHCPv6 server
	is not located on the same link as the client (necessitating the		is not located on the same link as the client (necessitating the
	delegating relay). The server supports prefix delegation and is		delegating relay). The server supports prefix delegation and is
	capable of leasing prefixes to clients, but is not responsible		capable of leasing prefixes to clients, but it is not responsible
	for other functions required of a delegating router, such as		for other functions required of a delegating router, such as
	managing routes for the delegated prefixes.		managing routes for the delegated prefixes.
	</t>		</t>
	<t>The term 'requesting router' has previously been used to		<t>The term "requesting router" has previously been used to
	describe the DHCP client requesting prefixes for use. This		describe the DHCP client requesting prefixes for use. This
	document adopts the <xref target="RFC8415"/> terminology and		document adopts the terminology of <xref target="RFC8415" format="defaul
	uses 'DHCP client' or 'client' interchangeably for this element.		t"/> and
	</t>		uses "DHCP client" or "client" interchangeably for this element.
	</section>		</t>
			</section>
	<section title="Topology">		<section numbered="true" toc="default">
	<t>The following diagram shows the deployment topology relevant		<name>Topology</name>
			<t>The following diagram shows the deployment topology relevant
	to this document.		to this document.
	</t>		</t>
	<figure align="center" anchor="topology_overview" title="Topology		<figure anchor="topology_overview">
	overview">		<name>Topology Overview</name>
	<artwork align="left"><![CDATA[		<artwork align="center" name="" type="" alt=""><![CDATA[
	+		+
	| ------- uplink ------>		| ------- uplink ------>
	| _ ,--,_		| _ ,--,_
	| +--------+ +------------+ _( `' )_ +--------+		| +--------+ +------------+ _( `' )_ +--------+
	+---+ PD |-------| Delegating |--( Operator )---| DHCPv6 |		+---+ PD |-------| Delegating |--( Operator )---| DHCPv6 |
	| | Client | | relay | `(_ Network_)' | server |		| | Client | | relay | `(_ Network_)' | server |
	| +--------+ +----------- + `--'`---' +--------+		| +--------+ +----------- + `--'`---' +--------+
	|		|
	| <----- downlink ------		| <----- downlink ------
	+ (client facing)		+ (client facing)
	Client		Client
	Network		Network
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>The client requests prefixes via the downlink interface of the		<t>The client requests prefixes via the downlink interface of the
	delegating relay. The resulting prefixes will be used for		delegating relay. The resulting prefixes will be used for
	addressing the client network. The delegating relay is		addressing the client network. The delegating relay is
	responsible for forwarding DHCP messages, including prefix		responsible for forwarding DHCP messages, including prefix
	delegation requests and responses between the client and server.		delegation requests and responses between the client and server.
	Messages are forwarded from the delegating relay to the server		Messages are forwarded from the delegating relay to the server
	using multicast or unicast via the operator uplink interface.		using multicast or unicast via the operator uplink interface.
	</t>		</t>
			<t>The delegating relay provides the operator's Layer 3 edge
	<t>The delegating relay provides the operator's Layer-3 edge
	towards the client and is responsible for routing traffic to		towards the client and is responsible for routing traffic to
	and from clients connected to the client network using addresses		and from clients connected to the client network using addresses
	from the delegated prefixes.		from the delegated prefixes.
	</t>		</t>
	</section>
	<section title="Requirements Language">
	<t>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 <xref target="RFC2119"/>
	<xref target="RFC8174"/> when, and only when, they appear in
	all capitals, as shown here.</t>
	</section>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Requirements Language</name>
	<section title="Problems Observed with Existing Delegating Relay		<t>
	Implementations"		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	anchor="relay_problems">		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	<t>The following sections of the document describe problems that		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
			RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
			</section>
			</section>
			<section anchor="relay_problems" numbered="true" toc="default">
			<name>Problems Observed with Existing Delegating Relay Implementations</na
			me>
			<t>The following sections of the document describe problems that
	have been observed with delegating relay implementations in		have been observed with delegating relay implementations in
	commercially available devices.		commercially available devices.
	</t>		</t>
			<section numbered="true" toc="default">
			<name>DHCP Messages Not Being Forwarded by the Delegating Relay</name>
	<section title="DHCP Messages not being Forwarded by the Delegating		<t>Delegating relay implementations have been observed not to
	Relay">
	<t>Delegating relay implementations have been observed not to
	forward messages between the client and server. This generally		forward messages between the client and server. This generally
	occurs if a client sends a message which is unexpected by the		occurs if a client sends a message that is unexpected by the
	delegating relay. For example, the delegating relay already		delegating relay. For example, the delegating relay already
	has an active PD lease entry for an existing client on a port.		has an active PD lease entry for an existing client on a port.
	A new client is connected to this port and sends a Solicit		A new client is connected to this port and sends a Solicit
	message. The delegating relay then drops the Solicit messages		message. The delegating relay then drops the Solicit messages
	until it receives either a DHCP Release message from the		until either it receives a DHCP Release message from the
	original client, or the existing lease times out. This causes		original client or the existing lease times out. This causes
	a particular problem when a client device needs to be replaced		a particular problem when a client device needs to be replaced
	due to a failure.		due to a failure.
	</t>		</t>
			<t>In addition to dropping messages, in some cases, the delegating
	<t>In addition to dropping messages, in some cases the delegating
	relay will generate error messages and send them to the client,		relay will generate error messages and send them to the client,
	e.g. 'NoBinding' messages being sent in the event that the		e.g., "NoBinding" messages being sent in the event that the
	delegating relay does not have an active delegated prefix lease.		delegating relay does not have an active delegated prefix lease.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Delegating Relay Loss of State on Reboot">		<name>Delegating Relay Loss of State on Reboot</name>
	<t>For proper routing of client traffic, the delegating relay		<t>For proper routing of client traffic, the delegating relay
	requires a corresponding routing table entry for each active		requires a corresponding routing table entry for each active
	prefix delegated to a connected client. A delegating relay		prefix delegated to a connected client. A delegating relay
	which does not store this state persistently across reboots		that does not store this state persistently across reboots
	will not be able to forward traffic to client's delegated		will not be able to forward traffic to the client's delegated
	leases until the state is re-established through new DHCP		leases until the state is reestablished through new DHCP
	messages.		messages.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Multiple Delegated Prefixes for a Single Client">		<name>Multiple Delegated Prefixes for a Single Client</name>
	<t><xref target="RFC8415"/> allows for a client to include more		<t>DHCPv6 <xref target="RFC8415" format="default"/> allows a client to i
			nclude more
	than one instance of OPTION_IA_PD in messages in order to request		than one instance of OPTION_IA_PD in messages in order to request
	multiple prefix delegations by the server. If configured for		multiple prefix delegations by the server. If configured for
	this, the server supplies one (or more) instance of		this, the server supplies one (or more) instance of
	OPTION_IAPREFIX for each received instance of OPTION_IA_PD, each		OPTION_IAPREFIX for each received instance of OPTION_IA_PD, each
	containing information for a different delegated prefix.		containing information for a different delegated prefix.
	</t>		</t>
	<t>In some delegating relay implementations, only a single		<t>In some delegating relay implementations, only a single
	delegated prefix per-DUID is supported. In those cases only one		delegated prefix per DHCP Unique Identifier (DUID) is supported. In those
	IPv6 route for one of the delegated prefixes is installed;		cases, only one
			IPv6 route for one of the delegated prefixes is installed,
	meaning that other prefixes delegated to a client are		meaning that other prefixes delegated to a client are
	unreachable.		unreachable.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Dropping Messages from Devices with Duplicate MAC		<name>Dropping Messages from Devices with Duplicate MAC Addresses and DU
	addresses and DUIDs">		IDs</name>
	<t>It is an operational reality that client devices with		<t>It is an operational reality that client devices with
	duplicate MAC addresses and/or DUIDs exist and have been		duplicate Media Access Control (MAC) addresses and/or DUIDs exist and ha
			ve been
	deployed. In some networks, the operational costs of locating		deployed. In some networks, the operational costs of locating
	and swapping out such devices are prohibitive.		and swapping out such devices are prohibitive.
	</t>		</t>
	<t>Delegating relays have been observed to restrict forwarding		<t>Delegating relays have been observed to restrict forwarding
	client messages originating from one client DUID to a single		client messages originating from one client DUID to a single
	interface. In this case if the same client DUID appears from a		interface. In this case, if the same client DUID appears from a
	second client on another interface while there is already an		second client on another interface while there is already an
	active lease, messages originating from the second client are		active lease, messages originating from the second client are
	dropped causing the second client to be unable to obtain a		dropped, causing the second client to be unable to obtain a
	prefix delegation.		prefix delegation.
	</t>		</t>
	<t>It should be noted that in some access networks, the MAC		<t>It should be noted that in some access networks, the MAC
	address and/or DUID are used as part of device identification		address and/or DUID are used as part of device identification
	and authentication. In such networks, enforcing MAC address/DUID		and authentication. In such networks,
	uniqueness is a necessary function and not considered a problem.		enforcing uniqueness of the MAC address and/or DUID is a necessary function and
	</t>		is not considered a problem.
	</section>		</t>
			</section>
			<section numbered="true" toc="default">
	<section title="Forwarding Loops between Client and Relay">		<name>Forwarding Loops between Client and Relay</name>
	<t>If the client loses information about an active prefix		<t>If the client loses information about an active prefix
	lease it has been delegated while the lease entry and		lease it has been delegated while the lease entry and
	associated route is still active in the delegating relay,		associated route are still active in the delegating relay,
	then the relay will forward traffic to the client which the		then the relay will forward traffic to the client. The
	client will return to the relay (which is the client's default		client will return this traffic to the relay, which is the client's defa
	gateway (learned via an RA)). The loop will continue until		ult
	either the client is successfully re-provisioned via DHCP, or		gateway (learned via a Router Advertisement (RA)). The loop will continu
			e until
			either the client is successfully reprovisioned via DHCP or
	the lease ages out in the relay.		the lease ages out in the relay.
	</t>		</t>
			</section>
	</section>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Requirements for Delegating Relays</name>
	<section title="Requirements for Delegating Relays">		<t>To resolve the problems described in
	<t>To resolve the problems described in		<xref target="relay_problems" format="default"/> and to preempt other undes
	<xref target="relay_problems"/> and pre-empt other undesirable		irable
	behavior, the following section of the document describes a set		behavior, the following <xref target="genreq" format="none">section</xref>
			of the document describes a set
	of functional requirements for the delegating relay.		of functional requirements for the delegating relay.
	</t>		</t>
	<t>In addition, relay implementers are reminded that		<t>In addition, relay implementers are reminded that
	<xref target="RFC8415"/> makes it clear that relays MUST forward		<xref target="RFC8415" format="default"/> makes it clear that relays <bcp1
	packets that either contain message codes (Section 19 of		4>MUST</bcp14> forward
	<xref target="RFC8415"/>) it may not understand, or contain		packets that either contain message codes it may not understand (<xref tar
	options that it does not understand (Section 16 of		get="RFC8415" sectionFormat="of" section="19"/>) or options that it does not und
	<xref target="RFC8415"/>).</t>		erstand (<xref target="RFC8415" sectionFormat="of" section="16"/>).</t>
			<section numbered="true" toc="default" anchor="genreq">
	<section title="General Requirements">		<name>General Requirements</name>
	<t>		<ol type="G-%d:">
	<list style="hanging" hangIndent="8">		<li>The delegating relay <bcp14>MUST</bcp14> forward messages
	<t hangText="G-1:">The delegating relay MUST forward messages
	bidirectionally between the client and server without		bidirectionally between the client and server without
	changing the contents of the message.		changing the contents of the message.</li>
	</t>
	<!-- <t hangText="G-2:">The relay MUST NOT discard messages because		<li>The relay <bcp14>MUST</bcp14> allow for multiple prefixes
	it does not recognize the message codes (Section 19 of
	<xref target="RFC8415"/> or contain options that it does not
	understand (or instances of vendor options with unknown
	enterprise-number values as described in
	Section 16 of <xref target="RFC8415"/>.-->
	<t hangText="G-2:">The relay MUST allow for multiple prefixes
	to be delegated for the same client IA_PD. These delegations		to be delegated for the same client IA_PD. These delegations
	may have different lifetimes.		may have different lifetimes.
	</t>		</li>
	<t hangText="G-3:">The relay MUST allow for multiple prefixes		<li>The relay <bcp14>MUST</bcp14> allow for multiple prefixes
	(with or without separate IA_PDs) to be delegated to a		(with or without separate IA_PDs) to be delegated to a
	single client connected to a single interface, identified		single client connected to a single interface, identified
	by its DHCPv6 Client Identifier (DUID).		by its DHCPv6 Client Identifier (DUID).
	</t>		</li>
	<t hangText="G-4:">A delegating relay may have one or more		<li>A delegating relay may have one or more
	interfaces on which it acts as a relay, as well as one or		interfaces on which it acts as a relay, as well as one or
	more interfaces on which it does not		more interfaces on which it does not
	(for example, in an ISP, it might act as a relay on all		(for example, in an ISP, it might act as a relay on all
	southbound interfaces, but not on the northbound		southbound interfaces but not on the northbound
	interfaces). The relay SHOULD allow the same client		interfaces). The relay <bcp14>SHOULD</bcp14> allow the same client
	identifier (DUID) to have active delegated prefix leases on		identifier (DUID) to have active delegated prefix leases on
	more than one interface simultaneously, unless client DUID		more than one interface simultaneously unless client DUID
	uniqueness is necessary for the functioning or security of		uniqueness is necessary for the functioning or security of
	the network. This is to allow client devices with duplicate		the network. This is to allow client devices with duplicate
	DUIDs to function on separate broadcast domains.		DUIDs to function on separate broadcast domains.
	</t>		</li>
	<!--
	<t hangText="G-6:">The relay up on detecting that the current		<li>The maximum number of simultaneous prefixes
	lease information of any delegated prefix is no more valid,		delegated to a single client <bcp14>MUST</bcp14> be configurable.
	then the relay MUST deprecate the invalid prefixes as quick		</li>
	as possible so that the clients use a new prefix quickly.
	</t>-->		<li>The relay <bcp14>MUST</bcp14> implement a mechanism to
	<t hangText="G-5:">The maximum number of simultaneous prefixes
	delegated to a single client MUST be configurable.
	</t>
	<t hangText="G-6:">The relay MUST implement a mechanism to
	limit the maximum number of active prefix delegations on a		limit the maximum number of active prefix delegations on a
	single port for all client identifiers and IA_PDs. This		single port for all client identifiers and IA_PDs. This
	value MUST be configurable.		value <bcp14>MUST</bcp14> be configurable.
	</t>		</li>
	<t hangText="G-7:">It is RECOMMENDED that delegating relays
			<li>It is <bcp14>RECOMMENDED</bcp14> that delegating relays
	support at least 8 active delegated leases per client device		support at least 8 active delegated leases per client device
	and use this as the default limit.		and use this as the default limit.
	</t>		</li>
	<t hangText="G-8:">The delegating relay MUST update the lease		<li>The delegating relay <bcp14>MUST</bcp14> update the lease
	lifetimes based on the client's reply messages it forwards to		lifetimes based on the client's reply messages it forwards to
	the client and only expire the delegated prefixes when the		the client and only expire the delegated prefixes when the
	valid lifetime has elapsed.		valid lifetime has elapsed.
	</t>		</li>
	<t hangText="G-9:">On receipt of a Release message from the		<li>On receipt of a Release message from the
	client, the delegating relay MUST expire the active leases		client, the delegating relay <bcp14>MUST</bcp14> expire the active l
			eases
	for each of the IA_PDs in the message.		for each of the IA_PDs in the message.
	</t>		</li>
	</list>		</ol>
	</t>		</section>
	</section>		<section numbered="true" toc="default">
			<name>Routing Requirements</name>
	<section title="Routing Requirements">		<ol type="R-%d:">
	<t>		<li>The relay <bcp14>MUST</bcp14> maintain a local routing
	<list style="hanging" hangIndent="8">
	<t hangText="R-1:">The relay MUST maintain a local routing
	table that is dynamically updated with leases and the		table that is dynamically updated with leases and the
	associated next-hops as they are delegated to clients. When		associated next hops as they are delegated to clients. When
	a delegated prefix is Released or expires, the associated		a delegated prefix is released or expires, the associated
	route MUST be removed from the relay's routing table.		route <bcp14>MUST</bcp14> be removed from the relay's routing table.
	</t>		</li>
	<t hangText="R-2:">The delegating relay's routing entry MUST
			<li>The delegating relay's routing entry <bcp14>MUST</bcp14>
	use the same prefix length for the delegated prefix as		use the same prefix length for the delegated prefix as
	given in the IA_PD.		given in the IA_PD.
	</t>		</li>
	<t hangText="R-3:">The relay MUST provide a mechanism to
			<li>The relay <bcp14>MUST</bcp14> provide a mechanism to
	dynamically update ingress filters permitting ingress		dynamically update ingress filters permitting ingress
	traffic sourced from client delegated leases and blocking		traffic sourced from client delegated leases and blocking
	packets from invalid source prefixes. This is to implement		packets from invalid source prefixes. This is to implement
	anti-spoofing as described in <xref target="BCP38"/>. The		anti-spoofing as described in <xref target="BCP38" format="default"/
	delegating relay's ingress filter entry MUST use the same		>. The
			delegating relay's ingress filter entry <bcp14>MUST</bcp14> use the
			same
	prefix length for the delegated prefix as given in the		prefix length for the delegated prefix as given in the
	IA_PD.		IA_PD.
	</t>		</li>
	<t hangText="R-4:">The relay MAY provide a mechanism to
			<li>The relay <bcp14>MAY</bcp14> provide a mechanism to
	dynamically advertise delegated leases into a routing		dynamically advertise delegated leases into a routing
	protocol as they are learned. If such a mechanism is		protocol as they are learned. If such a mechanism is
	implemented, when a delegated lease is released or expires,		implemented, when a delegated lease is released or expires,
	the delegated route MUST be withdrawn from the routing		the delegated route <bcp14>MUST</bcp14> be withdrawn from the routin g
	protocol. The mechanism by which the routes are inserted		protocol. The mechanism by which the routes are inserted
	and deleted is out of the scope of this document.		and deleted is out of the scope of this document.
	</t>		</li>
	<t hangText="R-5:">To prevent routing loops, the relay SHOULD
			<li>
			<t>To prevent routing loops, the relay <bcp14>SHOULD</bcp14>
	implement a configurable policy to drop potential looping		implement a configurable policy to drop potential looping
	packets received on any DHCP-PD client facing interfaces.		packets received on any DHCP-PD client-facing interfaces.
	<vspace blankLines="1" />		</t>
	The policy SHOULD be configurable on a per-client or		<t>
			The policy <bcp14>SHOULD</bcp14> be configurable on a per-client or
	per-destination basis.		per-destination basis.
	<vspace blankLines="1" />		</t>
			<t>
	Looping packets are those with a destination address in a		Looping packets are those with a destination address in a
	prefix delegated to a client connected to that interface,		prefix delegated to a client connected to that interface,
	as follows:		as follows:
	<list style="symbols">		</t>
	<t>For point-to-point links, when the		<ul spacing="normal">
	packet's ingress and egress interfaces match.</t>		<li>For point-to-point links, when the
	<t>For multi-access links, when the packet's ingress and		packet's ingress and egress interfaces match.</li>
			<li>For multi-access links, when the packet's ingress and
	egress interface match, and the source link-layer and		egress interface match, and the source link-layer and
	next-hop link-layer addresses match.</t>		next-hop link-layer addresses match.</li>
	</list>		</ul>
			<t>
	An ICMPv6 Type 1, Code 6 (Destination		An ICMPv6 Type 1, Code 6 (Destination
	Unreachable, reject route to destination) error message MAY		Unreachable, reject route to destination) error message <bcp14>MAY</
	be sent as per <xref target="RFC4443"/>, section 3.1.		bcp14>
	The ICMP policy SHOULD be configurable.		be sent as per <xref target="RFC4443" sectionFormat="comma" section=
	</t>		"3.1"/>.
	</list>		The ICMP policy <bcp14>SHOULD</bcp14> be configurable.
	</t>		</t>
	</section>		</li>
			</ol>
	<section title="Service Continuity Requirements"		</section>
	anchor="service_continuity">		<section anchor="service_continuity" numbered="true" toc="default">
	<t>		<name>Service Continuity Requirements</name>
	<list style="hanging" hangIndent="8">		<ol type="S-%d:">
	<t hangText="S-1:">To preserve active client prefix		<li>
	delegations across relay restarts, the relay SHOULD		<t>To preserve active client prefix
			delegations across relay restarts, the relay <bcp14>SHOULD</bcp14>
	implement at least one of the following:		implement at least one of the following:
	<list style="symbols">		</t>
	<t>Implement DHCPv6 bulk lease query as defined in		<ul spacing="normal">
	<xref target="RFC5460"/>.		<li>Implement DHCPv6 Bulk Leasequery as defined in
	</t>		<xref target="RFC5460" format="default"/>.
			</li>
	<t>Store active prefix delegations in persistent storage		<li>Store active prefix delegations in persistent storage
	so they can be re-read after the reboot.		so they can be reread after the reboot.
	</t>		</li>
	</list>		</ul>
	</t>		</li>
	<t hangText="S-2:">If a client's next-hop link-local address		<li>If a client's next-hop link-local address
	becomes unreachable (e.g., due to a link-down event on the		becomes unreachable (e.g., due to a link-down event on the
	relevant physical interface), routes for the client's		relevant physical interface), routes for the client's
	delegated prefixes MUST be retained by the delegating relay		delegated prefixes <bcp14>MUST</bcp14> be retained by the delegating relay
	unless they are released or removed due to expiring DHCP		unless they are released or removed due to expiring DHCP
	timers. This is to re-establish routing for the delegated		timers. This is to reestablish routing for the delegated
	prefix if the client next-hop becomes reachable without the		prefix if the client next hop becomes reachable without the
	delegated prefixes needing to be re-learned.		delegated prefixes needing to be relearned.
	</t>		</li>
	<t hangText="S-3:">The relay SHOULD implement DHCPv6 active		<li>The relay <bcp14>SHOULD</bcp14> implement DHCPv6 Active Leasequery
	lease query as defined in <xref target="RFC7653"/> to keep		as defined in <xref target="RFC7653" format="default"/> to keep
	the local lease database in sync with the DHCPv6 server.		the local lease database in sync with the DHCPv6 server.
	</t>		</li>
	</list>		</ol>
	</t>		</section>
	</section>		<section anchor="opreqs" numbered="true" toc="default">
			<name>Operational Requirements</name>
	<section title="Operational Requirements" anchor="opreqs">		<ol type="O-%d:">
	<t>		<li>The relay <bcp14>SHOULD</bcp14> implement an interface
	<list style="hanging" hangIndent="8">
	<t hangText="O-1:">The relay SHOULD implement an interface
	allowing the operator to view the active delegated prefixes.		allowing the operator to view the active delegated prefixes.
	This SHOULD provide information about the delegated lease		This <bcp14>SHOULD</bcp14> provide information about the delegated l
	and client details such as client identifier, next-hop		ease
			and client details such as the client identifier, next-hop
	address, connected interface, and remaining lifetimes.		address, connected interface, and remaining lifetimes.
	</t>		</li>
	<t hangText="O-2:">The relay SHOULD provide a method for the		<li>The relay <bcp14>SHOULD</bcp14> provide a method for the
	operator to clear active bindings for an individual lease,		operator to clear active bindings for an individual lease,
	client or all bindings on a port.		client, or all bindings on a port.
	</t>		</li>
	<t hangText="O-3:">To facilitate troubleshooting of		<li>To facilitate troubleshooting of
	operational problems between the delegating relay and other		operational problems between the delegating relay and other
	elements, it is RECOMMENDED that a time synchronization		elements, it is <bcp14>RECOMMENDED</bcp14> that a time synchronizati
	protocol is used by the delegating relays and DHCP servers.		on
	</t>		protocol be used by the delegating relays and DHCP servers.
	</list>		</li>
	</t>		</ol>
			</section>
	</section>		</section>
	</section>
	<section anchor="Acknowledgements" title="Acknowledgements">
	<t>The authors of this document would like to thank Bernie Volz,
	Ted Lemon, and Michael Richardson for their valuable comments.
	</t>
	</section>
	<!-- Possibly a 'Contributors' section ... -->
	<section anchor="IANA" title="IANA Considerations">
	<t>This memo includes no request to IANA.</t>
	</section>
	<section anchor="Security" title="Security Considerations">
	<t>This document does not add any new security considerations
	beyond those mentioned in Section 4 of <xref target="RFC8213"/>
	and Section 22 of <xref target="RFC8415"/>.
	</t>
	<t>If the delegating relay implements <xref target="BCP38"/>		<section anchor="IANA" numbered="true" toc="default">
			<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
			</section>
			<section anchor="Security" numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>This document does not add any new security considerations
			beyond those mentioned in <xref target="RFC8213" sectionFormat="of" sectio
			n="4"/>
			and <xref target="RFC8415" sectionFormat="of" section="22"/>.
			</t>
			<t>If the delegating relay implements <xref target="BCP38" format="default
			"/>
	filtering, then the filtering rules will need to be dynamically		filtering, then the filtering rules will need to be dynamically
	updated as delegated prefixes are leased.		updated as delegated prefixes are leased.
	</t>		</t>
			<t><xref target="RFC8213" format="default"/> describes a method for securi
	<t><xref target="RFC8213"/> describes a method for securing traffic		ng traffic
	between the relay agent and server by sending DHCP messages over an		between the relay agent and server by sending DHCP messages over an
	IPsec tunnel. It is RECOMMENDED that this is implemented by the		IPsec tunnel. It is <bcp14>RECOMMENDED</bcp14> that this be implemented by the
	delegating relay.</t>		delegating relay.</t>
			<t>Failure to implement requirement G-6 may have specific security
	<t>Failure to implement requirement G-6 may have specific security
	implications, such as a resource depletion attack on the relay.</t>		implications, such as a resource depletion attack on the relay.</t>
			<t>The operational requirements in <xref target="opreqs" format="default"/
	<t>The operational requirements in Section <xref target="opreqs"/>		>
	may introduce additional security considerations. It is		may introduce additional security considerations. It is
	RECOMMENDED that the operational security practices described		<bcp14>RECOMMENDED</bcp14> that the operational security practices describ
	in <xref target="RFC4778"/> are implemented.		ed
	</t>		in <xref target="RFC4778" format="default"/> be implemented.
	</section>		</t>
	</middle>		</section>
			</middle>
	<!-- *****BACK MATTER ***** -->
	<back>		<back>
	<references title="Normative References">
	<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.21
	19.xml"?-->
	&RFC2119;
	&RFC4443;
	&RFC4778;
	&RFC5460;
	&RFC7653;
	&RFC8174;
	&RFC8213;
	&RFC8415;
	</references>
	<references title="Informative References">
	<reference anchor="BCP38">
	<front>
	<title>Network Ingress Filtering: Defeating Denial of Service
	Attacks which employ IP Source Address Spoofing
	https://tools.ietf.org/html/bcp38
	</title>
	<author>
	<organization>IETF</organization>
	</author>
	<date />
	</front>
	<seriesInfo name="RFC" value="2827"/>
	<seriesInfo name="BCP" value="38" />
	</reference>
	<reference anchor="DOCSIS_3.1"
	target="https://apps.cablelabs.com/specification/CM-SP-MULPIv3.">
	<front>
	<title>MAC and Upper Layer Protocols Interface Specification",
	DOCSIS 3.1, January, 2017</title>
	<author>
	<organization abbrev="CL">CableLabs</organization>
	</author>
	<date />
	</front>
	</reference>
	<reference anchor="TR-092"
	target="https://www.broadband-forum.org/download/TR-092.pdf">
	<front>
	<title>Broadband Remote Access Server (BRAS) Requirements
	Document, August, 2004</title>
	<author>
	<organization abbrev="BBF">Broadband Forum</organization>
	</author>
	<date />
	</front>
	</reference>
	</references>
	<!-- Change Log		<references>
	v00 2019-05-7 IF Initial version		<name>References</name>
	2020-02-20 IF - Name change after adoption and typo fixes		<references>
	2020-03-27 IF - Updates after Bernie's review		<name>Normative References</name>
	2020-08-19 IF - Updates after Ted Lemon's review		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2
	2020-10-10 IF - WGLC updates included. Cleanup for publication		119.xml"/>
	2021-01-04 IF - Updates aftr IESG review-->		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4443.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4778.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5460.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7653.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8213.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8415.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<referencegroup anchor="BCP38" target="https://www.rfc-editor.org/info/bcp38">
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.2827.xml"/>
			</referencegroup>
			<reference anchor="DOCSIS_3.1" target="https://www.cablelabs.com/specifi
			cation/CM-SP-MULPIv3.1">
			<front>
			<title>MAC and Upper Layer Protocols Interface Specification</title>
			<author>
			<organization>CableLabs</organization>
			</author>
			<date month="January" year="2017"/>
			</front>
			<seriesInfo name="Version" value="10"/>
			<seriesInfo name="DOCSIS" value="3.1"/>
			</reference>
			<reference anchor="TR-092" target="https://www.broadband-forum.org/downl
			oad/TR-092.pdf">
			<front>
			<title>Broadband Remote Access Server (BRAS) Requirements
			Document</title>
			<author>
			<organization>Broadband Forum</organization>
			</author>
			<date month="August" year="2004"/>
			</front>
			<seriesInfo name="Technical Report" value="TR-092"/>
			</reference>
			</references>
			</references>
			<section anchor="Acknowledgements" numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>The authors of this document would like to thank <contact fullname="Ber
			nie Volz"/>,
			<contact fullname="Ted Lemon"/>, and <contact fullname="Michael Richardson
			"/> for their valuable comments.
			</t>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 93 change blocks.
	487 lines changed or deleted		464 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/