RADIUS Extensions for Dual-Stack Lite
Extracted elements (19)
A new RADIUS attribute is needed because DS-Lite AFTR information may be stored in AAA servers while client configuration is delivered via DHCPv6. Without a RADIUS attribute, there is no standard way to transfer the AFTR name from the AAA server to the NAS so the NAS can populate DHCPv6 OPTION_AFTR_NAME.
The DS-Lite-Tunnel-Name RADIUS attribute is defined to mirror the existing DHCPv6 OPTION_AFTR_NAME option (RFC 6334), deliberately reusing the same FQDN encoding so that the NAS can forward the value directly into the DHCPv6 option without any transformation.
The DS-Lite-Tunnel-Name field MUST be encoded exactly as required for DHCPv6 domain names (RFC 3315 Section 8): length-prefixed DNS labels, each at most 63 octets, terminated by a zero-length label. Any future updates to RFC 3315 Section 8 also apply to this field's encoding.
The DS-Lite-Tunnel-Name RADIUS attribute is intended for use only between the RADIUS server and the NAS; it is not intended to be used directly between the B4 element and the RADIUS server.
After receiving the DS-Lite-Tunnel-Name attribute in the initial Access-Accept, the NAS MUST store the received AFTR tunnel name locally so that DHCPv6 Renew responses can be served without a new Access-Request to the AAA server.
If the AAA server does not recognize the DS-Lite-Tunnel-Name attribute included by the NAS in an Access-Request, the attribute MUST be ignored by the AAA server.
If the NAS cannot support the received AFTR tunnel name for any reason, the tunnel SHOULD NOT be established.
If the NAS is pre-provisioned with a default AFTR tunnel name and the name received in the Access-Accept is different, the name from the Access-Accept MUST be used for the session, overriding the local default.
In IP-session scenarios where the Access-Request carries Service-Type = Authorize Only (17), the Access-Request packet MUST contain a State attribute, per RFC 5080.
The DS-Lite-Tunnel-Name RADIUS attribute MUST NOT appear more than once in a single RADIUS message.
The NAS SHALL use the name returned in the RADIUS DS-Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message.
Upon the B4 receiving an AFTR tunnel name different from the currently used one (via Reconfigure), the B4 MUST terminate the current DS-Lite tunnel and MUST establish a new one with the specified AFTR.
When a CoA Request containing the DS-Lite-Tunnel-Name attribute is received, the NAS MUST send a DHCPv6 Reconfigure message to the B4 so that it initiates a Renew/Reply or Information-Request/Reply to retrieve the updated AFTR name.
When a DHCPv6 Rebind triggers a new Access-Request and the returned AFTR tunnel name differs from the currently used one, the NAS MUST force the B4 to re-establish the tunnel using the new AFTR name.
When the NAS receives a DHCPv6 Rebind message (sent because the original DHCPv6 server did not respond by time T1), the NAS MUST initiate a new Access-Request message towards the AAA server.
The DS-Lite-Tunnel-Name RADIUS attribute carries an FQDN identifying the AFTR to which the B4 client should establish a DS-Lite tunnel. It is used between the RADIUS server and the NAS; the NAS then populates DHCPv6 OPTION_AFTR_NAME with this value.
IANA allocated RADIUS attribute type 144 for 'DS-Lite-Tunnel-Name' from the 'Radius Attribute Types' registry.
This document introduces no security considerations beyond those already identified in RFC 2865 for the RADIUS protocol and RFC 5176 for CoA messages. Security issues specific to DS-Lite are discussed in RFC 6333.
DS-Lite-Tunnel-Name attribute: Type = 144 (1 octet), Length (1 octet, total including Type and Length), followed by the FQDN encoded in DHCPv6 DNS-label format (length-prefixed labels, each up to 63 octets, terminated by a zero-length label). Data type is opaque string per RFC 2865 Section 5.