*我有以下情况：*
Bob希望直接与Alice交互（encryption交互，没有中介服务器将转发他的数据包）。 两者都在NAT后面。 Alice有一个公共ipv6地址和一个ipv4地址（在非对称NAT之后）。 Bob有ipv4端口转发的ipv4地址，但是Alice没有端口转发她的ipv4stream量。 Bob知道Alice的ipv6地址和她当前的ipv4地址，Alice知道Bob的公共ipv4地址。 Bob想直接与Alice发起networking通信，但Alice的私有ipv4地址在NAT后面不可访问。 Bob必须尝试从他的ipv4地址到达Alice的ipv6地址。 鲍勃怎样才能到爱丽丝？ 是6to4的解决scheme？
*背景资料：*
Alice和Bob都在运行点对点的应用程序（我正在开发）。 这个点对点应用程序在启动时试图打开Alice和Bob的ipv4端口。 uPnP（通用即插即用）端口开放库在Bob的路由器上使用其ipv4因特网工作，但不在具有双ipv4 / ipv6因特网的Alice路由器上工作。 这就是为什么鲍勃有他的ipv4端口打开时，他运行的应用程序，但爱丽丝没有。 假设STUN和TURN不可用–Bob想要启动与Alice的直接连接，而不使用中间服务器（STUN或其他）来促进连接。 Bob会怎么做呢（假设Alice和Bob都在NAT后面，而且他们的NAT都不是对称的NAT）？
*大清晰*
鲍勃不是从字面上从ipv6地址发送ipv6数据包。 爱丽丝的互联网既有ipv4也有ipv6（爱丽丝可以到达ipv6启用/就绪的网站，比如谷歌，她可以到达只提供ipv4的网站）。 因此，如果Alice向Googleinput“我的ip是什么”，她会得到一个ipv6地址（尝试它）。 但如果她去http://checkip.amazonaws.com （也尝试这个 – 它不是ipv6启用），她只会得到她的ipv4地址。 我想知道Bob是否有可能用ipv4数据包（ipv6 over ipv4或6to4）将ipv6数据包打包发送给Alice，作为NAT穿越的一种手段。
*“无中间人”是什么意思？ *
我的意思是没有TURN转发或任何其他forms的转发，其中中间服务器接收到发往Alice的数据包的副本，并将该副本转发给Alice。
*如果Alice有一个ipv4地址，而Bob和Alice知道彼此的ipv4地址，为什么Bob不把他的ipv4地址的数据包发送到Alice的ipv4地址？ *
鲍勃有端口转发，爱丽丝没有端口转发。 即使Alice正在等待私人端口30000上的连接，当Bob从他的ipv4地址的公共端口30000发送一个数据包到Alice的公共端口30000她的ipv4地址时，Alice的NAT也不会让Bob的数据包通过。
没有中间人的要求可以用不同的方式来解释。 而正在使用的确切解释确实有所作为，因为某些解释将与其他要求相结合，导致一组不可要求的要求。
考虑到ISP为每个端点提供互联网连接作为不可靠的第三方显然太严格，不允许通信。 但是，即使我们将路由器包含在我们可以依赖的基础架构中的端点之间的IPv4path中，但由于其他要求，它仍然是不可能的：
如果我们解释无中间人的要求，只是说大部分stream量不能通过第三方路由，但是让第三方参与连接设置是可以接受的，那么这是可能的。
Bob可以在公共IPv4地址上向第三方发送数据包，要求将消息发送给Alice的IPv6地址，请求Alice通过IPv4连接回Bob。 在任何旨在成为未来certificate的新协议devise中，我只会使用端点之间的IPv4连接作为隧道传输IPv6数据包的一种手段，然后让所有较高层仅处理IPv6。
哪个IPv6隧道协议可能是合适的
让我们考虑以下选项让Bob获得可用于批量传输的IPv6地址：6to4,6rd，6in4，native，Teredo，home种植。
鲍勃的ISP缺乏支持立即排除了第六和本地。
除非在Alice和Bob之间的直接path上的ISP之一提供了Bob可以使用的6in4，否则不要求第三方排除6in4。 这样的服务不太可能存在于直接path上，如果这样做需要在Bob方面进行更多的configuration，那么我认为你会愿意的。
没有第三方的要求也意味着6to4和Teredo是潜在的问题。
使用协议41的任何事情都很难通过NAT。 即使你能通过NAT工作，在大多数情况下也只能支持NAT后面的一个用户。 鉴于Alice甚至无法获得端口转发，我们几乎可以排除使用协议41端到端。 因此可以将6in4和6to4作为可能的端到端通信。
根据协议41设置任何内容都需要pipe理员权限。 这是对6in4，6rd和6to4的另一个论据。 基于UDP的隧道可以直接构build到应用程序中，因为UDP端口可以由非特权应用程序打开。
在Bob身边使用6to4和Alice的本地IPv6意味着必须使用中继。 由于我认为爱丽丝不能发送协议41数据包，爱丽丝将不得不依靠别人操作的继电器。 幸运的是，Alice的ISP有一个中继，但是你不能依赖这个。 因为Bob的ISP根本不支持IPv6，所以在另一个方向上并不好，他们也不可能有任何中继。 所以在这种情况下6to4很可能在两个方向都有问题。 这排除了6to4。
我们从起始名单中剩下的是Teredo或本土的。 如果Bob使用Teredo，他的第一个数据包将被发送到Bobselect的Teredo服务器。 由于Bob可以select使用哪个Teredo服务器，因此使用第三方将不是什么问题。 如果第三方原来是不可靠的，鲍勃可以简单地切换到另一个。
但是这只包含了Bob到Alice的第一个数据包。 返回path有点问题。 如果您仅仅依靠默认路由，那么来自Alice的返回stream量将转到由Alice的ISP运营的Teredo中继，或者更有可能是第三方中继。 如果Alice的ISP已经部署了足够的Teredo中继来处理客户的stream量，并且他们正在关注中继的稳定性，那么Teredo在这种情况下是可靠的。 然而，这样的ISP是罕见的。
爱丽丝可以决定运行自己的接力。 但是，Teredo客户端（在Bob的计算机上运行）和Teredo中继（在Alice的计算机上运行）之间的连接通常是从客户端到中继站。 那是不适合你的方向。
在Teredo中有一个被弃用的操作模式，其中连接可以从中继到客户端的另一个方向打开。
这意味着您可以将Teredo客户端直接构build到您的软件中，并在您所描述的特定设置中使用Bob的计算机上的此弃用模式。 在爱丽丝的一端，你的软件运行在一个本地的IPv6地址上，但是同时你的软件必须使用这种不赞成使用的Teredo模式来检测对等端，并且当检测到直接发送数据包到对等端时使用Teredo中继直接构build到你的软件中。
需要注意的一个问题是，当Bob的第一个回应请求通过Teredo服务器发送给Alice时，它将由Alice计算机上的操作系统中的IPv6堆栈处理，而不是由您的应用程序处理。 这意味着将通过Teredo中继构build的应答路由到您的软件中将会非常棘手。
如果采取这种方法，我强烈build议您编写软件来支持通过Teredo代码或普通路由来发送数据包。 并定期探测两种发送数据包的方式，以便始终使用两者中最可靠的方法。
有点讽刺的是，在我能想到的所有标准协议中，适合您的要求的最好scheme恰好是Teredo的一个已弃用的变体。 考虑到Teredo通常被认为是不可靠的，更是如此。 也就是说，我真的相信，在你描述的确切情况下，它可以做出可靠的工作。
一个可能的本土解决scheme
您可以在您的应用程序中select使用RFC 4193地址空间的/ 80前缀，并使用IPv6地址的最后16位来embedded隧道端点的IPv4地址和端口号。
用这种方法，Bob将有一个Alice可以发送数据包的IPv6地址。 这种方法存在的问题是，在达到来自Alice的第一个IPv6数据包之前，Bob将没有办法发送IPv6数据包给Alice。
也是本地的，没有公共服务器可以将Bob的数据包转发给Alice。 因此，这种特殊的自主开发方法就像Teredo，只是基础设施不足的问题会被放大。
基于此，我认为如果您想要采用自主开发的解决scheme，那么以Teredo为起点并尝试改进它，而不是从头开始构build本地解决scheme，您将更有可能获得良好的结果。
如果没有中间人，你所要求的是不可能的。 如果双方都有IPv6，则只能使用IPv6，如果没有端口转发，则无法接受NAT后面的传入连接。