RADIUS Option for the DHCPv6 Relay Agent
Extracted elements (17)
When the centralized DHCPv6 server is not co-located with the RADIUS server, there is no shared user database, so a new mechanism (OPTION_RADIUS) is needed for the DHCPv6 relay agent to transfer RADIUS authorization attributes to the DHCPv6 server. This document addresses that gap for ISP broadband deployments.
OPTION_RADIUS can only contain RADIUS attributes listed in the 'RADIUS Attributes Permitted in DHCPv6 RADIUS Option' registry; new attributes require Expert Review before being added. The RADIUS attribute Length field (per RFC 2865 Section 5) includes the Type and Length fields themselves.
A DHCPv6 server that does not support OPTION_RADIUS MUST silently discard this option.
After receiving a REBIND (6) message from the DHCPv6 client, the NAS MUST initiate a new Access-Request/Access-Accept exchange with the RADIUS server, unless RADIUS capability is disabled on the NAS.
After receiving a RENEW (5) message from the DHCPv6 client, the NAS SHOULD NOT initiate a new Access-Request/Access-Accept message exchange with the RADIUS server.
DHCPv6 clients MUST NOT send OPTION_RADIUS and MUST ignore OPTION_RADIUS if received, as the option is only exchanged between relay agents and servers.
If RADIUS authentication/authorization passes, the NAS MUST store the information indicated in the RADIUS attributes received in the Access-Accept message for the duration of the whole session.
If the relay agent is configured to send OPTION_RADIUS and the Access-Accept message contained permitted RADIUS attributes, the relay agent MUST include OPTION_RADIUS in the RELAY-FORW (12) message.
Relay agents and servers implementing this specification MUST support IPsec ESP with encryption in transport mode (per RFC 4303 Section 3.1.1 and RFC 3315 Section 21.1) to protect confidentiality of RADIUS attributes carried in DHCPv6 messages.
Upon receipt of RELAY-FORW with OPTION_RADIUS, a DHCPv6 server that supports OPTION_RADIUS SHOULD extract and interpret the RADIUS attributes and use that information to select configuration parameters for the requesting client.
When multiple RADIUS attributes of the same type are present in OPTION_RADIUS, the order of attributes with the same type MUST be the same as that received from the RADIUS server.
OPTION_RADIUS (option code 81) is a DHCPv6 option used by the relay agent to carry RADIUS authorization attributes from the Access-Accept message to the centralized DHCPv6 server. The option-data field contains a list of one or more RADIUS attributes.
OPTION_RADIUS SHOULD appear in RELAY-FORW (12) messages relaying SOLICIT (1), REQUEST (3), and REBIND (6) from the DHCPv6 client, and MAY appear in RELAY-FORW relaying any other DHCPv6 client message.
IANA assigned OPTION_RADIUS (code 81) in the 'DHCP Option Codes' registry. IANA also created a new registry 'RADIUS Attributes Permitted in DHCPv6 RADIUS Option' under the DHCPv6 registry, with an Expert Review allocation policy. Initial entries include Vendor-Specific (26), Delegated-IPv6-Prefix (123), DS-Lite-Tunnel-Name (144), Framed-IPv6-Address (168), DNS-Server-IPv6-Address (169), Delegated-IPv6-Prefix-Pool (171), and Stateful-IPv6-Address-Pool (172).
A compromised DHCPv6 relay agent can forge RADIUS attributes in OPTION_RADIUS of RELAY-FORW messages, potentially influencing parameter assignment on the DHCPv6 server for DHCPv6 clients. This attack vector is mitigated in practice by the NAS and DHCPv6 server belonging to the same administrative domain.
Although RADIUS messages are encrypted, DHCPv6 messages are always unencrypted. RADIUS vendor-specific attributes may contain sensitive or confidential information; administrators are strongly advised to prevent such information from being included in DHCPv6 messages, or to use IPsec ESP with encryption to protect confidentiality.
OPTION_RADIUS encodes a 2-octet option-code field (value 81), a 2-octet option-len field indicating the length of option-data in octets, followed by option-data containing a list of RADIUS attributes in the format defined in RFC 2865 Section 5 and RFC 6929 Sections 2.1-2.2.