IP requests and registrations

This document has been updated to cover both static IP address and dynamic IP ranges.

Requests for assignment

Administration of static IP addresses and dynamic IP ranges within assigned subnets is handled via Information Systems & Technology's (IST) Maintain system.

Subnet registration

The following information about each IP subnet in the campus computer network is recorded in the Domain Name System (DNS) data.

   name.net   IN A      129.97.subnetnumber.0
              IN HINFO  "parent_subnetname router_name" "protocol_type"
              IN TXT    "ORGUNIT unit,subunit,group"
              IN TXT    "ADMIN uwuserid"
              IN TXT    "CONTACT uwuserid"
              IN TXT    "LOCATION list of buildings"
              IN TXT    "DATE yyyy-mm-dd"

There are various ways to derive the name that has been assigned to a subnet number by using a DNS query utility. For example, for subnet 129.97.128.0/24, a query for 129.97.128.0 will tell you that this is "uw.net.uwaterloo.ca". A query to display all of the DNS entry for that name will display the information shown above.

The purpose of the TXT records is described below.

Dynamic IP ranges

Dynamic IP ranges are added to subnets by the hostmaster, to provide dynamic IP addresses. Dynamic IP addresses are primarily intended for mobile devices, temporary equipment, occasional use devices, or for hosts which do not need a static IP address.

Dynamic IP ranges may be configured to allow any host, or only registered hosts:

  • any - provides a dynamic IP address to any host which requests one
  • registered - provides a dynamic IP address to a host only if the host has a static IP assignment on another subnet.

Dynamic IP ranges which permit any hosts may not be used to provide network service in public areas unless additional mechanisms are used to provide security and accountability (e.g. captive portal authentication, 802.1x authentication).

For network service in private areas (e.g. offices, meeting rooms), dynamic ranges may be configured to allow any hosts, with the use of additional security mechanisms being optional.

Static IP device registration

Static IP addresses are primarily intended for fixed equipment (e.g. servers, workstations, printers), that require regular and ongoing network access.

Information about each device in the campus network with a static IP address is recorded in Infoblox. There are several extensible attributes (EAs) that can be filled in for a host. Many are optional, some are not.

Extensible Attributes (EAs)

Required EAs

  • Policy 8 Classification The classification of the highest level of data which is stored on this host (or, in some circumstances, which might transit this host). Most machines will be Restricted, as passwords are often either stored intentionally (password files) or are cached locally (like Windows credentials).
  • Primary OU A dropdown box. If none seems to be appropriate, IST can possibly add a new OU, but this should be done in conjunction with Information Security Services (ISS), so that ISS can ensure they have the appropriate contact information for that OU.
  • Technical Contact This is the email address of the person (or people) who can either log in to the host in the event of a network event (security incident or otherwise) involving it, or who can authorise its removal from the network. It is highly recommended that this contact address be set to a mailing list or to a generic address so as to ensure continuity of service.

Optional EAs

Compliance Type might be set for hosts that are required to meet a certain level of compliance (statutory, contractually, or otherwise). Currently only PCI and FISMA types are accepted, although others may be added as required.

User and Secondary OU may be used if OUs desire, but IST does not make use of this information.

Deprecated EAs

Some EAs have been used in the past, but have since been deprecated. Business Contact used to be an escalation point if the Technical Contact was unreachable, but in practise many OUs simply set the BC to the same address as the TC. Prior documentation might have referred to the BC as the ADMIN, and the TC as the CONTACT. Any EA prefixed with LEGACY should not be considered reliable information any longer, and should not be used.