RFC 4679

RFC 4679: DSL Forum Vendor-Specific RADIUS Attributes 🎀

Okay bestie, this one is a Network Working Group doc, and it's giving informational 💅 It's by V. Mammoliti and G. Zorn from Cisco Systems, P. Arberg from Redback Networks, Inc., and R. Rennison from ECI Telecom. It was published in September 2006. The header doesn't list anything it obsoletes or updates, so it's standing alone 🦋

---

Status of this Memo ✨

This memo is giving info for the Internet community 🌸 It is not a spec for any kind of Internet standard, and it can be shared freely with no limits 💖

Copyright Notice 💜

Copyright (C) The Internet Society (2006).

IESG Note 🙈

Real talk, this RFC is not a candidate for any level of Internet Standard 😭 The IETF is clear that it doesn't know whether this RFC is fit for any purpose. It also says the decision to publish wasn't based on IETF review of things like security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor picked to publish it at their own discretion, so readers should be careful about how they judge its value for implementation and deployment. For more info, see RFC 3932 🧚

Abstract 🍓

This doc describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum ✨

These attributes carry Digital Subscriber Line (DSL) information that the standard RADIUS attribute set doesn't support, so it's a whole glow-up 💅 The doc is expected to be updated if and when the DSL Forum defines more vendor-specific attributes. Its main purpose is to be a reference for DSL equipment vendors who want to interoperate with other vendors' products 🫶

Table of Contents 🗂️

1. Introduction ....................................................3
2. Terminology .....................................................3
   2.1. Requirements Language ......................................3
   2.2. Technical Terms and Acronyms ...............................3
3. Attributes ......................................................5
   3.1. DSL Forum RADIUS VSA Definition ............................5
   3.2. DSL Forum Vendor Specific Sub-Attribute Encoding ...........6
   3.3. Sub-attribute Definitions ..................................6
        3.3.1. Agent-Circuit-Id ....................................6
        3.3.2. Agent-Remote-Id .....................................8
        3.3.3. Actual-Data-Rate-Upstream ...........................9
        3.3.4. Actual-Data-Rate-Downstream .........................9
        3.3.5. Minimum-Data-Rate-Upstream .........................10
        3.3.6. Minimum-Data-Rate-Downstream .......................11
        3.3.7. Attainable-Data-Rate-Upstream ......................11
        3.3.8. Attainable-Data-Rate-Downstream ....................12
        3.3.9. Maximum-Data-Rate-Upstream .........................13
        3.3.10. Maximum-Data-Rate-Downstream ......................13
        3.3.11. Minimum-Data-Rate-Upstream-Low-Power ..............14
        3.3.12. Minimum-Data-Rate-Downstream-Low-Power ............15
        3.3.13. Maximum-Interleaving-Delay-Upstream ...............16
        3.3.14. Actual-Interleaving-Delay-Upstream ................16
        3.3.15. Maximum-Interleaving-Delay-Downstream .............17
        3.3.16. Actual-Interleaving-Delay-Downstream ..............18
        3.3.17. Access-Loop-Encapsulation .........................19
        3.3.18. IWF-Session .......................................20
4. Table of Attributes ............................................21
5. Security Considerations ........................................21
6. References .....................................................22
   6.1. Normative References ......................................22
   6.2. Informative References ....................................22

1. Introduction 🌈

The DSL Forum made extra RADIUS [RFC2865] [RFC2866] vendor-specific attributes so they can carry DSL line identification and characterization info 💖 That info travels from the Access Node/DSLAM to the BRAS through Vendor-Specific PPPoE Tags [RFC2516], DHCP Relay Options [RFC3046], and Vendor-Specific Information Suboptions [RFC4243]. This doc explains the subscriber line identification and characterization info, and how the BRAS maps it onto RADIUS VSAs 🦋

The info that gets collected can be used for authentication and accounting functionality ✨ It can also be gathered and used for management and troubleshooting, which is so practical 🔥

2. Terminology 📖

The sections below define how certain specialized terms are used and what they mean in the context of this document 🧚

2.1. Requirements Language 🔑

The keyword squad in this document is "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". Each one is read the way [RFC2119] describes ✨

