RE: Revised RADIUS MIBs I-Ds

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

> Is it correct to assume that the revised submissions address all open
> issues?

The only open RADEXT Issue on the MIBs is 87, but it consists of
multiple parts.  I believe the -01 versions address all the sub-issues
of Issue 87, with the possible exception of this one:
 
"Certainly there will be two different shared secret entries, one with
the
IPv6 address/shared secret and another with the IPv4 address/shared
secret.  Hopefully the RADIUS client will be a bit more intelligent in
not
doing things like failing over from the IPv4 address to the IPv6 address
when the RADIUS server doesn't answer.

However, this does bring up another issue, which is how the RADIUS
server
identifies the  NAS if it is more than one hop away.  NASes can have
more
than one IPv6 address and this makes it possible for a NAS to put a
linkscope address in the NAS-IPv6-Address field.  If the proxy is on the
same link as the RADIUS client, the RADIUS server could receive a packet
with a  NAS-IPv6-Address as a linklocal address.

The same issue can occur with IPv4 Link Local, and of course a NAS can
have more than one IPv4 and IPv6 address.

One potential suggestion might be to use the NAS-Identifier attribute in
such a situation so as to avoid having to configure the RADIUS server
with
all potential NAS addresses."

It is not clear that this is a MIB issue per se.  If the WG decides on a
solution to the issue of multi-homed, multi-version IP stacks, and the
global vs. local link scope issue, there might or might not be
implications to the MIBs.  I think that further discussion, and a WG
consensus is required.  This would seem to be fodder for the Issues and
Fixes draft.


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