Subject: Re: (radius) IPv6

From: Alan DeKok <[email-masked]>
Date: Thu, 01 Jun 2000 16:10:59 -0400

"[email-masked]" <[email-masked]> wrote:

> Putting aside the core dump, creating new Attributes with a new
> Type, call it IPv6-Address, will NOT work with non-IPv6 aware
> routers. At best, they will be handled as opaque objects.

  Yes.  Or, they can be handled as 'string', which will work with most
servers.

  This is an aside, but I'm really disappointed that the original
RADIUS protocol didn't define an 'octets' data type, where the data is
input/output as hex strings.  The 'string' attribute is nice, but
there are too many different implementation-specific modes of
behaviour for non-ASCII 'string' data.

> However, if the NAS-IP-Address-V6 attribute (or whatever it ends up
> being called) is not recognized by the non-v6 server, the request
> will be dropped.

  Why?  Servers can get hordes of attributes that they don't
understand.  Some NAS vendors pollute the low attribute numbers with
their own VSA's.  Some RADIUS administrators don't update their
dictionaries with NAS vendor VSA's.

  In either case, the server can generally ignore what it doesn't
understand, and continue processing the parts of the request it does
understand.  (i.e. Access-Request, User-Name, Password).

  I think that few, if any, RADIUS servers drop requests which contain
an attribute that they don't understand.

> Certainly one could request that the proxy be responsible for
> address translation, but this removes the NAS' original address,
> which is required by most ISPs.

  Agreed, we shouldn't go down that path.

> I would argue that replacing the foundation would not only be MUCH
> more solid, but it would design to withstand eathquakes that
> register 8 on the richter scale, water proof, etc.

  Then it's DIAMETER, not RADIUS.  And for full confidence, it would
greatly help to have a reference implementation that people
interoperate with or ELSE.

  One of the reasons RADIUS is so shaky is that most people did their
own thing on implementation.  The protocol is *nearly* interoperable
across implementations, but it isn't *completely* interoperable.

>  Certainly, replacing the foundation with cardboard and tape is not
> an option, and I am not sure that anyone was proposing doing that.

  There was the suggestion for dropping IPv6 addresses into IPv4
RADIUS attributes, and having the IPv6 recognition via the different
length.  I'd like to squash that with loud cries of "please, no!"

  Alan DeKok.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 01 Jun 2000 16:40:16 -0400

Bill Webb <[email-masked]> wrote:
> Well, given that certain unnamed NAS vendors are running out of Attribute
> numbers (yes, even using VSA's), I'd hate to see an extra 5-10 attributes
> identical to existing attributes except for having IPv6 addresses.

  That is a problem, definitely.

> How about having an attribute that when sent to a radius server says
> if it will accept IPv4, or IPv6 addresses (or both) and when sent
> from the radius server to the NAS says that the NAS can assume IP
> addresses are IPv4, IPv6, or it should check the length of IP
> addresses to figure it out. 

  RADIUS as a stateful protocol?  The ground shakes beneath me! :)

  Another possible idea is over-loading of the Vendor-ID in the VSA.
My reading of the network management private enterprise code documents
shows that this space is very sparsely populated.  It should be
possible to change the 32-bit Vendor-Id to:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Vendor-Attribute-Sub-Space   |            Vendor-Id          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Off of the top of my head, I can't think of many ways that this
would break existing RADIUS implementations.  You'd just have vendors
'lucent-1', 'lucent-2', etc.

  Alan DeKok.
-