IPv6 multicast background traffic (Part 5) – Microsoft’s Multicast IPv6 Service Discovery Protocols

By /

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article of this series we discussed the general ideas behind zero configuration networking and the two major enterprises zero config frameworks, Windows Rally and Apple Bonjour. We noted that zero config has three legs (automatic IP address assignment, device or service naming and service discovery) and went over LLMNR, Microsoft’s solution for naming. This article covers how Microsoft does service discovery over IPv6 multicast.

UPnP, SSDP, WS-Discovery and ff02::c

The link-local address ff02::c is defined in the IANA multicast address spec as belonging to the UPnP Forum. UPnP is an older, though still widely-used, framework that is based on the Simple Services Discovery Protocol (SSDP). It’s called “Simple” because it uses UDP packets that contain info about just a single service. SSDP is used by many consumer and home appliance-style devices as well as printers and various Windows services.

WS-Discovery is a newer protocol that employs a web-services approach. It is largely targeted at enterprise environments and because the SOAP and XML libraries it relies upon are fairly heavyweight, WS-Discovery tends to be restricted to devices that have a good deal of memory and computing power.

Both discovery protocols use the same link-local IPv6 multicast rendezvous address, ff02::c.

SSDP

Let’s take a look at some common Windows applications that use SSDP.

Windows Media Player (WMP) is UPnP-enabled – when launched, WMP both advertises its services to anyone listening on the local LAN (though we discuss Windows Firewall restrictions elsewhere in this series) as well as searching out multimedia libraries that others may be offering. Here is Microsoft’s Network Monitor showing details of two SSDP NOTIFY (service advertisement) packets:


Figure 1

In this first packet, note the NT (Notification Type) “MediaRenderer:1.” Without going too deeply into the architecture of UPnP (a formidable undertaking), MediaRenderer is one of a variety of Device Control Protocols that have been standardized by the UPnP Forum. While this article series focuses on the enterprise IT environment, as discussed in a previous post the UPnP Forum and DLNA trade associations arose in the consumer electronics sector but have “bled” over into IT. Using the UPnP jargon, the packet above is designed to advertise the MediaRenderer’s services to any UPnP Control Point listening in on multicast.

As we’ll see later, instead of SOAP Apple’s Bonjour takes a different tack, using DNS to advertise SRV and TXT records listing the services supported by a given device or application. The UPnP approach is “heavy” in that each Device Control Protocol takes months or years to standardize but is also therefore extremely thorough. Apple’s approach is lighter-weight, more of a true directory service for connecting interested parties and then assuming that once the parties are connected, higher-level protocols will be negotiated (such as printing, iTunes sharing, etc.). Both approaches are valid but UPnP is restricted to industry heavy-hitters whereas Apple’s approach can be used by anyone.


Figure 2

Both of the packets above contain a Location where the advertised service can be contacted – any PC listening on the ff02::c multicast address is now aware that WMP is offering some kind of service on the local LAN, where to reach it, and all without the benefit of any central directory service. If you copy the Location URL into a web browser, you’ll see the XML that tells you (or rather, tells another machine – XML doesn’t exactly make for light bedtime reading) what services this device offers:


Figure 3

A disadvantage of SSDP is that it’s quite chatty. Many devices and applications provide numerous services, which are often advertised in separate packets. You can see this in the WMP example’s two distinct NT (Notification Type) offerings in the two packets.

WMP also acts as an UPnP Control Point and seeks out other media services on the local LAN with an “M-SEARCH” SSDP packet to ff02::c:


Figure 4

When you close WMP, it notifies any multicast listeners that it has withdrawn its services. As noted previously, SSDP is very chatty and here it’s sending a “byebye” packet for each separate service. The next figure shows a sign-off packet for the RenderingControl service that we saw in one of the earlier NOTIFY packets:


Figure 5

Besides user-launched applications such as WMP, various Windows background services utilize IPv6 multicast. The Windows Media Player Network Sharing Service and Media Extender Service both generate SSDP M-SEARCH requests to locate other multimedia offerings on the local subnet.


Figure 6

WS-Discovery

This more modern discovery protocol, the basis for Microsoft’s Device Profile for Web Services standard, uses SOAP Web Services XML-based messages advertised via multicast. One service that utilizes WS-Discovery is the HomeGroup Provider:


Figure 7

HomeGroups are a peer-to-peer feature built into Windows 7 to allow non-domain PCs on a local LAN to share data. There are some basic security features – if you take home a domain-joined laptop, for example, you can join a HomeGroup in, well, your home, but supposedly Windows will only allow you to browse local resources, not share anything from your own laptop and inadvertently expose sensitive data. HomeGroup sharing is configured via the Control Panel:


Figure 8

When started, the HomeGroup Provider service sends several WS-Discovery packets to ff02::c, for example, this Hello message:


Figure 9

Numerous other services and devices utilize WS-Discovery. While at the moment you may not see much need for RFID on a typical corporate LAN, these chips are beginning to show up everywhere and the use of multicast discovery to locate them is a natural fit.

This concludes our look at Microsoft’s IPv6 multicast P2P technologies. In the next part of this series, we’ll move on to Apple’s Bonjour framework.

If you would like to read the other parts in this article series please go to:

About The Author

Jeremy spent over 15 years in the enterprise systems engineering trenches. He resurfaced as CTO of a startup focused on the legal sector. In his spare time he ponders the intersection of technology and society.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top