RE: Proposed Resolution to Issue 87 (RADIUS MIB Updates)

["Nelson, David" <dnelson@enterasys.com>]

> Question:  How does this work for NASes that support both IPv4 and
IPv6?
> Which objects would such devices use?

Here's some additional advice on this question, from David Harrington,
MIB Doctor.  Below is a portion of Dave's reply to my informal query, of
today, on how to handle the details of this issue.  This does not
constitute formal MIB Doctor review.

<quote>

I think you would also need to specify that an implementation MUST NOT
have different addresses in radiusAuthServerAddress [old object] and
radiusAuthServerInetAddress [new object]. It would probably be
acceptable to have an IPv6-formatted IPv4 address in the InetAddress and
the IPv4 format of the same address in the IPAddress object.

Note from RFC3291:
   "A single host system may be configured with multiple addresses (IPv4
   or IPv6), and possibly with multiple DNS names.  Thus it is possible
   for a single host system to be accessible by multiple
   InetAddressType/InetAddress pairs.

   If this could be an implementation or usage issue, the DESCRIPTION
   clause of the relevant objects must fully describe which address is
   reported in a given InetAddressType/InetAddress pair."

So it is possible that there is an IPv6 InetAddress, and
radiusAuthServerAddress COULD be used to store the IPv4 address of the
same server; I feel uneasy about doing this, because it would tend to
prolong the use of the deprecated radiusAuthServerAddress object, and
would have forward-compatibility issues for applications that only
supported the InetAddress objects, and only supported IPv4
communications; it could not retrieve the IPv4 address of the server.  I
would prefer to see one row for the IPv6 InetAddress, and another row
for the IPv4 InetAddress.

In any case, the MIB module (when separated from the surrounding text)
should be clear on how this should be handled.

</quote>

So, I guess we need to clarify the issues around multi-version IP stacks
on RADIUS servers (and clients) and include that guidance in the
relevant DESCRIPTION clauses of the MIB modules.

I would interpret this advice to suggest that a dual-stack RADIUS server
would need to have (at least) two row entries in the client's table of
servers, such that the IPv4 address was never confused with the IPv6
address.  Bernard has already indicated that robust client
implementations might not want to fail over from the IPv6 address of one
server host to the IPv4 address of the same host.

Dave H. also recommends:

<quote>

Write a compliance clause that calls for use of the new object, not the
old. Deal with backwards compatibility by deprecating the old compliance
clause and add a new compliance clause that includes the new address
objects and does not include the deprecated object.  Implementations can
always support both compliance clauses if they choose.

</quote>

If there are no objections, I will proceed to revise the drafts based on
the collected MIB Doctor suggestions.

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