2.2. Technical Terms and Acronyms 💜

AAL5 ATM Adaption Layer 5 [ITU.I363-5.1996] 🌸

Access Node/DSLAM The Access Node/DSLAM is a DSL signal terminator with at least one Ethernet interface, which is its northbound interface. It aggregates traffic from several southbound interfaces, which are either Asynchronous Transfer Mode (ATM)-based (subscriber ports) or Ethernet-based 🫶

BNG Broadband Network Gateway. A BNG is an IP edge router where bandwidth and QoS policies are applied. The functions a BRAS performs are a superset of the functions a BNG performs 👑

BRAS Broadband Remote Access Server. A BRAS is a BNG and it's the aggregation point for subscriber traffic. It provides aggregation capabilities (for example IP, PPP, Ethernet) between the access network and the core network. On top of aggregation, the BRAS is also an injection point for policy management and IP QoS in the access network 💅

DSL Digital Subscriber Line. DSL is a technology that lets digital data be sent over wires in the local telephone network 📞

DSLAM Digital Subscriber Line Access Multiplexer. A DSLAM is a device that terminates DSL subscriber lines. It aggregates the data and forwards it to ATM- or Ethernet-based aggregation networks 🧚

FCS Frame Check Sequence. The FCS is a checksum added to an Ethernet frame for error detection/correction purposes ✨

IPoA IP over ATM 🦋

IWF Interworking Function. This is the set of functions that's needed for connecting two networks of different technologies (for example ATM and Ethernet). IWF is used to carry PPP over ATM (PPPoA) traffic over PPPoE 🌈

LLC Logical Link Control 🍓

3. Attributes 💖

The subsections below describe the Attributes defined by this document 🎀 These Attributes MAY be transmitted in one or more RADIUS Attributes of type Vendor-Specific [RFC2865]. More than one attribute MAY be transmitted in a single Vendor-Specific Attribute. If you do that, the attributes SHOULD be packed as a sequence of Vendor-Type/Vendor-Length/Value triples, following the initial Type, Length, and Vendor-Id fields 🫶

3.1. DSL Forum RADIUS VSA Definition 🌸

Description

This Attribute works like a "container" 📦 It encapsulates one or more vendor-specific sub-attributes, and the encoding follows the recommendations in [RFC2865] 💜

Here's a summary of the generic DSL Forum VSA 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       |           Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Vendor-Id (cont)       |       Sub-Attribute(s)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

The value is 26 for Vendor-Specific 🔥

Length

Okay, this one is strict. The Length field MUST be set equal to the sum of the Vendor-Length fields of the sub-attributes inside the Vendor-Specific Attribute, plus six (Type + Length + Vendor-Id) 🧮

Vendor-Id

This field MUST be set to decimal 3561, which is the enterprise number assigned to the ADSL Forum [IANA] 🏷️

Sub-Attributes

This field MUST contain one or more DSL Forum Vendor-Specific sub-attributes, as specified below 💅

3.2. DSL Forum Vendor Specific Sub-Attribute Encoding 🧁

Here's a summary of the sub-attribute format. Like before, the fields are sent from left to right 👑

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor-Type | Vendor-Length |  Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

This field is one octet long and holds the sub-attribute type, which is assigned by the DSL Forum 🎀

Vendor-Length

This field is one octet and tells you the length of the entire sub-attribute. That includes the Vendor-Type, Vendor-Length, and Value fields 📏

Value

The Value field is zero or more octets and holds info specific to the sub-attribute 💖 Its format and length are determined by the Vendor-Type and Vendor-Length fields. The format of the Value field is one of 2 data types: string or integer [RFC2865] 🦋

3.3. Sub-attribute Definitions 🌈

The sub-sections below define the DSL Forum vendor-specific sub-attributes. We'll keep going with them in the next part 🧚✨

3.3.1. Agent-Circuit-Id ✨

Description 💖

okay so this one is giving subscriber identity tea 🫖. It carries the subscriber agent circuit identifier that matches the logical access loop port on the Access Node/DSLAM where a subscriber's requests start. It MAY be present in both Access-Request and Accounting-Request packets 🦋.

