As in the subject/question above, I'm seeing a different value between FreeRadius' dictionary.rfc2865 and the actual published rfc2865. In the published RFC 2865, the text for the Service-Type value of 6 says "Administrative" whereas in the FreeRadius package, the default loaded dictionary.rfc2865 shows a text value of "Administrative-User". I'm wondering why there's a difference between the actual rfc and what's supposed to be rfc compliant in dictionary.rfc2865.
Used a perl module to apply 'Administrative' value to the Service-Type attribute - which should have translated to the numerical value of 6, but received an error of "perl: Failed to create pair - Unknown or invalid value". I expected it to work, since it was an attribute defined in the RFC, but - upon inspection - I see that the dictionary.rfc2865 is out of compliance with the actual RFC2865 - unless I'm looking at an outdated publication:
The very first commit of FreeRADIUS included Administrative-User for that attribute value. FreeRADIUS came out of the Cistron RADIUS server, which also used Administrative-User. Cistron RADIUS it seems took its dictionaries from Livingston RADIUS, the very first RADIUS server, which also (in the only version I can find) used Administrative-User.
So I think the question should likely be the other way around - why did the RFC use Administrative instead? All older versions of the published RFC are the same, and the value didn't exist at all in the draft from 1994. Mailing list discussions leading up to that draft had a rather different selection of values with Administrative not even yet on the list .
It seems fairly safe to say that FreeRADIUS uses the same value as has historically always been used in actual implementations, and for some reason the RFCs were defined differently. As with a lot of software, the value has never been changed as it would cause problems for all the existing configurations out there, for very little gain.