OIT filters LLMNR (Link Local Multicast Name Resolution) multicast traffic on the wireless networks operated by OIT. We do so because LLMNR degrades campus network service while being unnecessary for the network functionality OIT supports.
DNS (Domain Name Service) is a network protocol used to maintain a distributed database containing information about Internet hosts. Most commonly, DNS is used to translate between Internet hostnames (e.g. www.example.com) and IP addresses (e.g. 192.168.1.9). Other uses include translating between hostnames and mail exchangers, and to record services provided by a host so other hosts can discover those services.
DNS is a client/server based protocol. Organizations such as Princeton University that own Internet DNS name space (e.g. princeton.edu) or IP address space operate DNS servers containing the portion of the distributed database belonging to them. These organizations also arrange for redundant DNS servers to be operated (often by others organizations) around the Internet. DNS clients (most devices throughout the Internet) contact DNS servers when they need to look up information in this database. (E.g. to learn the IP address corresponding to the hostname www.example.com.)
OIT operates the DNS servers for Princeton University, and populates the DNS data from information stored in the Princeton University Host Database.
LLMNR (Link Local Multicast Name Resolution) is a protocol intended to provide name resolution on networks where DNS name resolution is not possible. LLMNR operates only on the local link (IP subnet).
Most LLMNR query packets are "multicast" to the network. (LLMNR response packets, along with certain LLMNR queries, are sent via "unicast.") Unlike unicast traffic (used by DNS), multicast packets are flooded to large segments of the network, so every device interested in the requests and announcements can hear them.
LLMNR's uses of multicast packets is designed to work within a single IP subnet. That is, LLMNR traffic does not cross from one IP subnet to another. As a result, LLMNR can be used among a set of devices that are all attached to a single IP subnet, but cannot be used among devices attached to different IP subnets. Princeton University's campus network is composed of hundreds of IP subnets, so as designed, LLMNR only allows a device to exchange LLMNR information with devices that happen to be attached to the same IP subnet. This limitation is not a bug. This is part of the design of LLMNR; it's intended for use on relatively small networks, rather than across large networks composed of multiple IP subnets.
In addition to being designed for use within a single IP subnet, LLMNR appears to be best used on relatively small network, consisting of dozens (or perhaps a few hundred) of devices, not thousands of devices. It is intended for use in an environment where there is no traditional DNS service provided. Examples of places for which LLMNR is designed include homes, small private offices, and ad hoc collections of devices connected to each other but possibly not to the Internet. In such locations, there may be no DNS servers installed; no staff, expertise, and hardware available to set up DNS servers; and no need for the security provided by central control of the data in DNS. In such environments, LLMNR works to provide a "plug and play" environment; individuals can simply connect a set of computers, printers, and other devices together, then use LLMNR to look up (or browse) the devices available on their local network.
LLMNR was not designed for use on larger networks. Besides the fact that it does not span multiple IP subnets, LLMNR is a much "chattier" protocol than DNS. As each device multicasts to the network announcements of the services it is providing, and each device multicasts queries for services, LLMNR generates a significant volume of multicast traffic. (In normal DNS, traffic is unicast.)
Additionally, the LLMNR multicast traffic in turn triggers ARP broadcast traffic. Apparently as devices try to respond to LLMNR queries, they may need to broadcast an ARP request for the queryer. And once queryers discover devices via LLMNR, the queryers may broadcast ARP requests for the discovered devices.
Multicast (and broadcast) traffic is a vital part of the network; its existance is not inherently bad. However, when there are high rates of multicast traffic which most clients wish to receive (or high rates of broadcast traffic), this presents a problem. The network is forced to flood multicast traffic to all clients that wish to receive it (broadcast traffic is also flooded to all clients). And each client that receives the traffic is forced to examine these packets to decide what to do with each packet. Even when the actual bit rate for multicast (and broadcast) traffic may miniscule relative to the University's network capacity, our experience is that when the packet rate of such traffic gets too large, individual network-attached devices must consume excessive resources handling these packets. Workstations may be become unresponsive; network infrastructure may stop responding to management requests. Any networks with constrained bandwidth (e.g. wireless) may perform poorly. Eventually workstations become unusable and the network becomes unmanageable. As a result, we must take care that multicast (and broadcast) traffic on the network does not grow unecessarily large.
As the number of devices on a single IP subnet grows, and as those devices make increasing use of LLMNR, the volume of LLMNR multicast traffic and the ARP broadcast traffic it triggers grows to a point that adversely affects network service for all devices on that network. This problem doesn't arise in the environment for which LLMNR was designed (a small network), since that environment doesn't have many devices; it is a problem if many devices attached to single network try to use LLMNR.
This in fact is the situation we find at Princeton University. Recent versions of Microsoft Windows include LLMNR capabilites in addition to normal DNS. They often have LLMNR turned on by default, to make these devices easy to "plug and play" in the small network environments where LLMNR was designed to function. When these devices are attached to the campus network, although they rely on DNS for nearly all services, they still have LLMNR enabled. This results in unecessary LLMNR multicast traffic and ARP broadcast traffic on significant portions of the campus network.
LLMNR is not a protocol OIT has ever recommended for use on campus, or has ever supported. While there are many OIT-supported uses of the campus network, none of them rely on LLMNR.
For several years years, LLMNR was just one of many kinds of traffic that OIT didn't explicitly support; we didn't need to restrict because it wasn't causing any harm. As the volume of LLMNR multicast and related ARP broadcast traffic on the campus network has grown, that's changed. By Fall 2010, the volume of this traffic on some parts of the campus network had grown to the point where it was degrading network performance. If the use of LLMNR is left unchecked, we expect that network service will degrade further.
OIT began filtering LLMNR multicast traffic in November 2010. We filter LLMNR multicast traffic because it degrades network service while at the same time is unnecessary for any of the network functionality OIT supports.
OIT filters LLMNR multicast traffic at the core of the campus network. It's installed in such a way as to apply only to those networks supporting wireless services provided by OIT. Specifically, any IP traffic destined to IPv4 multicast address 224.0.0.252 UDP port 5355 is discarded as it tries to cross the core of the network. Due to network topology, this usually means that the LLMNR traffic is blocked as it tries to enter or leave a campus building (because to do so it must cross the network core), but the traffic is not blocked within the building. We say usually because there may be some buildings that share a single connection to the campus core, and conversely some buildings that have more than one connection to the core; the extant to which LLMNR traffic can flow before it is blocked will vary depending on the topology. Also keep in mind that even within a single building, OIT Ethernet Service and OIT Wireless Service are on different IP subnets, so LLMNR has never worked between the two.
The filter is also applied at the edge of the wireless services provided by OIT, so it also applies to traffic sent by a wireless client as that traffic arrives at the wireless access point or the wireless controller. This filters the traffic before it would be flooded to other clients (wireless or wired), even if those clients are on the same leg of the network, or behind the same wireless access point.
We do not filter LLMNR unicast traffic, only the multicast traffic. However, with the LLMNR multicast traffic filtered, we expect to see little or no LLMNR unicast traffic, given the way the protocol works.
It is possible that in the future, the filter installed at the network core might be expanded to also include the wired (non-wireless networks).
Our filtering of LLMNR does not indicate that OIT disapproves of LLMNR, or that there is anything inherently wrong with LLMNR. We don't require customers to turn off LLMNR on their devices, or forbid the use of LLMNR. But we don't provide support for LLMNR or any functionality that relies upon LLMNR, and we filter it to limit its ability to degrade network performance.