Creative solutions for testing MLDv2

Timothy Winters -April 03, 2013

The IPv6 Consortium of the University of New Hampshire InterOperability Lab (UNH-IOL) has tested multicast routing protocols between routers for the last ten years. As Senior Manager of IP Technologies at the UNH-IOL, one of my current projects is launching our Multicast Listener Discovery version 2 (MLDv2) Interoperability testing services. The purpose of this test plan is to make sure interactions between listener and router are understood and properly documented. These tests will be used for future requirements within the USGv6 Test Program.

Development of this test specification began with the creation of a test network consisting of both a listener and router, with a typical Linux server as the multicast IPv6 listener, and a standard commercial router.  A problem encountered was that the Linux kernel does not come with a standard application, for example ping or traceroute, that allows the operating system to join an IPv6 multicast group.   However, this did not slow the development down.

An advantage of having undergraduate computer science students working at the UNH-IOL is that they are eager to take on such projects.  The students created an application that enabled the OS to join and leave multicast groups, including source-specific multicast groups.  This allowed a robust investigation for validating the test specification, however this problem limits test ability for commercial solutions that do not have such applications.

Figure 1 CS Student working with MLDv2

As the development continued, we examined several hosts in the interoperability test bed which revealed extremely limited support for a multicast application that allowed joining of multicast groups.  Applications for operating systems, like the one we created, are not practical solutions for several IPv6 devices, such as printers, load balancers, firewalls and tape drives. It would be unrealistic to require that every implementation create an application to support joining multicast groups. Thus we raised the question, what methodology would allow testing the function without needing an application?

Taking a step back and thinking about our IPv6 basic functionality testing can answer this. Remember that it is required that IPv6 implementations support MLD and that every node must join the solicited node multicast group for neighbor discovery and duplicate address detection. Thus, this requirement will give us a method for joining and leaving multicast groups. Furthermore, IPv6 nodes have the ability to have addresses assigned by DHCPv6 clients or manually configured through router advertisements. When an IPv6 address becomes invalid or is removed, the node must leave the multicast group.   This methodology of creating addresses to join different multicast groups enabled the execution of all the source-specific MLDv2 test cases without having to create a custom application.

Alternatively, if an IPv6 host wanted to demonstrate source-specific multicast, it would be required to give us an interface to allow listeners to join the multicast group.  This is a reasonable requirement, since most IPv6 nodes utilizing source-specific multicast are designed for an application anyway. For the USGv6 Test Program, we were able to show interoperability for all the non-source-specific test cases using the addressing as the catalyst for multicast group membership. This will allow IPv6 nodes to run the testing without additional requirements. Oh, the joys of testing MLDv2!

Related Articles
Test challenges for the connected home: IPv6 and TR 09
IPv6 stresses network testing

About the Author
Timothy Winters is a Senior Manager, IP Technologies at the University of New Hampshire InterOperability Laboratory (UNH-IOL).  He works with companies from all over the world to develop broad-based, flexible testing strategies to cost effectively meet network interoperability requirements for the Internet Protocol version 6 (IPv6), Session Initiation Protocol (SIP), routing, and IP Multimedia Subsystem (IMS) communities.

Timothy is the United States Government IPv6 (USGv6) and IPv6 Ready Logo technical lead for the UNH-IOL.  In this role, he oversees various aspects in testing of IPv6 technology, deals with various multi-vendor IPv6 testing scenarios and acts as a liaison between students and vendors during device testing and development.

His ongoing collaboration with standards bodies and industry forums including the Internet Engineering Task Force (IETF), IPv6 Forum and IPv6 Ready Logo Committee demonstrates his dedication and persistence in developing new standards, as well as assisting commercial services providers, network equipment vendors and government agencies cost effectively speed go-to-market time for products.

Loading comments...

Write a Comment

To comment please Log In