RFC 6519
RADIUS Extensions for Dual-Stack Lite
RFC 6519: RADIUS Extensions for Dual-Stack Lite 💖
okay bestie, this is RFC 6519, and the title says it all: RADIUS Extensions for Dual-Stack Lite 🎀 Here's the title block tea 🫶:
- Authors: R. Maglione (Telecom Italia) and A. Durand (Juniper Networks) ✨
- Category: Standards Track 👑
- Date: February 2012 🌸
- ISSN: 2070-1721 🦋
- Obsoletes / Updates: the header doesn't list any document this one obsoletes or updates 🙈
- Published by: the Internet Engineering Task Force (IETF), as a Request for Comments 💜
Abstract 🦋
Dual-Stack Lite is a way to give both IPv4 and IPv6 connectivity to customers who only have an IPv6 prefix 🌈 The B4 element needs the Dual-Stack Lite AFTR tunnel info set up ahead of time 🍓 Lowkey, in lots of networks the customer profile lives in Authentication, Authorization, and Accounting (AAA) servers, while client config mostly comes through the Dynamic Host Configuration Protocol (DHCP) 💅
This document specifies a brand new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name ✨ It's modeled on the DHCPv6 OPTION_AFTR_NAME option, so it's giving family resemblance 👯 The attribute is meant to go between the RADIUS server and the Network Access Server (NAS). It is not meant to be used directly between the B4 element and the RADIUS server 🙅♀️
Status of This Memo 💅
This is an Internet Standards Track document 💖
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚
Info about the current status of this document, any errata, and how to send feedback can be found at http://www.rfc-editor.org/info/rfc6519 🔗
Copyright Notice 🔥
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💕
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🌸
Table of Contents 📚
1. Introduction ....................................................3
2. Terminology .....................................................4
3. DS-Lite Configuration with RADIUS and DHCPv6 ....................4
4. RADIUS Attribute ................................................7
4.1. DS-Lite-Tunnel-Name ........................................7
5. Table of Attributes .............................................9
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................101. Introduction ✨
Dual-Stack Lite [RFC6333] gives both IPv4 and IPv6 connectivity to customers who are addressed only with an IPv6 prefix. No IPv4 address is assigned to the attachment device 🧚 One of its key pieces is an IPv4-over-IPv6 tunnel, but a Dual-Stack-Lite Basic Bridging BroadBand (B4) element won't know whether the network it's attached to offers Dual-Stack Lite support 😭 Even if the B4 did know, it still wouldn't know the remote end of the tunnel it could connect to 💀
To tell the B4 element where the Address Family Transition Router (AFTR) is, a Fully Qualified Domain Name (FQDN) may be used 🦋 Once that info is conveyed, the presence of the configuration that points to the AFTR also tells a host to start Dual-Stack Lite (DS-Lite) service and become a Softwire Initiator. Main character energy 👑
[RFC6334] specifies a DHCPv6 option that a DS-Lite client (B4 element) uses to discover its AFTR name 🎀 To fill in that option, the DHCPv6 server has to be pre-provisioned with the AFTR name 🙈
In broadband environments, a customer profile may be managed by Authentication, Authorization, and Accounting (AAA) servers, together with AAA for users 💅 The Remote Authentication Dial-In User Service (RADIUS) protocol [RFC2865] is usually what AAA servers use to talk to network elements 🌈 [RADIUS-IPv6] describes a typical broadband network scenario where the Network Access Server (NAS) acts as the access gateway for users (hosts or Customer Premises Equipment (CPE) devices). It also embeds a DHCPv6 server function, so it can handle any DHCPv6 requests from clients locally 🫶
Here's the vibe check 🔥 The DS-Lite AFTR info can live in AAA servers, and client config mostly comes through DHCP running between the NAS and the requesting clients. So a new RADIUS attribute is needed to send AFTR info from the AAA server to the NAS 💖
This document defines that new RADIUS attribute for carrying the DS-Lite Tunnel Name, based on the equivalent DHCPv6 option already specified in [RFC6334] ✨
2. Terminology 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀
The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS-Lite Address Family Transition Router element (AFTR) are defined in [RFC6333] 🦋
3. DS-Lite Configuration with RADIUS and DHCPv6 ✨
okay so bestie, this section is where RADIUS and DHCPv6 team up to get DS-Lite set up on the B4 🦋 Figure 1 shows the whole vibe when a PPP session gives the user their connection.
The NAS is acting as a RADIUS client and as a DHCP Server 💅 It starts by sending an Access-Request message to the RADIUS server, asking for authentication. Once the server gets that request, it checks the sending client. If the request is approved, the AAA server sends back an Access-Accept message with a list of attribute-value pairs describing the parameters for this session. This list MAY also contain the AFTR tunnel name. ✨ When the NAS gets a DHCPv6 client request that has the DS-Lite tunnel option, the NAS SHALL use the name from the RADIUS DS-Lite-Tunnel-Name attribute to fill in the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message. 🎀
B4 NAS AAA
| | Server
| | |
|----PPP LCP Config-Request------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---- Access-Accept-----|
| | (DS-Lite-Tunnel-Name) |
|<-----PPP LCP Config-ACK ------- | |
| | |
| | |
|--- PPP IPv6CP Config-Request --->| |
| | |
|<----- PPP IPv6CP Config-ACK -----| |
| | |
|------- DHCPv6 Solicit -------->| |
| | |
|<-------DHCPv6 Advertisement -----| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
|<-------- DHCPv6 Reply ---------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS
Figure 1: RADIUS and DHCPv6 Message Flow for a PPP SessionFigure 2 is the same kind of party but for an IP session 🌸 Same cast, same vibe, different trigger.
B4 NAS AAA
| | Server
|------ DHCPv6 Solicit ---------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---Access-Accept-------|
| | (DS-Lite-Tunnel-Name) |
| | |
|<-------DHCPv6 Advertisement------| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
| | |
|<----- DHCPv6 Reply ------------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS
Figure 2: RADIUS and DHCPv6 Message Flow for an IP SessionSo the only real difference from the PPP one is who kicks things off 🙈 In the IP session, the NAS and the AAA/RADIUS server start talking because of the DHCPv6 Solicit message that the NAS gets from the B4 acting as a DHCPv6 client. In the PPP case, the trigger is the PPP Link Control Protocol (LCP) Config-Request message the NAS receives.
In the Figure 2 scenario, the Access-Request packet has a Service-Type attribute with the value Authorize Only (17). So, according to [RFC5080], the Access-Request packet MUST contain a State attribute. 💀
After the NAS gets the DS-Lite-Tunnel-Name attribute in the first Access-Accept packet, it MUST store that AFTR tunnel name locally 🧚 Then, when the B4 sends a DHCPv6 Renew message to ask for longer lifetimes on its assigned address or prefix, the NAS doesn't have to start a new Access-Request packet toward the AAA server just to get the AFTR tunnel name again. It just pulls up the tunnel name it already saved and uses it in the reply. Main character energy ✨
According to [RFC3315], if the DHCPv6 server that got the Renew message at time T1 doesn't respond, the DHCPv6 client starts a Rebind/Reply message exchange with any available server. In this case, the NAS that receives the DHCPv6 Rebind message MUST initiate a new Access-Request message toward the AAA server. The NAS MAY include the DS-Lite-Tunnel-Name attribute in that Access-Request message. 🌈
If the NAS doesn't get the DS-Lite-Tunnel-Name attribute in the Access-Accept message, it MAY fall back to a pre-configured default tunnel name, if it has one. But if the NAS has no pre-configured default tunnel name, or if it gets an Access-Reject message, the IPv4-over-IPv6 tunnel cannot be established 😭 Which means the B4 only has IPv6 connectivity. Sad, but that's the deal.
4. RADIUS Attribute 🎀
This section is where we spell out the format of the new RADIUS attribute.
4.1. DS-Lite-Tunnel-Name 🍓
The DS-Lite-Tunnel-Name RADIUS attribute holds an FQDN that points to the AFTR the client is supposed to connect to 🦋 The NAS SHALL use the name from the RADIUS DS-Lite-Tunnel-Name attribute to fill in the DHCPv6 OPTION_AFTR_NAME option [RFC6334].
This attribute MAY be used in Access-Request packets as a hint for the RADIUS server. For example, if the NAS has a pre-configured default tunnel name, that name MAY be put into the attribute. The RADIUS server MAY ignore the hint the NAS sent, and it MAY assign a different AFTR tunnel name. It's giving "I hear you, but I have my own plans" 💅
If the NAS includes the DS-Lite-Tunnel-Name attribute but the AAA server doesn't recognize it, this attribute MUST be ignored by the AAA server. Unbothered. 🙄
If the NAS doesn't get the DS-Lite-Tunnel-Name attribute in the Access-Accept message, it MAY fall back to a pre-configured default tunnel name, if it has one. If the NAS doesn't have any pre-configured default tunnel name, the tunnel cannot be established.
If the NAS is pre-provisioned with a default AFTR tunnel name, and the AFTR tunnel name in the Access-Accept message is different from that default, then the AFTR tunnel name from the Access-Accept message MUST be used for the session. The server wins, periodt 👑
If the NAS can't support the received AFTR tunnel name for any reason, the tunnel SHOULD NOT be established. 😬
When the Access-Request message gets triggered by a DHCPv6 Rebind message, and the AFTR tunnel name in the Access-Accept message is different from the one currently in use for that session, the NAS MUST force the B4 to re-establish the tunnel using the new AFTR name from the Access-Accept message. Plot twist, but make it make sense 🧚
If an implementation includes Change-of-Authorization (CoA) messages [RFC5176], they could be used to modify the current established DS-Lite tunnel. When the NAS gets a CoA Request message containing the DS-Lite-Tunnel-Name attribute, the NAS MUST send a Reconfigure message to a B4. That Reconfigure message tells the B4 that the NAS has new or updated configuration parameters, and that the B4 should start a Renew/Reply or Information-Request/Reply transaction with the NAS to get the updated info ✨
When the B4 receives an AFTR tunnel name that's different from the one it's currently using, the B4 MUST terminate the current DS-Lite tunnel, and the B4 MUST establish a new DS-Lite tunnel with the specified AFTR. Byebye old tunnel 🫶
The DS-Lite-Tunnel-Name RADIUS attribute MAY be present in Accounting-Request records where the Acct-Status-Type is set to Start, Stop, or Interim-Update. But the DS-Lite-Tunnel-Name RADIUS attribute MUST NOT appear more than once in a message. One is the magic number 🔥
Here's a quick look at the DS-Lite-Tunnel-Name RADIUS attribute format. The fields are sent from left to right 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | DS-Lite-Tunnel-Name (FQDN)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means:
- Type: the value is 144 for DS-Lite-Tunnel-Name.
- Length: this field gives the total length in octets of the whole attribute, including the Type and Length fields, plus the length in octets of the DS-Lite-Tunnel-Name field.
- DS-Lite-Tunnel-Name: this field holds a single FQDN for the remote tunnel endpoint, which lives at the DS-Lite AFTR.
Since the DS-Lite-Tunnel-Name attribute is used to fill in the DHCPv6 OPTION_AFTR_NAME option, the DS-Lite-Tunnel-Name field has to be formatted the way DHCPv6 requires (Section 8 of [RFC3315] -- "Representation and Use of Domain Names") 🧠 Quick version: it uses a single octet that says how long one DNS label is (at most 63 octets), followed by the label contents. This keeps going until all the labels in the FQDN are used up, and then there's a terminating zero-length label. Any updates to Section 8 of [RFC3315] also apply to how this field gets encoded. Rules are rules, bestie 📚
The data type of the DS-Lite-Tunnel-Name RADIUS attribute is a string with opaque encapsulation, according to Section 5 of [RFC2865] 🦋
5. Table of Attributes 💜
The tables below are your cheat sheet for which attributes can show up in which kinds of packets, and how many of them you can have 📋
Access- Access- Access- Challenge Accounting # Attribute
Request Accept Reject Request
0-1 0-1 0 0 0-1 144 DS-Lite-Tunnel-Name
CoA-Request CoA-ACK CoA-NACK # Attribute
0-1 0 0 144 DS-Lite-Tunnel-NameHere's what the entries in the tables above mean:
- 0: This attribute MUST NOT be present in the packet.
- 0+: Zero or more instances of this attribute MAY be present in the packet.
- 0-1: Zero or one instance of this attribute MAY be present in the packet.
6. Security Considerations 🔥
This document doesn't add any new security considerations beyond the ones already covered in [RFC2865] for the RADIUS protocol and in [RFC5176] for CoA messages. Those are the ones to read first 🫶
[RFC6333] talks about security issues related to Dual-Stack Lite. Go read it. Seriously. 🙈
7. IANA Considerations ✨
okay bestie, IANA is the org that keeps the big official lists of protocol numbers and names, and this section is literally just them getting a new entry 💅 IANA has given out a brand new RADIUS attribute type from the "Radius Attribute Types" registry (you can find it at http://www.iana.org/assignments/radius-types) 🌸
DS-Lite-Tunnel-Name - 144so the attribute is called DS-Lite-Tunnel-Name and its type number is 144 🎀 that's the whole section, no notes, just the number being locked in 🔒
8. References 📚
8.1. Normative References 💖
these are the docs you NEED to know to understand this spec, no skipping 😤
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T.,
Perkins, C., and M. Carney, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3315,
July 2003.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues
and Suggested Fixes", RFC 5080, December 2007.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee,
"Dual-Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) Option for
Dual-Stack Lite", RFC 6334, August 2011.8.2. Informative References 🦋
these ones are more like extra reading, helpful but not required to get the spec 🧚
[RADIUS-IPv6] Lourdelet, B., Dec, W., Ed., Sarikaya, B., Zorn, G.,
and D. Miles, "RADIUS attributes for IPv6 Access
Networks", Work in Progress, November 2011.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)",
RFC 5176, January 2008.Authors' Addresses 💌
Roberta Maglione 🍓 Telecom Italia Via Reiss Romoli 274 Torino 10148 Italy
EMail: roberta.maglione@telecomitalia.it
Alain Durand 💜 Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089-1206 USA
EMail: adurand@juniper.net
📦 where this page comes from
- ietf: rfc6519 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms