Problem: Current IPAM solution for Shands Healthcare and the University of Florida Health Science
Center must be expanded or replaced to meet changing network configuration, security, and reporting
needs of Shands and the University of Florida. Final solution may involve either upgrading the design of
the largely proprietary system already in place, purchasing a turnkey solution from a commercial vendor, or
some combination of the two. The purpose of this paper is to describe our diverse environment accurately
with a prioritization of the requirements for an extensible IPAM system.
Network Description (Shands and the UF Health Science Center)
Shands currently manages over 230 networks of varying sizes between all Shands facilities and the
University of Florida Health Science Center (UFHSC). Shands is in the process of migrating off of the
eight remaining 18.104.22.168/24 networks that will be returned to the University of Florida. After that
point, the enterprise and its customers will be entirely on 159.178/16 and the private networks 10.4/16, and
10.14/16. In addition to the normal data networks, we also provide separate geographically based VLANs
for wireless communication and Voice Over IP (VOIP) devices.
The UFHSC is an academic health center composed of six health-related colleges (Medicine, Nursing,
Pharmacy, Dentistry, Public Health, and Veterinary Medicine) on a single contiguous campus.
Information Systems for each of these colleges is further separated into additional distinct, often
autonomous, groups. Though closely affiliated with Shands Healthcare and its mission, the reporting,
security, and network policies and practices of these UFHSC groups may very significantly from those of
Shands. A key example of this is the use of different and non-cooperative authentication and authorization
systems for Shands and the UFHSC.
The Shands enterprise BIND and DHCP servers are each using ISC (Internet Software Consortium)
software. DNS services are provided by a primary nameserver, ns1.shands.ufl.edu, and a secondary slave
nameserver, at ns2.shands.ufl.edu. DHCP and BOOTP services are provided by a single server,
dhcp.shands.org. The leases and configuration files of this server are copied via rsync to a manual failover
server, dhcp2.shands.ufl.edu, every 3 minutes. Should the primary fail, the backup could be renamed and
the DHCP server software started w/the last configuration and leases file available (never more than
Although Shands DNS and BOOTP/DHCP services are provided for UFHSC administrators as part of the
contractual agreement between the two groups, there is no requirement that individual UFHSC departments
must use those services. Dependent on their needs and resources, many groups decide to run their own
services, provided they remain good network neighbors, causing no disruption of services for others.
Current IPAM environment
Networks shared by Shands and the UFHSC are provided name service and roaming DHCP service from
separate DNS and DHCP servers. Dynamic DNS (DDNS) is not supported. All devices unknown to the
Shands servers are denied network configuration information, so no devices can simply acquire an IP
address by connecting to an active network port within Shands or the UFHSC.
Authorized Shands and UF department and college administrators request IP addresses for their devices by
registering them with Shands via a web-based form. After providing the requisite information for the
device, the information is stored in a database and the request fulfilled. If the request is for a static IP
address, the information is automatically emailed to the role mailbox, IPAdmin@shands.ufl.edu.
Normally, within two business days, the IP administrator will manually assign an IP address for the device
and email the address and network information back to the requestor. If the manual address requires
BOOTP service, IPAdmin will add it to the Shands BOOTP server as a fixed-address assignment for the
given address and restart the DHCP server.
If the request is for a dynamically allocated IP address, after a successful submission, the device
information is written to an interim registration file. Every 4 minutes, the latest registrations are added to
the primary DHCP server configuration and the server restarted. At this point, the device can acquire an IP
address on any Shands or UFHSC network managed by Shands.
With few exceptions, parameters passed via DHCP are global and not network or registrant specific. They
Gateway or router interface
Default domain (shands.ufl.edu)
SLP Directory Agents
SLP Service Scope
Cisco VOIP Call Manager
There are essentially three types of device registration request:
- static, no BOOTP
- static, BOOTP services requested
- dynamic, via Shands DHCP
LAN administrators in Shands and the UFHSC may request authorization to register devices for their
department or group by emailing a request to IPAdmin@shands.ufl.edu. The Shands IP administrator
confirms w/the primary technical contact for the department or college to ensure this person has permission
to register devices for that group. The list of primary technical contacts is currently maintained at
Authorization information is stored in a local database while authentication is based on the University of
Florida’s GataorLink service (LDAP with a Kerberos backend). Using PERL modules developed by the
University, user authentication is performed and a session cookie is created on the client’s browser for his
connection to the Shands Network Services web pages. After a prescribed period of inactivity (15
minutes), the user is required to reauthenticate to continue using the services.
For static assignments, requiring no BOOTP services, the IP administrator simply finds an unused IP
address, as marked in the comments field of the network’s reverse zone file, and assigns it to the device.
Device registrations must contain the exact physical location (facility, bldg, floor, room) of the device to
ensure that the allocation is made from the proper network. Documentation of the registration (dept,
location, HW address) is made in the reverse zone file comment field and the assigned IP address is sent to
the email address of the registrant, or to the email address of the main technical contact for his department
Static allocations requiring BOOTP services, usually for printers or print servers, follow the procedure
outlined above for static allocations. After that, a fixed address device stanza is created for them in the
DHCP server configuration and the server is restarted. From that point, any broadcasts from that device on
that network should receive the allocated IP address.
Dynamic allocations require no manual intervention. A receipt email of the registration is sent to the
registrant, if possible, and a copy is also sent to IPAdmin. Additionally, a device registration record is
created in a separate database.
Other DNS / DHCP administration tasks
In addition to registering devices for network communication, the Shands Network Services webpage
(http://net-services.shands.ufl.edu) provides these tools for authorized network systems administrators:
■ Query device registration and current DHCP address leases for either IP address or HW address. Used
to help determine identity of devices and department or group responsible for the device.
■ Query status of DHCP address pools for each network. Will display number of active leases and number
of unused addresses remaining to help administrators confirm there are available IP addresses on any
■ List DNS resource records (RRs) for any domain for which the Shands nameservers are authoritative.
■ View/search nameserver zone records for comments. Helps admins confirm statically allocated IP
addresses belong to their department or group.
Requirements and Needs:
A consolidated DNS and DHCP IPAM solution that provides
- roaming access for dynamically allocated devices
- DNS name consistency across networks
- multiple management classes for providing different network configuration parameters based on
device type and registrant
- graphical management system for easy administration and reporting
- support for distributed management with varying levels of access and control
1. Secure Dynamic DNS (DDNS) so that devices may maintain the same DNS name regardless of their
physical location or IP address.
2. DHCP failover configurations for high availability and redundancy.
3. Native use of Internet Software Consortium (ISC) BIND and DHCP, including capacity for updating
the code without vendor intervention
4. Support for BIND views, caching only nameservers, and IPV6.
5. Support for multiple DHCP management classes, and current client options
6. Quick and proactive determination of rogue devices providing unauthorized or incorrectly configured
■ Structured device registration system
1. Departmental groups and individual authorization based on UF and Shands Security Units.
Specifically, each Unit ISA (Information Security Administrator) would be responsible for delegating
authority for other administrators within that Unit.
2. Ability for Unit ISA to set the global parameters to be passed to devices within his/her group as part of
a normal DHCP communication (e.g., NETBIOS servers, SLP directory agents, Active Directory
configuration, DNS servers, default domain, PXE servers, etc.)
3. Option of authentication sources: i.e., GatorLink, Kerberos, UFAD for UF staff, Shands OID,
ShandsAD, Radius for Shands staff
4. Some administrators able to “proxy” register devices for many different groups; one example might be
a HealthNet tech registering laptop NICs for students in different colleges.
5. Security administrators given extra authority in order to delete or disable registrations, query lease
6. All administrators able to query, edit, and delete the device registrations for the groups for whom they
have registration authority.
7. “Age” device registrations. After some period of device inactivity on the network, warn the
department administrator and then remove the device from the registration database and server
8. An exception list of HW addresses that would be checked before a successful registration is completed.
If the device being registered is on this list, the registration would be denied. Examples of devices that
might be placed on this list would include stolen devices, incorrectly configured or insecure devices.
9. Fields and attributes required for device registration:
- Registration expiration (remove device after expiry date; if empty, don’t remove)
- Unit or group responsible for the device (an administrator may be authorized to register devices
for several groups)
- Requested DNS name (if DDNS, only)
- Allocation type (static, static w/BOOTP, dynamic)
- Hardware address
- Client name
- Device type
- Device operating system
- Name of primary user or group
- Serial number of device
- Other comments
■ Reporting and Analysis
1. Ability to query device registrations and address leases, real-time and historically.
2. Ability to trend static and dynamic address use and alert when address pools are reaching a critical
3. Alert to potential DNS zone and domain resolution issues
Questions: (some for us, some for vendor)
■ How to maintain accurate device inventory information?
■ What will be the process to maintain Units and Unit ISAs and ISMs?
■ Can large lists of decommissioned devices be removed or changed as a group?
■ What kind of reporting and trending tools are available?
■ What are our plans for future NAC (Network Access Control)? Where in our environment?
UF Department of Surgery (College of Medicine) receives a new desktop and wants it to receive an IP
address dynamically anywhere w/in Shands or the University of Florida Health Center. An
administrator for the department, who is also an authorized administrator for Pediatrics, connects to the
device registration system and authenticates against the University of Florida LDAP server. After
authenticating successfully and choosing to add a device, he is presented w/a screen requesting the
Address allocation required (DHCP, static BOOTP, static manually configured)
Registration unit (in this case, a pull-down menu allows user to choose between Surgery and
Pediatrics to assign the responsibility of this device)
Device type (server, desktop, printer, laptop, pda or other portable, clinical device, environmental
Device location (required for static IP address requests)
DNS name required (if static IP address requested)
Associated user information, if applicable. If available, a user name or email address.
Network zone for device (closed, protected, open)
Registration expiration (never, two weeks, four weeks, etc)
Upon submission, static IP address requests are emailed to a role-based account for manual allocation.
For both static and dynamic address allocation, the device HW address provided is checked against the
current database of registered devices. If the device does not already exist, the registration
information is added to the database, along with the date of registration, registrant unit (in this case
Surgery), and registrant login name.
The devices to be configured dynamically via DHCP are added to the vendor class corresponding to
the Department of Surgery in the DHCP server. Within the scope of that class, configuration variables
(e.g. SLP servers, NTP servers, DNS servers, default domain, etc) unique to Surgery are defined.
For each unit, there may be several vendor classes defined within the DHCP server; e.g. Surgery-
Mobile-Open, Pediatrics-Fixed-protected. These vendor classes will identify the unit, requested lease
period (likely a shorter lease period for mobile devices), and the security zone required for the device.
Device Registration Modifications
An authorized administrator wishes to move a registered device from an open network zone to a
protected (filtered) security zone. After authenticating, he searches his department’s list of registered
devices (sorted by HW address or registration date). After selecting the device he wishes to change,
the initial registration screen is provided w/all fields modifiable except for the HW address. He makes
the necessary change and resubmits the new information. Device database information changed and
the device is moved from existing security zone class in DHCP server to new security zone class.
A device was compromised last night and began attacking other network devices. We have an IP
address and need to find the identity of the device that had that address at that point in time and turn it
off, contacting the responsible department when we do.
Statically allocated addresses on a network are almost depleted. Need a trending report on a given
DHCP address range to determine the maximum number of addresses used and how use is changing
over time, so that we can reclaim addresses for static assignment.
A given DHCP address pool becomes 90% utilized. Email alerts (incl to a paging gateway) are sent to
the IPAM administrator’s mailbox to notify them that it may be necessary to add more address space to
If devices are no longer active on our networks, we wish to remove them from the database of devices
that may acquire IP addresses dynamically. Create a report of all registered devices that have not
acquired an address lease w/in the last six months.
Changes are made to an existing registered device. A record of the change, incl the date and the
registrant making the change, is emailed to the unit’s primary administrator (ISM) and the registrant.
Delegated Authority and Roles
The role of central IPAM administrator creates one administrator for each registrant group
(corresponds to the security manager, or ISM, already formally defined w/in the University of Florida
computer environment). This ISM can define DHCP allocated parameters for all devices acquiring IP
Each ISM creates users capable of adding, deleting, modifying, querying device registrations for his or
her unit only (e.g., Surgery, Pediatrics, etc). Do not have the ability to change the group’s defined
DHCP allocated parameters.
Security administrators for either Shands or the UFHSC have the ability to query, remove, or edit
devices for any unit or group w/in the enterprise.
IP “guest” users have the capability to perform certain non-device specific queries and reports.