How will the migration from IPv4 to IPv6 impact visual communication?

All information in the Internet and in private intranets is carried in packets. The packet format was defined in the 1980s and described in the Internet Protocol specification (also referred to as IPv4, IETF RFC 791, http://www.ietf.org/rfc/rfc0791.txt?number=791). When IPv4 was designed no one really expected that the Internet would become so pervasive and using 32 bits to address network elements seemed reasonable. The maximum size of the IP packet was set to 65535 bytes which was more than enough for any application at the time. Since the organizations initially using Internet trusted each other, security was not important requirement for IPv4, and the protocol itself did not provide any security mechanisms.

In the 1990s, the rapid growth of the Internet led to the first discussions about the design limitations of the IPv4 protocol. The industry was mostly concerned about the small address space and the discussion lead to the definition of a new packet protocol (IPv6, IETF RFC 1883 and later RFC 2460, http://www.ietf.org/rfc/rfc2460.txt?number=2460) that uses 128-bit addresses. However, changing the underlying networking protocol means high cost to service providers and they did not rush into implementing IPv6. Instead, service providers used Network Address Translation (NAT) and later double-NAT as workarounds to overcome the address space shortage. NATs directly impact real-time communication – including visual communication – because they hide the real IP address of the destination and video system on the Internet cannot just call a video system behind the corporate NAT. Business-to-business calls must go through multiple NATs, and this frequently leads to call failures. Another fundamental problem with NATs is that they change the IP address field in the IP packet and this leads to incorrect checksums and encryption failures, i.e., NATs break end-to-end security in IP networks.

So why has the migration to IPv6 become such a hot topic over the last few months? I wrote about the discussions at the 74th IETF meeting http://videonetworker.blogspot.com/2009/04/summary-of-74th-ietf-meeting-in-san.html, and there were additional discussions, presentations and panels about the urgent need to migrate to IPv6 at the FutureNet conference http://www.futurenetexpo.com/attend/conf_at_a_glance.html.

While corporate networks can continue to use IPv4 address and NATs for decades, service providers do need unique IP addresses for the home routers, laptops and other mobile devices their customers are using. The pool of available IPv4 addresses is being depleted very fast, and according to Internet Assigned Numbers Authority (IANA), the last full block of IP addresses will be assigned in about 2.5 years, i.e. in end 2011. The address shortage is bad in Europe and very bad in Asia where China is adding something like 80 million Internet users a year. It is human psychology to ignore things that are far in the future but 2011 is so close and so real that everyone started panicking, and looking at IPv6 as the savior of the Internet.

Although the migration to IPv6 is driven by the address shortage, IPv6 brings many new functions that will have impact on real-time applications such as voice and video over IP. Since there will be enough IPv6 addresses for everyone and everything, NATs can be completely removed, and real-time applications would work much better on the Internet. Some organizations believe that NATs’ ability to hide IP addresses of internal IP servers and devices provide security, and they push for having NATs in IPv6 networks. Security experts have repeatedly stated that NATs do not improve security because a hacker can scan the small IPv4 subnets– they usually have just 255 IP addresses each – within seconds, even if they are behind a NAT. Scanning IPv6 subnets in comparison is futile because these subnets are so large that it would take years to find something in the subnet. Removing NATs would allow end-to-end security protocols such as IPSEC to efficiently secure the communication in IP networks.

Quality of Service (QoS) mechanisms developed for IPv4 can be further used with IPv6. The new header structure in IPv6 allows faster header parsing which leads to faster packet forwarding in routers. The impact on real-time communication is positive: voice and video packets will move faster through the IP network.

The new packet structure in IPv6 allows for larger packets with jumbo payload between 65535 and 4 billion bytes. This would allow sending more video information in a single packet, instead of splitting it in multiple packets. This should benefit visual communications, especially as video quality increases and video packets get larger. The way IPv6 handles packets leads to another security improvement. Many security problems in IPv4 are related to packet fragmentation, which happens if a packet has to be sent through a slower link. The router splits the packet in multiple fragments and sends them as separate IP packets. The receiver must recognize the fragmentation, collect all pieces, and put the original packet together. IPv6 does not allow packet fragmentation by intermediaries/routers which now must drop too large packets and send ICMPv6 Packet Too Big message to the sender/source. The source then reduces the packet size so that it can go across the network in one piece.

Note that just supporting the new IPv6 headers in networking equipment is only a part of supporting IPv6. Several other protocols have been enhanced to support IPv6:
- Internet Control Message Protocol (ICMP) v6 (RFC 4443, http://www.ietf.org/rfc/rfc4443.txt?number=4443) and the additional SEcure Neighbor Discovery (SEND, RFC 3971, http://www.ietf.org/rfc/rfc3971.txt?number=3971)
- Dynamic Host Configuration Protocol (DHCP) for IPv6 (RFC 3315, http://www.ietf.org/rfc/rfc3315.txt?number=3315)
- Domain Name System (DNS) for IPv6 (RFC 4472, http://www.ietf.org/rfc/rfc4472.txt)
- Open Shortest Path First (OSPF) routing protocol for IPv6 (RFC 5340, http://www.ietf.org/rfc/rfc5340.txt?number=5340)
- Mobility Support in IPv6 (RFC 3775, http://www.ietf.org/rfc/rfc3775.txt?number=3775)