OIT Wireless Service allows University faculty, staff, and students to connect a computer to the campus data network via a Wireless (radio) interface.
The service is available in nearly all University buildings on the main campus; see OIT's Wireless Coverage Map.
This document describes the service and provides information about how to connect to the service. It also explains how to register Wireless computers and interfaces in the Princeton University Host Database.
OIT Wireless Service is intended to be available only to devices registered in the Princeton University Host Database. A different service, Temporary Visitor Wireless Network Access (TVWNA), provides short-term Internet connectivity to unregistered wireless devices visiting the campus network.
Despite its convenience and rapidly growing popularity, wireless service is very unlikely to provide you with with the same performance, consistency, or reliability as wired Ethernet service in the forseeable future. OIT's view is that wireless service complements wired service; it is not a substitute. It is best to view OIT Wireless Service as a convenience network, not the University's primary network service.
Some University departments and individuals choose to construct their own wireless networks (e.g. by attaching their own Wireless Access Points to the campus network). This document does not describe the operation of those private wireless networks; they do not operate the same as OIT Wireless Service. If you choose to use one of those private wireless networks, contact the department or individual responsible for operating it if you need information. (If you are constructing such a private wireless network, be sure to see Connecting a Private Wireless Access Point to the Campus Network.)
To be eligible for OIT Wireless Service, the device must meet the following requirements:
As access to OIT Wireless Service is restricted based upon hardware address, the hardware address registered must be accurate.
Within the Host Database entry, there must be an IP address allocated to the interface you wish to use with OIT Wireless Service. It doesn't matter what the IP address is (the device's network interface will use a different IP address while connected via OIT Wireless Service), but there must be some IP address allocated.
Similarly, workstations that operate as wireless bridges or repeaters are not suitable for use with OIT Wireless Service.
OIT Wireless Service is not provided to devices registered in the Host Database with an ENTRY-TYPE of NAT, HUB, BRIDGE, ROUTER, or COMMUNICATIONS-SERVER.
Documentation describing the requirements and behavior of that NAT service and that specialized DHCP service is not presently available.
Because wireless networking technology is changing rapidly, and because of the special security challenges presented by wireless networking, it is possible these requirements will be revised in the future.
All the OIT Wireless Access Points are configured to provide a wireless network with the network name: puwireless. The network name is sometimes referred to as the SSID (Service Set Identity).
Any wireless client you wish to use with OIT Wireless Service should be configured to connect specifically to the network name puwireless.
We strongly advise against the alternative, of configuring your client to connect to "ANY" wireless network it finds; some client software may describe this as "using the broadcast SSID (Service Set Identity)." There are many private wireless networks throughout campus; allowing your device to try to connect to "ANY" network it overhears would cause your device to sometimes connect to some of them, instead of OIT Wireless Service. That will lead to a variety of difficulties for the wireless client. It will also cause your client to try sometimes to connect to puvisitor networks; attempting to do so will interfere with your device's ability to connect to the puwireless networks, as described below.
Be sure your device is not configured to try to connect to any wireless network with a name that starts with puvisitor. Those networks are part of Temporary Visitor Wireless Network Access (TVWNA). A device that tries to connect to TVWNA and is not permitted to connect (because it is not eligible for TVWNA) will be unable to connect to OIT Wireless Service for two minutes. If your device periodically retries to connect to TVWNA, it will keep preventing itself from connecting to OIT Wireless Service. So if your device was previously configured to connect to any puvisitor network(s) and still remembers those network(s), reconfigure your device to "forget" those network(s).
Clients that can support Wired Equivalent Privacy (WEP) or Wireless Protected Access (WPA, WPA2) should disable these when connecting to OIT Wireless Service. (Some client software may call these settings "encryption.") OIT's service does not provide WEP, WPA, or WPA2.
Clients that can support 802.1x authentication should disable this when connecting to OIT Wireless Service. OIT's service does not currently use 802.1x.
We use 802.11 "open" authentication, not 802.11 "shared" authentication.
OIT Wireless Service service supports moving from one Wireless Access Point's coverage area to another overlapping coverage area without restarting the computer.
Reconfiguration of the computer is not required.
Our service is intended to provide service to clients which support a number of the IEEE 802.11 standards.
The basis of our service is the IEEE 802.11g standard, and our service includes backward compatibility for 802.11b. All locations where our service is installed support 802.11g and 802.11b clients. 802.11b and 802.11g services always operate in the 2.4 GHz frequency range.
Our 802.11b service supports data rates of 5.5 and 11 Mbps. Our 802.11g service supports data rates of 5.5, 6, 9, 11, 12, 18, 24, 36, 48, and 54 Mbps.
Our 802.11b and 802.11g services do not support data rates of 1 and 2 Mbps, because clients communicating so slowly (either due to poor signal or lack of support for 802.11b) would monopolize the available bandwidth, leaving little for faster clients.
We do not support clients that speak only the original version of IEEE 802.11 (no letter after the '11'). That's the specification that predated 802.11b, and also operated in the 2.4 GHz frequency range. Those clients only support data rates of 1 and 2 Mbps, neither of which we support.
Some vendors sold 802.11g equipment before that standard was finalized in November 2001; such equipment was based on earlier drafts of the standard. Some of these early 802.11g devices may experience compatibility problems both with 802.11b networks, and with other vendor's 802.11g devices. Some 802.11g devices that do not comply the final version of the 802.11g standard may even interfere with surrounding 802.11b networks. If you have an 802.11g device, contact the vendor for updates to bring it into full compliance with the final version of the 802.11g standard. If you have difficulty using an 802.11g device, a workaround may be to reconfigure it to limit itself to 802.11b.
We began upgrading our service in 2010 to add support for IEEE 802.11a service. In locations that have been upgraded, in addition to the existing 802.11b and 802.11g service, we also provide 802.11a service. By September 2015 this upgrade had been completed in all of the undergraduate dormitory buildings, the Graduate College, Lawrence Apartments, and 86 academic and administrative buildings (including all of the largest or most-populated ones). By the end of Summer 2016, we expect to finish upgrading the remaining academic and administrative biuldings and the eating clubs.
802.11a service operates solely in the 5 Ghz frequency range.
In those locations that have been upgraded, the 802.11a service makes use of channels throughout the set permitted in the 5 GHz range in our regulatory domain as of late 2010. (2010 was the year in which we began providing any service in the 5 GHz frequency range.) Those 5 GHz channels are: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 136, 140, 149, 153, 157, and 161. Clients with older 5 GHz wireless interfaces may support only a subset of those channels. As a result, such older wireless clients will not always be able to "hear" our 5 GHz service even in the areas where the service is available. We use many of the 5 GHz channels (instead of only the "lowest common denominator" set supported by the oldest 5 GHz clients) to allow us to provide the maximum bandwidth for modern 5 GHz clients. Older clients that can't hear the newer 5 GHz channels will still be able to use our 2.4 GHz services; the 2.4 GHz services remain available everywhere we provide wireless service; this is one reason that every client should continue to support 2.4 GHz.
We began upgrading our service in 2010 to add support for IEEE 802.11n service. In locations that have been upgraded, in addition to the existing 802.11b and 802.11g service, we also provide 802.11n service. By September 2015 this upgrade had been completed in all of the undergraduate dormitory buildings, the Graduate College, Lawrence Apartments, and 86 academic and administrative buildings (including all of the largest or most-populated ones). By the end of Summer 2016, we expect to finish upgrading the remaining academic and administrative biuldings and the eating clubs.
802.11n service operates in both the 2.4 Ghz frequency range (the same range used by 802.11b and 802.11g) and in the 5 Ghz frequency range (the same range used by 802.11a).
In those locations that have been upgraded, the 802.11n service in the 5 GHz frequency range makes use of channels throughout the set permitted in the 5 GHz range in our regulatory domain as of late 2010. (2010 was the year in which we began providing any service in the 5 GHz frequency range.) Those 5 GHz channels are: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 136, 140, 149, 153, 157, and 161. Clients with older 5 GHz wireless interfaces may support only a subset of those channels. As a result, such older 5 GHz wireless clients will not always be able to "hear" our 5 GHz service even in the areas where the service is available. We use many of the 5 GHz channels (instead of only the "lowest common denominator" set supported by the oldest 5 GHz clients) to allow us to provide the maximum bandwidth for modern 5 GHz clients. Older clients that can't hear the newer 5 GHz channels will still be able to use our 2.4 Ghz services; the 802.11b and 802.11g 2.4 GHz services remain available everywhere we provide wireless service, and the 802.11n 2.4 Ghz service is available in those locations upgraded to add 802.11n support. This is one reason that every client should continue to support 2.4 Ghz.
Most (if not all) 802.11n equipment available through mid-2012 is based upon drafts of the 802.11n specification, rather than the final published specification. Our 802.11n service is presently based on draft 2 of the IEEE 802.11n specification. It is possible the behavior of our 802.11n service will evolve as vendors release updates. You may find that you need to update your client's wireless software to work with (or continue to work with) our 802.11n service.
We began upgrading our service in 2014 to add support for IEEE 802.11ac service. In locations that have been upgraded, in addition to the existing 802.11b, 802.11g, and 802.11n service, we also provide 802.11ac service. By September 2015 this upgrade had been completed in 26 academic and administrative buildings. During the 2015-2016 academic year and Summer 2016 we expect to upgrade additional academic/administrative buildings and the eating clubs.
802.11ac service operates in the 5 Ghz frequency range (the same range used by 802.11a and one of the same ranges used by 802.11n).
In those locations that have been upgraded, the 802.11ac service makes use of channels throughout the set permitted in the 5 GHz range in our regulatory domain as of late 2010. (2010 was the year in which we began providing any service in the 5 GHz frequency range.) Those 5 GHz channels are: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 136, 140, 149, 153, 157, and 161. Clients with older 5 GHz wireless interfaces may support only a subset of those channels. As a result, such older 5 GHz wireless clients will not always be able to "hear" our 5 GHz service even in the areas where the service is available. We use many of the 5 GHz channels (instead of only the "lowest common denominator" set supported by the oldest 5 GHz clients) to allow us to provide the maximum bandwidth for modern 5 GHz clients. Older clients that can't hear the newer 5 GHz channels will still be able to use our 2.4 Ghz services; the 802.11b and 802.11g 2.4 GHz services remain available everywhere we provide wireless service, and the 802.11n 2.4 Ghz service is available in those locations upgraded to add 802.11n support. This is one reason that every client should continue to support 2.4 Ghz.
We emphasize that to be eligible for our service, the client must include support for IEEE 802.11b or 802.11g. (That also implies the client supports the 2.4 GHz frequency range, as 802.11b and 802.11g operate solely in that range.)
Examples of clients that do not meet our eligibility requirements include:
Clients that do not meet our eligibility requirements will be unable to "hear" our wireless services in most locations.
Our 802.11b and 802.11g services are available throughout our service area. Many of our locations have been upgraded to add support for 802.11a and 802.11n services, and a few dozen locations have also been upgraded to add support for 802.11ac service. Those locations that have been upgraded should also support all 802.11n clients that operate in the 2.4 GHz frequency range; they will suport only 802.11n clients (and 802.11ac clients in those areas with 802.11ac support) that operate in the 5 GHz range and 802.11a clients only if the client supports all the 5 GHz range channels that were defined as of 2010.
Customers purchasing new equipment should prefer hardware that supports all five standards: 802.11b, 802.11g, 802.11a, 802.11n, and 802.11ac. Support for 802.11b or 802.11g is a necessity. Support for 802.11a and 802.11n is not an absolute necessity, but is highly desirable, because it will allow the client to automatically take advantage of our the newer services available in many campus locations. Support for 802.11ac is not a requirement, but will allow the client to automatically take advantage as more campus locations are upgraded in the future to support that service.
Clients that support multiple wireless standards usually require no special configuration to select a particular standard. Once you configure the device to try to connect to a particular network name (SSID), the device will usually look for that network name using all the frequency ranges and protocol standards supported by that device. For example, if the device supports the 802.11b, 802.11g, and 802.11n protocols in the 2.4 GHz frequency range, and supports the 802.11a, 802.11n, and 802.11ac protocols in the 5 GHz frequency range, the device may discover the requested network name is available in both frequency ranges. The device will automatically choose one of the frequency ranges; our service tries to steer such a device toward the 5 GHz frequency range if possible; such steering is not always possible. The device will select one of the protocols supported in that frequency range; usually the device will select the newest protocol.
In nearly all locations, OIT Wireless Service uses wireless network name puwireless. In those locations, OIT Wireless Service provides IP service to clients by relying on a NAT service.
It also relies on a specialized DHCP service (not OIT DHCP Service). It does not rely on OIT Mobile IP Service.
It also relies on a specialized DNS service (not OIT DNS Service).
Clients are leased dynamically-assigned private (RFC 1918) IP addresses using DHCP. That network is connected to the campus network via Network Address and Port Translator (NAPT, a.k.a. NAT) Routers. NAT is used to allow the large number of simultaneously-attached wireless clients to share a smaller pool of globally-routable IP addresses.
This is a change which took effect September 6 2012. (Prior to that date, IP Service on puwireless relied on OIT DHCP Service, OIT Mobile IP Service, and OIT DNS Service. There were no NAT Routers involved.)
Documentation describing the behavior of the IP service in these locations is not presently available.
It is extremely simple for someone to intercept traffic sent to or from your computer via wireless networking. Modification of the traffic is also possible.
Traffic sent to or from your computer via wired networking is also vulnerable, but interception typically requires a physical connection to a segment of the wired network across which your traffic flows. Obtaining such a connection can range from trivial to more difficult, depending on the wired network topology and infrastructure along the traffic path. Nevertheless, wireless is considered even less secure; the snooper/interloper may even be in another building across the street.
OIT Wireless Service does not use WEP ("Wired Equivalent Privacy"), a feature of 802.11 intended to provide some degree of security to data traversing the wireless (radio) portion of the network. WEP is unsuitable for use among a large community as it requires publishing "the password" to everyone who might wish to use the wireless network. (A secret which must be published to eight thousand people is no secret.) Since then, WEP's design itself has been demonstrated to be flawed; it is not secure.
OIT Wireless Service does not currently use WPA ("Wireless Protected Access"), a technology offered by many wireless vendors (it is not part of the approved 802.11 family of standards), or WPA2 (its successor). WPA was intended as a temporary replacement for WEP, designed to address many of WEP's flaws. (It was positioned as a temporary solution, until all existing wireless hardware and software is replaced with a new generation of equipment designed to support the 802.11i security standard.) It appears that if we were to deploy WPA (or WPA2) at this time, all clients that do not support WPA (or WPA2) would lose access to OIT Wireless Service. As many campus clients do not currently support WPA (or WPA2), we do not plan to deploy WPA (or WPA2) at this time. We expect to re-evaluate this stance in the future.
As you cannot rely on the network to prevent interception or modification of your data, if your data is sensitive, you would be prudent to take steps to ensure that anyone who might intercept your traffic would find it of little value, and steps that make it difficult for an interloper to modify your traffic in-transit. For example, instead of using applications that send and receive your data in the clear, use applications that use strong encryption before placing your data on the network. (E.g. avoid cleartext telnet, ftp, and rlogin; instead use ssh, scp/sftp, kerbererized telnet, kerberized ftp, or kerberized rlogin. When using ssh/scp/sftp, verify that the public key of the server to which you are connecting is legitimate. Do not send sensitive data to Web sites unless the Web site connection is using strong encryption and you verify that the Web site's public key is legitimate.)
You should be aware that 802.11 wireless networking does not provide the same reliability and performance as wired Ethernet service.
When this happens, there is no obvious indication to OIT or to the operator of the private Wireless Access Point of the problem. Nevertheless, it results in greatly reduced performance to the clients of both OIT Wireless Service and clients of the private Wireless Access Point.
As a result, as departments and individuals continue to install their own wireless access points, it is likely that the reliability and performance experienced by all wireless clients will continue to decline. Indeed, in some locations, customers have reported that such interference can be severe, to the point of making OIT Wireless Service unusable in such areas.
Essentially all these wireless devices are operating on a large shared network. So if there are ten devices in the area on 2.4 Ghz channel 6 (or partially-overlapping channels 4, 5, 7, and 8) sharing the 54 half-duplex channel (say, 22 Mbps half-duplex of effective bandwidth), each gets only a small portion of the bandwidth.
This sharing of bandwidth is something like Ethernet was in the days before Ethernet switches. But it's worse with wireless, because with 802.11, the bandwidth also is not shared equally among all the clients. Wireless devices communicating at lower data rates (perhaps because they are far from the access point or only support 802.11b) will monopolize the channel, because it takes so much longer for them to transmit and receive data than devices operating at higher data dates. This leaves only a small fraction of the channel available for devices communicating at the higher data rates. That is, the bandwidth available to a device operating at a high data rate is reduced disproportionately by the presence of other devices operating at low data rates; bandwidth is not divided equally among the devices.
The result is that the presence of slower clients in the area using the same channel (even those using different Wireless Access Points) dramatically reduce the bandwidth available to faster clients.
Contrast this to OIT Ethernet Service, which typically provides a consistent and reliable 10 Mbps half-duplex (or 100 Mbps full-duplex, or 1000 Mbps full-duplex) connection between the Ethernet switch and each device.
Contrast this again to OIT Ethernet Network Service, which typically provides a consistent and reliable 10 Mbps half-duplex (or 100 Mbps full-duplex or 1000 Mbps full-duplex) connection between the Ethernet switch and each device.
As a result, OIT Wireless Service suffers more service disruptions than OIT Ethernet service, these disruptions last longer, and we are less able to correct them effectively.
We list these caveats not to discourage you from using wireless service, but to help you set reasonable expectations of what wireless service can provide. As indicated above, despite its convenience and rapidly growing popularity, wireless service is very unlikely to provide you with with the same performance, consistency, or reliability as wired Ethernet service in the forseeable future. OIT's view is that wireless service complements wired service; it is not a substitute. It is best to view OIT Wireless Service as a convenience network, not the University's primary network service.
For this reason, you should ensure that your device is not configured to try to simply connect to "all wireless networks" that it sees.
Similarly, if your device is configured to remember selected wireless networks it has connected to in the past, you should ensure that this list does not include the TVWNA networks; those networks have names that begin with puvisitor.
Sometimes devices are declared ineligible for OIT Wireless Service (or all wireless services offered by OIT) because they are infected or compromised, then attempt to break into other devices, or attack other Internet destinations.
A list of devices ineligible for OIT Wireless Service appears in Devices Blocked from OIT Wireless Service. That document includes devices that have been declared completely ineligible for OIT Wireless Service (i.e. from all OIT Wireless Access Points) and devices that have been declared ineligible for all wireless services offered by OIT.
Most often this is because the client's association attempt is rejected (e.g. the client is not eligible for the requested wireless service), and the client simply retries at a high rate. Other times this is because the client is succesfully associated to the Access Point, but has a poor quality connection, so it chooses to disconnect, then immediately tries to reconnect. And sometimes this is because the client has associated to a wireless service that is protected with a password, but the client has specified the wrong password; the client encounters difficulties so decides to disconnect and then reconnect.
To reduce the impact these clients have on network service, OIT limits the frequency at which a wireless client may request an association to any single OIT Wireless Access Point. Currently, we allow a wireless client to request an association up to three times within a two-minute period for all wireless services (e.g. OIT Wireless Service or TVWNA) provided by the OIT Wireless Access Point. After three (successful or unsuccessful) association requests, that particular OIT Wireless Access Point will reject any further association requests from that particular wireless client for two minutes.
Even with this rate limit in place, wireless clients that continuously connect and disconnect at a very high rate on an ongoing basis day after day still place a high enough load on the service as to degrade service for other customers. Typically these problematic wireless clients lose connectivity within a few seconds of connecting, and reconnect immediately, and then lose connectivity again, round-the-clock. To maintain an acceptable service level for properly functioning clients, OIT may mark the problematic clients ineligible for wireless services provided by OIT.
You can avoid this problem by ensuring your computer cannot simultaneously use both network interfaces. E.g. only enable a single network interface at the same time. OIT recommends this approach.
(For the technically curious, the explanation is that nearly all computers use the "Weak End System Model" with respect to transmitting. So sometimes your computer transmits some data via one network port, but marks the data as coming from the IP address of the other network port. OIT's IP routers perform "IP ingress spoof filtering" to discard packets containing IP sources inappropriate for the network on which they were received, as such traffic can represent a security problem.
This is not a bug in your computer's operating system; the "Weak End System Model" is allowed by IP specifications. Neither is there anything wrong with the IP ingress spoof filtering performed on OIT's IP routers. IP ingress spoof filtering is an important measure to combat certain kinds of network-based attacks; it will not be disabled. However, when both are used in combination, they result in packet loss.
One fix would be for all operating systems to adopt the "Strong End System Model" with respect to transmitting. This would ensure that data transmitted by your computer from each network port is marked with the IP address of that network port, not the computer's other network port. Such an approach is especially appropriate for multihomed hosts, increasingly common in today's "wired and wireless" world. However, we are not aware of any plans by major operating system vendors to do this.)
The same is true if your device later proves unsuitable for use with OIT Mobile IP Service (perhaps as a result of malfunctioning DHCP client software).
If you instead purchase a device that has both a Wireless and an Ethernet interface, even if the device's wireless interface and/or DHCP client software proves unsuitable, you will at least be able to use the device's Ethernet interface with OIT Static IP Service (by connecting the Ethernet interface to the device's "home network).
Sometimes customers configure wireless devices in this way to conserve battery power; this is understandable. They want the device to periodically check for something (incoming email, for example), but not to remain connected all the time.
This is fine when the frequency is low. At higher frequencies it can degrade network performance when many devices behave this way. That's due to the activity happens each time a device connects; it requires work by the Wireless Access Point, communication with RADIUS servers to authorize the connection, and communication with the DHCP servers to obtain an IP address. (Some of the DHCP traffic is broadcast, which also increases broadcast traffic seen by all devices on the wireless network.)
As a rule of thumb, if you configure your device to operate this way, please configure it to connect no more often than every 10 minutes.
This is not an issue for devices that simply remain connected to the wireless network and periodically run a program (e.g., to check for email). It's the connecting and disconnecting from the wireless network that is the more expensive operation.
By "server", we mean most devices that provide a networked service to other networked clients. Examples include (but are not limited to) file servers, printers and print servers, audio/video servers and other such "appliances."
If the wireless device is essentially a client (say, a workstation), but also offers some low-volume "services" to the owner's other networked devices, the lack of a static IP address and DNS hostname will likely present challenges to the owner, particularly in combination with OIT's blocking of various broadcast/multicast-based service discovery protocols on the wireless networks. Keep in mind that attaching servers via OIT Ethernet Service (where OIT Static IP Address Service is available) is the recommended solution.
This is consistent with our policy that wireless is not the appropriate way to connect servers to the network; servers should be attached via OIT Ethernet Service (where OIT Static IP Address Service is available). Servers using OIT Static IP Address Service on OIT Ethernet Service will have an static DNS hostname and IP address, making it possible for clients (regardless of whether the client is attached via Ethernet or Wireless) to be manually configured to make use of the server.
Additionally, as our wireless services continue to grow, it will be necessary for OIT to setment the wireless network into smaller regions to help control broadcast and multicast traffic rates. Such segmentation will further limit the ability of broadcast or multicast "browsing" or "discovery" protocols to locate peers; such traffic will not cross the boundaries between segments.
The ever-increasing demand for client IP addresses does not allow us to allocate a globally-routable IP address for every wireless client.
This is an advanced topic, of interest to customers who desire static IP addresses when using OIT Wireless Service.
We do not provide OIT Static IP Addresses to devices connected via OIT Wireless Service. Instead, we provide dynamically-allocated private (RFC 1918) IP addresses behind a NAT to clients while they are connected to OIT Wireless Service in most locations (those locations where the wireless network name is puwireless). We provide OIT Mobile IP Addresses to clients while they are connected via OIT Wireless Service in a few locations (those locations where the wireless network name is puwireless).
From time to time, customers ask OIT to provide their devices with static IP addresses (or static globally-routable IP addresses) for use with OIT Wireless Service. We do not provide such IP addresses for a number of reasons:
We rely on the expectation that not all registered wireless clients are simultaneously attached via the parts of OIT Wireless Service using OIT Mobile IP Service. At any time, some of those wireless clients are offline, outside the wireless coverage area, or no longer exist. As a result, the number of simultaneously-attached wireless clients is fewer than the number of IP addresses we have available for the use of wireless clients at any one time.
This requires that we allocate those IP addresses to online clients dynamically. As a client goes online via OIT Wireless Service, we loan the client an IP address; after that client has gone offline, the same IP address may be loaned to a different client. IP addresses are not reserved solely for the use of specific clients.
Clients obtain these "loans" automatically using DHCP . DHCP associates each loan (DHCP calls this a "lease") with a duration, so the IP address can be reclaimed once the client stops renewing the lease (e.g., goes offline), and then leased to a different client.
If we were to instead assign a static IP address to a wireless client, that address would be reserved for the use of that client all the time, even when the client was offline. This approach does not scale for our wireless service, as we have more wireless clients than available IP addresses for the parts of OIT Wireless Service using OIT Mobile IP Service.
Depending on which portion of OIT Wireless Service a client happens to attach to, the client is leased an IP address appropriate for that subnet.
A client using OIT Static IP Service would need to be allocated multiple static IP addresses: one on each subnet comprising OIT Wireless Service. All of these IP addresses would have to be reserved for the client at all times.
We expect the number of IP subnets comprising OIT Wireless Service to continue to grow in the future, making it even less feasible to allocate a static IP address for a client on each subnet.
Devices that lack properly-functioning DHCP client software do not meet the minimum eligibility requires for OIT Wireless Service.
Customers sometimes propose that because their device vendor is unable to provide working DHCP client software, and because OIT cannot provide a way to fix the vendor's malfunctioning DHCP client software, OIT should provide the customer's device with a static IPv4 address so the device may use OIT Wireless Service. While we understand a customer's frustration with a vendor that fails to provide properly-functioning DHCP client software, if we were to award such malfunctioning devices with static IP addresses, we would exhaust the supply of IPv4 addresses for the use of properly-functioning wireless clients.
Owners of devices with faulty DHCP client software may wish to contact the vendors of their devices to emphasize the need for the vendor to fix the faulty DHCP client software.
OIT Wireless Service is not intended as a way to connect servers to the campus network. Servers should be attached via OIT Ethernet Service. An Ethernet-attached device may be assigned an OIT Static IP Address. OIT Wireless Service is intended as a convenience service for mobile workstations, not as a replacement for Ethernet.
Most often, this is because the service is using such restrictions as a form of security, or as a way to try limit use to only customers licensed to use a service.
If this is being done as a form of security, it represents a weak form of security; as it could be trivially circumvented by any other device on the same network as the client. The service might as well provide access to an entire subnet.
If the intent is to extend use of the service to specific devices or persons, this would be better accomplished through the use of any of a variety of other authentication or authorization mechanisms not based upon the client device's IP address.
If you have questions or need assistance with any of the procedures in this document, please contact the OIT Support and Operations Center.