Conflict in attribute value for RFC 2868 dictionary
Hi all, I am wondering why the dictionary.rfc2868 isn't conform with RFC 2868. For values of Tunnel-Medium-Type, RFC states: 1 IPv4 (IP version 4) 2 IPv6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 (POTS) 8 E.164 (SMDS, Frame Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress As dictionary file states: IP 1 X25 2 ATM 3 Frame-Relay 4 BBN-1822 5 IEEE-802 6 E.163 7 E.164 8 F.69 9 X.121 10 IPX 11 Appletalk 12 DecNet-IV 13 Banyan-Vines 14 E.164-NSAP 15 I think that the dictionary is broken, but updating it may have impact on existing deployements, using attribute values to set AVpairs. If required, I can post a patch. Regards, Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Geoffroy Arnoud wrote:
I am wondering why the dictionary.rfc2868 isn't conform with RFC 2868.
Weird. Looking at CVS, the dictionary was created before the RFC, so my suspicion is that it matches the drafts, but not the final document
I think that the dictionary is broken, but updating it may have impact on existing deployements, using attribute values to set AVpairs.
I think that's possible, but not likely. Only the numbers 2,3, and 4 are wrong. The higher numbers were added later, and are correct. So only people using X25, ATM, or Frame-Relay will be affected... except that the NASes likely use the correct numbers, so they won't be using the wrong values for 2..4.
If required, I can post a patch.
Please. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (2)
-
Alan DeKok -
Geoffroy Arnoud