如果我的地址 10.3.3.2 ，将其映射到v6将导致0：0：0：0：0：ffff：a03：302。 我可以ping 10.3.3.2但ping 0：0：0：0：0：ffff：a03：302给出“无路由到主机”错误。现在，我无法从我的网络中ping任何IPv6地址，因此错误是预期的。
我很好奇 ping6 0：0：0：0：0：ffff：a03：302
如果IPv6流量完美无缺。
答案 0 :(得分：3)
您要做的事情称为 NAT64 ，并在RFC-6146中说明。
你必须做更多的事情才能发挥作用。
首先，映射的地址必须以64:ff9b::（它是保留的前缀，特别是NAT64）而不是0:0:0:0:0:ffff:开头（这个旧的前缀，最初出现在1995年末，在RFC-1884内） ，不用于IPv6到IPv4网关 - 例如，它用于映射网络软件存储的地址，但不希望通过IPv6网络连接到IPv4主机时。）
因此，将10.3.3.2映射到ipv6会产生64:ff9b::a03:302
但在现实世界中，没有人必须做这样一个奇怪的映射，你只需要对IP地址为10.3.3.2的主机名发出DNS请求到符合DNS64的解析器（这样的DNS解析器被调用） DNS64解析器，如RFC-6147中所述。谷歌提供了这个（以及其他）：2001:4860:4860::6464，免费供所有人使用。因此，您只需配置DNS解析程序即可请求此Google主机（不要忘记删除任何其他解析程序）。
请注意，Google公共DNS64解析程序不支持私有IPv4地址。因此，在您的示例中，我们需要通过公共地址替换10.3.3.2。所以，我选择1.3.3.2，这是一个公共地址。
为了进行测试，我创建了以下DNS记录：tstaupreti.fenyo.fr，映射到1.3.3.2。
然后使用dig，您可以轻松查看其工作原理：
% dig @8.8.8.8 tstaupreti.fenyo.fr. a +short
1.3.3.2
%
2-现在，您可以检查没有与主机名关联的IPv6地址：
% dig @8.8.8.8 tstaupreti.fenyo.fr. aaaa +short
%
3-所以，让我们看看Google DNS64解析器会发生什么：
% dig @2001:4860:4860::6464 tstaupreti.fenyo.fr. a +short
1.3.3.2
%
这是正常的，因为我们已经请求了IPv4地址，而DNS64解析器当然是符合IPv4的。
4-但现在，让我们看看DNS64解析器正在为您计算映射：
% dig @2001:4860:4860::6464 tstaupreti.fenyo.fr. aaaa +short
64:ff9b::103:302
%
正如您所看到的，NAT64 Google解析器没有看到任何与tstaupreti.fenyo.fr相关联的IPv6地址，所以它试图查看IPv4地址是否与此主机名相关联，它找到了1.3.3.2，所以，将其转换为NAT64 IPv6格式： 64:ff9b::103:302
但是，当使用IPv6 ping tstaupreti.fenyo.fr时，这还不足以获得icmp回复。
这是因为您还需要访问 NAT64 IPv6到IPv4网关，并将64:ff9b::/96的IPv6数据包路由到此NAT64网关。这样，无论DNS64映射返回什么值，您的ICMP请求（ping）都将转到NAT64网关。此网关将您的数据包从IPv6转换为IPv4（或多或少像标准的NAT IPv4网关 - 请参阅RFC以获取更多详细信息，有细微的变化）。
不幸的是，NAT64将64:ff9b::/96定义为您无法在Internet上路由的保留前缀（这是因为在提供NAT64网关的每个专用网络上，此地址是相同的，如10.xxx，这通常是因此，在专用网络上路由，出于同样的原因，它不能在因特网上路由）。因此，没有公共NAT64网关使用NAT64前缀64:ff9b::/96（您可以使用另一个前缀，并将其路由到配置了这个不常见前缀的NAT64网关，但这是另一个故事）。某些Internet服务提供商将此类地址路由到专用于其客户的专用NAT64网关。如果您的ISP不这样做，您需要自己在私有IPv6网络上安装这样的网关。为此，您可以将Tayga用于Linux。
因此，在完成最后一步（例如安装Tayga）后，您将收到ping请求的ICMP回复。将ping数据包发送到Internet上任何仅支持IPv4的服务器时，它将起作用。