DHCPv6 Prefix Delegating Relay Requirements
Extracted elements (29)
Delegating relays have been observed dropping Solicit messages when a new client appears on a port that already has an active PD lease, requiring a Release or lease timeout before forwarding resumes; requirement G-1 directly addresses this to support device replacement scenarios.
Forwarding loops arise when a client loses its active lease state while the relay still holds the route: traffic is forwarded to the client, which returns it to the relay as its default gateway. Requirement R-5 (loop detection) and S-1/S-2 (state preservation) mitigate this.
Relay loss of routing state on reboot causes traffic forwarding failures until DHCP state is reestablished; requirements S-1 and S-2 mandate persistent storage or Bulk Leasequery to address this gap.
Some relay implementations restrict delegated prefixes to one per DUID, installing only a single route and leaving other delegated prefixes unreachable; requirements G-2 and G-3 mandate support for multiple simultaneous delegations per client.
The term 'delegating router' from RFC 8415 is intentionally not used here because this document targets deployment scenarios where the DHCPv6 relay and server functions are separated; 'delegating relay' is introduced to precisely describe the relaying function without implying a server role.
Relays MUST forward packets containing message codes or options they do not understand, as required by RFC 8415 Sections 19 and 16 respectively.
The requirements in this document apply solely to the DHCP relay agent co-located with the first-hop router to which the client is connected; multi-hop DHCPv6 relaying is not affected and no changes to subsequent relays in the path are needed.
If a client's next-hop link-local address becomes unreachable, routes for the client's delegated prefixes MUST be retained by the delegating relay unless explicitly released or removed by expiring DHCP timers.
It is RECOMMENDED that a time synchronization protocol be used by delegating relays and DHCP servers to facilitate troubleshooting of operational problems.
It is RECOMMENDED that delegating relays support at least 8 active delegated leases per client device and use this as the default limit.
It is RECOMMENDED that the delegating relay implement RFC 8213 (IPsec tunnel between relay agent and server) to secure relay-to-server DHCPv6 traffic.
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.
The delegating relay MUST forward messages bidirectionally between the client and server without changing the contents of the message.
The delegating relay MUST update lease lifetimes based on the client's reply messages it forwards and MUST only expire delegated prefixes when the valid lifetime has elapsed.
The delegating relay's routing entry MUST use the same prefix length for the delegated prefix as given in the IA_PD.
The maximum number of simultaneous prefixes delegated to a single client MUST be configurable.
The relay MAY provide a mechanism to dynamically advertise delegated leases into a routing protocol; if implemented, when a lease is released or expires, the delegated route MUST be withdrawn.
The relay MUST allow for multiple prefixes to be delegated for the same client IA_PD, and these delegations may have different lifetimes.
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 DUID.
The relay MUST implement a configurable mechanism to limit the maximum number of active prefix delegations on a single port for all client identifiers and IA_PDs. Failure to implement this may enable resource depletion attacks.
The relay MUST maintain a local routing table dynamically updated with delegated leases and their associated next hops; when a delegated prefix is released or expires, its route MUST be removed.
The relay MUST provide a mechanism to dynamically update ingress filters to permit traffic from delegated prefixes and block packets with invalid source prefixes, implementing BCP38 anti-spoofing; the filter entry MUST use the same prefix length as given in the IA_PD.
The relay SHOULD allow the same client DUID to have active delegated prefix leases on more than one interface simultaneously, unless DUID uniqueness is required for network functioning or security, to permit duplicate-DUID devices on separate broadcast domains.
The relay SHOULD implement DHCPv6 Active Leasequery (RFC 7653) to keep the local lease database in sync with the DHCPv6 server.
To preserve active client prefix delegations across relay restarts, the relay SHOULD implement either DHCPv6 Bulk Leasequery (RFC 5460) or persistent storage of active prefix delegations readable after reboot.
To prevent routing loops, the relay SHOULD implement a configurable policy (per-client or per-destination) to drop packets received on a DHCP-PD client-facing interface whose destination address falls within a prefix delegated to a client on that same interface.
A 'delegating relay' is defined as an intermediate device that forwards DHCPv6 messages containing IA_PD and IAPREFIX options between client and server, does not implement a DHCPv6 server function, and is responsible for routing traffic for the delegated prefixes. This is distinct from the RFC 8415 'delegating router' term.
Failure to implement a configurable per-port limit on active prefix delegations (requirement G-6) may expose the relay to a resource depletion attack. The operational interface requirements (Section 4.4) may introduce additional security considerations; RFC 4778 operational security practices are RECOMMENDED.
If the delegating relay implements BCP38 filtering, the filtering rules must be dynamically updated as delegated prefixes are leased, since static rules cannot account for dynamically assigned prefixes.