Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IPv6 Network Testing: Avoid The Top 5 Troubles: Page 2 of 3

3. Multihoming: And behind this door…
Multihoming is not a new concept with IPv6, but it is one that causes many more issues when it comes to testing and deploying IPv6. This is partly due to increased user-friendliness in the autoconfiguration of IPv6 -- specifically, the autoconfiguration of default routes. A correctly formed ICMPv6 router advertisement (RA) will cause a device to install a default route (or "route of last resort") through the transmitting router.

The problem occurs when more than one router is sending such a packet. You might think that the odds of two routers sending these well-formed packets is slim, but in a test network, it's all too easy for an RA to slip out onto a production network, or a different test network, wreaking havoc. Of course, this is only a problem if your device has more than a single interface -- which turns out to be very common! Phones (WiFi and cellular) and laptops (WiFi and Ethernet) are two very common devices that typically have a minimum of two potential egress interfaces.

Like hardware and firewall issues, a multihoming problem will make it seem as though traffic is being lost, or never sent. The difference here is that it will work -- or rather not work -- seemingly intermittently. This could be due to a difference in timers or lifetimes, allowing the device a "recovery" period, where it appears to operate correctly. This is an easy one to identify, as two default routes will be clearly present on the system. Of course, resolving it may be difficult, as you now have to track down the sender of the rogue RA. Or, you could try a firewall…

4. Addresses: They're big
And there are a lot of them, and they are hard to type. Testing issues related to something as simple as the IPv6 address abound. This can manifest itself in something as trivial as a mistype of an E for a D, or a 3 for a 6. With so many numbers to type, this happens all the time. Here's a typical IPv6 address:

FC00:41FF:3880:1FE0:5851:75f2:8867:de1b

The best solution here is to copy and paste always. Don't trust yourself to type an IPv6 address under any circumstances!

Other addressing issues are more advanced, and are actually designed to help, rather than hurt networks. But, like with so many other cases, test networks are dramatically different than production networks. Consider duplicate address detection, which is a strategy built into IPv6 for identifying addresses that have been duplicated on a network.

Duplication would be unlikely to happen on a fully autoconfigured network, even in production environments. But in test environments, where tools and devices are configured with the same or similar addresses to streamline testing and configuration, it's all too easy for two devices to end up with the same address. The resolution here is similar to identifying rogue RAs: A simple look at the interface should tell you if the address is duplicated. The hard part is tracking down the thief!

NEXT: Device memory