Category Archives: IPv6

Where Does the World Stand with IPv6

After IPv6 Day on June 6, Akamai, a Web high-performance company, released statistics to see how IPv6 Day publicity affected the overall use of this protocol. This blog details the findings, and highlights that the adoption increased by 460 times since 2011’s World IPv6 Day. However the percentage adoption rate for this 14 year-old protocol is still fairly low and surprisingly low in different Asian countries, particularly India and South Korea.

Google continually collects statistics about IPv6 connectivity among Google users. You can view it by overall conversation rate and by country. IPv6 usage by end users is a lot lower by percent in Asia than in Europe and the U.S., a finding which is correlated by a recent humorous article by RIPE Labs (the European regional IP registrar) comparing IPv6 adoption to the results of the 2012 London Olympic Games.

Initially, one of the major assumptions about IPv6 was that conversion to this protocol would be incredibly aggressive in Asian and South Pacific countries due to the scarcity of new IPv4 addresses in this region, but this does not seem to be the case. Why?

Why is IPv6 Lagging in Asia?
There are several speculations as to why IPv6 conversion seems to be stagnant in Asia. Ellyne Phneah of ZDnet provided some insight into why certain regions in Asia may be lagging, including end-users satisfaction and comfort level with the existing Internet protocol – convincing users to make the move might be a challenge – as well as service providers not including IPv6, and general lack of commercial availability for IPv6.

Several countries are making more of a push for IPv6 as Phneah notes in her piece, including Malaysia and Singapore, whose governments have been notable in their commitment to enable IPv6 in their internal networks. Additionally China and Japan are also embracing IPv6.

Why is the World Lagging in General for the Transfer?
In the U.S, while IPv6 is being rolled out by several major broadband providers such as AT&T, Comcast, and Time Warner Cable, there is still little apparent demand. As with Asia, lack of interest among enterprise customers leads to little or no incentive for carriers to make the switch, which cascades into limited availability for other customers.

Remember, IPv4 touches every level of the Internet, from Tier 1 carriers down to individual desktops, which means a lot of effort is required by different organizations and vendors from network monitoring and management, mobile network operators, consumer routers, etc. to overcome the inertia of IPv4 and move the world to IPv6.

Fortunately, most end-user computers are ready for the switch. Windows, Linux, and OSX have good IPv6 support as soon as the networks are ready. While that support keeps improving (Microsoft Windows 8 will have a stronger preference for IPv6 than previous versions)  we still have a long way to go.

Who is Making the Switch to IPv6?
While the percentage numbers may look bad, the data behind those numbers is more promising. By using the graphing tool from RIPE Labs on IPv6 network announcements, it’s clear that APNIC – the Asia-Pacific region – is leading the globe in terms of percent of IPv6-ready networks at 18%, versus 11% in ARIN, the North American region. However, the raw numbers show that APNIC is announcing 954 IPv6 networks, which is smaller than ARIN’s 1687.

Similarly, while China and South Korea appear to be lagging in terms of end-user adoption, the APNIC Labs project to measure end-user adoption shows that they are nearly tied for first place in terms of total number of IPv6 users measured over the last 3 months, at over 550,000 users each, nearly double the third-place Thailand at 300,000 users. (The U.S. had just under 200,000).

All IPv6 numbers have risen over time, which is expected, especially since RIPE hit exhaustion on September 14, less than 2 weeks ago. ARIN also implemented phase 2 of their exhaustion plan on September 18, after they reached only 3 /8 blocks remaining.

How Can You Bring IPv6 into Your Office or Home?
The first factor is cost. The cost of an IPv4 address has risen, and with IPv6 being the “future” of Internet, there is an incentive to progress as opposed to regress into older technology.

As we’ve indicated before, even if the end of IPv4 is not immediately upon us, it is inevitable and as with any technology it is always better to prepare your network for testing before it’s too late. If you have not upgraded, due to an equipment vendor or another tool you are using, demand that they add or create a product that is IPv6 compatible.

If it is more a means of trying to combat some of the issues that come up, and they do come up, check out how you can solve common IPv6 problems in this blog.

Common Deployment Pains with IPv6: How to Identify and Fix Them

Yesterday was World IPv6 Launch day. Last year saw World IPv6 Day, the single largest test of IPv6 interconnectivity, in which several major Internet sites enabled IPv6 as a 1-day test. For this year’s event, the participating companies have turned on IPv6 and plan to keep it on – some participants, like Google and Facebook, never turned it off the first time! Last year was merely a precursor to this year’s event in hopes that it would entice Internet service providers, home hardware makers, operating system vendors, and web companies to start preparing their services for IPv6 in order to ensure a successful transition from IPv4 for everybody.

