Present Location: News >> Blog >> AirPlay and mDNS

Blog

> AirPlay and mDNS
Posted by prox, from Charlotte, on May 27, 2012 at 23:57 local (server) time

If you keep up at all with Apple products and technology, you probably know what AirPlay is, even if you haven't used it.  Yes, it's one of those proprietary protocols developed by Apple that allows iOS devices and iTunes to stream audio and video to an AppleTV device.  Display mirroring is also available.

The problem with AirPlay is that it depends exclusively on multicast DNS (shortened as mDNS) with DNS service discovery (DNS-SD) to operate.  mDNS is a zero configuration protocol that relies on link-local multicast messages on the local LAN to publish DNS records without the need for a centralized DNS server.  DNS-SD is a protocol that compliments mDNS and provides service discovery, too.  Apple's implementation of mDNS/DNS-SD is called Bonjour.  When I say that AirPlay relies on mDNS/DNS-SD exclusively, I'm saying that there is no way of plugging in an IPv4 and IPv6 address of an AirPlay receiver - if mDNS doesn't work, you're screwed.

And where does mDNS not work?  Between subnets (LANs, L2 domains, whatever you want to call it).  mDNS uses an IPv4 multicast address of 224.0.0.251 and an IPv6 multicast of ff0X::fb, where X is the scope value (see draft-cheshire-dnsext-multicastdns-15 for details).  The IPv4 implementation of mDNS has no hope of getting outside of the current L2 domain even with multicast routing, PIM, and IGMP enabled everywhere.  Link-local means those packets cannot ever be routed.  The IPv6 implementation of mDNS, on the other hand, might be able to work between L2 domains if the scope value is set to 5 (site).  However, I haven't seen an implementation of mDNS on any Apple products that set the scope to anything but 2, which is link-local.

Back to AirPlay!  Fortunately, there are some different ways of getting around the above limitations of AirPlay and mDNS.  One is purchasing a Bonjour Gateway from a company called Aerohive Networks.  This product apparently processes local mDNS packets and unicasts them to other Bonjour gateways that regenerate the packets.  The result is that all mDNS-aware devices see devices in other L2 domains.  This seems like a nice solution since the L3 infrastructure doesn't need to be changed.  Aerohive indicates that these Bonjour gateways can also filter mDNS messages, which sounds somewhat useful.

If you've got a network with Linux boxes, another option is to just run the Avahi daemon on each Linux box and toggle reflection.  Avahi is a FOSS implementation of mDNS and DNS-SD.  It's really as simple as adding these two lines to /etc/avahi/avahi-daemon.conf:

[reflector]
enable-reflector=yes

This tells the Avahi daemon to regenerate mDNS messages on all interfaces.  Easy, right?  Well, this requires your network to actually run Linux-based routers.  My network at home does just that, and I had this up and running in about a minute!  I used Aerodrom on Windows 7 as an AirPlay receiver, since I don't own an AppleTV.

Unfortunately, most networks don't run Linux-based routers, but this same solution should work with the help of OpenVPN.  OpenVPN can be configured to establish an L2 tunnel between two Linux boxes using TAP interfaces, perfect for use with avahi-daemon.  Putting a Linux box on each L2 domain and connecting them with OpenVPN TAP interfaces should be all that's necessary.  The Avahi daemon will relay the mDNS messages between the Linux boxes thinking they share a L2 domain.

Obviously this use of avahi-daemon doesn't scale, but wouldn't it be interesting if router manufacturers added this type of functionality to the control plane of their devices?  On the other hand, wouldn't it be interesting if Apple used ff05::fb for IPv6 mDNS and provided users the option to plug in an IP address or FQDN instead of requiring the use of mDNS?

Comment by Michael [Website] on May 28, 2012 at 00:02 local (server) time

Nice post.

I've known about this issue for a while but had never looked into it. This looks like a good way to fix the problem. Thanks!

It would be really cool if you could do this in JunOS, hehe, like that will ever happen.

Comment by Mark Kamichoff [Website] on May 28, 2012 at 09:37 local (server) time

I'm wondering if something like this would be possible to achieve using the Junos SDK.  I've heard of some interesting applications that folks have created that I originally didn't think possible on a closed routing platform.


> Add Comment

New comments are currently disabled for this entry.