名称很有趣（IPv4 + IPv6 == IPv10），但实际的建议看起来很奇怪（还有一种分组格式可以解决分组格式之间的不兼容问题）。
是具有平衡利弊的正常建议，还是只是一个最低限度的可行文档，以取笑带有严肃面孔的“ IPv10”？一种“ tl; dr”的方式。为什么要使用这种转换技术而不是像nat64 / teredo这样的另一种转换技术？
#1 楼
正如罗恩所说，任何人都可以撰写提案。不过，我很难认真对待那些建议将卫星与光纤互连的人的建议。此外，我无法想象这个实际的建议会获得任何动力，尤其是由于以下原因：
所有Internet连接的主机都必须是IPv10主机，以便能够
进行通信，而不管使用的是哪个IP版本，并且IPv10部署过程可以由所有技术公司开发操作系统
用于主机网络和安全设备。
因此，要解决仅IPv4主机无法与仅IPv6主机进行通信的问题（反之亦然）您需要实现另一种协议：IPv10。然后，为什么要麻烦它，而不仅仅是在该仅IPv4的主机上实现IPv6并用它完成。可以用来解决部分问题。
老实说，我认为作者希望通过声明版权获得商业上的成功，如以下推文所示：
公告：保护版权，＃IPv10和KHALED路由协议（#KRP或#RRP）由@The_Road_Series CEO开发。未经开发人员@Eng_Khaled_Omar批准的任何组织
今天，2017年5月26日，第二个请求已发送到ietf，要求从其存储库中删除＃IPv10 #KRP（#RRP）草稿。
评论
很好，您知道他们在说什么-您可以用另一层抽象解决所有问题，但抽象层过多的问题除外！
–再见
17年9月9日在22:39
ROFL处的卫星通过光纤相连。听起来和IPoAC一样合理。
– reirab
17/09/10在6:41
他没有版权。他已经通过参与RFC流程为IETF分配了版权，无论它在文档文本中怎么说，这都不符合IETF政策。
–user207421
17/09/10在12:52
是时候重新训练我的大脑，使其不隐含地信任我以RFC格式阅读的任何内容。
–马特
17年9月10日在16:04
鸣叫链接使我成为一天（/周/月）
–失败的科学家
17年9月10日在16:13
#2 楼
您必须记住，任何人都可以向IETF提交提案，并且认真对待它们，直到由于缺乏兴趣而被采纳或死亡。几次。它似乎没有太多的支持，甚至没有建议的RFC状态，例如标准跟踪。作者可能对他的提案很认真，但他似乎并未对此提案获得任何认真的支持。小组支持，但要完全采用它还需要很长的路要走。它旨在解决从IPv4过渡到IPv6时固有的问题。#3 楼
“ IPv10”是个玩笑还是认真的RFC草案？我认为bloke是认真的，他没有得到他提议的荒谬计划。
纤维卫星提案更加荒唐，因为它忽略了所需的纤维长度，完全忽略了轨道力学。
IETF应该阻止他进行拖曳。 />
评论
另请参见en.wikipedia.org/wiki/Crank_(person）。
– Michael-sqlbot
17年9月11日在17:34
#4 楼
这是解决实际问题的认真尝试。无论该解决方案是好是坏（可能是垃圾），其问题陈述都是正确的：到目前为止，尝试实现IPv6的当前策略已失败。正如其介绍所言，IPv6已有19年的历史了，我们仍然没有办法看到自己以任何有意义的方式进行了过渡。它也提及其他人）。这些很好，而且很好，但是仍然不允许完全过渡到IPv6，因为它们假定仅保留公共IPv4主机在这里。那，我对此规范将如何提供帮助表示怀疑鉴于我所看到的是向IPv6过渡的根本问题。我花了很多时间试图理解它的工作方式，也许它比我聪明（尽管其他答案中的共识表明我是对的），但是它似乎遭受了与IPv6相同的引导问题。第一名。
回答问题，但这仍然是解决问题的认真尝试。
评论
多年来，一切都为IPv6做好了准备。实际采用速度似乎很慢，其原因仅是因为IPv4仍然“有效”。但是，IPv6流量约为20％，并且增长非常快。在2017年，不提供IPv6的互联网服务应该重新考虑其地位。我们现在真正不需要的是另一种过渡机制。
–ch7kor
17年9月12日在16:05
都没错但是我感到IPv6永远不会达到有意义的渗透率（前20％应该是最简单的渗透，后20％应该更困难），而且有一天人们会决定采取其他方法。旨在简化过渡的技术的意义在于，一旦它们存在足够长的时间，您就会意识到它们已成为新的互联网。
–胸骨
17年9月12日在23:23
实际上，有人可能会争辩说，最后20％是最简单的，因为当IPv6拥有80％的Internet流量时，提议将IPv4日落作为标准，大多数ISP将停止路由IPv4流量。从IPv6的诞生开始，这种情况将逆转，因此必须在（IPv6）Internet上通过隧道传输IPv4流量。
–罗恩·莫潘♦
17年9月13日在13:32
#5 楼
新协议的实现具有一定的有效性。当前的转换协议是NAT64。NAT64是一种IPv6转换机制，它通过使用一种形式的网络地址转换（NAT）来促进IPv6和IPv4主机之间的通信。 NAT64网关是IPv4和IPv6协议1之间的转换器，为此，它至少需要一个IPv4地址和一个包含32位地址空间的IPv6网段。
IPv6客户端将其希望嵌入的IPv4地址嵌入其中。与IPv6网段的主机部分进行通信，生成IPv4嵌入的IPv6地址（因此IPv6网段中的32位地址空间），并将数据包发送到结果地址。 NAT64网关在IPv6和IPv4地址之间创建映射，这些映射可以手动配置或自动确定。消除了NAT64。严格来说，NAT一直是瓶颈。
评论
最初访问该链接时，我希望看到“ 4月1日”。强制XKCD吗？
虽然提案可能是个玩笑，但名称却不是。 IPv4到IPv9已被保留（尽管仅使用了IPv4和IPv6）。 IPv10是下一个可用的未分配版本。
有趣的是，当32位ASN已经很常见时，作者建议将16位用于ASN字段。
RFC的传统很好，传统上在4月1日发布。 en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments是一个不错的起点。