IPv6 的口号喊了这么多年, 一直没有什么声响, 大家都没有改造的意愿, 因为从眼前看 IPv6 就是一个费钱费力又得不到更多好处的事情, IPv4 地址是不够用, 但也有一些延缓的变通技术.
2018 年以来, 国内掀起了 IPv6 网络改造的热潮, 从运营商到互联网, 从企业到个人, 都要将 IPv6 的网络改造付诸于行动, 不少企业都立了军令状, 必须要在 2018 年完成 IPv6 网络初步改造, 让 IPv6 跑起来.
不过, IPv6 的口号喊了这么多年, 一直没有什么声响, 大家都没有改造的意愿, 因为从眼前看 IPv6 就是一个费钱费力又得不到更多好处的事情, IPv4 地址是不够用, 但也有一些延缓的变通技术.
5G, 物联网兴起来后, 对 IPv6 的需求迫切了, IPv4 再怎么节省也无法满足物联网的未来部署, 这推动着所有的网络运营商必须要进行 IPv6 改造. 改造意愿是一方面, 技术部署也存在不少阻力, IPv4 网络运行多年, 各种网络联接和应用盘根错节, 极其复杂, 这时再将 IPv6 纳入进来, 网络就更复杂了, 部署 IPv6 面临着很多现实问题.
首先, 就是转发表项容量的问题
网络设备转发芯片为实现简单, 基本都是采用 IPv4 和 IPv6 公用转发表的方式, 一条 IPv6 占用两条 IPv4 表项或者四条 IPv4 表项. IPv4 存量网络规模太大, 不可能用 IPv6 将 IPv4 一下子替掉, 就需要让两者在一个网络中, 甚至一台设备上共存, IPv6 要占用原有 IPv4 资源, IPv4 和 IPv6 共存, IPv6 要占用更多的资源, 会使得 IP 转发表资源急剧下降.
网络在设计之初, 虽然 IPv6 作为网络设备的基本功能都要求支持, 但对容量并没有明确要求, 实际部署时 IPv6 功能也是摆设, 没有实际用, 现在真要用了, 就要认真考虑容量问题了. 比如: 设备若 IPv4 转发表是 16K, 则只能支持 IPv6 转发表是 8K, 如果是两者公用, 那么应该是 IPv4+2*IPv6=16K. 实际应用时可用转发表项数量会更少, 这是因为 IPv4 和 IPv6 的 IP 地址长度并不相同, IPv6 是 IPv4 的四倍, 有 128 个 BIT, 长度差异导致两者向同一个 IP 转发表下发时, 极其容易出现 HASH 冲突, 从而下不去, 报资源不足. 实际应用中, 这种情况实际可用的容量也就达到原来的一半, 16K 的资源, 总共也就下发 8K 左右, 即 IPv4+2*IPv6=8K, 之后出现 HASH 冲突的概率大大增加了. 显然, 若是现网中设备的 IPv4 表项已经使用的比较多, 就不能再启用 IPv6 了, 转发表资源会快速下降, 出现不足.
其次, 是 IPv4 与 IPv6 互通问题
部署 IPv6 不能将原来的 IPv4 网络推倒重建, IPv6 部署是循序渐进的过程, 这就要求技术上处理好旧的 IPv4 网络与新的 IPv6 网络兼容性, 尤其是两者互通问题, 有的网络终端是 IPv4 的, 网络接入是 IPv4 的, 核心部署是 IPv6 的, 也有的网络终端是 IPv6 的, 网络部分又是 IPv4 的, 这就要解决互通问题. 以我们最熟悉的 QQ 为例, 如果 IPv4 和 IPv6 用户不能互相通信将是非常糟糕的情况.
显然, 大家已经为此设计了一些互通技术: 双栈, 隧道和地址转换三种. 双栈技术本身不解决网络互联互通, 只是要求所有主机都支持两种 IP 协议, 这样对用户而言就是互通了, 通过主机上的协议切换从而与两个网络的用户实现互通, 但这样无法做到无缝切换, 要同时与 IPv4,IPv6 网络都要实时互通技术上就存在困难, 只能将主机的网卡来回切换, 分别与两个网络实现互通.
隧道技术可以解决双向互通, 但还是需要强大的隧道服务器, 隧道的带宽是一定限制, 另外隧道其实是通过双层 IP 头实现的, 这样增加了报文的长度, 增加了占用带宽, 浪费掉了部分带宽资源. 地址转换技术方面曾经有一个标准草案 NAT-PT, 但已被 IETF 放弃了. 另外还有法国运营商 Comcast 提出的 DS-Lite, 国内 CERNET2 团队提出的 IVI, 这些方案都是将隧道和地址转换结合起来, 可能更适合实现过渡的目的, 但这些都大大增加了网络开销, 对网络带宽是个考验. 显然, 这些互连互通技术还不能让人满意, 只能作为过渡技术临时被采用.
第三, 是两张网运维的问题
在两张不同的网络上, 虚拟机如何迁移, 迁移过程中的运维管理问题也需要考虑. 我们面临着要同时运维 IPv6 和 IPv4 两张网络, 运维工作量是原来的两倍还不止, IPv6 的技术特点和 IPv4 并不是简单的地址加长, 在协议处理, 安全保护, 状态计算等方面都有差异, 所以运维的知识还要补充和学习, 甚至要引入一些 IPv6 的技术专才, 这些都给运维的工作和资金带来压力.
同时, 两张网还不是隔离的, 在同一台设备上都要共存, 还要考虑兼容问题, 相同的命令看 IPv4 转发表是一个结果, 看 IPv6 又是一个结果, 将两者放在一起看又可能是另外的结果, 如何分析, 都需要积累经验. 原来运维的工具, 显然要将 IPv6 网路部分也要纳入, 但很多时候这些信息并不能分开统计与分析, 比如端口流量, 无法区分是 IPv4 流量还是 IPv6 流量, 流量图上看出是哪部分流量, 出了问题自然也看不出是 IPv4 流量出了问题, 还是 IPv6 流量出了问题, 只能通过其它方面的表现来确定. 在运维可视化, 自动化工具方面都要考虑 IPv6 部分, 尤其是两种网络共存的情况, 如何显示, 哪个内容分开现实, 哪些内容又要汇总在一起来显示, 这里都还不能用技术来解决.
当然还远不止这几个方面的问题, IPv6 没有广播, 只有组播, 要占用不少的组播转发表项, 设备能否满足, IPv6 地址长, 设备 ACL 匹配能力是否够, 匹配到 IPv6 地址比较深入的内容等等, 这些都是 IPv6 在实际网络部署时面临的现实问题. IPv6 的部署刻不容缓, 很多网络已经陆续上了 IPv6, 但真正能有 IPv6 流量跑起来的又有几个网络呢, 这些摆在大家面前的现实问题若不能一一很好的解决, IPv6 就算是已在所有设备上都启用了, 那 IPv6 也不过是一种摆设, 空载跑跑而已, 很难形成气候, IPv6 真正替换 IPv4 网络还有很长的路要走.
来源: http://network.51cto.com/art/201810/585951.htm