| RFC 8987 | DHCPv6 PD Relay | February 2021 |
| Farrer, et al. | Standards Track | [Page] |
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 failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with prefix delegation.¶
It is recommended that any network operator using DHCPv6 prefix delegation with relays ensure that these requirements are followed on their networks.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8987.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
For Internet 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's Layer 3 customer edge device and a separate, centralized DHCPv6 server infrastructure. [RFC8415] describes the functionality of a DHCPv6 relay, and Section 19.1.3 of [RFC8415] 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.¶
A DHCPv6 relay agent for prefix delegation is a function commonly implemented in routing devices, but implementations vary in their functionality and client/server interworking. This can result in operational problems such as messages not being forwarded by the relay or unreachability of the delegated prefixes. This document provides a set of requirements for devices implementing a relay function for use with prefix delegation.¶
The mechanisms for a relay to inject routes (including aggregated 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 document.¶
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 router to which the DHCPv6 client requesting the prefix is connected, so no changes to any subsequent relays in the path are needed.¶
This document uses the terminology defined in [RFC8415]. However, when defining the functional elements for prefix delegation, [RFC8415], Section 4.2 defines the term "delegating router" as:¶
The router that acts as a DHCP server and responds to requests for delegated prefixes.¶
This document is concerned with deployment scenarios in which the DHCPv6 relay and DHCPv6 server functions are separated, so the term "delegating router" is not used. Instead, a new term is introduced to describe the relaying function:¶
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.¶
In CableLabs DOCSIS environments, the Cable Modem Termination System (CMTS) would be considered a delegating relay with respect to Customer Premises Devices (CPEs) ([DOCSIS_3.1], Section 5.2.7.2). A Broadband Network Gateway (BNG) in a DSL-based access network may be a delegating relay if it does not implement a local DHCPv6 server function ([TR-092], Section 4.10).¶
[RFC8415] defines the "DHCP server" (or "server") as:¶
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 delegating router.¶
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.¶
The term "requesting router" has previously been used to describe the DHCP client requesting prefixes for use. This document adopts the terminology of [RFC8415] and uses "DHCP client" or "client" interchangeably for this element.¶
The following diagram shows the deployment topology relevant to this document.¶
+ | ------- uplink ------> | _ ,--,_ | +--------+ +------------+ _( `' )_ +--------+ +---+ PD |-------| Delegating |--( Operator )---| DHCPv6 | | | Client | | relay | `(_ Network_)' | server | | +--------+ +----------- + `--'`---' +--------+ | | <----- downlink ------ + (client facing) Client Network
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.¶
The delegating relay provides the operator's Layer 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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following sections of the document describe problems that have been observed with delegating relay implementations in commercially available devices.¶
Delegating relay implementations have been observed not to forward messages between the client and server. This generally occurs if a client sends a message that 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 receives a DHCP Release message from the original client or the existing lease times out. This causes a particular problem when a client device needs to be replaced due to a failure.¶
In addition to dropping messages, in some cases, the delegating relay will generate error messages and send them to the client, e.g., "NoBinding" messages being sent in the event that the delegating relay does not have an active delegated prefix lease.¶
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 relay that does not store this state persistently across reboots will not be able to forward traffic to the client's delegated leases until the state is reestablished through new DHCP messages.¶
DHCPv6 [RFC8415] allows a 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.¶
In some delegating relay implementations, only a single delegated prefix per DHCP Unique Identifier (DUID) is supported. In those cases, only one IPv6 route for one of the delegated prefixes is installed, meaning that other prefixes delegated to a client are unreachable.¶
It is an operational reality that client devices with duplicate Media 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.¶
Delegating relays have been observed to restrict forwarding client messages originating from one client DUID to a single interface. In this case, 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 are dropped, causing the second client to be unable to obtain a prefix delegation.¶
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, enforcing uniqueness of the MAC address and/or DUID is a necessary function and is not considered a problem.¶
If the client loses information about an active prefix lease it has been delegated while the lease entry and associated route are still active in the delegating relay, then the relay will forward traffic to the client. The client will return this traffic to the relay, which is the client's default gateway (learned via a Router Advertisement (RA)). The loop will continue until either the client is successfully reprovisioned via DHCP or the lease ages out in the relay.¶
To resolve the problems described in Section 3 and to preempt other undesirable behavior, the following section of the document describes a set of functional requirements for the delegating relay.¶
In addition, relay implementers are reminded that [RFC8415] makes it clear that relays MUST forward packets that either contain message codes it may not understand (Section 19 of [RFC8415]) or options that it does not understand (Section 16 of [RFC8415]).¶
To prevent routing loops, the relay SHOULD implement a configurable policy to drop potential looping packets received on any DHCP-PD client-facing interfaces.¶
The policy SHOULD be configurable on a per-client or per-destination basis.¶
Looping packets are those with a destination address in a prefix delegated to a client connected to that interface, as follows:¶
An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error message MAY be sent as per [RFC4443], Section 3.1. The ICMP policy SHOULD be configurable.¶
To preserve active client prefix delegations across relay restarts, the relay SHOULD implement at least one of the following:¶
This document has no IANA actions.¶
This document does not add any new security considerations beyond those mentioned in Section 4 of [RFC8213] and Section 22 of [RFC8415].¶
If the delegating relay implements [BCP38] filtering, then the filtering rules will need to be dynamically updated as delegated prefixes are leased.¶
[RFC8213] describes a method for securing traffic between the relay agent and server by sending DHCP messages over an IPsec tunnel. It is RECOMMENDED that this be implemented by the delegating relay.¶
Failure to implement requirement G-6 may have specific security implications, such as a resource depletion attack on the relay.¶
The operational requirements in Section 4.4 may introduce additional security considerations. It is RECOMMENDED that the operational security practices described in [RFC4778] be implemented.¶
The authors of this document would like to thank Bernie Volz, Ted Lemon, and Michael Richardson for their valuable comments.¶