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