Here's the Agent-Circuit-Id Attribute format. The fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |           String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

1 for Agent-Circuit-Id

Vendor-Length 📏

<= 65

String 🧵

The String field holds info about the Access-Node the subscriber is plugged into, plus an identifier for the subscriber's DSL port on that Access-Node. It's giving two-part energy 👯.

The exact syntax of the string is implementation dependent 🛠️. That said, the common practice is to split it into two or more space-separated components: one for the Access-Node, one for the subscriber line on that node, and maybe a hint about whether the line is Ethernet or ATM 🌈. Here are example formats:

"Access-Node-Identifier atm slot/port:vpi.vci"
   (when ATM/DSL is used)

"Access-Node-Identifier eth slot/port[:vlan-id]"
   (when Ethernet/DSL is used)

And here's a slot and port example so you can see the encoding in action 🔍:

"[Relay-identifier] atm 3/0:100.33"
   (slot = 3, port = 0, vpi = 100, vci = 33)

The Access-Node-Identifier is a unique ASCII string with no 'space' characters 🙅. The slot and port fields follow typical practices that are already out there. The slot identifier can't go over 6 characters, and the port identifier can't go over 3 characters, with a '' as the delimiter 💅.

How slots get identified is totally up to the Access Node/DSLAM implementation 🤷. The vpi, vci, and vlan-id fields (when they apply) belong to a given access loop (U-interface) 💜.

---

3.3.2. Agent-Remote-Id 🌸

Description 🎀

The Agent-Remote-Id Attribute holds an operator-specific string that's statically configured. It uniquely identifies the subscriber on the associated access loop of the Access Node/DSLAM 🔑.

In a typical subscriber setup, a few attributes can be used to identify the user, along with others: Username (like one defined on a PPP client); Agent-Circuit-Id (a static, pre-defined string sent from the Access Node/DSLAM); and Agent-Remote-Id (an operator-defined string configured on and sent by the Access Node/DSLAM) 🧠.

This Attribute MAY be included in both Access-Request and Accounting-Request packets 🦋.

Here's the Agent-Remote-Id Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |           String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

2 for Agent-Remote-Id

Vendor-Length 📏

<= 65

String 🧵

The value of this field is totally up to the service provider 👑. For example, it MAY contain a subscriber billing identifier or telephone number 📞.

---

3.3.3. Actual-Data-Rate-Upstream 🚀

Description 💖

This Attribute holds the actual upstream train rate of a subscriber's synchronized DSL link. It MAY be included in both Access-Request and Accounting-Request packets 🦋.

Here's the Actual-Data-Rate-Upstream Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont'd.)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

129 (0x81) for Actual-Data-Rate-Upstream

Vendor-Length 📏

6

Value 💎

This field is a 4-byte unsigned integer, showing the subscriber's actual upstream data rate on a synchronized DSL link. The rate is coded in bits per second ⚡.

---

3.3.4. Actual-Data-Rate-Downstream 🌈

Description 💖

This Attribute holds the actual downstream train rate of a subscriber's synchronized DSL link. It MAY be included in both Access-Request and Accounting-Request packets 🦋.

Here's the Actual-Data-Rate-Downstream Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont'd.)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

130 (0x82) for Actual-Data-Rate-Downstream

Vendor-Length 📏

6

Value 💎

This field is a 4-byte unsigned integer, showing the subscriber's actual downstream data rate on a synchronized DSL link. The rate is coded in bits per second ⚡.

---

3.3.5. Minimum-Data-Rate-Upstream 🫶

Description 💖

This Attribute holds the subscriber's operator-configured minimum upstream data rate. It MAY be included in Accounting-Request packets 🦋.

Here's the Minimum-Data-Rate-Upstream Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont'd.)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

131 (0x83) for Minimum-Data-Rate-Upstream

Vendor-Length 📏

6

Value 💎

This field is a 4-byte unsigned integer, showing the subscriber's minimum upstream data rate (as configured by the operator). The rate is coded in bits per second ⚡.

---

3.3.6. Minimum-Data-Rate-Downstream 🍓

Description 💖

This Attribute holds the subscriber's operator-configured minimum downstream data rate. It MAY be included in Accounting-Request packets 🦋.

