闲谈IPv6-现状和过渡

1.现状

2011年2月3日这天IPv4地址已经分配完毕，接下来就等着各大运营商耗尽自己的储蓄了，人们越来越多的依赖于TP-Link那种有线无线路由器。如果人们再不去考虑IPv4向IPv6的过渡，互联网真的要爆炸了，在这个人们越来越不关心底层的年代，大家都把注意力放在了应用层，随着互联网和云技术的发展，应用将会呈现爆炸式增长，直到压得底层协议喘不过气，终于坍塌。
        《新发现》2009年3月的杂志有一期专门来讲互联网的崩溃，这绝不是危言耸听。IPv4早已落后于时代：
a.缺乏安全性使互联网只是一个草根网络，难入大雅之堂，很多机要组织很难使用互联网，高危作业也不能信赖互联网；
b.缺乏流量识别机制，RFC的建议成了一纸空文，各大路由器厂商军阀混战，使得音视频等流量很难保证质量，三网合一不了了之；
c.额外的小技巧越来越多，互联网补丁越发混乱，然而没有一个补丁能从根本上解决问题，大家都没有达成共识，因此大家的小手段又各异；
d.流量增大使得互联网设备负载增加，各种IP报头字段的处理以及被捧上天的X层交换使接入层到核心层的路由器不堪重负，而实际上IPv4报头根本就不适合做多层交换，为了高效，IP选项基本被认为是非法的。
e.IPv4地址空间的耗尽其实只是所有问题中最不值得一提的，毕竟它在NAT技术之下已经足够稳定，充其量是限制了P2P，即便如此，我们不还是整天在NAT后使用电驴吗？

2.过渡

主机以及路由器技术：
如今基本主流的OS都支持IPv4/IPv6双协议栈，因此也就可以为主机同时配置IPv4地址和IPv6地址。隧道技术几乎是使IPv6流量通过IPv4网络的唯一技术，OS的双栈实现使封装IPv6的隧道很容易构建。主流的隧道有两类：
a.ISATAP技术：IPv6终端经常使用的技术，可以让IPv6终端直接使用IPv6而不必在意自己实际上是被部署在一个IPv4网络内。需要ISATAP路由器的支持。
b.6to4技术：IPv6中间节点使用的技术，可以让一侧的IPv6流量通过另一侧的IPv4网络到达远端的另一个6to4路由器。
隧道技术的原理如下：

以上这两种技术实现方式基本一样，不同的是，ISATAP隧道是为客户终端设计的，它初始化时包含了链路本地地址，接下来可以基于这个链路本地地址自动化的配置全球地址而不需要人工干预，而6to4隧道则是规定了一个全球地址前缀，它一般用于中间路由器。
        简单的讲，不管是哪一种隧道技术，都是将IPv4网络当成了自己一种链路层。IPv6流量在IPv4上传输时，它们并不处在同一个层次上。两种技术可以结合在一起使用，这样物理上就不需要一条IPv6的链路了。
        其实，所谓的过渡很简单，终端使用IPv6，在互联网上寻找一个6to4路由器之类的设备，然后将本身到该路由器的IPv4网络当成一个链路层就可以了，再说IPv6基本上都不需要人工干预，完全支持自动配置。那么问题在哪里呢？问题根本就不在网络技术方面，而是在应用的支持以及人的想法方面。
DNS方面的因素：
除了底层基础设施的过渡技术之外，还有DNS的因素，那就是少用IP地址直接用域名，由DNS决定返回的是IPv4地址还是IPv6地址，逐渐的将IPv6的分量增大。DNS的助力作用其实很大，这也大大减轻了用户终端直接处理IPv6地址的工作量。

3.问题

应用开发方面：软件厂商谁也不想去为IPv6做先行者，因为利润空间有限，甚至根本就看不到。只要软件巨头不主推IPv6，小型软件企业对IPv6的支持一般都是不管不问。如今软件从开发到使用已经成了一个生态系统了，谁也不想去改变它。然而各软件巨头们如今好像都把大量的心血投入在了云服务和用户体验上了，大家都在某一个点-能让用户怦然心动的点上拼得你死我活，对网络好像是有意的遗忘或者放弃，深信自己的舞台是钢混结构，而其实它却是镂空的。
        如果在弥补了底层缺陷之后，再去打造一系列战场，我想这场绝杀才更过瘾，我们谁都不想在角斗场看角斗士们厮杀的时候，看台塌了，我们就全完了，《斯巴达克斯 第二季》中真的有这一幕！各大家都在比谁家的平板电脑更好，谁家的虚拟化更实用...其实不需要做别的，各大家在厮打之前先说句话，事情就解决了，具体的事情根本就不需要他们去做。
人的想法方面：人对新的东西一般都是不在乎，不管它被宣传得多么好，只要现在老的东西还没有问题，那就尽量不去想新的东西。即使是政策上强制要求支持IPv6，下面的人也只是能应付的就应付，除了对技术深感兴趣的具体研发人员之外，管理层基本都是做最少的工作来应付对政策执行程度的审核。不光中国是这样，全世界都一样。你会发现，从古至今，几乎所有的事情都是自发产生的，所谓的瞬间大的变动只是最后一击，如果没有前面很长时间的自发形成的祭奠，任何大的变动都不会发生。这也许就是万有惰性原则吧。

4.不留遗憾

NAT问题：
针对目标的NAT往往可以起到对内部服务器保护的作用，去掉NAT后，这种保护作用就没有了。有没有什么替代方案呢？其实这种保护的粒度很粗，只能控制到协议，控制不到应用数据，充其量也就是防止恶意扫描，防洪泛攻击之类的。这些本是防火墙的工作。真正的保护应该特定于应用，比如WEB有WEB的保护方式，邮件有邮件的方式。对于WEB应用，更好的方式是使用反向代理。反向代理不光能保护内部内容服务器，还能对内容做缓存从而提高效率。因此可以毫不心痛的丢弃DNAT。