Sometimes it's obvious when things are out of whack, like when an ISP is delivering bandwidth well below the service-level agreement and it's causing users to open "The Internet is slow" helpdesk tickets. But other times, especially when troubleshooting intermittent routing issues, our helpdesk tickets tell us something seems broken, but nonspecifically and in a manner that's a difficult to reproduce. IPv6 Internet endpoint reachability should be essentially identical to its IPv4 ancestor, but many admins supporting dual-stack endpoints have developed a generalized unease about it. As usual in IT, it turns out you're not paranoid: There is a problem with the IPv6 Internet and IPv4 to IPv6 conversion, and it's not just you.
IPv6: Hello world
Many companies are at least experimenting with IPv6, usually beginning with enabling externally facing websites. That's actually a great first project because it's small enough not to disrupt your business, but complex enough that you'll have to work through the issues of arranging for a dual-stacked Internet service provider (ISP) link, firewall, at least a router or two, VM host and server configs. Later on, when you're ready to pull IPv6 into your core, you'll have the experience for a smooth transition. Certainly, there are a number of bridge technologies like NAT64 and tunneling to carry packets over, under and around IPv4 nodes, but it's better to do it the right way with pure dual-stack the first time. Meantime, all the IPv6 foot-dragging allowed vendors and normal hardware refresh cycles to put almost everything we need to migrate to IPv6 in place, including experimental OS images.
So how do you effectively monitor, compare and report on IPv6 reachability in comparison to your always reliable IPv4 service?
So why then do we lose some sleep when we roll out the IPv6 welcome mat for a website? We can place application monitors on the server inside the IPv6 segment of the colocated DMZ so we know the server is up. We ping it periodically, and latency seems OK. Still, every now and then there's the odd helpdesk ticket that says the site is unreachable and research discovers the client is IPv6. Other times there's a subjective report that site performance is slower over IPv6 than IPv4. But hours later when we test everything, the site seems to be performing identically regardless of protocol. Eventually, we admit an unfortunate reality about the IPv6 Internet -- that despite all the hoopla surrounding World IPv6 Day, IPv6 peering between ISPs still has some dark spots where packets just can't pass. How then can you ensure your newly v6-enabled website is truly reachable?
It's OK to configure paranoid testing
With IPv4 there are enough users on endpoints exchanging packets with servers that virtually every possible Internet route is tested with regularity. When IPv4 peering does break down, somebody complains and it gets fixed. That's not the case with IPv6. Ignoring for a moment notorious peering feuds like Cogent vs. Hurricane Electric, there are simply not enough IPv6 users yet to effectively report all the broken routing when the Internet itself is suffering a peering issue. We can monitor internally all day but that won't identify common routing issues like flapping routes and Domain Name Server trouble at an ISP. So how do you effectively monitor, compare and report on IPv6 reachability in comparison to your always-reliable IPv4 service?
Continuous multipath monitoring can provide the answer
Fortunately, to get the heavy lifting required to track IPv6 performance, network engineers can steal some handy tools from their systems team counterparts. A great example is using a Web performance monitor for real-time comparative analysis. To use the monitor, create a recording of a basic Web transaction on your IPv4/6-enabled website over the IPv4 link. Load the captured recording into a test agent on your IPv4 network. Next, set up another test agent on a pure IPv6 host routed to the Internet via your dual-stack network. Ensure the routes are fairly closely matched in terms of hops and that your Web performance monitor server is centrally located and dual-stacked.
Let the test recordings run concurrently from both sites and you'll create historical graphs of IPv4 versus IPv6 reachability. You'll likely see some interesting phenomena like asymmetric performance between protocols, different routes to the same destination (especially for content delivery networks) and a surprising number of dropouts via v6.
About the author:
Patrick Hubbard is a head geek and senior technical product marketing manager at SolarWinds. With 20 years of technical expertise and IT customer perspective, his networking management experience includes work with campus, data center, storage networks, VoIP and virtualization, with a focus on application and service delivery in both Fortune 500 companies and startups in high tech, transportation, financial services and telecom industries. He can be reached at Patrick.Hubbard@solarwinds.com.
This was first published in July 2013