Re: IPv6

[Alan DeKok <aland@deployingradius.com>]

Wojciech Dec (wdec) wrote:
> Sure, that's fair. The point I was making is that with the string
> definition above, passing an IPv6 prefix (or anything else up to 255
> bytes really) did not require any new data-type and in terms of say the
> IPv6-prefix.

  From the design guidelines document:

   If the RADIUS Server simply passes the contents of an attribute to
   some non-RADIUS portion of the network, then the data is opaque, and
   SHOULD be defined to be of type String.  A concrete way of judging
   this requirement is whether or not the attribute definition in the
   RADIUS document contains delineated fields for sub-parts of the data.
   If those fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.

> Furthermore rfc2868 provides plenty of precedent for
> structured attributes with "String", if one wants, eg Tunnel-Password.

  From the design guidelines document:

   As can be seen in Appendix B, most of the existing complex attributes
   involve authentication or security functionality.  Supporting this
   functionality requires code changes on both the RADIUS client and
   server, regardless of the attribute format.  As a result, in most
   cases, the use of complex attributes to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.


  All of these arguments are familiar, and have been hashed through in
detail in this WG.  There are good reasons for the current behavior.
The document explains that *changes* in behavior need good reasons, too.

  Alan DeKok.

--
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/>