Attribute-Value Pairs

## Three fields, always the same three RADIUS is an unusually plain protocol on the wire. After the header, a packet is nothing but a sequence of attributes laid end to end, and every attribute — standard, vendor-defined, one octet long or two hundred — has the same shape: 1. **`Type`** — one octet. The number that says which attribute this is. `User-Name` is 1, `Filter-Id` is 11, `Vendor-Specific` is 26, `Session-Timeout` is 27. 2. **`Length`** — one octet. The size of the **whole attribute**, including the `Type` and `Length` octets themselves. 3. **`Value`** — `Length` minus 2 octets, interpreted according to what that attribute is defined to hold. Because `Length` is self-inclusive, the arithmetic goes the other way from what people expect. An attribute carrying a four-octet integer has `Length` 6, not 4. An attribute whose value is the ten characters `tier-basic` has `Length` 12. Reading `Length` as "how much value follows" is the single most common decoding error, and it desynchronises the parse of every attribute after it, because the reader steps to the wrong offset for the next `Type`. ## Where 253 comes from A one-octet `Length` can express at most 255. Two of those octets are the header, so: | | Octets | |---|---| | Maximum `Length` value | 255 | | `Type` + `Length` overhead | 2 | | **Maximum value in one attribute** | **253** | That number is worth committing to memory, because it is the boundary every interesting encoding decision on this protocol runs into. It is also *per attribute*: the packet has its own ceiling of 4096 octets, so a reply full of long attributes meets the packet limit long before it runs out of attribute slots. The value itself is typed by the attribute's definition rather than by anything on the wire. Integers such as `Session-Timeout` (27) are four octets; an address such as `NAS-IP-Address` (4) is four octets; text such as `Filter-Id` (11) is a run of characters with no terminator, its extent given entirely by `Length`. RFC 8044 later wrote these data types down formally, but nothing in the encoding announces them — a receiver knows a value is an integer because it knows what type 27 is. ## What happens when a value does not fit Here the honest answer is narrower than the intuitive one. **The base format has no general fragmentation.** There is no continuation bit, no sequence number, and no rule that a receiver may glue two instances of an attribute together. What the specification does say is that when an attribute may appear more than once, the **order of like attributes must be preserved**; what those repeated instances *mean* is left to the attribute's own definition. Some are defined so that repeated instances concatenate; some are defined as a list of independent values; for some, a second instance is simply an error. So a value longer than 253 octets has three honest answers, and "RADIUS splits it automatically" is not one of them: - The attribute's own definition provides a multi-instance rule, and both ends implement exactly that rule. - The value is carried under `Vendor-Specific` (26) in a private shape both ends already agree on. - The deployment uses RFC 6929's **long extended types**, which add a `Flags` octet with a *More* bit and so give the protocol a generic, attribute-independent way to spread one value across several attributes. ## Why the shape is worth knowing On a ship's passenger wireless network, the reply that turns an accepted login into a usable session is a handful of these triples: an address, a filter name, a time limit. Each one is three fields, and the whole session profile is often under fifty octets. The shape only becomes visible when something outgrows it — a filter name longer than 253 characters, a vendor payload that must be chunked — and at that point the difference between "the protocol will handle it" and "the attribute definition must handle it" is the difference between a working deployment and a truncated value nobody notices until a session behaves oddly.