skip to content

How does Vendor-Specific (26) let a RADIUS deployment carry an attribute the standard set lacks?

level: middleimportance: must knowfreq 52%

answer

  1. the standard's escape hatch
  2. an enterprise code, then opaque octets
  3. the receiver need not understand it
  4. ignore it, do not reject it
  5. both ends need the same definitions

basics

~20 s

Vendor-Specific (26) is the standard's escape hatch: its value opens with a four-octet Vendor-Id holding an SMI Network Management Private Enterprise Code, followed by an opaque String the vendor defines. A receiver that cannot interpret it must ignore it.

solid answer

~40 s

`Vendor-Specific` (26) is the escape hatch in the standard vocabulary. Its value begins with a four-octet `Vendor-Id` — the high-order octet zero and the low three the vendor's **SMI Network Management Private Enterprise Code** — followed by a `String` that the protocol treats as opaque. The recommended shape inside that `String` is a sequence of vendor-type, vendor-length and value fields, but nothing in the base protocol parses it. A receiver not equipped to interpret that vendor's information **must ignore the attribute** rather than reject the packet, and a sender that wanted it back should be able to operate without it. So type 26 buys extensibility at the cost of interoperability: the octets travel fine, and only ends configured with the same definitions know what they mean.

code

pseudocode · 14 lines
pseudocode
Vendor-Specific (26) layout:

  Type      = 26
  Length    = 2 + 4 + length(String)      # at most 255 in total
  Vendor-Id = 0x00 || three-octet SMI Private Enterprise Code
  String    = opaque to the protocol

  # recommended, not required, shape inside String:
  #   vendor-type (1 octet) | vendor-length (1 octet) | value

receiving it:
  if Vendor-Id is not one we hold definitions for:
      ignore this attribute
      continue with the next attribute      # do not reject the packet

go deeper

for a junior

Recall that one standard attribute exists purely to carry non-standard ones, that it is labelled with a registered vendor number, and that a receiver who does not recognise that number leaves it alone.

for a middle

Explain the layout — a four-octet Vendor-Id then an opaque String — and the required behaviour on an unknown vendor: ignore the attribute, do not reject the packet. Note that the nested vendor-type shape is only a recommendation.

for a senior

Show the operational consequence: because ignoring is silent and the meaning lives in configuration, a vendor attribute can be dropped at every hop for months without an error, and an equipment change can quietly empty half a session profile.

for a principal

The call to own is where a deployment's vocabulary lives: private extensibility that ties policy to one maker's equipment, versus staying inside the standard and extended spaces at the cost of expressing less.

## An escape hatch with a registered door number The standard attribute set is finite and was largely fixed decades ago, yet equipment makers kept needing to say things the set had no word for. `Vendor-Specific` (26) is the answer the protocol chose: one standard attribute whose job is to carry something non-standard, labelled so that nobody mistakes whose non-standard thing it is. The value of a type 26 attribute starts with a four-octet **`Vendor-Id`**. Its high-order octet is zero and the remaining three octets carry the vendor's **SMI Network Management Private Enterprise Code** — a number from a public registry that already existed for network-management purposes. Because the numbers are registered, two vendors cannot collide, and a receiver can look at the first four octets of the value and know immediately whether the rest is addressed to it. Everything after those four octets is a `String` the specification declines to define. That is the deliberate part. ## What is inside the String | Part of the attribute | Size | Defined by | |---|---|---| | `Type` = 26 | 1 octet | The standard | | `Length` | 1 octet | The standard, counting the whole attribute | | `Vendor-Id` | 4 octets | A registered private enterprise code | | `String` | the rest | The vendor alone | The specification **recommends** a shape for the `String`: a sequence of vendor-type, vendor-length and value fields, so that one type 26 attribute can carry several vendor attributes in a nested form mirroring the outer encoding. It is a recommendation, not a requirement, and the base protocol does not parse it. To a receiver with no definitions for that vendor, the `String` is undistinguished octets — a blob whose internal structure it has no standing to guess at. The outer `Length` still applies, so a single type 26 attribute holds at most 253 octets in total, four of which are already spent on the `Vendor-Id`. ## What a receiver is required to do The rule that makes the mechanism safe is about *ignoring*, and its direction matters. A server not equipped to interpret the vendor-specific information sent to it **must ignore** the attribute — it does not reject the packet, and it does not treat the request as malformed. On the other side, a sender that expected vendor-specific information back and did not get it should make an attempt to operate without it. That pair of rules is what lets an unknown attribute cross a path of mixed equipment without breaking anything. An intermediary that cannot read a type 26 attribute is not obliged to understand it in order to carry it: it is carrying registered, self-labelled octets. ## What it costs Extensibility bought this way is not interoperability: - **Meaning lives outside the protocol.** Two ends agree only because both were configured with the same vendor's definitions. Nothing on the wire declares them, so a mismatch produces a well-formed attribute that one side reads differently — or ignores entirely. - **Ignoring is silent.** The required behaviour on a `Vendor-Id` you do not know is to say nothing. A deployment can send an attribute for months, have it ignored at every hop, and see no error anywhere. - **It does not survive an equipment change.** Replacing a piece of equipment replaces the vocabulary, even though the protocol is unchanged. - **It competes with the standard route.** Where an attribute has become genuinely general, the registered standard space — and RFC 6929's extended space beyond it — is the interoperable home for it; type 26 is the private one. On a ship's passenger wireless network the practical shape of this is a service tier expressed twice: the parts of the session profile the standard has words for travel as standard attributes, and whatever the on-board equipment needs beyond them travels inside type 26 under that maker's enterprise code, understood only by devices configured for it. The first question to ask of such a deployment is which of the two halves a replacement piece of equipment would still understand.

  • What is actually inside the opaque String of a Vendor-Specific (26) attribute?
    Whatever that vendor decided. The specification recommends a nested sequence of vendor-type, vendor-length and value fields, which lets one type 26 attribute carry several vendor attributes, but it is a recommendation and the base protocol never parses it. A receiver without that vendor's definitions sees undistinguished octets and nothing more.
  • Why can two deployments exchange a Vendor-Specific (26) attribute successfully and still disagree about what it means?
    Because success on the wire only requires a well-formed attribute with a registered `Vendor-Id`. The meaning of the `String` lives in configuration at each end, not in the packet, so two ends holding different or outdated definitions for the same vendor code read the same octets differently — and neither side gets an error saying so.

A diplomatic pouch. The carrier moves it because the seal on the outside says whose it is, not because anyone along the route is entitled to know, or able to read, what is inside.

saying these in an interview costs you the question

  • Thinks the String inside type 26 has a structure every receiver can parse.
  • Says an unrecognised Vendor-Id should cause an Access-Reject (Code 3).
  • Believes the Vendor-Id is the vendor's own attribute number.
  • Assumes a vendor attribute means the same thing on any equipment.
  • Treats type 26 as the only way to extend the attribute set.