Here's the Minimum-Data-Rate-Downstream Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont'd.)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

132 (0x84) for Minimum-Data-Rate-Downstream

Vendor-Length 📏

6

Value 💎

This field is a 4-byte unsigned integer, showing the subscriber's minimum downstream data rate (as configured by the operator). The rate is coded in bits per second ⚡.

---

3.3.7. Attainable-Data-Rate-Upstream 🔥

Description 💖

This Attribute holds the subscriber's attainable upstream data rate. It MAY be included in Accounting-Request packets 🦋.

Here's the Attainable-Data-Rate-Upstream Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont'd.)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

133 (0x85) for Attainable-Data-Rate-Upstream

Vendor-Length 📏

6

Value 💎

This field is a 4-byte unsigned integer, showing the subscriber's actual DSL attainable upstream data rate. The rate is coded in bits per second ⚡.

---

3.3.8. Attainable-Data-Rate-Downstream 👑

Description 💖

This Attribute holds the subscriber's attainable downstream data rate. It MAY be included in Accounting-Request packets 🦋.

Here's the Attainable-Data-Rate-Downstream Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont'd.)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

134 (0x86) for Attainable-Data-Rate-Downstream

Vendor-Length 📏

6

Value 💎

This field is a 4-byte unsigned integer, showing the subscriber's actual DSL attainable downstream data rate. The rate is coded in bits per second ⚡.

---

3.3.9. Maximum-Data-Rate-Upstream 💜

Description 💖

This Attribute holds the subscriber's maximum upstream data rate, as configured by the operator. It MAY be included in Accounting-Request packets 🦋.

Here's the Maximum-Data-Rate-Upstream Attribute format. Fields go 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor-Type  | Vendor-Length |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont'd.)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

135 (0x87) for Maximum-Data-Rate-Upstream

Vendor-Length 📏

6

Value 💎

This field is a 4-byte unsigned integer, showing the numeric value of the subscriber's DSL maximum upstream data rate. The rate is coded in bits per second ⚡.

3.3.10. Maximum-Data-Rate-Downstream 🌸

Description 💖

Okay so this Attribute holds the subscriber's maximum downstream data rate, the one the operator configured ✨. It MAY be included in Accounting-Request packets 🎀.

Here's the Maximum-Data-Rate-Downstream layout, read 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

136 (0x88) for Maximum-Data-Rate-Downstream, obviously 💅

Vendor-Length 🍓

6

Value 🔥

This is a 4-byte unsigned integer that holds the subscriber's DSL maximum downstream data rate. The rate is coded in bits per second ✨

3.3.11. Minimum-Data-Rate-Upstream-Low-Power 🌈

Description 💜

This Attribute holds the subscriber's minimum upstream data rate while they're in low power state, as configured by the operator 🧚. It MAY be included in Accounting-Request packets 💖.

Here's the Minimum-Data-Rate-Upstream-Low-Power layout 🦋

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🌸

137 (0x89) for Minimum-Data-Rate-Upstream-Low-Power

Vendor-Length 🍓

6

Value 🔥

This is a 4-byte unsigned integer that holds the subscriber's DSL minimum upstream data rate when they're in low power state (L1/L2). The rate is coded in bits per second 💅

3.3.12. Minimum-Data-Rate-Downstream-Low-Power 🦋

Description 💖

This Attribute holds the subscriber's minimum downstream data rate while they're in low power state, as configured by the operator ✨. It MAY be included in Accounting-Request packets 🎀.

Here's the Minimum-Data-Rate-Downstream-Low-Power layout 🧚

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🌈

138 (0x8A) for Minimum-Data-Rate-Downstream-Low-Power

Vendor-Length 🍓

6

Value 🔥

This is a 4-byte unsigned integer that holds the subscriber's DSL minimum downstream data rate. The rate is coded in bits per second 💜

3.3.13. Maximum-Interleaving-Delay-Upstream ⭐

Description 🫶

This Attribute holds the subscriber's maximum one-way upstream interleaving delay, as configured by the operator 👑. It MAY be included in Accounting-Request packets ✨.

