The router that acts as a DHCP server and responds to requests for delegated prefixes.

Delegating relay:

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.

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.

1. The delegating relay MUST forward messages bidirectionally between the client and server without changing the contents of the message.
2. The relay MUST allow for multiple prefixes to be delegated for the same client IA_PD. These delegations may have different lifetimes.
3. The relay MUST 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).
4. 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 southbound interfaces but not on the northbound interfaces). The relay SHOULD allow the same client identifier (DUID) to have active delegated prefix leases on more than one interface 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.
5. The maximum number of simultaneous prefixes delegated to a single client MUST be configurable.
6. The relay MUST implement a mechanism to limit the maximum number of active prefix delegations on a single port for all client identifiers and IA_PDs. This value MUST be configurable.
7. It is RECOMMENDED that delegating relays support at least 8 active delegated leases per client device and use this as the default limit.
8. The delegating relay MUST 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.
9. On receipt of a Release message from the client, the delegating relay MUST expire the active leases for each of the IA_PDs in the message.

1. The relay MUST maintain a local routing table that is dynamically updated with leases and the associated next hops as they are delegated to clients. When a delegated prefix is released or expires, the associated route MUST be removed from the relay's routing table.
2. The delegating relay's routing entry MUST use the same prefix length for the delegated prefix as given in the IA_PD.
3. The relay MUST 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 . The delegating relay's ingress filter entry MUST use the same prefix length for the delegated prefix as given in the IA_PD.
4. The relay MAY 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 route MUST be withdrawn from the routing protocol. The mechanism by which the routes are inserted and deleted is out of the scope of this document.
5. 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:
   • For point-to-point links, when the packet's ingress and egress interfaces match.
   • For multi-access links, when the packet's ingress and egress interface match, and the source link-layer and next-hop link-layer addresses match.
   An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error message MAY be sent as per . The ICMP policy SHOULD be configurable.

1. To preserve active client prefix delegations across relay restarts, the relay SHOULD implement at least one of the following:
   • Implement DHCPv6 Bulk Leasequery as defined in .
   • Store active prefix delegations in persistent storage so they can be reread after the reboot.
2. 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 prefixes MUST be retained by the delegating relay unless they are released or removed due to expiring DHCP timers. This is to reestablish routing for the delegated prefix if the client next hop becomes reachable without the delegated prefixes needing to be relearned.
3. The relay SHOULD implement DHCPv6 Active Leasequery as defined in to keep the local lease database in sync with the DHCPv6 server.

1. The relay SHOULD implement an interface allowing the operator to view the active delegated prefixes. This SHOULD provide information about the delegated lease and client details such as the client identifier, next-hop address, connected interface, and remaining lifetimes.
2. The relay SHOULD provide a method for the operator to clear active bindings for an individual lease, client, or all bindings on a port.
3. To facilitate troubleshooting of operational problems between the delegating relay and other elements, it is RECOMMENDED that a time synchronization protocol be used by the delegating relays and DHCP servers.