网络测试必不可少，但有时候颇具挑战性;遇到软件缺陷和破损的设备是测试环境的一个再平常不过的方面。但要是没有软件缺陷，设备又没有破损，可是测试依然通不过，那又出现了什么情况呢?是测试本身有缺陷吗?应该怪罪于测试工程师?还是说问题出在其他别的方面，可能是较为隐蔽的方面?
奇怪和预料不到的测试问题一直会出现;而运行使用IPv6的测试网络的人士对这些问题绝不陌生。本文将逐一分析与IPv6测试有关的若干最常见问题，另外给出了可能适合的解决办法。
1. 硬件：它有没有链路?
当然，这是很明显的出发点，并不是IPv6所特有的，但它可能是追查起来最令人沮丧的问题之一，常常是由于你根本没有想到问题会出在线缆上。事实上，线缆会脱落，交换机会重启，有时候硬件会出现故障。所有这些问题都会导致硬件系统的最基础层面出现通信中断，因而给你的测试带来棘手的问题。说到交换，由于无线网络、虚拟化、甚至简单的虚拟局域网(VLAN)很普遍，硬件故障会变成看不见的问题，要识别起来甚至更加麻烦。
解决这个问题的最好办法就是使用一个稳定的、标记清楚、备份起来的测试网络。很少变化、了解得一清二楚的测试网络也许无法防止故障，但是问题果真出现时，可以大大简化辩明真相。
2. 防火墙：它们存在!
防火墙就像IPv6协议一样在不断完善，说到保护用户和软件远离危险，防火墙是绝对必不可少的部件。这意味着，认识到防火墙是如何部署的，以及它经配置后可以监控或阻止什么对象，这一点很重要。防火墙常常阻止尽管对协议测试验证而言很重要，但可能似乎是拒绝服务(DoS)攻击或另一种危险攻击的流量。过于谨慎的防火墙会让你想自己是不是果真接入了你认为应该接入的系统，害得你捕风捉影。
这里的解决办法很棘手。就测试而言，一台被禁用的防火墙有助于迅速缩小原因范围。说到部署，这无助于事;然后你得确保你的设备在互联网上会正常运行，可保护其用户。这方面可没有什么高招;需要做的最好办法就是，调查防火墙为什么阻止协议流量，寻求专家的帮助，确定这是异常阻止还是真正的安全漏洞。
3. 多宿主：这道门后面是……
多宿主(Multihoming)并不是IPv6的一个新概念，但说到测试和部署IPv6，这个概念会引起一大堆问题。这一方面归因于IPv6的自动配置越来越对用户友好――具体来说，是默认路由的自动配置。格式正确的ICMPv6路由器公告(RA)会引起设备安装通过传送路由器的默认路由(或“最后采取的路由”)。
不止一个路由器发送这样的数据包时，问题就会出现。你可能认为，两个路由器发送这种格式正确的数据包的可能性微乎其微，可是在测试网络中，路由器公告很容易溜出去、跑到生产环境上，或者是跑到不同的测试网络上，从而造成严重破坏。当然，只有你的设备拥有不止一个接口时――可是事实证明这种情况很常见，才会出现这个问题。手机(无疑和蜂窝)和笔记本电脑(无线和以太网)就是两种很常见的设备，它们通常至少有两个潜在的出站接口。
与硬件和防火墙问题一样，多宿主问题会导致流量似乎丢失或从来没有被发送。区别在于，它时而行，时而不行，似乎是间歇性的。这归因于计时器或生命周期的不同，让设备有一个“恢复”期间：它在这段期间似乎会正常运行。这个问题很容易识别，因为两个默认路由会清楚地显示在系统上。当然，解决这个问题可能有难度，因为现在你得查明谁是未授权路由器公告的发送者。或者，你可能要试一下防火墙。
4.地址：地址很大
地址有许许多多，而且地址很难输入。与IPv6地址这么简单的东西有关的测试问题比比皆是。这个问题会体现在把E误输成D或把3误输成6这么简单的事情。由于有那么多的数字需要输入，这个问题一直在发生。下面是一个典型的IPv6地址：