Here's the Maximum-Interleaving-Delay-Upstream layout 🦋

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🌸

139 (0x8B) for Maximum-Interleaving-Delay-Upstream

Vendor-Length 🍓

6

Value 🔥

This is a 4-byte unsigned integer that holds the subscriber's DSL maximum one-way upstream interleaving delay, in milliseconds 💅

3.3.14. Actual-Interleaving-Delay-Upstream 💖

Description 🧚

This Attribute holds the subscriber's actual one-way upstream interleaving delay 🌈. It MAY be included in Accounting-Request packets 🦋.

Here's the Actual-Interleaving-Delay-Upstream layout ✨

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🎀

140 (0x8C) for Actual-Interleaving-Delay-Upstream

Vendor-Length 🍓

6

Value 🔥

This is a 4-byte unsigned integer that holds the subscriber's DSL actual upstream interleaving delay, in milliseconds 💜

3.3.15. Maximum-Interleaving-Delay-Downstream 🌸

Description 👑

This Attribute holds the subscriber's maximum one-way downstream interleaving delay, as configured by the operator 🫶. It MAY be included in Accounting-Request packets 🎀.

Here's the Maximum-Interleaving-Delay-Downstream layout 🦋

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🧚

141 (0x8D) for Maximum-Interleaving-Delay-Downstream

Vendor-Length 🍓

6

Value 🔥

This is a 4-byte unsigned integer that holds the subscriber's DSL maximum one-way downstream interleaving delay, in milliseconds ✨

3.3.16. Actual-Interleaving-Delay-Downstream 💅

Description 🌈

This Attribute holds the subscriber's actual one-way downstream interleaving delay 💖. It MAY be included in Accounting-Request packets 🌸.

Here's the Actual-Interleaving-Delay-Downstream layout 🦋

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |            Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont'd.)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🎀

142 (0x8E) for Actual-Interleaving-Delay-Downstream

Vendor-Length 🍓

6

Value 🔥

This is a 4-byte unsigned integer that holds the subscriber's DSL actual downstream interleaving delay, in milliseconds 💜

3.3.17. Access-Loop-Encapsulation 🧚

Description 💖

This Attribute describes the encapsulation(s) the subscriber uses on the DSL access loop 🌈. It MAY be present in both Access-Request and Accounting-Request packets 🦋.

