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 most 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 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.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:
More information about the wireless hardware supported by OIT Wireless Service is below, in Wireless Hardware and Configuration.
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.
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.
OIT Wireless Service is currently based on the IEEE 802.11b and 802.11g standards. (These are sometimes referred to as "Wi-Fi.") Our service uses 802.11g, and includes backward support for 802.11b.
The service does not support equipment based on the IEEE 802.11a standard. (That is sometimes referred to as "Wi-Fi5.")
The service does not support equipment based on any of the drafts of the (not yet finalized) IEEE 802.11n standard.
The service does not support BlueTooth wireless equipment. BlueTooth is a short-range wireless standard for extremely short-range connections (e.g. among a mouse, a keyboard, and a computer workstation).
Our services supports data rates of 5.5, 6, 9, 11, 12, 18, 24, 36, 48, and 54 Mbps. (802.11b clients will only be able to use data rates of 5.5 and 11 Mbps.)
We 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 IEEE 802.11 clients (i.e. those that predate 802.11b), because those clients only support data rates of 1 and 2 Mbps, neither of which we support.
Some vendors sold 802.11g equipment before the standard was finalized in November 2001; this 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 with OIT Wireless Service, also try reconfiguring it to limit itself to 802.11b.
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)." Doing so would allow your computer to select any wireless network within radio range; as there are many private wireless networks throughout campus, your machine would sometimes connect to one of them, instead of OIT Wireless Service. That will lead to a variety of difficulties for the wireless client.
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.
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.
As all wireless devices operating in the same area on the same channel share bandwidth, the bandwidth above (e.g. 8 Mbps half-duplex) is shared among all those clients; each clients receives some smaller fraction of the total.
These figures assume the client is very close to the Wireless Access Point's antenna(s), with no intervening obstacles or other RF interference. Distance, obstructions and interference all reduce performance.
Essentially all these wireless devices are operating on a large shared network. So if there are 10 devices in the area on channel 6 (or partially-overlapping channels 4, 5, 7, and 8) sharing 8 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.
The difference between (switched) Ethernet and (shared) wireless bears repeating: if there are 30 wireless clients in one area associated to a Wireless Access Point, they are all sharing (say) 8 Mbps half-duplex of bandwidth, one might get 277 Kbps half-duplex (at best) on the first network segment. If each of those 30 clients were instead attached to 10 Mbps half-duplex Ethernet ports, each client would get 10 Mbps half-duplex of bandwidth on the first network segment. The difference in bandwidth is dramatic. The more active wireless clients there are, the less bandwidth there is available to each client. The difference becomes even more pronounced when comparing wireless service to 100 Mbps full-duplex Ethernet service.
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.
This is not surprising, as Wireless technology is relatively immature compared with Ethernet technology. 802.11 wireless equipment has been in general use only since 1999, while Ethernet has been in general use since the early 1980s. We expect that given time, new generations of wireless equipment will slowly improve in reliability. (A typical 'genereration' for equipment may be 3-5 years, so the rate of improvement is not swift.)
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. 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.
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.
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. The coverage areas of each Wireless Access Point overlap (in fact, they must overlap to provide reliable service). Wireless clients typically choose to associate themselves with an appropriate Wireless Access Point based on factors that include signal strength. 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. Doign so would require we leave "dead zones" where no wireless service were available, to avoid any overlap among Wireless Access Points attached to different subnets. The coverage area of a Wireless Access Point is generally not possible to control very precisely, so these "dead zones" would need to be quite large.
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 becomes more popular we will 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 will be limited by the number of clients simultaneously attached to OIT Wireless Service, instead of the number of clients registered in the Host Database as possessing wireless intefaces. Presumably not all clients with wireless interfaces will 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.
The most-common 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 Help Desk.