[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADIUS Design Guidelines
Alan DeKok said:
"I have no objections to the guidelines permitting the definition of
new attributes that re-use existing formats, however awkward. The
practice should be discouraged, but not forbidden."
Question: what would you define as "existing formats"?
For example, the following compound attributes are described in
RFC 2865, 2868, 2869 and 3162. Note the similarity between
RFC 2869 ARAP-Features and RFC 3162 Framed-IPv6-Prefix.
===========================================================================
RFC 2865
Section 5.3 CHAP-Password
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Request Accept Reject Challenge # Attribute
0-1 0 0 0 3 CHAP-Password [Note 1]
RFC 2868
Attributes utilizing a one-octet tag field:
Tunnel-Type: tag + 3 octet value (Integer)
Tunnel-Medium-Type: tag + 3 octet value (Integer)
Tunnel-Client-Endpoint: tag + string (String)
Tunnel-Server-Endpoint: tag + string (String)
Tunnel-Password: tag + 2 octet salt + string (String)
Tunnel-Private-Group-ID: tag + string (String)
Tunnel-Assignment-ID: tag + string (String)
Tunnel-Preference: tag + 3 octet value (Integer)
Tunnel-Client-Auth-ID: tag + string (String)
Tunnel-Server-Auth-ID: tag + string (String)
Request Accept Reject Challenge Acct-Request # Attribute
0+ 0+ 0 0 0-1 64 Tunnel-Type
0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type
0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint
0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint
0 0+ 0 0 0 69 Tunnel-Password
0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID
0 0+ 0 0 0-1 82 Tunnel-Assignment-ID
0+ 0+ 0 0 0 83 Tunnel-Preference
0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID
0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID
RFC 2869
Section 5.5 ARAP-Features
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request Accept Reject Challenge # Attribute
0 0-1 0 0-1 71 ARAP-Features
RFC 3162
2.3 Framed-IPv6-Prefix
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request Accept Reject Challenge Accounting # Attribute
Request
0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>