Here's the Access-Loop-Encapsulation layout ✨

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |                    Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Value (cont'd) |
   +-+-+-+-+-+-+-+-+

Vendor-Type 🌸

144 (0x90) for Access-Loop-Encapsulation

Vendor-Length 🍓

5

Value 🔥

This is a string that's 3 bytes long, logically split into three 1-byte sub-fields, as you can see in this diagram 👑

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Data Link   |    Encaps 1   |    Encaps 2   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here are the valid values for each sub-field 🫶

Data Link 🧚

• 0x01 AAL5
• 0x02 Ethernet

Encaps 1 🌈

• 0x00 NA - Not Available
• 0x01 Untagged Ethernet
• 0x02 Single-Tagged Ethernet

Encaps 2 💜

• 0x00 NA - Not Available
• 0x01 PPPoA LLC
• 0x02 PPPoA Null
• 0x03 IPoA LLC
• 0x04 IPoA Null
• 0x05 Ethernet over AAL5 LLC with FCS
• 0x06 Ethernet over AAL5 LLC without FCS
• 0x07 Ethernet over AAL5 Null with FCS
• 0x08 Ethernet over AAL5 Null without FCS

3.3.18. IWF-Session 🦋

Description 🎀

The presence of this Attribute tells you that the IWF has been performed for the subscriber's session 💖. There's no data field here, because none is needed 🌸. It MAY be included in both Access-Request and Accounting-Request packets ✨.

Here's the IWF-Session layout 🧚

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type  | Vendor-Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type 🌈

254 (0xFE) for IWF-Session

Vendor-Length 🍓

2

4. Table of Attributes ✨

Okay so this table is your cheat sheet for which attributes can show up in which kinds of packets, and how many of each you can get 💅. The DSL Forum VSAs can't show up in Access-Accept, Access-Reject or Access-Challenge packets at all, so those columns got left out 🙈.

Request   Acct-Request  #   Attribute
0-1       0-1            1  Agent-Circuit-Id
0-1       0-1            2  Agent-Remote-Id
0-1       0-1          129  Actual-Data-Rate-Upstream
0-1       0-1          130  Actual-Data-Rate-Downstream
0         0-1          131  Minimum-Data-Rate-Upstream
0         0-1          132  Minimum-Data-Rate-Downstream
0         0-1          133  Attainable-Data-Rate-Upstream
0         0-1          134  Attainable-Data-Rate-Downstream
0         0-1          135  Maximum-Data-Rate-Upstream
0         0-1          136  Maximum-Data-Rate-Downstream
0         0-1          137  Minimum-Data-Rate-Upstream-Low-Power
0         0-1          138  Minimum-Data-Rate-Downstream-Low-Power
0         0-1          139  Maximum-Interleaving-Delay-Upstream
0         0-1          140  Actual-Interleaving-Delay-Upstream
0         0-1          141  Maximum-Interleaving-Delay-Downstream
0         0-1          142  Actual-Interleaving-Delay-Downstream
0-1       0-1          144  Access-Loop-Encapsulation
0-1       0-1          254  IWF-Session

Here's what the entries in that table mean 🔥

• 0 means this Attribute MUST NOT be present in packet 🙅
• 0-1 means zero or one instances of this Attribute MAY be present in packet 💜

5. Security Considerations 🔐

okay bestie, this part is serious, so let's be serious for a sec 🫶 The security of these Attributes basically rests on an implied trust relationship between the Access Node/DSLAM and the BRAS. The identifiers the Access Node/DSLAM inserts are unconditionally trusted, and the BRAS doesn't do any validity check on what it receives. These Attributes are meant for environments where the network infrastructure (the Access Node/DSLAM, the BRAS, and the whole network those two devices live in) is trusted and secure. 🛡️

Here, "trusted" has a specific meaning 👀 It means unauthorized traffic can only get into the network through secured and trusted devices, and every device inside the network is secure and trusted. So you should give careful thought to the security weak spots this model has before you turn this option on in real networks. 💀

These Attributes neither increase nor decrease the security of the RADIUS protocol. If you want the tea on various RADIUS vulnerabilities, check out [RFC2607], [RFC3579], [RFC3162], and [RFC3580]. 📖

---

6. References 📚

6.1. Normative References

• [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.
• [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

6.2. Informative References

• [IANA] Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE NUMBERS", January 2006, <http://www.iana.org/assignments/enterprise-numbers>.
• [ITU.I363-5.1996] International Telecommunications Union, "B-ISDN ATM Adaptation Layer Specification: Type 5 AAL", ITU-T Recommendation I.363.5, August 1996.
• [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
• [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
• [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
• [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
• [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
• [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
• [RFC4243] Stapp, M., Johnson, R., and T. Palaniappan, "Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4243, December 2005.

---

Authors' Addresses 🖊️

The authors are a crew from Cisco, Redback, and ECI Telecom 💜 Here are their details, formatted exactly as they appear in the RFC:

Vince Mammoliti
Cisco Systems
181 Bay Street, Suite 3400
Toronto, ON  M5J 2T3
Canada

EMail: vince@cisco.com


Glen Zorn
Cisco Systems
2901 Third Avenue, Suite 600
SEA1/5/
Seattle, WA  98121
USA

Phone: +1 (425) 344 8113
EMail: gwz@cisco.com


Peter Arberg
Redback Networks, Inc.
300 Holger Way
San Jose, CA  95134
USA

EMail: parberg@redback.com


Robert Rennison
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA  15205
USA

EMail: robert.rennison@ecitele.com

---

Full Copyright Statement ©️

Copyright (C) The Internet Society (2006). 💖

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html. Except as set forth in there, the authors keep all their rights. 🎀

The legal disclaimer is shown word for word below, because it needs to be exact:

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

---

Intellectual Property 💡

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover this technology are valid or in scope, or on whether a license for them is available. It also doesn't say it has independently tried to find any such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79. 📜

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of any attempt to get a general license or permission for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🔎

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 🫶

---

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). ✨