RFC6929 - support for 4 octets vendorId?
Hallo, RFC6929 states that it is recommended to support 4 octets for the vendorId field. When I try to test this using freeradius server , version V3.0.x I get the error : Errors reading dictionary: dict_init: /usr/local/share/freeradius/dictionary.alcatel.sr.ext[117]: dict_addvendor: Cannot handle vendor ID larger than 2^24 Is it not supported yet in freeradius version V3.0.x? Thanks, Kind regards, Katrien.
On 14 Dec 2015, at 04:03, Vereecke, Katrien (Katrien) <katrien.vereecke@alcatel-lucent.com> wrote:
Hallo,
RFC6929 states that it is recommended to support 4 octets for the vendorId field.
When I try to test this using freeradius server , version V3.0.x I get the error : Errors reading dictionary: dict_init: /usr/local/share/freeradius/dictionary.alcatel.sr.ext[117]: dict_addvendor: Cannot handle vendor ID larger than 2^24 Is it not supported yet in freeradius version V3.0.x?
No, because parts of the vendor ID field were overloaded unfortunately. This limitation was removed in v3.1.x and the full 32bits are available. This will not be backported, it was a 10,000+/- line change. v3.1.x also adds support for (theoretically) unlimited nesting depth, though it's capped at 24 for sanity. v3.0.x was limited to 4. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Dec 14, 2015, at 4:03 AM, Vereecke, Katrien (Katrien) <katrien.vereecke@alcatel-lucent.com> wrote:
RFC6929 states that it is recommended to support 4 octets for the vendorId field.
When I try to test this using freeradius server , version V3.0.x I get the error : Errors reading dictionary: dict_init: /usr/local/share/freeradius/dictionary.alcatel.sr.ext[117]: dict_addvendor: Cannot handle vendor ID larger than 2^24 Is it not supported yet in freeradius version V3.0.x?
Arran's reply answers this directly. I'll add another note. The highest IANA private enterprise number is currently 46935. FreeRADIUS was assigned 11344 in 2000 or so. So that's about 2000 numbers assigned per year. The PEC hasn't even broken 16 bits yet. I think it will be a *long* time before we need 24 bits. Mandating 32 bits is useful for "future proofing" the specs. But realistically, there is no need for it in my lifetime. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Vereecke, Katrien (Katrien)