It is a fact that the world is running out of new IPv4 addresses – in fact, Asia has already run out – meaning the time to incorporate IPv6 is quickly approaching. And rightfully so! IPv6 is already a proven protocol and provides several cool advancements that we discussed in a little more detail in IPv6: Is It Finally Time. In fact, IPv6 was widely used even as far back as the 2008 Olympic Games.

For this blog, we are going to take a deeper dive into the transition to IPv6 and help provide you with the common problems that might arise while deploying this protocol and how to fix them.

The largest historical problem with IPv6 has been just getting connectivity. Until recently, there were few ISPs who provided IPv6, especially to residential users. One of the major goals of World IPv6 Launch was to bring IPv6 as an option to a larger audience via ISP and home router support. While the Internet Society acknowledges that it’s unlikely for IPv6 demand to be widespread – their target number is 1% of consumers – the goal is to make sure it’s available as an option for anyone who wants to use it.

After ensuring that access is available, the next problem is how to configure IPv6 access with respect to IPv4. Should you use one of the tunneling mechanisms, or one of the NAT transition methods? The short answer is neither! Given that IPv6 does not interfere with “classic” IPv4, it only adds complication to bind the two together artificially. Given the historical scarcity of IPv6 support, connectivity for most users did require using a tunnel broker, but native IPv6 support from ISPs means that the best answer is to run “Dual Stack,” using both IPv4 and IPv6 at the same time.

Before bringing up IPv6 connectivity, don’t forget the basics of Internet information hygiene: use a firewall! Most modern equipment should have at least a basic level of support for IPv6 traffic security policies. The good news is that, given that IPv6 does not require (nor should it support) NAT, the security policy should be straightforward to configure.

IPv6 addresses look different than IPv4, so it’s easy to get confused about what addressing best practices should be. It’s tempting to use Stateless Address Auto-Configuration (SLAAC) to reduce configuration overhead, but that creates technical debt in a network. SLAAC uses the MAC address of an interface as a GUID to reduce the chance of duplicate addresses. Aside from privacy issues in including a hardware-specific identifier in a globally routable address, SLAAC adds unnecessary length to an IPv6 address. Greater manageability comes from re-applying the IPAM lessons of DHCP. Whereas a SLAAC address would have a format like 2001:db8::7ee9:d3ff:ffe46:86bb, a DHCP address for the same machine could be 2001:db8::1c. While DHCPv6 may take a little more time to deploy, it will make daily administration much simpler.

MTU, fragmentation, and ICMP
The first “unexpected” problem with IPv6 will likely come from bad habits learned with IPv4 regarding MTU, fragmentation, and ICMP. In IPv4, oversized packets are split into fragments by routers along the path. In IPv6, routers will simply return an ICMPv6 error message for oversized packets – it is the job of the sending node to handle its own fragmentation. Why would a node choose to fragment unreliably at layer 3 when it can rely on TCP at layer 4? If a programmer didn’t query the OS for path MTU, and instead relied on the Ethernet MTU of 1500 bytes, minus 20 bytes for IPv4 and 20 bytes for TCP, that leaves 1460 bytes for TCP data in each datagram. However, the IPv6 header is at least 40 bytes – resulting in 20 fewer bytes in the same Ethernet MTU. While most common network applications, such as web browsers, have been by now extensively tested with IPv6, there may be legacy applications that were not coded with dynamic values from the network stack, which will cause oversized packets. Those oversize notifications will be delivered via ICMPv6. However, aggressive security practices in IPv4 have sometimes recommended blocking ICMP messages other than ping. Therefore, increased header size in IPv6, plus lack of router fragmentation, may couple with overzealously blocked ICMPv6 to create packets that don’t reach their destination and don’t allow delivery of diagnostic error messages. The problem may be especially hard to find if the local LAN switches allow jumbo Ethernet frames, which specifically allow otherwise oversized frames – the packets will flow on local subnets between L2 and L3 switches, but will be dropped by Internet routers.

