Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Why IPv6 Matters to Your Station

Broadcasters need to be aware of the implications of a looming revolution

The author is broadcast technical writer for Tieline Technology.

Since 1981, IPv4 has been the predominant Internet Protocol (IP) architecture and it is currently the foundation for most Internet communications.

On June 8, the Internet Society has declared June 8 ‘World IPv6 Day.’ Organizations like Google and Facebook will offer content over IPv6 for a 24-hour ‘test flight.’

However, the exponential growth of the Internet has created the need for many more IP addresses than IPv4 is capable of providing. As a result, IPv6 infrastructure is about to become a very hot topic, as it solves the Internet address shortage and delivers other benefits to broadcasters.

Internet address allocation is managed by the Internet Assigned Numbers Authority (IANA) and earlier this year they allocated the last remaining IPv4 addresses to Regional Internet Registration (RIRs) authorities around the world. These RIRs allocate addresses to Internet Service Providers (ISPs), who in turn allocate them to their customers.

Address exhaustion
The first RIRs have already started to run out of IPv4 addresses, and once they are totally exhausted, this finite resource officially will become a commodity that current owners will need to maintain and manage as IPv6 infrastructure becomes more prevalent. IPv6 will deliver many billions of new addresses; even though IPv4 essentially will be legacy technology, it will not be going away anytime soon.

While this is good news for IPv4-compatible devices, the bad news is that the IPv4 and IPv6 Internet infrastructures will not just work together seamlessly. Although they both use the same physical network, they are for all intents and purposes different Internets; an IPv4-only device will not talk to an IPv6-only device.

As for the question of how long support for IPv4 will remain, this is unknown and depends entirely upon how long it is commercially viable for suppliers and users to maintain both infrastructures. During the transition period it will be necessary for IP codecs and other IP devices to connect over both IPv4 and IPv6 infrastructure, or they will not be able to connect seamlessly across the entire Internet. This can be achieved with “dual stack” IPv4/v6 compatibility, whereby a device is able to connect to and use both IPv4 and IPv6 networks at the same time.

Benefits for broadcasters
IPv6 delivers simpler networking, enhanced security and almost unlimited numbers of IP addresses. These advantages eventually will revolutionize broadcasting over the Internet using IP.

From a networking perspective, the design of IPv6 infrastructure potentially allows all IP addresses to be public. How visible each node is to the Internet is at a network administrator’s discretion. This provides the ability to create end-to-end IP connections without the need for network address translation (NAT), whereas with IPv4, NAT is required to connect devices with private IP addresses on private local area networks (LANs) to other devices on public networks like the Internet.

IPv6 has in-built mobility provisions that will facilitate the expansion and support of “roaming” IP devices like audio codecs. This means it won’t matter where in the world a device goes, it can be contacted using the same global IP address. IPv6 will therefore make it extremely easy to establish codec connections and removes the need for NAT routing workarounds, which have often taken up significant IT administrator support time and costs within organizations.

IPv6 also has Quality of Service (QoS) support built into it. Whereas IPv4 generally delivers “best effort” IP packet delivery across networks, IPv6 has a traffic-class field within packet headers allowing users to prioritize data packets based on their importance. This has obvious benefits for broadcasters who rely on uninterrupted data flows to maintain continuity of audio and video.

Multicasting in IPv6 is performed differently compared to IPv4. In IPv4 specific multicast routers are required to send multicast IP packets over IP networks. In IPv6 the addressing scheme inherently caters for multicast packet routing at different levels — from local multicast links through to global.

This is facilitated by embedding rendezvous point addresses in an IPv6 multicast group address, which simplifies the deployment of inter-domain solutions. As a result, multicasting will become increasingly useful as a scalable, localized method of disseminating audio streams without the bandwidth restrictions of multiple-unicast transmissions.

From a security perspective, unique IPv6 addresses allow more finely tuned IP security without NAT traversal issues, as well as end-to-end authentication and identification of IP devices. Currently security features like firewalls generally are managed at the network level and we may see a greater focus on security at the node, or individual device level, as end-to-end IPv6 connections become more prevalent.

With IPv4 addresses nearing exhaustion and the world moving inexorably towards IPv6 becoming the dominant Internet infrastructure, IP audio codecs and other devices must adapt to operate in both IPv4 and IPv6 worlds. Over time, IP audio codecs in particular will require connectivity to a wide array of IPv6 endpoints. These endpoints will include local, national and international media contributors and syndicated stations.

Perhaps the biggest driver in the expansion of IPv6 infrastructure will be the proliferation of new wireless devices over the next few years and their use of IPv6 addresses. This will ensure IPv6 infrastructure spreads rapidly to support burgeoning numbers of new devices. Broadcasters will need to keep pace with these changes to support interconnections to both IPv4 and IPv6 hardware. Tieline Bridge-IT and the upcoming Genie STL and distribution codecs are the first to support both architectures.

Comment on this or any article. Write to [email protected].