Author Profile - Chris Greer is a Senior Network Analyst for Network Protocol Specialists, a Seattle based Network Consulting company. Chris has 10 years of experience in analyzing and troubleshooting networks. He regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. When he isn’t hunting down problems at the packet level, he can be found teaching various analysis workshops at Interop and other industry trade shows. Chris also delivers Fluke Networks public courses and protocol analysis themed webcasts. He can be contacted at chris (at) nps-llc (dot) com.
IPv6 Protocol Stacks: When do they cause problems?
Several operating systems now have IPv6 enabled out of the box.
Why should we be aware of these?
We all know that the IPv6 protocol has been coming for some time. In many environments however, it is already here, whether we know it or not. While some companies are practically using the IPv6 protocol for client-server communication or for other services, most are not yet utilizing this new stack in production. Even in these environments, the pre-installed IPv6 stack may be present by default in some operating systems such as Windows Vista and Mac OS X. The myth is that this protocol just silently operates in the background having no affect on applications unless we ask it to.
This assumption is wrong.
Time and again we see the IPv6 stack operating under the hood, having a silent affect on applications. One area we have seen this is in DNS calls for application servers. Depending on the application and specific stack in use, the client may make DNS calls over IPv4 requesting the IPv6 address of application servers. We see this in the screenshot below. The client is sending calls to the DNS server, requesting the AAAA (or IPv6) address for cnn.com.
The client sends this request 5 times, with no response from the DNS server. After the final request, the client sends a request for the A record, or IPv4 address. The AAAA requests wasted a total of 15 seconds in the users application experience. By disabling this stack, we no longer saw these requests. The client went immediately to the IPv4 A record lookup, and the application fired up immediately.
We are seeing these situations more and more as operating systems have the IPv6 stack pre-loaded. So as a rule of thumb, if you are not using the stack in production, disable it. It can always be re-enabled when you need it later.