无论您的组织是否部署了IPv6，在Internet上的其他节点转移到双协议连接时，您最终可能需要对与IPv6相关的问题进行故障排除。我们需要考虑的是，IPv6的引入将如何改变我们故障诊断网络的方式，现在我们是在一个双协议的世界中运行。本文将重点介绍在双协议网络上运行的双协议服务器上的双协议应用程序的故障排除。
随着IPv6开始被添加到环境中，我们已经使用了几十年的技术来诊断TCP/IP网络将需要适应。当我们将IPv6添加到网络中，我们将需要学习如何解决IPv6连接问题。当我们回顾早期的IPv4网络时，我们使用了与现在不同的故障排除技术。现在，IPv4网络已经经过了几十年的成熟，我们很少像上世纪90年代那样“指责网络”了。现在IPv6的部署是更新的，可以想象，我们将再次听到“这是网络的错”。
即使您的组织尚未部署IPv6，您也可能拥有拥有某种形式IPv6连接的终端用户、客户或业务合作伙伴。即使问题的错误可能不在您的网络中，您也可能是负责该服务的组织，并且您必须对这些启用了ipv6的网络进行故障排除。还可能引入端到端连接的其他复杂性大规模NAT (LSN)或NAT64 / DNS64沿着到远程端点的路径使用的部署。
既然我们有两个协议，可以在OSI模型的网络层使用，我们将需要测试它们中的每一个。Internet协议(IP)被称为TCP/IP协议沙漏的“窄腰”。沙漏的比喻来自这样一个事实:IP可以在许多层2协议上操作(以太网,购买力平价,POS,帧中继,光纤通道,IEEE 802.15.4,IEEE 1394,令牌环,FDDI,ARCnet和IP也可以支持许多不同类型的传输协议(TCP,UDP,SCTP,DCCP，等等)，甚至更多的应用。我们需要彻底地对网络和系统进行故障排除，以确保我们拥有端到端的IPv4和/或IPv6连接。
你可能看过这个喜剧故障诊断流程图。然而，为了成为一个有效的网络工程师，你必须有一个可靠的网络故障排除方法。当您正在故障排除网络时，一个常见的技术是基于OSI模型的层故障排除。有时您从物理层开始，然后从协议栈开始(但这可能很耗时)。有时，您可以从应用层开始，然后一直向下(当您对特定于应用程序的问题进行故障排除时适用)。其他时候，您可以从网络层开始，执行快速ping，然后根据结果决定向上或向下移动层。在双协议网络中，您需要执行两个ping，一个用于IPv4，一个用于IPv6。
开始故障排除过程的第一个地方是通信的端点。我们首先需要验证终端节点具有正确的IP地址，并在其本地网络上运行。我们需要验证每个系统都有IPv4和/或IPv6地址，以及正确的DNS解析器。IP地址可以是静态配置的(数据中心中的服务器的常见做法)，也可以是动态配置的(访问网络上的最终用户的常见做法)。在IPv4网络中，我们将对DHCP进行故障排除。然而，在启用ipv6的网络中，我们需要能够排除无状态地址自动配置(SLAAC)的故障，并调查来自本地第一跳路由器的ICMPv6路由器广告(RA)消息。基于RA消息中包含的信息，终端节点可以使用SLAAC、无状态DHCPv6(路由器提供DNS前缀和解析器信息)或有状态DHCPv6。我们还必须知道，WindowsXP和Mac OS X不使用DHCPv6，但他们可以使用SLAAC，然后在本地配置他们的DNS服务器。另一种选择是使用点播器(一个开源的DHCPv6客户端/服务器/中继)。
现在我们已经验证了节点有它的IP地址，我们需要验证主机可以ping它的默认路由器，并且ping到第一个跳之外。通常情况下，默认路由器可以同时拥有一个可聚合的全局单播地址和一个链路本地地址。我们的主机可以配置来自RA消息的链路本地地址。我们可以使用以下链接本地地址进行ping，这取决于您的操作系统。当我们ping一个链路本地地址时，我们必须指定要用来发送这个ICMPv6回送请求包的接口。
eth0 fe80::1 ping fe80::1%12 ping fe80::1%GigabitEthernet0/0
我们要解决的下一层问题涉及到将人类可识别的完全合格域名映射到IP地址的应用程序。我们将需要验证IP连接到DNS解析器和故障排除DNS查找。我们可以使用nslookup、dig和host命令来验证对A和AAAA记录以及PTR记录的DNS查询。我们需要知道哪些DNS服务器可能只与ipv4通信，或者是双协议的。我们还需要记住，WindowsXP、Windows Server2003和Mac OS X仅在IPv4传输上执行DNS查找。它也可能是有用的Wireshark或tcpdump以查看DNS查找包。我们将希望看到客户端如何发送单独的A和AAAA查询并执行后续操作RFC 4074。
大多数双协议操作系统将对IPv4和IPv6记录执行DNS查询，如果可能的话，将倾向于使用IPv6进行连接。但是，旧版本的Mac OS X使用第一个返回的DNS响应来建立连接。如果A记录响应首先返回，那么连接将在IPv4上发生，但是如果AAAA记录响应首先返回，那么连接将在IPv6上发生。此外,各种web浏览器而其他应用程序可能不会通过IPv6进行连接，即使节点具有双协议能力并且在一个活跃的双协议网络上。
我们的故障诊断方法的下一步是确保与IPv4和IPv6的双向端到端连接。这意味着我们希望在两个方向上执行ping和traceroute。我们需要在两个方向做这些测试，看看是否有不对称的通信路径。我们还必须知道路径中可能存在的任何IPv6-in-IPv4隧道。在传输路径上可能存在手动配置的隧道、动态配置的隧道(ISATAP、6to4、Teredo)或转换(NAT-PT、NAT64/DNS64)，这些隧道可能会影响端到端连接。隧道可能会增加通信的延迟和性能。我们还可以使用pathping(例如pathping -6 2001:DB8:0DD:BA11::1)或JPerf验证端到端性能。
故障诊断的下一个阶段将重点关注尚未测试的特定于ipv6的问题。支持ipv6的节点遵循默认地址选择过程(RFC 3484)。如果操作系统中的前缀策略有问题，它可能会导致神秘的行为。这可能会影响源地址选择或目标地址选择。在微软系统上，我们可以使用“netsh interface ipv6 show prefixpolicies”命令来查看策略表。在BSD系统上，我们可以使用ip6addrctl命令，在Solaris系统上，我们可以使用ipaddrsel命令来查看策略表。
我们需要测试的另一件事是邻居发现协议(NDP)。这是IPv6相当于IPv4的ARP。由于IPv6不使用广播，NDP ICMPv6消息使用多播来将第2层地址(MAC地址)映射到IPv6地址。我们可以使用ping来验证与LAN上其他节点的IPv6连接，然后检查邻居缓存(比如IPv4 ARP缓存)。在Windows主机上，我们可以使用命令“netsh interface ipv6显示邻居”。在Linux系统上，我们可以使用“ip邻居show”命令。在BSD系统上，命令是“ndp -a”，在Solaris系统上，命令“netstat -p -f inet6”将显示它的邻居缓存。在思科路由器和瞻博路由器上，命令都是“显示ipv6邻居”。
在双协议网络上可能遇到的另一个问题是最大传输单元(MTU)大小降低了的链路。如果IPv6数据包遇到了隧道，并且隧道开销减少了MTU大小，就会发生这种情况。如果IPv6数据包被放置在IPv4协议41数据包的6in4隧道内，那么MTU大小将减少20个字节(IPv4报头大小)。因为IPv6路由器不执行碎片，它是必需的，路由器放下IPv6数据包和发送回一个ICMPv6数据包-太大的消息，表明首选的MTU大小。然后，支持ipv6的源必须执行路径MTU发现(PMTUD)，然后将数据包分段到适当的大小。使用具有不同包大小的ping可以显示沿流量路径是否有MTU大小的减少。您可以执行一个“ping -l 1500 2001:DB8:DEAD:C0DE::1”，然后验证ICMPv6数据包响应太大与嵌入的理想数据包大小。
一旦我们用两种协议验证了可靠的端到端连接，那么最后要测试的事情之一就是端到端应用程序协议通信。可以想象，节点之间存在有状态的防火墙，阻止某种类型的通信。为了测试这一点，我们可能需要生成一些合成流量，并验证它是否能够在两个终端节点之间运行。我们可以使用一个工具netcat6使用特定端口号在节点之间创建模拟流量。我们还可以使用telnet或SSH(顺便说一句，我最喜欢的SSH客户机是SecureCRT)。我们可以表演NMAP从源扫描目标主机。我们还可以使用支持ipv6的web浏览器通过IPv6或IPv4地址浏览。
当我们开始遇到更多启用ipv6的系统时，我们将需要改进故障排除技能，以弥补这种增加的复杂性。尽管双堆栈是首选的过渡技术，它不是万灵药。没有人声称生活在一个双重协议的世界是容易的。在系统需要同时使用IPv4和IPv6语言的漫长时期中，我们需要成为双语用户，并且能够熟练地对两种协议进行故障排除。
斯科特