Subject: (radius) NAS-Port-Id and Framed-IP-Pool

From: Carl Rigney <[email-masked]>
Date: Tue, 2 Mar 1999 00:17:15 -0800 (PST)

In reviewing the archives, the two most-asked-for attributes not
already granted are a string alternative to NAS-Port, for NASes that
cannot conveniently number their interfaces, and a Framed-IP-Pool string
to allow multiple assigned address pools.

Do people still think these would be useful, and if so, would they
be worth adding to the Extensions draft?  Feel free to email me directly
or if you prefer, to the mailing list.

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

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 2 Mar 1999 10:59:22 -0500

Carl Rigney writes...

> <snip> and a Framed-IP-Pool string

I guess I missed this one.  Could someone please elaborate?
I presume the Framed-IP-Pool (or pools) would be assigned to a
RADIUS user, in an Access-Accept.  I understand well how a NAS
might use a pool of IP addresses administered in the NAS for
assignment to PPP or SLIP dial-up connections.  Unless the "user"
is the NAS itself or the dial-up connection is from another NAS
or a router, I'm confused as to how the user is going to utilize
a pool of addresses.

Assuming that the attribute is useful, then I wonder if a string
is the right way to encode it.  I can think of several ways to
describe one or more ranges or collections of IP addresses using
ASCII (or UTF-8) strings, each of which would be parsed quite
differently in software.  This naturally leads to poor 
interoperability.

I have no problems using strings for names and for opaque data
structures.  I really don't like using strings for transparent data
structures unless the encoding format is unambiguously spelled out
in the RFC.

Regards,

Dave

David B. Nelson                          Cabletron Systems, Inc.
Software Engineer V                      50 Minuteman Road
(978) 684-1330                           Andover, MA 01810

-

---

From: "Mun, Mike" <[email-masked]>
Date: Tue, 2 Mar 1999 11:55:08 -0500

Here is what I think a good reason to have Framed-IP-Pool:

Some Radius server has resource management for IP addresses which can be
full at a time. A NAS can send Framed-IP-Pool as a hint to the server as
addition available addresses, the server can response back with these
Framed-IP-Pool instead of access reject. If the NAS receives a
Framed-IP-Pool in an access accept, it then selects framed-ip-address from
its pool. There are the reasons some user wants to use Framed-IP-Address
from a particular pool. Access-challenge can give a user selection of
server's pool or a NAS pool by user's profile configuration. 

Mike
	----------
	From:  Nelson, David [SMTP:[email-masked]]
	Sent:  Tuesday, March 02, 1999 10:59 AM
	To:  'Carl Rigney'; [email-masked]
	Subject:  RE: (radius) NAS-Port-Id and Framed-IP-Pool

	Carl Rigney writes...

	Regards,

	Dave

	-

---

From: "Mun, Mike" <[email-masked]>
Date: Wed, 3 Mar 1999 11:08:49 -0500

That is in the single domain. What I talk about is in case of roaming users
and proxy to different domain.

Mike

	----------
	From:  Dave Mitton [SMTP:[email-masked]]
	Sent:  Wednesday, March 03, 1999 10:42 AM
	To:  Mun, Mike; Nelson, David; Steven P. Crain
	Cc:  [email-masked]'
	Subject:  RE: (radius) NAS-Port-Id and Framed-IP-Pool

	That's silly.

	From the server's point of view, you should know if you configured
an IP
	pool on that NAS and provision the use of it accordingly.  If there
is no
	pool, then ignore it.

	If you need some help in remembering such things, your server
	implementation can certainly organize it's data internally.  Many of
the
	leading RADIUS servers now have internal "attributes" which are used
to
	trigger appropriate behaviors.  The NAS never sees them on the wire.

	The semantics of Framed-IP-Address already allow for the NAS to
assign an
	address given the magic value of 255.255.255.254.  Your proposal is
redundant.

	Adding another attribute just allows the Server to select from
multiple
	potential pools.
	I would even go so far as to say that it could be used in a DHCP
request
	from the NAS, to a DHCP server that uses "Class" arguments for
address
	selection.

		Dave.

	At 10:05 AM 3/3/99 -0500, Mun, Mike wrote:
	>>From AS server's point of view, I think Framed-IP-Pool should be
an integer
	>value: 
	>0	NAS pool available
	>1	NAS pool only
	>If this attribute is not present, then NAS pool is not available.
	>Mike
	>
	>
	>	----------
	>	From:  Steven P. Crain [SMTP:[email-masked]]
	>	Sent:  Tuesday, March 02, 1999 3:40 PM
	>	To:  Nelson, David
	>	Cc:  'Dave Mitton'; [email-masked]'
	>	On Tue, 2 Mar 1999, Nelson, David wrote:
	>
	>	> Of course, I've always been left a little unsatisfied by
the "some
	>
	>	> mechanism outside the scope of RADIUS" business.  It
doesn't do
	>much to
	>	> promote interoperability.  However, since we have already
cast the
	>die
	>	> in terms of the Filter-ID usage, I guess Framed-IP-Pool
would be
	>OK on
	>	> that basis.
	>
	>	Maybe we should call it Framed-IP-Pool-ID for consistency.
	>
	>	-- 
	>	Steven P. Crain, Development
	>	http://www.shore.net/~scrain
	>	Shore.Net: Local Ties... World Class Connections
	>
	>	-
	>Attachment Converted: "L:\Eudora\attachments\RE (radius)
NAS-Port-Id and Fr1"
	---------------------------------------------------------------
	David Mitton			  		ESN: 248-4570
	Consulting Engineer, Nortel Networks	978-916-4570 Direct
	Carrier Packet Solutions, I&SP Netwks	978-916-4789 FAX
	Billerica, MA 01821
[email-masked]
	-
	To unsubscribe, email [email-masked]' with
	'unsubscribe ietf-radius' in the body of the message.