1 IPv6 and Multicast Filtering for High-Performance Multimedia Applications Thomas Pike * , Craig Russell † , Alex Krumm-Heller † , Vijay Sivaraman * * School of Electrical Engineering and Telecommunications, University of New South Wales, Australia † ICT Centre, CSIRO, Australia Abstract—It is widely acknowledged that the IPv4 address space will be close to exhaustion within the next few years, and the future growth of the Internet increasingly depends on the timely deployment and availability of IPv6. Both the Internet Corporation for Assigned Names and Numbers (ICANN) and the Australian Government have recently issued statements pushing for the adoption of IPv6. This paper reports on our experiences in migrating CSIRO’s multicast-based high-performance mul- timedia platform, currently used in medical conferencing and remote education applications, to IPv6. Application code changes, along with network equipment configuration, are discussed. Additionally, to optimise network bandwidth and end system resource usage, we implement and compare three multicast filtering techniques: at the application, in the OS kernel, and in the network via source specific multicast (SSM). We show that the integrated multicast support in IPv6 allows high-performance multimedia applications to be enhanced with minimum effort when migrating to IPv6. I. I NTRODUCTION Since the early 1990’s when IPv4 address exhaustion was first considered, there has been a concerted effort by the Internet industry to develop an alternative protocol with the goal of one day replacing IPv4 altogether so that address shortage would never again be a problem. As early as 1992 Huitema [1] describes writing a draft recommendation after leaving the Internet Society (ISOC) and Internet Architecture Board (IAB) conference in Kobe, Japan. To Huitema and others it was clear that a new version of the Internetworking Protocol was required, “[the] Internet was in great danger of running out of network numbers, routing tables were getting too large, and there was even a risk of running out of addresses altogether”. The new protocol, named IPv6, was published in 1995 as RFC 1883 [2] and refined in 1998 as RFC 2460 [3]. The major router vendors have supported IPv6 for several years and while initially much of this support was confined to software and not in the high speed hardware-based forwarding plane, our recent experience with Cisco Systems and Nortel Networks devices has been that IPv6 is fully supported in hardware with switching performance the equal of IPv4 ie. at multiple gigabits per second. Similarly, Miller [4] notes that most major computer hardware and software vendors; Apple, Hewlett-Packard, Hitachi, IBM, Linux, Microsoft, Novell and Sun support IPv6 to differing extents. The launch of Microsoft Windows Vista provides the first large scale implementation of an end user configurable IPv6 stack together with two IPv4 to IPv6 transition technologies (Teredo and 6to4 tunnelling). Technological developments have led to the increasingly widespread use of consumer devices that require Internet connectivity (PDAs, laptop computers, home entertainment systems, even refrigerators), and coupled with the rapidly expanding broadband networks being deployed by ISPs around the world the number of devices requiring IP addresses is increasing rapidly. Several analysts such as Hain [5] and Huston [6], [7] have attempted to estimate the date when the last IPv4 address blocks will be allocated by the Regional Internet Registries (RIRs) and current projections are that it will be sometime around 2010 or 2011 [8]. IPv6 is much more than an attempt to provide a protocol to overcome address shortage. IPv6 seeks to incorporate the wisdom of the last twenty five years of networking experience, drawing on the rich experimentation and innovation which has occurred. Worthy extensions to IPv4 have been merged into the core of IPv6 whilst obsolete components have been discarded. King et al. [9] identify five key areas which were considered during specification of IPv6: • Addressing and routing • Eliminating Special Cases • Minimizing Administrative Workload • Security • Mobility There is a discussion in [5], however, that suggests that the IPv4 address space will never in fact entirely deplete, rather that the end game for IPv4 should be considered to have occurred “at the point at which one needs to start designing networks and subnets, not in a way that is optimal from a network architecture or network management and growth standpoint, but in order to conserve address space”. The discussion continues to state that this point has already occurred, networks are no longer being designed in a manner that is optimal from an architectural sense, rather address conservation is key, witnessed through the introduction of tech- nologies such as NAT. In the light of these facts, it may seem strange to the network scientist or engineer that the transition to IPv6 hasn’t occurred sooner or more rapidly. Reasons for this are many and are equally due to economic and policy reasons as much as technical or engineering considerations. Huston [7] provides a substantial discussion of some of these issues. In July 2007 the Internet Corporation for Assigned Names and Numbers (ICANN) adopted a board resolution [10] to work with the RIRs and other stakeholders to promote the timely deployment of IPv6, while in the same month the 2007 Australasian Telecommunication Networks and Applications Conference December 2nd – 5th 2007, Christchurch, New Zealand 146