HTTP Compliance
The final transition problem with IPv6 will be a subtle one. HTTP is simple from a protocol perspective, but it hides layers of complexity, because the vast majority of web pages include tags to tell the browser to load additional content, potentially from a different server. Web pages on IPv6-hosted servers will likely load content from IPv4-hosted servers for quite some time. During the initial transition, web pages may load slowly if non-IPv6-compliant DNS servers ignore requests for AAAA IPv6 records, causing the user’s PC to time out and try the IPv4 A record. Given that this problem would exist on the server side – which may be literally on the far side of the Internet – the problem may persist until the server maintainer upgrades to a modern version of DNS and/or their web service infrastructure. Fortunately, this problem has been recognized in various formats since at least 2005 (see RFC 4074). The DNS lookup method – AAAA or A – is controlled by the browser itself, and this problem is being actively addressed. APNIC Labs did research in late 2011 that shows Internet Explorer 9 has a 21-second timeout, but Google Chrome uses a method that reduces the delay to 0.3 seconds – and recent Firefox versions are even faster. Additionally, there may be filtering and processing solutions using a local DNS server which will perform the lookup recursion for the end node, resolving the problem through a combination of resolution caching and forced protocol fallback. The paradox of the Internet is that HTTP drove the mass adoption which is leading to IPv4 exhaustion, but HTTP may be the last major protocol to be fully IPv6 compliant.

The good thing is that most of your users really won’t notice anything different when using IPv6. IPv6 is supported by all major PC operating systems and all major Internet client applications like Web browsers. While there may be some smaller issues, such as the aforementioned content on IPv6 pages referencing IPv4 sites, the majority of the web will not cause any problems for IPv6.

For legacy applications and users such as developers who need to use numbered IPv4 addresses, there is still nothing to fear. IPv6 is a new protocol: rather than a patch which replaces or changes IPv4, IPv6 will run in parallel, so legacy applications should continue to function unless and until the company eventually decides to turn off IPv4, possibly several decades from now.

IPv6 is here and it is best to come to the party prepared. For an easy transition it is important to have a solid grasp of the tools that will help clear the way for this new protocol as well as what to look for if issues do occur.

Top Features in OmniPeek Network Analyzer 6.8

It’s that time again. Spring is in the air and with the changing seasons comes the newest version of our flagship product, the OmniPeek network analyzer—now available in version 6.8! We’ve included some great additions to OmniPeek, making it even better equipped to help network engineers quickly analyze and troubleshoot enterprise network issues.

We announced the release last week at Interop Las Vegas and we are looking forward to hearing lots of user feedback!

Below are some of the top additions that we think are pretty cool.

IPv6 Analysis
With the ever-changing nature of enterprise networks comes the need for constant adaptability. The next major change is the addition of IPv6 to current IPv4 networks.  For enhanced monitoring of a dual stack environment, OmniPeek Expert analysis provides automated inspection of all OSI layers simultaneously for an active diagnosis of traffic regardless of network layer, IPv4 or IPv6.

The Expert analysis can detect misconfigurations and anomalies within IPv6, just as it has with IPv4, alerting network engineers to issues quickly in order to maintain service levels through all stages of the IPv6 deployment, reducing the time and cost of transition.

As a bonus, OmniPeek 6.8 also provides analysis of VoIP and video over IPv6, for sites and providers migrating to next-generation transport.

Timeline View
As company networks become ever more distributed and the level and type of network traffic increases, it is important to give network engineers visibility into all of the current network information from one easy-to-use interface, to determine when and where it is necessary to perform more in-depth analysis. For this reason, OmniPeek now includes the Timeline dashboard, which provides the most complete set of real-time statistics, quick data rewinding, and rapid search and forensic analysis of collected data.

Capturing traffic 24×7 saves time and allows you to view all of your historical network traffic to quickly drill down and fix performance bottlenecks across multiple network segments. Trying to reproduce the problem without a detailed history to refer to can use up valuable time and still leaves room for missed events and incomplete data to diagnose the issue.

Packet De-Duplication
Nobody likes to do the same thing over and over, and OmniPeek 6.8 helps to make network engineers lives easier by performing real-time packet de-duplication for aggregated packet capture. Removing duplicate packets from the analyzer data makes the capture files much smaller and less cluttered when performing troubleshooting.

In addition, advanced aggregating techniques, such as multi-channel Wi-Fi analysis, or differential packet analysis to view packet changes in network transit, are still supported when using packet de-duplication. OmniPeek filters out only exact duplicates, still allowing an analyst to measure the information-rich Wi-Fi retransmissions rate or differential packet changes.

Additional updates include:

For more information on OmniPeek 6.8, click here.