RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
Extracted elements (23)
6rd configuration is stored in AAA servers but CEs acquire configuration via DHCP from BNGs; new RADIUS attributes are needed to propagate 6rd parameters from AAA servers to BNGs, which act as both RADIUS clients and DHCP servers.
IPv4MaskLen is encoded as a 32-bit field even though the value range is 0–32, because RFC 6158 Appendix A.2.1 forbids 8-bit fields in RADIUS attributes.
The sub-attribute grouping structure within a single RADIUS attribute was chosen as a reasonable compromise because RADIUS has no recommended way of grouping multiple attributes; this allows a single attribute to carry all three 6rd parameters (IPv4MaskLen, 6rdPrefix, and BR addresses).
The IPv6-6rd-Configuration attribute is usable within both RADIUS and Diameter. Since the attribute is allocated from the standard RADIUS type space, no special handling is required by Diameter entities.
A secondary BNG receiving a DHCP message when the CE enters the REBINDING state MUST initiate a new Access-Request towards the AAA server.
After receiving the IPv6-6rd-Configuration attribute in the initial Access-Accept, the BNG SHOULD store the 6rd configuration parameters locally so it can reply to subsequent DHCP Request messages (lease renewal) without a new Access-Request.
For the re-authorization scenario (Authorize Only), the Access-Request packet MUST contain a State attribute obtained from the previous authentication process, as required by RFC 5080.
If the AAA server approves authentication, an Access-Accept message MUST be acknowledged with the IPv6-6rd-Configuration attribute.
If the AAA server does not recognize the IPv6-6rd-Configuration attribute included by the BNG, the attribute MUST be ignored by the AAA server.
If the BNG cannot support the received 6rd configuration for any reason, the tunnel SHOULD NOT be established.
If the BNG is pre-provisioned with a default 6rd configuration and the 6rd configuration received in Access-Accept is different, the configuration received in the Access-Accept message MUST be used for the session.
In the Access-Request, the User-Name attribute (1) SHOULD be filled by the 6rd CE MAC address, and the User-Password attribute (2) SHOULD be filled by the shared 6rd password preconfigured on the DHCP server.
Message-Authenticator (type 80) SHOULD be used to protect both Access-Request and Access-Accept messages in both cooperation scenarios.
When the BNG receives a DHCPDISCOVER, it SHOULD initiate a RADIUS Access-Request to the RADIUS server.
The attribute table (Section 4.2) permits the IPv6-6rd-Configuration attribute (173) to appear 0 or 1 times in Access-Request, Access-Accept, and Accounting-Request packets; it MUST NOT appear in Access-Reject or Access-Challenge packets.
Two cooperation scenarios are defined: (1) RADIUS authentication coupled with DHCPDISCOVER, where BNG sends an Access-Request and relays the received 6rd config in a DHCPOFFER; (2) re-authorization decoupled from authentication, triggered by a DHCPREQUEST with Service-Type=Authorize Only.
IANA assigned RADIUS Attribute Type 173 (IPv6-6rd-Configuration) in the 'Radius Types' registry.
Known security vulnerabilities of the RADIUS protocol (RFC 2607, RFC 2865, RFC 2869) apply to this use. Use of IPsec (RFC 4301) for securing RADIUS carried over IPv6 is discussed in RFC 3162.
To obtain unauthorized 6rd configuration, a malicious user may perform MAC address spoofing and/or a dictionary attack on the shared 6rd password preconfigured on the DHCP server; these risks are discussed further in RFC 5969 Section 12.
SubType1 (IPv4MaskLen suboption, SubLen=6) carries a 32-bit IPv4MaskLen field specifying the number of high-order bits identical across all CE IPv4 addresses in the 6rd domain; valid range is 0–32.
SubType2 (6rd prefix suboption, SubLen=20) carries a 1-octet Reserved field (MUST be zero; MUST be ignored by receiver), a 1-octet 6rdPrefixLen (MUST be ≤128), and a 16-octet 6rdPrefix IPv6 address field.
SubType3 (6rd Border Relay IPv4 address suboption, SubLen=6 per instance) carries one or more 4-octet IPv4 addresses of 6rd Border Relays; the maximum RADIUS attribute length of 255 octets limits this to 37 IPv4 addresses. Multiple SubType3 sub-attributes are RECOMMENDED to be placed together.
The IPv6-6rd-Configuration attribute has Type=173, with total Length=28+n*6 octets where n is the number of BR IPv4 addresses (minimum 1). It contains three sub-attributes (SubType1, SubType2, SubType3) that may appear in any order.