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.
As the use of IP on OIT Wireless Service relies upon OIT Mobile IP Service, the procedures and requirements described in the OIT Mobile IP Service document also apply to devices using OIT Wireless Service; OIT Mobile IP Service is one of the building blocks of OIT Wireless Service.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:
Although the following ENTRY-TYPEs are exempt from the Tigernet Host Charge, they are eligible for OIT Wireless Service: PRINTER, PLOTTER, SCANNER, PROJECTOR, PRINT-SERVER. However, take note that because devices with the ENTRY-TYPES above also act as servers, we do not recommend connecting them to wireless service. Devices acting as servers should be attached instead to Ethernet service.
Such devices are exempt from the Tigernet Host Charge because the person responsible for the device has indicated that the device is attached to privately-maintained wiring, and it is not possible to communicate in any way with the device from any other device attached to OIT wired or wireless service.
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.
While all of the requirements described in OIT Mobile IP Service are relevant, in particular we wish to call to your attention the fact that in order to OIT Wireless Service, a client must have properly-functioning DHCP client software.
Be aware that DHCP client software sometimes has bugs which do not pose a serious problem when the device is used with OIT Static IP Service, but make the DHCP client unsuitable for use with OIT Mobile IP Service, and therefore, also for OIT Wireless Service. These bugs include, for example, those DHCP client bugs which lead a client to ignore DHCP lease expiration times. From time to time, some computer operating systems have such bugs. We have also found that nearly all physical appliances (printers, print servers, file servers, NATs, wireless access points, audio/video servers, etc.) have such bugs. (As noted below, OIT Wireless Service is not intended as a way to attach "appliances" to the network.)
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 or puwireless2. (Almost all locations use puwireless, a very few must use puwireless2.) 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 (puwireless2 in a few locations).
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, except possibly when roaming between puwireless and puwireless2.
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. As of February 2012, twenty of the largest academic and administrative buildings have been upgraded; more buildings are upgraded each month.
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. As of February 2012, twenty of the largest academic and administrative buildings have been upgraded; more buildings are upgraded each month.
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-2010 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 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. Very few of our locations have been upgraded to-date to add support for 802.11a and 802.11n services. 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 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 four standards: 802.11b, 802.11g, 802.11a, and 802.11n. Support for 802.11b or 802.11g is a necessity. Support for 802.11a and 802.11n is not a necessity, but is desirable, because it will allow the client to automatically take advantage of our newer services as those services become more widely available on campus.
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 and 802.11n 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.
OIT Wireless Service provides IP service to clients by relying upon OIT Mobile IP Service. Customer devices using OIT Wireless Service are always treated as visitors to the OIT Wireless Service network; this network is never treated as any client's home network. When attached to the network via OIT Wireless Service, your computer is assigned a temporary IP address and hostname via DHCP.
To use OIT Wireless Service, your computer must follow the procedures and meet the requirements associated with OIT Mobile IP Service. OIT Wireless Service will not work for clients that do not meet those requirements, nor for Devices Blocked from OIT Mobile IP Service. In fact, when a device is declared ineligible for OIT Mobile IP Service as a result of a problem with its DHCP client software, the device often is also declared ineligible for wireless services provided by OIT, since our wireless services all rely on the client's DHCP software working properly.
In most cases, your Host Database entry's Wireless interface has been registered in the Host Database so that it is assigned an IP address on a subnet named wirelessnet. This IP subnet does not actually correspond to any real IP network on campus (neither wired nor wireless). The wirelessnet IP address assigned to your Wireless interface is simply a placeholder, and in fact your computer will never use that IP address. (Do not manually configure your wireless interface to use this IP address!)
Instead, when your Wireless interface is attached to the campus network via OIT Wireless Service, it will be assigned an OIT Mobile IP Address on an IP subnet named vapornet or vapornet2. (Almost all locations use vapornet; a very few must use vapornet2.) We guarantee that these IP subnets are different than any network to which your Ethernet interface(s) may be attached.
OIT Mobile IP Camping rules don't apply to devices using OIT Wireless Service; a device may visit OIT Wireless Service for as long as it wishes without being declared a Mobile IP Camper. (Of course, if the wireless interface visits some other network, it may indeed be declared a Mobile IP Camper on that network; this can happen if you you allow your wireless client to connect via wireless services other than OIT Wireless Service.)
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.
In particular:
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), devices that have been declared partially ineligible for OIT Wireless Service (i.e. from certain 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.
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 OIT Mobile IP Addresses to clients while they are connected via OIT Wireless Service.
From time to time, customers ask OIT to provide their devices with static 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 OIT Wireless 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.
Depending on which portion of OIT Wireless Service a client happens to attach to, OIT Mobile IP Service dynamically leases the client 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 do not have enough globally routable IPv4 IP addresses to permit this even for a very small number of wireless clients.
We expect the number of IP subnets comprising OIT Wireless Service to continue to grow in the future, making it even less possible 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.
This is an advanced topic, mostly of interest to support staff. You can skip this material unless you're curious about the details.
Sometimes a device that meets the eligibility requirements for OIT Wireless Service may be declared "partially ineligible" for the service. This means that the device is ineligible to use the service from specific OIT Wireless Access Points (usually just a few), but remains eligible to use the service via any other OIT Wireless Access Points.
This is a workaround for an issue that arises because OIT Wireless Service does not currently blanket the entire campus, but instead covers only selected areas. The service is provided by many OIT Wireless Access Points; each Access Point is a radio transceiver connected to the campus network. Each Access Point is able to provide service to a small area; the Access Points are positioned to provide acceptable coverage to those areas where OIT Wireless Service is currently intended (e.g. funded) to be available. Wireless clients connect to a nearby Access Point, typically selecting one based on signal strength, and roam from one Access Point to another as needed.
Each intended coverage area is surrounded by a region where coverage wasn't intended, but some RF signal still reaches. However, the RF signal in portions of those "fringe" areas is too poor to sustain a good wireless connection. Sometimes these "fringe" areas coincide with places where clients eligible for OIT Wireless Service spend significant time (e.g. offices, dormitory rooms and apartments). When a client is configured so that it will always try to connect to OIT Wireless Service, the result is that the client connects even when in the "fringe" area, requests an IP address via DHCP, then disconnects due to the poor RF signal. This happens continuously, resulting in excess load on the campus DHCP servers, degrading campus DHCP/BootP service. It also produces unecessary broadcast traffic throughout OIT Wireless Service, degrading performance for others.
Ideally, the wireless client would notice that the connections were poor, and would eventually stop trying to connect, or at least, reduce the rate at which it retries. Unfortunately, this is not the way wireless clients behave, and there is nothing OIT can do centrally to cause them to behave that way.
This issue would not exist if OIT Wireless Service were expanded to cover the entire campus. If it were possible to push the "fringe" areas out beyond the borders of campus. no devices eligible for OIT Wireless Service would spend significant time in those fringe areas. However, funding for doing so is not available at this time. (OIT recognizes the value of wireless computing. As funding becomes available, OIT will be phasing in wireless capabilities throughout campus.)
Another way to address the issue is for customers to only enable their wireless interfaces when they are in locations intended to be served by OIT Wireless Service. However, few customers do so; most leave their computer's wireless interfaces enabled all the time.
As a workaround, when we detect that a particular device spends significant time on most days in a "fringe" area, and constantly connects and disconnects from OIT Wireless Service during that time, we declare that device "partially ineligible" for OIT Wireless Service. That is, we determine which nearby OIT Wireless Access Points the device is using (when in that fringe area), and declare the device ineligible for OIT Wireless Service from those specific OIT Wireless Access Points.
A list of devices declared "partially ineligible" for OIT Wireless Service (including the specific OIT Wireless Access Points each is ineligible to use) is included in the Devices Blocked from OIT Wireless Service document.
There are several ways OIT can mark a device "partially ineligible" for OIT Wireless Service. One of these ways is to mark the device's Host Database entry with an OIT-NETGROUP tag that specifies oitwirelessineligible along with a list of OIT Wireless Access Points. For example, a netgroup tag of oitwirelessineligible,nas=airo-130,nas=airo-205 would declare that the device is ineligible for OIT Wireless Service using Access Points airo-130 and airo-205. It does not mean that the device is completely ineligible for OIT Wireless Service campus-wide. (A netgroup tag of oitwirelessineligible containing no list of OIT Wireless Access Points would declare the device completely ineligible for OIT Wireless Service from all OIT Wireless Access Points. The presence of a list of Access Points causes the ineligibility to apply to just those Access Points.) Regardless of whether OIT marks a device "partially ineligible" for OIT Wireless Service using this netgroup tag approach, or another approach that does not involve the Host Database entry, the information will appear in Devices Blocked from OIT Wireless Service.
When we declare a device ineligible from using OIT Wireless Service from specific Access Points, those specific Access Point will reject connections from the wireless device. (They will do so regardless of whether the device is in the intended coverage area of those Access Points, or in the "fringe" area beyond.) This has no effect on the client's ability to use OIT Wireless Service via other OIT Wireless Access Points; e.g. elsewhere on campus. It's important to understand that declaring a device "partially ineligible" for OIT Wireless Service does not block the device from using the service in other parts of campus.
Because most of the devices declared "partially ineligible" for OIT Wireless Service involve fringe areas that coincide with dormitories or apartments, and most students' residences change annually, OIT annually reviews all devices marked "partially ineligible" for OIT Wireless Service. When it no longer makes sense for a device to be declared "partially ineligible", OIT removes that marking.
A concrete example should make this clearer. There are several OIT Wireless Access Points installed in University office buildings along Alexander Street. Those Access Points are intended to provide OIT Wireless Service in those office buildings. However, a weak RF signal from those Access Points reaches some of the nearest dormitory rooms across the street in Forbes College. A resident of one of those dormitory rooms may have configured her laptop computer to connect to OIT Wireless Service (or "any" wireless service it can hear). When she returns to her room with her laptop computer each day, she may leave the computer's wireless interface configured to try to connect to OIT Wireless Service (or "any" wireless service), even though her computer is not currently in an area intended to be served by OIT Wireless Service. The computer hears the weak RF signal from the OIT Wireless Access Points across the street, connects via one of those Access Points, but soon loses its connection due to the weak signal. Each time it connects, it requests an IP address via DHCP. It keeps connecting and disconnecting throughout the evening and night, until the owner takes the computer with her to classes the following morning. After several weeks (or months) of this, if the volume of connects/disconnects (or DHCP requests) is high enough, OIT may notice the pattern. To work around the problem, we may declare the customer's computer ineligible for OIT Wireless Service using the specific OIT Wireless Accesss Points in those office buildings across Alexander Street. Although the device is now "partially ineligible" for OIT Wireless Service, it remains able to use the service elsewhere on campus. (If the student carried the computer into those office buildings on Alexander Street, it would not be able to use OIT Wireless Service there, despite a strong RF signal.) At the end of the Summer, OIT would review this student's Host Database entry because it is marked "partially ineligible" for OIT Wireless Service, and notice that it involves OIT Wireless Access Points on Alexander Street. If the student's new residence isn't Forbes College, OIT would likely remove the "partially ineligible" mark from that Host Database entry.
This section provides some advanced information about the use of the wirelessnet, vapornet, and vapornet2 subnets. You can skip this material unless you're curious about the details.
The actual IP subnet on which OIT Wireless Service operates is vapornet or vapornet2. Almost all locations use vapornet; a very few must use vapornet2. We only use vapornet2 in those remote locations bridged to the campus network via a low-speed link that would be saturated by the volume of broadcast traffic on vapornet.
All OIT Wireless Access Points are attached to vapornet (or vapornet2), and the Mobile IP Addresses temporarily assigned to wireless clients via DHCP are all on vapornet (or vapornet2). However, when we register a wireless client's hardware address, we specify in the Host Database that it should be assigned an IP address on wirelessnet, not vapornet or vapornet2. This unusual arrangement is deliberate, and serves several purposes.
We endeavor to use a single IP subnet (vapornet) wherever possible, to ensure IP service continues to function as a wireless client shifts from one Wireless Access Point to another. Wireless clients typically choose to associate themselves with an appropriate Wireless Access Point based on factors that include signal strength and the the channels used by the access points. This association can change when the client is moved (even slightly, depending on location), when something obstructs the signal (e.g. another person walking between the client and the access point), or when there is RF interference. The client re-associates with another Wireless Access Point serving the same network name (SSID) automatically. Since this may happen frequently while the computer is in-use, all the Wireless Access Points serving the same network name (SSID) must be on the same IP subnet to avoid interrupting the client's IP service.
This is different from wired service, where it is reasonable to expect the user to shut down and later restart the computer when moving it from one wired Ethernet connection to another. That assumption in the wired environment allows us to place different buildings' wired Ethernets onto different IP subnets. Controlling the number of buildings wired to each subnet allows us to control the number of clients wired to each subnet, so we do not exhaust the IP addresses available on any one wired subnet.
Avoiding IP address depletion by splitting the campus into multiple wireless subnets appears to be impractical. Each subnet would need to be associated with a different network name (SSID). Customers would need to configure there wireless devices to be willing to connect to each of the network names we created, a tedious process for most clients. Each time a client device moved from one network to another (something that would happen many times per day for most mobile devices), it would need to obtain a fresh IP address on the new network, breaking all open connections on the client. Furthermore, a design in which the wireless client moves among multiple IP subnets would rapidly exhaust our supply of IP addresses; this is because clients rarely advise DHCP servers to release their old DHCP leases. The DHCP servers instead are forced to wait for the old leases to expire, so a client that visits several IP subnets over the course of a few hours would force the DHCP servers to expend several IP addresses for that client at any one time. We do not have the luxury of holding even two IP addresses for each wireless client at one time, let alone several.
Given that almost all OIT Wireless Service is attached to the single IP subnet vapornet, the finite size of the IP subnet limits the number of simultaneously attached wireless clients we can serve. As wireless hardware is very popular, we have more wireless interfaces registered in the Host Database than we could simultaneously serve. By not assigning each wireless interface its own static IP address on vapornet and vapornet2, but instead loaning each active client a vapornet or vapornet2 IP address, we can postpone IP address depletion. (We are limited by the number of clients simultaneously attached to OIT Wireless Service at any one time, instead of the total number of clients registered in the Host Database as possessing wireless intefaces. We rely on the fact that not all clients with wireless interfaces need to use them simultaneously.
IP Address space depletion is not an issue on the fictituous wirelessnet subnet. This subnet is very large; it can afford to be, since it's not actually allocated to Princeton University.
Some wireless clients are portable computers which have two physical interfaces (one Ethernet and one Wireless), only one of which will be attached to the network at a time.
Such a device (say foo.princeton.edu) is usually attached via Ethernet when it on its home network. When on its home network, the device might run some service (e.g. a Web server). Clients of that service would expect to be able to look up the name foo.princeton.edu in DNS to learn the device's IP address.
If we were to insert into DNS two IP addresses (one assigned to the device's Ethernet interface, and one assigned to its Wireless interface), clients looking up the name foo.princeton.edu would get back both IP addresses (in random order). They might try to communicate with the device's wireless IP adddress, which would not respond when the device is attached via its Ethernet interface. Eventually the client would probably try the other IP address and reach the device via its Ethernet interface, but only after a (possibly lengthy) delay.
We avoid this problem by not inserting into DNS any IP address for the device's Wireless interface; that way, looking up foo.princeton.edu will only return a single IP address (the one assigned to the device's Ethernet interface).
The way we recognize that an interface's IP address shouldn't be inserted into DNS is to see if the IP address is on the wirelessnet subnet. When building data for inclusion into DNS, we do not insert the wirelessnet IP addresses. In effect, we are using the wirelessnet subnet as a way for you to indicate in the Host Database that the interface isn't really attached to the network "all the time" the way an Ethernet interface typically is.
This workaround isn't perfect. While the device is attached via its Wireless interface, clients will not be able to contact it via its usual hostname or IP address. (They could contact it via its Mobile IP address or hostname, but those will change for each visit to OIT Wireless Service. You might consider whether a computer that doesn't always have a fixed, stable connection to the network is really an appropriate one on which to run any servers to which you expect clients to connect.)
From the discussion above, you can see the subnet wirelessnet is actually a placeholder, used in the Host Database to identify wireless interfaces which should receive Mobile IP Service on OIT Wireless Service. The wirelessnet subnet is a fiction maintained by the Host Database; there is no actual IP network on campus on which wirelessnet IP addresses would function. In fact, these IP addresses fall into a range of reserved IP addresses which is not assigned to Princeton University (or any other organization); traffic involving these addresses is not supposed to be routed across the Internet, and these IP addresses are not supposed to be inserted into DNS data visible to the Internet.
Since wirelessnet IP addresses are not inserted into DNS, a device registered in the Host Database with just a single interface on wirelessnet will not have any static IP address in DNS. Although the device may be registered in the Host Database as foo.princeton.edu, if you look up that name in DNS, you will not find any IP address. (And similarly, if you look up the device's assigned wirelessnet IP address, you will not find it in DNS.) This makes sense; the device will always be using a Mobile IP Address, which will change over time. While this does mean that other Internet hosts won't be able to contact your wireless-only host by name (at least, not a static name), this shouldn't be a serious limitation, as a wireless-only host is probably not an appropriate one on which to run servers to which you expect clients to connect.
If you have questions or need assistance with any of the procedures in this document, please contact the OIT Support and Operations Center.