<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!-- updated by Chris 01/05/21 --> <!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"?>"rfc2629-xhtml.ent"> <rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dhc-dhcpv6-pd-relay-requirements-05"ipr="trust200902">number="8987" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.5.0 --> <front> <title abbrev="DHCPv6 PD Relay">DHCPv6 Prefix Delegating Relay Requirements</title> <seriesInfo name="RFC" value="8987"/> <author fullname="Ian Farrer"initials="I"initials="I." surname="Farrer"> <organization>Deutsche Telekom AG</organization> <address> <postal> <street>Landgrabenweg 151</street> <city>Bonn</city> <code>53227</code><country>DE</country><country>Germany</country> </postal> <email>ian.farrer@telekom.de</email> </address> </author> <author fullname="Naveen Kottapalli"initials="N"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><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"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><country>Czech Republic</country> </postal> <email>martin.hunek@tul.cz</email> </address> </author> <author fullname="Richard Patterson"initials="R.P."initials="R." surname="Patterson"> <organization>Sky UKLtd</organization>Ltd.</organization> <address> <postal> <street>1 Brick Lane</street> <city>London</city> <code>E1 6PU</code><country>UK</country><country>United Kingdom</country> </postal> <email>richard.patterson@sky.uk</email> </address> </author> <datemonth="January"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 withPrefix Delegation.prefix delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays withPrefix Delegation.</t>prefix delegation.</t> <t>It is recommended that any network operatorthat isusing DHCPv6 prefix delegation with relaysshouldensure that these requirements are followed on their networks.</t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>ForinternetInternet service providers that offer native IPv6 access with prefix delegation to their customers, a common deployment architecture is to have a DHCPv6 relay agent function located in the ISP'sLayer-3Layer 3 customer edge device and a separate, centralized DHCPv6 server infrastructure. <xreftarget="RFC8415"/>target="RFC8415" format="default"/> describes the functionality of a DHCPv6relayrelay, andSection 19.1.3<xref target="RFC8415" sectionFormat="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 operate deterministically in this deployment scenario.</t> <t>A DHCPv6 relay agent for prefix delegation is a function commonly implemented in routing devices, but implementations vary in their functionality and client/serverinter-working.interworking. This can result in operational problems such as messages not being forwarded by the relay orun-reachabilityunreachability of the delegated prefixes. This document provides a set of requirements for devices implementing a relay function for use with prefix delegation. </t> <t>The mechanisms for a relay to inject routes (including aggregatedones),ones) on its network-facing interface based on prefixes learned from a server viaDHCP-PDDHCP prefix delegation (DHCP-PD) are out of scope of the document.</t> <t>Multi-hop DHCPv6 relaying is not affected. The requirements in this document are solely applicable to the DHCP relay agent co-located with the first-hop routerthatto which the DHCPv6 client requesting the prefix isconnected to,connected, so no changes to any subsequent relays in the path are needed.</t> </section> <sectiontitle="Terminology">numbered="true" toc="default"> <name>Terminology</name> <sectiontitle="General">numbered="true" toc="default"> <name>General</name> <t>This document uses the terminology defined in <xreftarget="RFC8415"/>, however,target="RFC8415" format="default"/>. However, when defining the functional elements for prefixdelegationdelegation, <xreftarget="RFC8415"/>, Section 4.2target="RFC8415" sectionFormat="comma" section="4.2"/> defines the term'delegating router'"delegating router" as:<list style="empty"> <t>"The</t> <blockquote>The router that acts as a DHCP server and responds to requests for delegatedprefixes." </t> </list>prefixes.</blockquote> <t> This document is concerned with deployment scenarios in which the DHCPv6 relay and DHCPv6 server functions are separated, so the term'delegating router'"delegating router" is not used. Instead, a new term is introduced to describe the relaying function:<list style="hanging" hangIndent="17"> <t hangText="Delegating relay">A</t> <dl newline="true" spacing="normal"> <dt>Delegating relay:</dt> <dd>A delegating relay acts as an intermediate device, forwarding DHCPv6 messages containing IA_PD and IAPREFIX options between the client and server. The delegating relay does not implement a DHCPv6 server function. The delegating relay is also responsible for routing traffic for the delegated prefixes.</t> </list> </t></dd> </dl> <t>Where the term'relay'"relay" is used on its own within this document, it should be understood to be a delegatingrelay,relay unless specifically stated otherwise. </t> <t>In CableLabs DOCSIS environments, the Cable Modem Termination System (CMTS) would be considered a delegating relay with respect to Customer Premises Devices (CPEs)<xref(<xref target="DOCSIS_3.1"/>, Section5.2.7.2.5.2.7.2). A Broadband Network Gateway (BNG) in aDSL basedDSL-based access network may be a delegating relay if it does not implement a local DHCPv6 server function<xref(<xref target="TR-092"/>, Section4.10.4.10). </t> <t><xreftarget="RFC8415"/>target="RFC8415" format="default"/> defines the'DHCP server',"DHCP server" (or'server')"server") as:<list style="empty"> <t>"A</t> <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 its capabilities, if it supports prefix delegation it may also feature the functionality of a delegatingrouter." </t> </list>router. </blockquote> <t> This document serves the deployment cases where a DHCPv6 server is not located on the same link as the client (necessitating the delegating relay). The server supports prefix delegation and is capable of leasing prefixes to clients, but it is not responsible for other functions required of a delegating router, such as managing routes for the delegated prefixes. </t> <t>The term'requesting router'"requesting router" has previously been used to describe the DHCP client requesting prefixes for use. This document adopts the<xref target="RFC8415"/>terminology of <xref target="RFC8415" format="default"/> and uses'DHCP client'"DHCP client" or'client'"client" interchangeably for this element. </t> </section> <sectiontitle="Topology">numbered="true" toc="default"> <name>Topology</name> <t>The following diagram shows the deployment topology relevant to this document. </t> <figurealign="center" anchor="topology_overview" title="Topology overview">anchor="topology_overview"> <name>Topology Overview</name> <artworkalign="left"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ + | ------- uplink ------> | _ ,--,_ | +--------+ +------------+ _( `' )_ +--------+ +---+ PD |-------| Delegating |--( Operator )---| DHCPv6 | | | Client | | relay | `(_ Network_)' | server | | +--------+ +----------- + `--'`---' +--------+ | | <----- downlink ------ + (client facing) Client Network ]]></artwork> </figure> <t>The client requests prefixes via the downlink interface of the delegating relay. The resulting prefixes will be used for addressing the client network. The delegating relay is responsible for forwarding DHCP messages, including prefix delegation requests and responses between the client and server. Messages are forwarded from the delegating relay to the server using multicast or unicast via the operator uplink interface. </t> <t>The delegating relay provides the operator'sLayer-3Layer 3 edge towards the client and is responsible for routing traffic to and from clients connected to the client network using addresses from the delegated prefixes. </t> </section> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <sectiontitle="Problemsanchor="relay_problems" numbered="true" toc="default"> <name>Problems Observed with Existing Delegating RelayImplementations" anchor="relay_problems">Implementations</name> <t>The following sections of the document describe problems that have been observed with delegating relay implementations in commercially available devices. </t> <sectiontitle="DHCPnumbered="true" toc="default"> <name>DHCP Messagesnot beingNot Being Forwarded by the DelegatingRelay">Relay</name> <t>Delegating relay implementations have been observed not to forward messages between the client and server. This generally occurs if a client sends a messagewhichthat is unexpected by the delegating relay. For example, the delegating relay already 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 message. The delegating relay then drops the Solicit messages until either it receiveseithera DHCP Release message from the originalclient,client or the existing lease times out. This causes a particular problem when a client device needs to be replaced due to a failure. </t> <t>In addition to dropping messages, in somecasescases, the delegating relay will generate error messages and send them to the client,e.g. 'NoBinding'e.g., "NoBinding" messages being sent in the event that the delegating relay does not have an active delegated prefix lease. </t> </section> <sectiontitle="Delegatingnumbered="true" toc="default"> <name>Delegating Relay Loss of State onReboot">Reboot</name> <t>For proper routing of client traffic, the delegating relay requires a corresponding routing table entry for each active prefix delegated to a connected client. A delegating relaywhichthat does not store this state persistently across reboots will not be able to forward traffic to the client's delegated leases until the state isre-establishedreestablished through new DHCP messages. </t> </section> <sectiontitle="Multiplenumbered="true" toc="default"> <name>Multiple Delegated Prefixes for a SingleClient"> <t><xref target="RFC8415"/>Client</name> <t>DHCPv6 <xref target="RFC8415" format="default"/> allowsfora client to include more than one instance of OPTION_IA_PD in messages in order to request multiple prefix delegations by the server. If configured for this, the server supplies one (or more) instance of OPTION_IAPREFIX for each received instance of OPTION_IA_PD, each containing information for a different delegated prefix. </t> <t>In some delegating relay implementations, only a single delegated prefixper-DUIDper DHCP Unique Identifier (DUID) is supported. In thosecasescases, only one IPv6 route for one of the delegated prefixes isinstalled;installed, meaning that other prefixes delegated to a client are unreachable. </t> </section> <sectiontitle="Droppingnumbered="true" toc="default"> <name>Dropping Messages from Devices with Duplicate MACaddressesAddresses andDUIDs">DUIDs</name> <t>It is an operational reality that client devices with duplicateMACMedia Access Control (MAC) addresses and/or DUIDs exist and have been deployed. In some networks, the operational costs of locating and swapping out such devices are prohibitive. </t> <t>Delegating relays have been observed to restrict forwarding client messages originating from one client DUID to a single interface. In thiscasecase, if the same client DUID appears from a second client on another interface while there is already an active lease, messages originating from the second client aredroppeddropped, causing the second client to be unable to obtain a prefix delegation. </t> <t>It should be noted that in some access networks, the MAC address and/or DUID are used as part of device identification and authentication. In such networks, enforcingMAC address/DUIDuniqueness of the MAC address and/or DUID is a necessary function and is not considered a problem. </t> </section> <sectiontitle="Forwardingnumbered="true" toc="default"> <name>Forwarding Loops between Client andRelay">Relay</name> <t>If the client loses information about an active prefix lease it has been delegated while the lease entry and associated routeisare still active in the delegating relay, then the relay will forward traffic to theclient which theclient. The client will return this traffic to therelay (whichrelay, which is the client's default gateway (learned viaan RA)).a Router Advertisement (RA)). The loop will continue until either the client is successfullyre-provisionedreprovisioned viaDHCP,DHCP or the lease ages out in the relay. </t> </section> </section> <sectiontitle="Requirementsnumbered="true" toc="default"> <name>Requirements for DelegatingRelays">Relays</name> <t>To resolve the problems described in <xreftarget="relay_problems"/>target="relay_problems" format="default"/> andpre-emptto preempt other undesirable behavior, the followingsection<xref target="genreq" format="none">section</xref> of the document describes a set of functional requirements for the delegating relay. </t> <t>In addition, relay implementers are reminded that <xreftarget="RFC8415"/>target="RFC8415" format="default"/> makes it clear that relaysMUST<bcp14>MUST</bcp14> forward packets that either contain message codes(Section 19 of <xref target="RFC8415"/>)it may notunderstand,understand (<xref target="RFC8415" sectionFormat="of" section="19"/>) orcontainoptions that it does not understand(Section 16 of <xref target="RFC8415"/>).</t>(<xref target="RFC8415" sectionFormat="of" section="16"/>).</t> <sectiontitle="General Requirements"> <t> <list style="hanging" hangIndent="8"> <t hangText="G-1:">Thenumbered="true" toc="default" anchor="genreq"> <name>General Requirements</name> <ol type="G-%d:"> <li>The delegating relayMUST<bcp14>MUST</bcp14> forward messages bidirectionally between the client and server without changing the contents of themessage. </t> <!-- <t hangText="G-2:">The relay MUST NOT discard messages because 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:">Themessage.</li> <li>The relayMUST<bcp14>MUST</bcp14> allow for multiple prefixes to be delegated for the same client IA_PD. These delegations may have different lifetimes.</t> <t hangText="G-3:">The</li> <li>The relayMUST<bcp14>MUST</bcp14> allow for multiple prefixes (with or without separate IA_PDs) to be delegated to a single client connected to a single interface, identified by its DHCPv6 Client Identifier (DUID).</t> <t hangText="G-4:">A</li> <li>A delegating relay may have one or more interfaces on which it acts as a relay, as well as one or more interfaces on which it does not (for example, in an ISP, it might act as a relay on all southboundinterfaces,interfaces but not on the northbound interfaces). The relaySHOULD<bcp14>SHOULD</bcp14> allow the same client identifier (DUID) to have active delegated prefix leases on more than one interfacesimultaneously,simultaneously unless client DUID uniqueness is necessary for the functioning or security of the network. This is to allow client devices with duplicate DUIDs to function on separate broadcast domains.</t> <!-- <t hangText="G-6:">The relay up on detecting that the current lease information of any delegated prefix is no more valid, then the relay MUST deprecate the invalid prefixes as quick as possible so that the clients use a new prefix quickly. </t>--> <t hangText="G-5:">The</li> <li>The maximum number of simultaneous prefixes delegated to a single clientMUST<bcp14>MUST</bcp14> be configurable.</t> <t hangText="G-6:">The</li> <li>The relayMUST<bcp14>MUST</bcp14> implement a mechanism to limit the maximum number of active prefix delegations on a single port for all client identifiers and IA_PDs. This valueMUST<bcp14>MUST</bcp14> be configurable.</t> <t hangText="G-7:">It</li> <li>It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that delegating relays support at least 8 active delegated leases per client device and use this as the default limit.</t> <t hangText="G-8:">The</li> <li>The delegating relayMUST<bcp14>MUST</bcp14> update the lease lifetimes based on the client's reply messages it forwards to the client and only expire the delegated prefixes when the valid lifetime has elapsed.</t> <t hangText="G-9:">On</li> <li>On receipt of a Release message from the client, the delegating relayMUST<bcp14>MUST</bcp14> expire the active leases for each of the IA_PDs in the message.</t> </list> </t></li> </ol> </section> <sectiontitle="Routing Requirements"> <t> <list style="hanging" hangIndent="8"> <t hangText="R-1:">Thenumbered="true" toc="default"> <name>Routing Requirements</name> <ol type="R-%d:"> <li>The relayMUST<bcp14>MUST</bcp14> maintain a local routing table that is dynamically updated with leases and the associatednext-hopsnext hops as they are delegated to clients. When a delegated prefix isReleasedreleased or expires, the associated routeMUST<bcp14>MUST</bcp14> be removed from the relay's routing table.</t> <t hangText="R-2:">The</li> <li>The delegating relay's routing entryMUST<bcp14>MUST</bcp14> use the same prefix length for the delegated prefix as given in the IA_PD.</t> <t hangText="R-3:">The</li> <li>The relayMUST<bcp14>MUST</bcp14> provide a mechanism to dynamically update ingress filters permitting ingress traffic sourced from client delegated leases and blocking packets from invalid source prefixes. This is to implement anti-spoofing as described in <xreftarget="BCP38"/>.target="BCP38" format="default"/>. The delegating relay's ingress filter entryMUST<bcp14>MUST</bcp14> use the same prefix length for the delegated prefix as given in the IA_PD.</t> <t hangText="R-4:">The</li> <li>The relayMAY<bcp14>MAY</bcp14> provide a mechanism to dynamically advertise delegated leases into a routing protocol as they are learned. If such a mechanism is implemented, when a delegated lease is released or expires, the delegated routeMUST<bcp14>MUST</bcp14> be withdrawn from the routing protocol. The mechanism by which the routes are inserted and deleted is out of the scope of this document.</t> <t hangText="R-5:">To</li> <li> <t>To prevent routing loops, the relaySHOULD<bcp14>SHOULD</bcp14> implement a configurable policy to drop potential looping packets received on any DHCP-PDclient facingclient-facing interfaces.<vspace blankLines="1" /></t> <t> The policySHOULD<bcp14>SHOULD</bcp14> be configurable on a per-client or per-destination basis.<vspace blankLines="1" /></t> <t> Looping packets are those with a destination address in a prefix delegated to a client connected to that interface, as follows:<list style="symbols"> <t>For</t> <ul spacing="normal"> <li>For point-to-point links, when the packet's ingress and egress interfacesmatch.</t> <t>Formatch.</li> <li>For multi-access links, when the packet's ingress and egress interface match, and the source link-layer and next-hop link-layer addressesmatch.</t> </list>match.</li> </ul> <t> An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error messageMAY<bcp14>MAY</bcp14> be sent as per <xreftarget="RFC4443"/>, section 3.1.target="RFC4443" sectionFormat="comma" section="3.1"/>. The ICMP policySHOULD<bcp14>SHOULD</bcp14> be configurable. </t></list> </t></li> </ol> </section> <sectiontitle="Serviceanchor="service_continuity" numbered="true" toc="default"> <name>Service ContinuityRequirements" anchor="service_continuity"> <t> <list style="hanging" hangIndent="8"> <t hangText="S-1:">ToRequirements</name> <ol type="S-%d:"> <li> <t>To preserve active client prefix delegations across relay restarts, the relaySHOULD<bcp14>SHOULD</bcp14> implement at least one of the following:<list style="symbols"> <t>Implement</t> <ul spacing="normal"> <li>Implement DHCPv6bulk lease queryBulk Leasequery as defined in <xreftarget="RFC5460"/>. </t> <t>Storetarget="RFC5460" format="default"/>. </li> <li>Store active prefix delegations in persistent storage so they can bere-readreread after the reboot.</t> </list> </t> <t hangText="S-2:">If</li> </ul> </li> <li>If a client's next-hop link-local address becomes unreachable (e.g., due to a link-down event on the relevant physical interface), routes for the client's delegated prefixesMUST<bcp14>MUST</bcp14> be retained by the delegating relay unless they are released or removed due to expiring DHCP timers. This is tore-establishreestablish routing for the delegated prefix if the clientnext-hopnext hop becomes reachable without the delegated prefixes needing to bere-learned. </t> <t hangText="S-3:">Therelearned. </li> <li>The relaySHOULD<bcp14>SHOULD</bcp14> implement DHCPv6active lease queryActive Leasequery as defined in <xreftarget="RFC7653"/>target="RFC7653" format="default"/> to keep the local lease database in sync with the DHCPv6 server.</t> </list> </t></li> </ol> </section> <sectiontitle="Operational Requirements" anchor="opreqs"> <t> <list style="hanging" hangIndent="8"> <t hangText="O-1:">Theanchor="opreqs" numbered="true" toc="default"> <name>Operational Requirements</name> <ol type="O-%d:"> <li>The relaySHOULD<bcp14>SHOULD</bcp14> implement an interface allowing the operator to view the active delegated prefixes. ThisSHOULD<bcp14>SHOULD</bcp14> provide information about the delegated lease and client details such as the client identifier, next-hop address, connected interface, and remaining lifetimes.</t> <t hangText="O-2:">The</li> <li>The relaySHOULD<bcp14>SHOULD</bcp14> provide a method for the operator to clear active bindings for an individual lease,clientclient, or all bindings on a port.</t> <t hangText="O-3:">To</li> <li>To facilitate troubleshooting of operational problems between the delegating relay and other elements, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that a time synchronization protocolisbe used by the delegating relays and DHCP servers.</t> </list> </t></li> </ol> </section> </section> <sectionanchor="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 ... --> <sectionanchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>Thismemo includesdocument has norequest to IANA.</t>IANA actions.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document does not add any new security considerations beyond those mentioned inSection 4 of<xreftarget="RFC8213"/>target="RFC8213" sectionFormat="of" section="4"/> andSection 22 of<xreftarget="RFC8415"/>.target="RFC8415" sectionFormat="of" section="22"/>. </t> <t>If the delegating relay implements <xreftarget="BCP38"/>target="BCP38" format="default"/> filtering, then the filtering rules will need to be dynamically updated as delegated prefixes are leased. </t> <t><xreftarget="RFC8213"/>target="RFC8213" format="default"/> describes a method for securing traffic between the relay agent and server by sending DHCP messages over an IPsec tunnel. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that thisisbe implemented by the delegating relay.</t> <t>Failure to implement requirement G-6 may have specific security implications, such as a resource depletion attack on the relay.</t> <t>The operational requirements inSection<xreftarget="opreqs"/>target="opreqs" format="default"/> may introduce additional security considerations. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the operational security practices described in <xreftarget="RFC4778"/> aretarget="RFC4778" format="default"/> be implemented. </t> </section> </middle><!-- *****BACK MATTER ***** --><back><references title="Normative References"> <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> &RFC2119; &RFC4443; &RFC4778; &RFC5460; &RFC7653; &RFC8174; &RFC8213; &RFC8415;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4778.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5460.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7653.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8213.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/> </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><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.RFC.2827.xml"/> </referencegroup> <reference anchor="DOCSIS_3.1"target="https://apps.cablelabs.com/specification/CM-SP-MULPIv3.">target="https://www.cablelabs.com/specification/CM-SP-MULPIv3.1"> <front> <title>MAC and Upper Layer Protocols InterfaceSpecification", DOCSIS 3.1, January, 2017</title>Specification</title> <author><organization abbrev="CL">CableLabs</organization><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/download/TR-092.pdf"> <front> <title>Broadband Remote Access Server (BRAS) RequirementsDocument, August, 2004</title>Document</title> <author><organization abbrev="BBF">Broadband<organization>Broadband Forum</organization> </author> <date/>month="August" year="2004"/> </front> <seriesInfo name="Technical Report" value="TR-092"/> </reference> </references><!-- Change Log v00 2019-05-7 IF Initial version 2020-02-20 IF - Name change after adoption and typo fixes 2020-03-27 IF - Updates after Bernie's review 2020-08-19 IF - Updates after Ted Lemon's review 2020-10-10 IF - WGLC updates included. Cleanup for publication 2021-01-04 IF - Updates aftr IESG review--></references> <section anchor="Acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors of this document would like to thank <contact fullname="Bernie Volz"/>, <contact fullname="Ted Lemon"/>, and <contact fullname="Michael Richardson"/> for their valuable comments. </t> </section> </back> </rfc>