Mac OS X (10.2 and later) includes an "Internet Sharing" feature, software intended to let one computer share its Internet connection with other computers. The software is a a combination NAT (Network Address Translator), DHCP server, and Wireless Access Point. The feature is built into the operating system, but is turned off by default.
The software runs on a Mac OS X computer (the "server") that already has an Internet connection (e.g. Ethernet or Wireless). It is intended to provide service to other computers (the "clients") that are able to communicate with the server via an Ethernet or Wireless connection.
OIT testing of the version included with Mac OS X 10.2 shows that the feature is inappropriate for use on a computer attached to the campus wired network or wireless network. It is also inappropriate for use on a computer within radio range of any wireless service provided by OIT.
OIT testing of versions included with Mac OS X 10.3 through 10.7 shows that the feature is inappropriate for use on a computer attached to the campus wired or wireless network.
OIT testing of the version included with Mac OS X 10.8 shows that the feature is safe if used with care.
The following information is based upon version 10.2 (i.e. 10.2.0). We did not re-test in later versions of 10.2.x; lacking additional information, we assume they too exhibit the same bugs.
Even when properly configured to only provide service to a private Ethernet or wireless network, the Internet Sharing software can act as a rogue DHCP server on the campus wired or wireless network.
Additionally, it may continue to do so even after the Internet Sharing software is turned off. It may continue to do so even after the network port (e.g. AirPort or Ethernet) it was serving has been "turned off."
Therefore:
As the radio range of wireless services provided by OIT include much of campus (and continues to grow), there's essentially no place on campus that should be considered "safe enough" for the buggy version of the "Internet Sharing" software.
The following information is based upon version 10.3.2. We did not examine the feature in 10.3 and 10.3.1. We have not re-tested this in versions of 10.3.x since version 10.3.2.
The device responds erroneously to certain traffic it receives on the interface attached to the campus network (the "uplink"):
We reported this issue to Apple.
We reported this issue to Apple.
The following information is based upon version 10.4.1. We also verified this is was present in version 10.4.7 and 10.4.10.
The device responds erroneously to certain traffic it receives on the interface attached to the campus network (the "uplink"):
We reported this issue to Apple.
We reported this issue to Apple.
The following information is based upon version 10.5.8.
The device responds erroneously to certain traffic it receives on the interface attached to the campus network (the "uplink"):
We reported this issue to Apple.
We reported this issue to Apple.
The following information is based upon version 10.6.1. We also re-tested it in version 10.6.8 and found it was still accurate.
When the uplink receives an IP broadcast packet, and it decides it is not interested in the packet (or that something is wrong with the packet), the device sends an ICMP error message back to the sender. This is not correct behavior; no device should ever send an ICMP error message in response to broadcast or multicast traffic. That's because if devices do so, it can easily create very large traffic spikes (even broadcast storms) on the network.
We reported this issue to Apple.
Our testing shows that this bug was never corrected in version 10.6.x, but was fixed starting in version 10.7.
When the uplink sees an UDP/IP unicast or broadcast packet destined to a non-local IP destination other than the uplink's IP address, it attempts to forward the packet. This is not correct behavior; it should not try to route the packet at all. By doing so, it contributes to traffic storms on the campus network.
We reported this issue to Apple.
Our testing shows that this bug was never corrected in version 10.6.x, but was fixed starting in version 10.7.
Operating as a Bonjour Sleep Proxy Server on the campus network causes the device to use IP addresses not assigned for its use on the campus network.
Mac OS X does not appear to provide a way to disable the Bonjour Sleep Proxy Server functionality.
We reported this issue to Apple.
Our testing shows that this issue was never addressed in version 10.6.x.
The following information is based upon version 10.7, and we have verified it is still accurate in 10.7.4.
Operating as a Bonjour Sleep Proxy Server on the campus network causes the device to use IP addresses not assigned for its use on the campus network.
Mac OS X does not appear to provide a way to disable the Bonjour Sleep Proxy Server functionality.
We reported this issue to Apple previously.
The following information is based upon version 10.8 (that is, 10.8.0).
At this time we are not aware of any issues with the Internet Sharing Feature in Mac OS X 10.8.
Mac OS X's "Internet Sharing" is not a feature that OIT explicitly supports for on-campus use. You are not forbidden from using it on the campus network in this version of Mac OS X, but OIT does not provide assistance with the feature.
Because the feature acts as a Network Address Translator (NAT) Router, be sure to see Connecting a Private Network Address Translator to the Campus Network.
Because the feature also act as a DHCP server, be sure to see OIT DHCP and Bootp Services: Private DHCP or BootP Servers, or BootP Relay Agents.
And because the feature has the ability to be configured as a Wireless Access Point, also be sure to see also Connecting a Private Wireless Access Point to the Campus Network.